As promised in my previous email, I would like to look at the priorities that Peter presented in his LGM talk (at which I was not present), and try to give a sense of my impression of how much work each one involves. You can find a web version of Peter's talk at http://www.mmiworks.net/eng/publications/2007/05/ 10. better printing support Evaluation: It wouldn't be very hard to improve the page layout capabilities in Gimp. Most of the things mentioned in the talk should be straightforward to implement. 9. painting with brushes Evaluation: Although this is listed as a priority, the conclusion is that this should *not* be supported by the Gimp core, but rather by plug-ins. This is not, however, possible in the current Gimp architecture, because there is no way for plug-ins to get pointer movement information in real time, and it would take major changes to make it possible -- and even then, it would be challenging to make the painting happen fast enough. The conclusions here should be reconsidered. 8. improve the text tool Evaluation: Most of the points mentioned here would be relatively simple to implement. One of them -- the ability to have multiple text items within a single layer -- might not be simple, and it should be considered whether this would better be dealt with by implementing layer groups. 7. save for web Evaluation: all of this is easy. Given a specification, this can all be assembled very quickly. 6. organize brushes, palettes, gradients in categories Evaluation: we have already had some discussion of this one. Peter and Sven favor a scheme that depends on tagging each item with a set of labels. I can't tell how hard this will be to set up because I don't have a clear picture of how it is supposed to work, at the level of specific user interactions. Adding tags would be relatively easy; supporting them might not be. 5. avoid pop-up dialogs Evaluation: Nothing is easier than getting rid of a dialog, and simply using default values. Most of the dialogs are actually present for a reason, though, even if it isn't obvious. For the rotation tool, for example, if you make an error and need to make a slight correction (and the preview isn't enough to tell you what you need), then the only way to do it is to note the angle that you see in the dialog. There must be a better way to solve this problem, but until such a better way is found, getting rid of the dialog is impossible. So it is with most of the dialogs in gimp. 4. better painting tools Evaluation: Most of the suggestions here would be relatively easy to implement. The "blobs of paint" strikes me as a potentially a very nice UI feature, and it too should be relatively easy to implement. 3. layer trees Evaluation: this depends on Gegl, and will be implemented as soon as the Gegl capabilities in Gimp make it possible. 2. adjustment layers Evaluation: I'm surprised to see this prioritized so high, but in any case the evaluation is the same: this depends on Gegl. 1. single window interface Evaluation: This is straightforward, but it will take considerable work. The hard part is that the image-containing part of the interace must have pretty powerful window-management capabilities, and the code for this, as far as I can tell, would have to be written from scratch. If it was just a matter of tabbed images, or if we could somehow find a window manager written in pure Gtk+ code (with minimal X code), then it would be a lot simpler. In any case, nothing prevents this from happening except limited developer time. -- Bill
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
