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] input from the UI team needed
Hi, On Fri, 2008-01-25 at 04:38 +, William Skaggs wrote: 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. Pango allows to change fonts and style in the same PangoLayout, so I don't see how this could be particularly difficult to implement. 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. Some dialogs seem to be considered avoidable though. We already allow to skip them by means of using the Shift Key. The UI team promised to make us a list of dialogs that should by default be suppressed. As soon as we have that list, we can start to do the changes. That should be easily doable in almost no time. 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. I think you are misinterpreting this. As Peter says: We have not reached a conclusion yet on the introduction of a single window interface. We are positive that the current situation needs to be improved. I don't see a WiW user interface coming to GIMP, ever. This is so backwards, I can't even believe that it is still being discussed. While this is an often requested feature, almost all of us, including the UI team, seem to aggree that there are better solutions to this problem. So let's concentrate on them and migrate the GIMP user interface towards our vision which is an image-centred user interface without a pointless gray backdrop. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] input from the UI team needed
Hi, On Thu, 2008-01-24 at 20:20 +0100, peter sikking wrote: Even before 2.4 came out, I was warned that not to much UI work could be done for 2.6. GEGL first. OK. suits me, that leaves a period where the UI analysis can get (finally!) done and a transition can be made towards tackling the mayor UI issues in GIMP systematically, based on a UI masterplan. Sorry. But perhaps we should have explained that better. Only one or two people are working on the GEGL transition and that is good because throwing more developers on it would not help at all. So that leaves room for other improvements and we definitely want to get some UI changes into 2.6 still. By now we should have enough of an idea of the GIMP's user interface problems that we should be able to start working towards a better one. I don't believe in masterplans. In particular not in masterplans that take years to write, when at the some time we could already have them implemented. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tasks list
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 ___ 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] tasks list
On Jan 25, 2008 10:06 PM, Sven Neumann 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. This is what Inkscape guys do. They have a roadmap based on a rough estimation, what features might be released in what version, and they manage to work within it, implementing some planned features sooner than planned and some - later. Their users just got used to having a new release every ~6 months, so they don't bother much about particular features not being implemented in a particular new version, because they are more or less sure that it won't take ages to see it done. Even now, when the 0.46 is about 5 months off the usual schedule, noone is crying out loud. So yes - something in these lines could work. Roadmaps are positive - people see that what they need is planned to be addressed. And we need positive users, don't we? ;-) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tasks list
Hi, On Fri, 2008-01-25 at 20:03 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding SpaceNavigator support
Hi Ettore. Ettore Pasquini ([EMAIL PROTECTED]) wrote: I work for 3Dconnexion (a Logitech company) and we make 3D input devices. We also care about popular 2D apps that could use the high sensitivity of our SpaceNavigator for panning and zooming. GIMP was under our radar and now we are considering to add support for our devices. I am new to the GIMP code base so I wanted to ask some questions about the architecture first. What would be the best way (from a pure engineering standpoint) to integrate my code? Meaning, via a plugin or just into the main app? Are there modules for I/O events (to deal with tablets, controllers, etc) that I should start with and expand? BTW let's not worry about licensing issues now. My code will obviously be shared and our devices are HID compliant, so no need to mess with proprietary drivers. yeah, except for at least one quirk :) (I wrote the patch to enable the LEDs for the Linux-Kernel :) On what Operation System are you working btw.? There already is a HID input module for the Gimp, you can find the source code in the top-level modules directory, relevant are the controller_*-files. We have various input modules, also available is a MIDI input module. The current architecture unfortunately does not yet allow you to hook into the (paint)-Tools directly, you can only invoke actions. There are lots of actions and it is easy to e.g. control the opacity. However, you can not control the pointer position in this way. Have a look into this, I'd be glad to help you to work on this. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Adding SpaceNavigator support
Hello everyone, I work for 3Dconnexion (a Logitech company) and we make 3D input devices. We also care about popular 2D apps that could use the high sensitivity of our SpaceNavigator for panning and zooming. GIMP was under our radar and now we are considering to add support for our devices. I am new to the GIMP code base so I wanted to ask some questions about the architecture first. What would be the best way (from a pure engineering standpoint) to integrate my code? Meaning, via a plugin or just into the main app? Are there modules for I/O events (to deal with tablets, controllers, etc) that I should start with and expand? BTW let's not worry about licensing issues now. My code will obviously be shared and our devices are HID compliant, so no need to mess with proprietary drivers. Thanks in advance, Ettore -- http://www.3dconnexion.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tasks list
From: Sven Neumann [EMAIL PROTECTED] 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. I'm not sure it needs to be published officially, but it's at least essential for Peter to have a complete picture. I think it would also be good if people who follow this list could have a general picture of what is expected for the current cycle, even if no promises are made. 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. I agree with you that there is no sense in creating rigid roadmaps extending far into the future. I think, though, that the planning process should be a little more public (at least public enough for the UI team and potential new developers to be able to look at the current state), and a little more forward-looking. Everybody should realize that not all plans that are made will be executed, but if we want coordination between the UI team and developers, there must be an ability to create definite plans. -- Bill ___ 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] input from the UI team needed
Sven Neumann wrote: Hi, On Thu, 2008-01-24 at 06:35 +0100, Martin Nordholts wrote: It would also be nice to get the Polygonal Select Tool details sorted out for 2.6. There is code for such a tool in bug #119646 [1], the question is just to what extent it should be merged/integrated with the Free Select Tool. Should it be possible to use the Polygonal Select Tool for free hand-type selections too, or should it be a strict polygonal tool? Exactly how should it behave? Would it make sense to add it as a new tool now (provided that Jimmac draws a nice icon for it)? I guess we can always merge it with the Free Select tool later if that is desired. I think we should do that if we are willing to release 2.6 with the polygonal tool in its current form. From what you say it seems as if you think that would be fine, and personally I also think it will be better to release 2.6 with a primitive Polygonal Select Tool rather than with no such tool at all, and simply postpone further improvements on it to 2.8 or later if it does not happen in time for 2.6. Also, by putting the tool in trunk we might even get some valuable ideas/opinions on the tool which will be useful when it is being finalized. So let's ask Jimmac for a tool icon. I have some ideas for how to do the Free Hand/Polygonal Select merge, but I'd rather await the UI team input before doing any changes. - Martin ___ 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] input from the UI team needed
Hi, On Fri, 2008-01-25 at 17:21 +, William Skaggs wrote: The idea I was responding to was, as I understood it, basically to have multiple PangoLayouts within the same layer. Even that would probably not be so difficult to implement, but I think it would probably cause more harm than good. Agreed. 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 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
Re: [Gimp-developer] tasks list
From: Sven Neumann [EMAIL PROTECTED] 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. 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. The target dates are for soft freeze, hard freeze, and release. The accomplishments are the things that *need* to be done to have a release. For the current cycle, for example, I see the essential accomplishments as: 1) stabilize the new gegl code 2) merge the toolbox and image menus 3) change to a Cairo-based canvas That doesn't mean that nothing else can be done, just that nothing else will be allowed to shift the target dates. 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. With a good roadmap, the UI team can work on specifications ahead of time, and developers can have at least some code ready to commit at the start of the release cycle. There actually *was* a roadmap for 2.6 already during the 2.4 cycle, but it was never made public. The fact that a roadmap existed can be seen in that (1) the first gegl work began immediately after branching for 2.5, (2) code had already been written for the merged menus, and (3) the first experiments with Cairo started immediately after branching. What is needed is for this sort of roadmap to be published, instead of just existing in the heads of people who read the ChangeLog every day and hang out all the time in #gimp. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] input from the UI team needed
From: Sven Neumann [EMAIL PROTECTED] 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. Pango allows to change fonts and style in the same PangoLayout, so I don't see how this could be particularly difficult to implement. The idea I was responding to was, as I understood it, basically to have multiple PangoLayouts within the same layer. Even that would probably not be so difficult to implement, but I think it would probably cause more harm than good. I don't see a WiW user interface coming to GIMP, ever. This is so backwards, I can't even believe that it is still being discussed. While this is an often requested feature, almost all of us, including the UI team, seem to aggree that there are better solutions to this problem. So let's concentrate on them and migrate the GIMP user interface towards our vision which is an image-centred user interface without a pointless gray backdrop. This attitude strikes me as too rigid. Adding a WiW interface would be very unintrusive -- almost the only changes in existing code would be to make docks and images into children rather than toplevels. (There would also be some changes in menu code and sessioninfo handling.) So if somebody came along who wanted to work on it, I don't see any good reason for forbidding it. I understand the fear of confusing users, or of creating maintenance problems, but it does not seem to me that those worries are sufficient in this case. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
