input from the UI team needed
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| input from the UI team needed | Sven Neumann | 23 Jan 20:50 |
| input from the UI team needed | Martin Nordholts | 24 Jan 06:35 |
| input from the UI team needed | Sven Neumann | 24 Jan 09:10 |
| input from the UI team needed | Alexandre Prokoudine | 24 Jan 09:18 |
| input from the UI team needed | Sven Neumann | 24 Jan 09:34 |
| input from the UI team needed | Martin Nordholts | 26 Jan 08:09 |
| input from the UI team needed | Alexia Death | 26 Jan 10:58 |
| input from the UI team needed | Alexander Rabtchevich | 26 Jan 12:03 |
| input from the UI team needed | Martin Nordholts | 26 Jan 12:38 |
| input from the UI team needed | Alexander Rabtchevich | 28 Jan 10:55 |
| input from the UI team needed | Alexander Rabtchevich | 28 Jan 18:03 |
| input from the UI team needed | peter sikking | 24 Jan 20:20 |
| input from the UI team needed | Sven Neumann | 25 Jan 08:55 |
| input from the UI team needed | Sven Neumann | 25 Jan 09:26 |
| input from the UI team needed | Sven Neumann | 25 Jan 09:14 |
| input from the UI team needed | Sven Neumann | 25 Jan 19:48 |
input from the UI team needed
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:
Merge toolbox and image menus
It would be very nice if we could get this done for 2.6. It would be a major user-visible change and as such it would give a clear sign that GIMP is moving. What's needed here is a mockup that shows how GIMP should look like with no image window open. And a specification that tells us what should happen when the first image is opened, what happens for the second image, what happens when the last image is closed.
Text boxes
This is described in bug #122707 and Bill has a patch for the text tool that makes it use the rectangle tool interface similar to the Rectangular Selection and Crop tools. It would be nice to have a specification that defines how the text tool should behave.
Keyboard Shortcut dialog
This has come up in bug #507257. We already made the Keyboard Shortcut editor accessible from the Edit menu. So it is not any longer necessary to access it from the Preferences dialog. IMO this should be taken further by moving more Keyboard related stuff from the Preferences dialog to the Keyboard Shortcut dialog. Some comments on the bug report would be helpful.
Remove the "add/remove alpha channel" option for layers
This is described in bug #486902. Not sure if it is a good idea or not. Comments from the UI team would be very much appreciated.
Show current aspect ratio in Crop tool
As described in bug #508183, this is a regression from GIMP 2.2 and it would be nice to sort this out for GIMP 2.6.
Make it easier to select and move areas
As described in bug #505761, the new rectangular/ellipse selection tools get in the way of the workflow of some users. Bug #349340 is somewhat related to this. It would be nice if the solutions outlined in these bug reports could be evaluated by the UI team.
I hope that you and your team can help us to sort out these issues.
Sven
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
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
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
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
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
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
input from the UI team needed
Hi,
On Fri, 2008-01-25 at 04:38 +0000, 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
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
input from the UI team needed
Hi,
On Fri, 2008-01-25 at 17:21 +0000, 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
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
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
input from the UI team needed
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.
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
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.
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.
