Hi,

On Thu, 2008-01-24 at 18:06 +0000, William Skaggs wrote:

* Construct an optional MDI version of the gui.

That is definitely not a goal. We are not willing nor able to maintain optional user interfaces. The UI has to evolve and it will be highly customizable, but we are not going to offer an optional WiW user interface.

* Allow libgimp or something like it to be linked with the core, and implement actions and tool operations by means of it, so that it will be possible to record and play macros.

We haven't talked about this and it sounds like a terrible description. Being able to record and play macros has nothing to do with linking anything with the core. Actually, I don't think that we need to put action recording on our list as that will become obsolete with non-destructive editing. And that's the actual goal.

* Make it so that sequences of transformations on a layer do not cause a steady buildup of error. (Yes, this is possible, because any sequence of affine transformations can be reduced to a single affine transformation.)

That is part of the GEGL transition and doesn't need to be mentioned explicitly.

Sven

Hi,

On Thu, 2008-01-24 at 11:48 +0300, Alexandre Prokoudine wrote:

Well, there _had been_ a beta version of the list (to which several people including myself contributed) and since then nothing has happened, so I was wondering if you still liked that idea ;-)

I did not like any of the beta versions as they were all way too specific and didn't really bring along a vision. And there wasn't any feedback from other developers. My impression is that no developer really wants this list. So I consider this attempt failed.
Perhaps if we could first decide what the purpose of the roadmap/task list should be. I tried to raise that question when we started with this topic. But no one ever attempted to answer it. So before we start this again, can we have this discussion, please. That would probably help to get us somewhere.

Sven

Hi Alexandre,

On Jan 25, 2008 9:52 PM, Alexandre Prokoudine wrote:

On Jan 25, 2008 11:01 AM, Sven Neumann wrote:

Actually, I don't think that we need to put action recording on our list as that will become obsolete with non-destructive editing.

This is apples and oranges, Sven :-) Non-destructive editing boosts productivity as well, but has nothing (or very few things) in common with *automation*.

It does, though. If you make a chunk of graph -- say you want to gaussian-blur a layer, gradient-map some part of it, and posterize the result to 32 levels; you could do this with the following snippet of graph:

(graph root) |
posterize (levels = 32)
|
+- atop
| |
| mask
| |
| gradient-map (gradient = )
| |
+-gauss-blur (hblur = 5, vblur = 5)
|
+-sourcelayer

In case that isn't clear:

Source layer is gauss blurred, A gradient-mapped version is made, which is then masked.
This image is then rendered atop the gaussian-blurred image, and the result is posterized.

This is what is conventionally covered by macros, this kind of thing.

All the users who ever bugged you asking for macros recording did it because they don't feel like programmers to learn Script/Python/Perl-Fu.

With non-destructive editing, used as above, almost all the things that users want to do are things that can be expressed in terms of a modification of the image graph. The example you see above -- the only user input required would be to choose which layer becomes sourcelayer. twould probably be pretty easy to build a 'quick change' dialog where the user can change all the involved values (eg gauss blur radius.)

The things which do not fall into that category.. * batch processing (trivial amount of programming. Just keep resetting the filenames at the leaf and root of a graph). * view handling (I'd like to be able to, say, tag an image or directory as 'pixel art', and when I opened one of those images, have an additional, 300% view appear (for real size preview). Personally I think views are one of the things that may end up needing a PDB interface*, despite the vast obsoletion that should otherwise happen (gauss blur, gradient map, colorize, what ever filter you name -- won't need a PDB interface any more, they just implement their gegl Ops)

I've just gone through the menus.. and the vast majority of actions available are directly equivalent to inserting, deleting, or shuffling nodes in a graph. The remainder alter either the context (Tools menu, View menu) or the GUI (Dialogs menu, View menu). (We might want to consider implementing a 'meta-load' Op, that would load a graph from file and pass image data through it. That would be a pretty simple and flexible way of facilitating macros shared between images -- just connect the output at a place of the user's choosing.)

What significant sequence of actions that you can take is there, that cannot be done by simple graph editing?

Date: Fri, 25 Jan 2008 23:50:56 +1030 From: "David Gowers"

On Jan 25, 2008 9:52 PM, Alexandre Prokoudine

> All the users who ever bugged you asking for macros > recording did it because they don't feel like programmers to learn > Script/Python/Perl-Fu.

With non-destructive editing, used as above, almost all the things that users want to do are things that can be expressed in terms of a modification of the image graph. The example you see above -- the only user input required would be to choose which layer becomes sourcelayer. twould probably be pretty easy to build a 'quick change' dialog where the user can change all the involved values (eg gauss blur radius.)

The question is, do users what to have to learn about image graphs, or do they just want to say "save what I did so I can do the same thing to another set of images"?

On Jan 26, 2008 12:09 AM, Alexandre Prokoudine wrote:

On Jan 25, 2008 4:20 PM, David Gowers wrote:

What significant sequence of actions that you can take is there, that cannot be done by simple graph editing?

