Suggestions for 2.6: hopefully not very difficult
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.
| Suggestions for 2.6: hopefully not very difficult | Michael Grosberg | 04 Nov 14:16 |
| Suggestions for 2.6: hopefully not very difficult | Sven Neumann | 04 Nov 20:22 |
| Suggestions for 2.6: hopefully not very difficult | Sven Neumann | 04 Nov 20:34 |
| Suggestions for 2.6: hopefully not very difficult | peter sikking | 06 Nov 12:04 |
| Suggestions for 2.6: hopefully not very difficult | Michael Grosberg | 04 Nov 21:25 |
| Suggestions for 2.6: hopefully not very difficult | Kevin Cozens | 04 Nov 23:39 |
| Suggestions for 2.6: hopefully not very difficult | Sven Neumann | 05 Nov 09:26 |
| Suggestions for 2.6: hopefully not very difficult | Laxminarayan Kamath | 05 Nov 14:15 |
| Suggestions for 2.6: hopefully not very difficult | Sven Neumann | 05 Nov 14:46 |
Suggestions for 2.6: hopefully not very difficult
I just have a couple of small suggestions, whose aim is to streamline the UI a little bit.
The first is to take, if possible, the "tools" dialog, and incorporate it
into the "toolbox" tab in the preferences. Then remove the tools dialog as
a separate dialog.
my reasoning, and correct me if I'm wrong, is that The tools dialog is
only used to determine the order and visibility of icons in the toolbox.
It *can* be used to select tools to use, but in ths it duplicates the
function of the toolbox itself. So, its only feature is actually a setting,
and will almost never be used once it is set up to the user's liking.
So: there's no need to have it as a dialog along with the other more
used dialogs.
The preferences dialog is a more logical place for such a feature.
As for implementation, I guess a "configure toolbox" button, similar to
the "configure keyboard shortcuts", is a good solution.
My second suggestion - I think it was discussed before - is to switch the
functionality of the "add layer" button in the layers menu, at least as
an option:
click will create a new empty layer, shift-click will open the new layer
dialog.
The reason is that 99% of the time an empty layer is what's needed anyway.
There is no reason to force the user to press additional keys 995 of the
time just for the once or twice a month something else is needed.
My third suggestion - and this is based on personal experience - is to
return the "transient dialog" option, not just as an option but as a
default if possible.
I've been using Gimp 2.4 rather extensively both on Windows and Linux
(Ubuntu+Compiz) for some time now, and have not run into any major
problems while using the transient docks.
While it's far from perfect, it is still so much better than doing
without them that the benefits far outweigh any possible problems IMHO.
Thank you for reading this, please consider my suggestions.
Michael
Suggestions for 2.6: hopefully not very difficult
Hi,
On Sun, 2007-11-04 at 13:16 +0000, Michael Grosberg wrote:
My third suggestion - and this is based on personal experience - is to return the "transient dialog" option, not just as an option but as a default if possible.
This option still exists, see the gimprc man-page.
I would like to bring it back for 2.6, perhaps even as the default. But my experience is that it didn't work well enough to be even considered as an option. It works to some degree if one is working on a single image. But as soon as more than one image window is opened, or if there's no image window at all, the whole things breaks terribly.
It would probably help a lot if we made sure that there's always an image window opened. As soon as that has happened, we can unifiy the toolbox and image menu and we can reintroduce transient docks.
Sven
Suggestions for 2.6: hopefully not very difficult
Hi,
On Sun, 2007-11-04 at 13:16 +0000, Michael Grosberg wrote:
The first is to take, if possible, the "tools" dialog, and incorporate it into the "toolbox" tab in the preferences. Then remove the tools dialog as a separate dialog.
That's reasonable and it has been suggested before. Just needs someone to write the patch for it. It's simple enough that the core developers shouldn't have to deal with it. And that is probably why no one has done it yet.
My second suggestion - I think it was discussed before - is to switch the functionality of the "add layer" button in the layers menu, at least as an option:
click will create a new empty layer, shift-click will open the new layer dialog.
I am concerned that we are hiding important functionality here and that most users will never figure out how to get the dialog in case they should need it. But since even the UI team seems to suggest that we do this change, we should probably do it all over the user interface then. There are a few more places that use "Shift suppresses dialog".
Again, this should be rather simple and if Peter gives his OK, then we just need someone to preparse some patches.
Sven
Suggestions for 2.6: hopefully not very difficult
Sven Neumann gimp.org> writes:
Hi,
On Sun, 2007-11-04 at 13:16 +0000, Michael Grosberg wrote:
The first is to take, if possible, the "tools" dialog, and incorporate it into the "toolbox" tab in the preferences. Then remove the tools dialog as a separate dialog.
That's reasonable and it has been suggested before. Just needs someone to write the patch for it. It's simple enough that the core developers shouldn't have to deal with it. And that is probably why no one has done it yet.
Thanks for the kind replies. I should have figured it would have been suggested before. Are you planning to create some "todo" list for new developers so they know this has been suggested?
I guess you're right about the transient dock option: I almost always open a single image when working with Gimp. It's a pity... somehow it fit my own use perfectly and I didn't notice anything wrong until I just now started to play with minimizing and restoring multiple windows. But perhaps it's still better than the current situation... I'm not sure anymore.
Suggestions for 2.6: hopefully not very difficult
Sven Neumann gimp.org> writes:
On Sun, 2007-11-04 at 13:16 +0000, Michael Grosberg wrote:
The first is to take, if possible, the "tools" dialog, and incorporate it into the "toolbox" tab in the preferences. Then remove the tools dialog as a separate dialog.
That's reasonable and it has been suggested before. Just needs someone to write the patch for it. It's simple enough that the core developers shouldn't have to deal with it. And that is probably why no one has done it yet.
It sounds simple enough. Any hints as to how it should look? Would the Tools dialog be added to the bottom of the Toolbox preference tab as a scrollable area or should it be at the top?
Does this need to be added to bugzilla so we have a place to submit patches? I did a search for open bugs with "Tools" in the summary and didn't see an entry that covered this suggested change.
Suggestions for 2.6: hopefully not very difficult
Hi,
On Sun, 2007-11-04 at 17:39 -0500, Kevin Cozens wrote:
It sounds simple enough. Any hints as to how it should look? Would the Tools dialog be added to the bottom of the Toolbox preference tab as a scrollable area or should it be at the top?
It could be in a scrolled window or, if that doesn't work, it could be put into an extra dialog. But perhaps we should try to avoid extra dialogs if possible.
It would probably also make sense to move the Unit Editor to the Preferences dialog. Perhaps it is even about time for a more complete overhaul of the Preferences dialog.
Feel free to open bug-reports for these tasks.
Sven
Suggestions for 2.6: hopefully not very difficult
On Nov 5, 2007 1:04 AM, Sven Neumann wrote:
Hi,
I am concerned that we are hiding important functionality here and that most users will never figure out how to get the dialog in case they should need it. But since even the UI team seems to suggest that we do this change, we should probably do it all over the user interface then. There are a few more places that use "Shift suppresses dialog".
(Sorry Sven, I did not realise I replied only to you before)
Cant this be implemented like the playlist buttons in XMMS/Winamp ? I
mean the tiny triangle which users intuitively take as "There are more
options!".
Suggestions for 2.6: hopefully not very difficult
Hi,
On Mon, 2007-11-05 at 18:45 +0530, Laxminarayan Kamath wrote:
Cant this be implemented like the playlist buttons in XMMS/Winamp ? I mean the tiny triangle which users intuitively take as "There are more options!".
We are talking about showing a dialog or not showing a dialog. I don't think that you can hide a dialog in an expander. I will assume that you simply missed the context.
Sven
Suggestions for 2.6: hopefully not very difficult
Sven Neumann wrote:
Michael Grosberg wrote:
My second suggestion - I think it was discussed before - is to switch the
functionality of the "add layer" button in the layers menu, at least as
an option:
click will create a new empty layer, shift-click will open the new layer
dialog.I am concerned that we are hiding important functionality here and that
most users will never figure out how to get the dialog in case they should need it. But since even the UI team seems to suggest that we do this change, we should probably do it all over the user interface then.
There are a few more places that use "Shift suppresses dialog".
yep, _even_ we think this is necessary from an interaction point of view. ;^}
but watch out broad-brushing this over all dialogs that use "Shift suppresses dialog" at the moment. for every one of these the _right_ choice needs to be made, depending on our essential user scenarios and our product vision.
Again, this should be rather simple and if Peter gives his OK, then we just need someone to preparse some patches.
I say we put this on the 2.6 roadmap, the UI team can go through the list of all of these and publish a spec with rationale of which should be switched over, which can then be reviewed.
--ps
founder + principal interaction architect man + machine interface works
http://mmiworks.net/blog : on interaction architecture
