Re: [Gimp-developer] input from the UI team needed
Martin Nordholts wrote: Hello Just wanted to mention this since it appears if you haven't noticed it: You can already now do what you are asking for: 1. Make an arbitrary selection 2. Select - To Path 3. Use the Path Tool to edit the created path 4. Select - From Path I already know it :). Now these sequence is rather long. In order to edit already existing selection as a path, next actions are required: 1. Selection to path 2. Select last selection from selections tab and make it visible. This step is not straightforward and quick. 3. Choose path tool and start editing... I understand there should be the separate selection to path action, and there should be an ability to edit a path not affecting existing selection. But could the 1. and 2. actions be merged into one additional menu item to make the things quicker? The existing selection to path can be renamed into Copy selection to path, and Move selection to path or Convert selection to path can be added. The last should create a path from the selection, clear the selection and make the path ready for editing. Optionally it can switch to the path tool too. The Polygonal Select Tool should IMO only fill the void of a way to quickly make polygonal selections. (If it will even be a separate tool and not just en enhancement to the Free Select Tool.) OK, I understood. -- With respect Alexander Rabtchevich ___ 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
Martin Nordholts wrote: Hello Just wanted to mention this since it appears if you haven't noticed it: You can already now do what you are asking for: 1. Make an arbitrary selection 2. Select - To Path 3. Use the Path Tool to edit the created path 4. Select - From Path I already know it :). Now these sequence is rather long. In order to edit already existing selection as a path, next actions are required: 1. Selection to path 2. Select last selection from selections tab and make it visible. This step is not straightforward and quick. 3. Choose path tool and start editing... I understand there should be the separate selection to path action, and there should be an ability to edit a path not affecting existing selection. But could the 1. and 2. actions be merged into one additional menu item to make the things quicker? The existing selection to path can be renamed into Copy selection to path, and Move selection to path or Convert selection to path can be added. The last should create a path from the selection, clear the selection and make the path ready for editing. Optionally it can switch to the path tool too. The Polygonal Select Tool should IMO only fill the void of a way to quickly make polygonal selections. (If it will even be a separate tool and not just en enhancement to the Free Select Tool.) OK, I understood. -- With respect Alexander Rabtchevich ___ 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: 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 As a user I can say it is definitely desired. I miss the option to draw straight segments every time I use Freehand selection tool. Martin Nordholts wrote: .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 think this is a good idea. Martin Nordholts wrote: 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. Perhaps UI team would like to consider IMHO logical approach as I see it. My logical expectation when using the Freehand select is that Shift key down mid drawing makes it a line segment, Ctrl constrains angle. It follows the UI logic of all other freehand tools. And it will not collide with boolean mode selection because those need to be down before you start drawing. It does create a bit of overloading, but this is very logical to the user. An option to set it in pure polygon mode where Ctrl is needed for freehand would be desired too. --Alexia ___ 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
Alexander Rabtchevich wrote: And I can see freehand and polygonal selection tools as two different tools or modes. The main wish is to be able to handle any existing selection as a set of Bezier curves (or polygonals). So one can draw a selection as he wishes with any of existing tools, using existing modifiers. And if he wants to correct the existing selection in a regular way, he switches to the polygonal selection tool and starts editing already existing curve. Of course, selection can be done from scratch with the polygonal selection tool itself. This approach exists in vector graphics editors. Hello Just wanted to mention this since it appears if you haven't noticed it: You can already now do what you are asking for: 1. Make an arbitrary selection 2. Select - To Path 3. Use the Path Tool to edit the created path 4. Select - From Path The Polygonal Select Tool should IMO only fill the void of a way to quickly make polygonal selections. (If it will even be a separate tool and not just en enhancement to the Free Select Tool.) BR, Martin Nordholts ___ 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] 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] 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] 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
Re: [Gimp-developer] input from the UI team needed
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. Oh, and we should perhaps think about adding some tool categories. There are already way too many tools in our toolbox. I guess that putting them into groups and separating these groups visually would help a lot. 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
On Jan 24, 2008 11:10 AM, Sven Neumann wrote: Oh, and we should perhaps think about adding some tool categories. There are already way too many tools in our toolbox. I guess that putting them into groups and separating these groups visually would help a lot. Sven, I hate to raise quasi-offtopic themes, but is the plan to publish a roadmap still in force? ;-) 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 Thu, 2008-01-24 at 11:18 +0300, Alexandre Prokoudine wrote: Sven, I hate to raise quasi-offtopic themes, but is the plan to publish a roadmap still in force? ;-) 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. May I ask why you are asking this? And then, why you are using this thread instead of creating a new one for such a question? 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
Hey all, sorry for fading out of view for a while. demanding projects (ongoing), a big flue and christmas got in the way. but that is just part of it. The other part is the lack of a roadmap. the lack is now so that I was prepared to write one myself, just to have something to work with. But I remembered somebody was on it, it turned out to be Alexandre. 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. At the release of 2.4 I announced the end of fire-fighter mode accordingly. Then during the roadmap-2.6 items kept popping up that deal with UI problems. Fine, we can work on them, as soon as the roadmap is fixed. Yep, fixed. frozen. A roadmap is a tool for me to plan (assign tasks to my team) and also to say no to spontaneous initiatives that need a long, full spec (say, polygonal tool). When making the roadmap the rational decision can be taken what GIMP needs now: polygonal tool or fixing the floating selection. One gets the nod, the other has to wait for a next release to get worked on (UI spec, dev, test, doc, etc.) I see the list below of what needs input and they are all worthy problems to solve. But they look to be in part different problems than the ones discussed for the roadmap two months ago. There lies the problem. I will give direction for the small ones on the list below that have bug numbers. I am still putting out small fires. ^} the big spec ones need to be roadmapped to get done... Sven Neumann wrote: Merge toolbox and image menus Text boxes Keyboard Shortcut dialog Remove the add/remove alpha channel option for layers Show current aspect ratio in Crop tool Make it easier to select and move areas I hope that you and your team can help us to sort out these issues. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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: peter sikking [EMAIL PROTECTED] I see the list below of what needs input and they are all worthy problems to solve. But they look to be in part different problems than the ones discussed for the roadmap two months ago. There lies the problem. I will give direction for the small ones on the list below that have bug numbers. I am still putting out small fires. ^} the big spec ones need to be roadmapped to get done... There are two big things that are definitely roadmapped for 2.6 and need specifications from the UI team. The first is the merged menus. This was done at the suggestion of the UI team. Some infrastructure has already been created, but it is not possible to go farther without a specification -- or, to put it differently, it is not possible to go farther without making assumptions about what the specification will be, which Sven thinks would be hostile to the UI team. The other critical thing (less critical because it is not quite ready to be implemented) is that the canvas drawing will be moved to Cairo, which will give a lot more freedom to make the tool interface look better. It will soon be possible to improve the interface for the crop and rectangle-select tools, among others, and it would be very helpful to have a specification for what the interface should look like as soon as the Cairo-drawing is in place. In general there seems to be a misunderstanding here. I believe Sven is reluctant to definitely roadmap anything that will affect the interface without first getting input from the UI team. But it seems that the UI team is reluctant to create a specification until something is definitely roadmapped. I believe that the only way around this impasse is for both the roadmapping and the UI specification to be done interactively, by means of ongoing discussion between the UI team and the developers. The fault is not all just on one side. Peter in his LGM presentation has given a list of what he considers the top 10 priorities (linked from http://www.mmiworks.net/eng/publications/2007/05/ ), but there is no way he can know how easy/hard each of them is to implement, and it is up to the developers to give feedback. I will make a start on this in the following email message. -- 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
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@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: When making the roadmap the rational decision can be taken what GIMP needs now: polygonal tool or fixing the floating selection. One gets the nod, the other has to wait for a next release to get worked on (UI spec, dev, test, doc, etc.) Huh? We have several developers waiting to implement these things. Actually for most of the things, some of the code has already been written. If working with the UI team means that we can only have one or two changes per release cycle, then that means that only one or two developers can work on GIMP and that means that it will not improve ever. I see the list below of what needs input and they are all worthy problems to solve. But they look to be in part different problems than the ones discussed for the roadmap two months ago. There lies the problem. These are the things that people are actively working on. I cannot assign tasks to developers and you can't do that either. This is a voluntary project. People spend their time on the things they want to spend their time on. They are willing to follow advice from the UI team, but that does not mean that they are just a bunch of code-writing monkeys. I will give direction for the small ones on the list below that have bug numbers. I am still putting out small fires. ^} the big spec ones need to be roadmapped to get done... Please assume them to be on the roadmap then. Everything on my list is on our roadmap and some of the items have been sitting there for years. These are all long-standing problems that need to be addressed. And if we can address them now, then we should do that. 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
Sven Neumann wrote: Hi Peter, there are a couple of things that are waiting for input from the UI team. Things that we would like to sort out for GIMP 2.6. It would be nice if we could get some advice from you and your team. I made a list of the things that in my opinion are most important right now. The order is arbitrary: [...] I hope that you and your team can help us to sort out these issues. Sven Yo 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? - Martin [1] http://bugzilla.gnome.org/show_bug.cgi?id=119646 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