Users do not think in terms of graphs, they think in terms of actions and sequences of actions. They want to click Record, mess around with filters etc., then just click Stop and be able to replay it to any number of other images, send this sequence of actions to a collegue or use his sequence of actions. This is about productivity.

What I was talking about -- recording is automatic, it's always happening. Every change to the image can be recorded, because most changes (say, gaussian blurring) can be recorded with a trivial amount of memory (what type of node is it, where is it connected, what properties does it have and what are their values). This is easily seen when you look at GEGL's current XML format.

In short -- what you call 'action recording', I call 'packaging up a chunk of the undo stack'. Really, your 'start' and 'stop' actions would be trivial to implement:
mark the start location in undo stack; mark the end; and prompt the user for a filename. Applying them is similarly trivial (choose an action, load it, append to the undo stack)

On Fri, 2008-01-25 at 23:50 +1030, David Gowers wrote: [...]

What significant sequence of actions that you can take is there, that cannot be done by simple graph editing?

You might want to look at the "nip2" graphics editor, which works this way. I find nip2 hard to use despite (or maybe because of?) the graphical interface, though.

Liam

Hi,

On Fri, 2008-01-25 at 14:22 +0300, Alexandre Prokoudine wrote:

Actually, I don't think that we need to put action recording on our list as that will become obsolete with non-destructive editing.

This is apples and oranges, Sven :-)

Well, it is not the same thing, that is right. But non-destructive editing will completely change how action recording works. It would be a waste of time to do the changes needed for classic action recording (which would be a major change) and at the same time migrate to non-destructive editing. We should rather focus on the latter.

Sven

Hi,

On Fri, 2008-01-25 at 16:54 +0000, William Skaggs wrote:

A roadmap should be thought of as a component of a full development strategy. In my view, each release cycle should have a set of target dates, and a set of essential accomplishments.

Well, we have that for 2.6. We didn't put publish it. But we discussed these points and agreed on a roadmap for 2.6. The question is, do we gain anything if we published such a roadmap officially? I am afraid that the only result would be that people will expect us to stick to the release date no matter how far the essential features are developed. And at the same time they will expect us to implement all the essential features.

The main value of a roadmap, in this context, is in planning for future release cycles. Thus, the roadmapping that should be going on now is for 2.8 and beyond, not for 2.6.

Agreed. The 2.6 development cycle is soon coming to an end and we should start to talk about what can still be achieved and what should happen next. The question is still, do we really want to make a roadmap public?

I think it would be a lot more useful if we would just collect a list of tasks that we consider important, without sticking them into a particular release time-frame. That will make it easier for new developers to participate. And that's what's most important.

Sven

Hi,

On Fri, 2008-01-25 at 20:03 +0000, William Skaggs wrote:

I think it would be a lot more useful if we would just collect a list of tasks that we consider important, without sticking them into a particular release time-frame. That will make it easier for new developers to participate. And that's what's most important.

That leaves the UI team with no way of influencing development, and no way to know what they should be working on. If the idea is to have a specification before something is implemented, then the process needs to have more structure.

You are throwing things together here. My proposal was for the task list that should be published prominently on www.gimp.org. Of course we need to discuss what will be done in the next development cycle. We have always done that and we will always do that. No one ever questioned this.

Sven

On Jan 26, 2008 12:53 AM, Alexandre Prokoudine wrote:

On Jan 25, 2008 4:54 PM, David Gowers wrote:

In short -- what you call 'action recording', I call 'packaging up a chunk of the undo stack'. Really, your 'start' and 'stop' actions would be trivial to implement:
mark the start location in undo stack; mark the end; and prompt the user for a filename. Applying them is similarly trivial (choose an action, load it, append to the undo stack)

That makes sense :) But then GEGL needs ops for handling selection, masks, paths, text... - everything that is now accessible via PDB and more. I'm not that technically experienced to say if those procedures are all exposable as ops.

The only thing that is not, of that list, is path modification. 'selection to path'
and
'selection from path'
would both work as ops, Anything that doesn't deal directly in image data (eg. adding/removing points from a path) would not work as an op, so that includes things like gradients, parasites, palettes. The main beneficiary could be plug-ins; most of them could be implemented as ops. (notable exception is GIMP-GAP, which has a unique position in that it tends to edit the image structure/associated files rather than pixel data directly.)

I would guess though, that we might end up having many PDB entries that are not required, for convenience. Though I think the main benefit of this would be
easily rememberable names for combinations of ops -- which may be better done by just a system to remember op combinations under a particular name.

Hi,

On Fri, 2008-01-25 at 10:45 -0500, Liam R E Quin wrote:

You might want to look at the "nip2" graphics editor, which works this way. I find nip2 hard to use despite (or maybe because of?) the graphical interface, though.

Thanks for the pointer. But we already decided that we don't want to expose the GEGL graph to the user. At least not as the main way of interacting with it. Still the fact that everything is in a graph fundamentally changes things like action recording and undo. Not from a user interface point of view, but from how things work internally.

Sven