Re: [Gimp-developer] task list
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
Hi, On Thu, 2008-01-24 at 18:06 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
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*. 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. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
Date: Fri, 25 Jan 2008 23:50:56 +1030 From: David Gowers [EMAIL PROTECTED] 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? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
Hi Alexandre, On Jan 25, 2008 9:52 PM, Alexandre Prokoudine [EMAIL PROTECTED] 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 = how would you specify this?) | | +-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? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
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. Don't get me wrong - I'm very much excited about GEGL features ( I even did a happy dance when I saw nodes caching code committed to SVN a while ago :)), but your example is rather a demonstration of adjustment layers and/or live filters and doesn't not deal with the issue we are speaking about. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
On Jan 26, 2008 12:09 AM, Alexandre Prokoudine [EMAIL PROTECTED] 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) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] task list
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. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] task list
From: Sven Neumann [EMAIL PROTECTED] I don't think we want to publish something and call it a roadmap. But we had the plan to make a list of important tasks that outline where GIMP is heading and what we consider important to work on. Since there doesn't seem to be enough interest among the developers and other people reading this list, we still don't have such a list. I believe there is quite a bit of interest. Here is my current understanding of the long term goal list. This is probably incomplete and no doubt incoherent in parts. I have tried to put the most important things first, but don't take the order too seriously. A few of these things are already under way, and expected to be finished for 2.6, but I include them because they are not finished yet. * Move to a Gegl-based image structure, in which an image is represented as a tree of gegl nodes. This is a prerequisite for many other changes, including: ** Implement layer groups. ** Implement Layer effects. ** Support 16 bit layers. ** Support clipping paths. ** Support CMYK internally. * Make canvas drawing use Cairo, and consequently not use XOR drawing. This will allow great improvements in the quality of tool-interface drawing. * Construct an optional MDI version of the gui. * Change the PDB so that plug-ins can be made into GObjects, with their parameters as object properties. This will make it possible to save and restore settings in a generic way. * 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. * Enhance the text tool: ** Support basic text transformations. ** Properly support text along a path. ** Add a text layer api. ** Support on-canvas text editing. ** Improve the font selector widget. * Implement a tagging system to organize resources such as brushes, gradients, patterns, and palettes. * 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.) * Reorganize tools so that the toolbox is less crowded. ** Merge the transform tools into a single tool, with the type of transformation as a tool option. * Merge the toolbox menu contents into the image menu, and get rid of the toolbox menu. * Implement vector layers, starting with lines, rectangles, and ellipses, then perhaps moving to full path layers. * Find alternatives to the floating selection when pasting. * Make it possible to apply filters using a brush. * Add a save for web feature. * Complete support for metadata. * Add ability to lock a layer/drawable. * Implement autsaving. * Make Iwarp into a tool. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
