Does it keep the entire menu inside the screen if the "layers" dialog is at the right edge of the screen ?

Hi,

On Fri, 2008-02-15 at 08:01 +0000, Laxminarayan Kamath wrote:

Does it keep the entire menu inside the screen if the "layers" dialog is at the right edge of the screen ?

Of course. If it wouldn't, that would be a bug in GTK+.

Sven

Hi,

On Thu, 2008-02-14 at 21:47 -0800, Bill Skaggs wrote:

One of the minor annoyances of using Gimp is that the Layer Mode menu (and paint mode menu, etc) is unpleasantly long -- for me, it nearly extends from the top to the bottom of the screen. It would actually be very easy to change the code so that these menus are laid out in two columns, and in my opinion they look nicer that way. I am attaching a screenshot showing how it looks. (Hopefully the attachment will come through.)

I am not sure. I have never had problems with the long menu and I think that the separators help a lot to understand the paint modes. The two-column layout doesn't provide this information and it even seems to suggest that there's some relationship between modes that are shown on the same row.

IMO this change would be a regression but I might be convinced that it is an improvement.

Sven

On Fri, Feb 15, 2008 at 8:47 AM, Bill Skaggs wrote:

One of the minor annoyances of using Gimp is that the Layer Mode menu (and paint mode menu, etc) is unpleasantly long -- for me, it nearly extends from the top to the bottom of the screen.

It very much depends on particular GTK+ theme in use. I've used few Murrina (a GTK+ engine) based themes that a *very* compact. For instance, the whole list of layer modes takes something between 1/2 and 1/3 with them on my aging 1280x800 px laptop.

Thus I'd rather encourage creating improved Default/Smaller themes :)

Alexandre

Bill wrote:

It seems to me
that the separators are not that important, because the categories are pretty artificial in the first place, and were really imposed mostly
to give the very long list some structure, as far as I can see. But this
is something that you should consider.

separators are very important in a menu, to be able to deal with many (> 5)
items, by putting them in sub groups, you get your bearing for aiming. even arbitrary sub-grouping is better than none.

Anyway, I would like to make this change, and I wonder if there are objections.

yeah, this is also harder to use because you have to do a controlled sideways movement to get from one column to the other.

sorry: no cigar...

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

agree with Peter,
(part of my job is to improve user interaction && UI usability) separators are good, even better are spacers (like in Firetox and Thunderbird [fluid spacers]) also a line OR a background surrounding a group of buttons are good for focusing to a 'grouped set of functions' ...instead of individual buttons.

anyhow : 2 cigars

peter sikking wrote:

Bill wrote:

It seems to me
that the separators are not that important, because the categories are pretty artificial in the first place, and were really imposed mostly
to give the very long list some structure, as far as I can see. But this
is something that you should consider.

separators are very important in a menu, to be able to deal with many (> 5)
items, by putting them in sub groups, you get your bearing for aiming. even arbitrary sub-grouping is better than none.

Anyway, I would like to make this change, and I wonder if there are objections.

yeah, this is also harder to use because you have to do a controlled sideways movement to get from one column to the other.

sorry: no cigar...

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Bill Skaggs wrote:

One of the minor annoyances of using Gimp is that the Layer Mode menu (and paint mode menu, etc) is unpleasantly long -- for me, it nearly extends from the top to the bottom of the screen. It would actually be very easy to change the code so that these menus are laid out in two columns, and in my opinion they look nicer that way. I am attaching a screenshot showing how it looks. (Hopefully the attachment will come through.)

I should say that the disadvantage is that it's hard to maintain the separators that divided the modes into categories -- it would be possible, but coding it would be a significant pita. It seems to me that the separators are not that important, because the categories are pretty artificial in the first place, and were really imposed mostly to give the very long list some structure, as far as I can see. But this is something that you should consider.

I think the separators are important. And the categories are full of sense.

About create two columns, I think it may be a nice idea, but I have no problem with only one column.

May be could be possible make two columns but mantaining separators.

Anyway, I would like to make this change, and I wonder if there are objections.

-- Bill

Salu2 de jEsuSdA 8)

------------------------------------------------------------------------

------------------------------------------------------------------------

Why not add it as a preference.. By default, keep it one column. If people find it annying, they can choose to have two columns in "preferences" dialog.

On Fri, 2008-02-15 at 13:13 -0800, Bill Skaggs wrote:

Well, it's clear that the idea is not generating a great deal of enthusiasm.

[... screenshot...]

I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better, other than asking people to use specific Gtk themes?

Seems to me that probably most people will use at most a couple of the layer modes in normal use, so maybe putting the top 7 on the menu and having a "more modes" submenu is a possibility.

If gimp starts to have adjustment layers, that can e.g. apply a filter, or user-defined painting modes, or if the ilst of built-in modes got longer, the menu approach would probably become unworkable, and we'd need a drawing mode pallette or something.

But it seems to me it's worth living with it as it is for a while, until the hot goat love (GEGL) has been explored a little more.

Liam

Liam R E Quin writes:

Seems to me that probably most people will use at most a couple of the layer modes in normal use, so maybe putting the top 7 on the menu and having a "more modes" submenu is a possibility.

Eek, please no! Often the best way to use layer modes is to go down the list one by one, which would become even worse if you had to click through a "more" submenu each time. Bad enough to have to go to the bottom of the menu then wait for it to scroll.

Personally I'd like Bill's side-by-side mode menu, just because it would be faster, and a shorter distance, to get to most entries. But Sven does have a good point that it implies there's a connection between each side-by-side pair of modes.

Bill wrote:

I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better

I don't have a great solution, just a few specifics the gtk widget doesn't do well that I wish the modes menus could handle better. Like the fact that clicking on the button pops up the menu, but not always with the current mode selected -- sometimes it's the mode above the currently selected one, so I can't just arrow down once and assume I'm on the next mode -- I have to look at the current mode before I click, then choose the next one explicitly.

And I wish there was a faster way to select them by keyboard than the current "click on the button then use up or down arrow" ... I wish I could type ad and be on Addition right away.

...Akkana

On Sat, 16 Feb 2008 05:55:33 +0100, Akkana Peck wrote:

Liam R E Quin writes:

Seems to me that probably most people will use at most a couple of the layer modes in normal use, so maybe putting the top 7 on the menu and having a "more modes" submenu is a possibility.

Eek, please no! Often the best way to use layer modes is to go down the list one by one, which would become even worse if you had to click through a "more" submenu each time. Bad enough to have to go to the bottom of the menu then wait for it to scroll.

Personally I'd like Bill's side-by-side mode menu, just because it would be faster, and a shorter distance, to get to most entries. But Sven does have a good point that it implies there's a connection between each side-by-side pair of modes.

Bill wrote:

I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better

I don't have a great solution, just a few specifics the gtk widget doesn't do well that I wish the modes menus could handle better. Like the fact that clicking on the button pops up the menu, but not always with the current mode selected -- sometimes it's the mode above the currently selected one, so I can't just arrow down once and assume I'm on the next mode -- I have to look at the current mode before I click, then choose the next one explicitly.

And I wish there was a faster way to select them by keyboard than the current "click on the button then use up or down arrow" ... I wish I could type ad and be on Addition right away.

...Akkana

Yes Bill's screenshot shows that huge gap at the top which is a another gtk widget defect.

All of these points seem out of reach to Gimp so long as it is restained to use these widgets (GTK+ is notoriously refractory to change or requests from outside).

If there's need for functional change the only possiblity is probably for gimp to have its own menu widget, which could be forked from the existing code.

This menu is overloaded and more clicking and jiving would not make things easier. Maybe the GUI guys could look at why there is so much content here. Are there maybe different use categories that are all getting called modes and so getting grouped together when functionally they could be separate?

I have not looked at this in detail but my gut instinct is that this has grown and evolved and now there's a need to take a step back and look at structure rather than remain concentrated how to change the menu.

regards, gg.

Hi!

Thanks for discussing the layer mode menu.

1. As shown in Bills screen shot the widget rendering is a bit strange even if there is enough space on screen.

2. The separators are not bad thing.

3. If you know exactly what to do you simply click the mode and ready - but you should be able to select the mode with a single click from the list.

4. If you want to experiment with the layer modes you want to cycle them as long as you have found one to choose. Currently it's not possible to cycle through the list and look for the result. If you choose one mode you leave the menu :-(

Thank you all for making Gimp step by step a usable workhorse ;-)

Danko

-> After installing Gimp 2.4.4 win32 - I switched to fullscreen mode only to see if it fails on my dual screen machine - but now it works and goes fullscreen on the current display and not on the primary laptop display reserved for file windows and error messages - Wow!!! Thank You!!! ;-)

Hi,

On Fri, 2008-02-15 at 13:13 -0800, Bill Skaggs wrote:

I'm attaching a screenshot
showing a typical incarnation of the Paint Mode menu, using the Default Gimp theme and Ubuntu's default Human theme. I don't think I have to persuade anybody that this is less than ideal from a usability point of view.

This has been discussed to death and the general consensus is that it is the most ideal solution from a usability point of view. The selected menu entry is always under the mouse pointer and that's the most important thing here from a usability point of view. If you have a better solution than what's currently implemented in GTK+, feel free to propose it on the gtk-developer list.

Your proposal for a two-column layout would make the situation worse, at least for the menu in the Layers dialog which is typically located at the right side of the screen. With a two-column layout it would become more likely that the menu cannot be popped up with the selected menu entry under the pointer.

Sven

I got to thinking some more about this discussion about the mode list UI. What I've really always wanted for the mode list (but didn't want to say because it didn't seem like a good general UI model) is a sort of "mode tool": a way to keep the mode list menu posted so I can change modes on the current layer with a single click.

In a way, the mode list is like the font list in the text tool: that combobox, like the mode option menu, is way too long and unweildy to navigate, but for font choosing you have another option, the Fonts dialog, which makes the process a lot easier. I've always wished I could have something like that for the mode on the current layer, so I could easily try each layer mode sequentially.

And then I realized that it's actually quite easy to have that now, with no gtk changes needed. Just write a little script that changes the current layer's mode to the "next" one. So here it is: http://shallowsky.com/software/gimp/next-mode.py

If you do this layer-changing often, just bind Layer->Next mode to a key, or use tear-offs to keep the Layer menu posted so you just need to click on "Next mode" repeatedly.

And now I no longer wish for some new exotic option menu replacement. :-)

...Akkana

Bill Skaggs writes:

Well, it would be very easy to make the layer mode menu support a tearoff. It can literally be done by adding two lines of C code. (I just tested.)

A tear-off Mode menu from the Layers dialog would be lovely, and would solve every problem I've ever had with that menu.

One possible problem: would Modes from drawing tool options also be tear-off, and would that be a different Modes tear-off from the one in the Layers dialog? Would there be a way to tell them apart?

...Akkana

Hi,

On Sat, 2008-02-16 at 10:47 -0800, Bill Skaggs wrote:

Well, it would be very easy to make the layer mode menu support a tearoff. It can literally be done by adding two lines of C code. (I just tested.)

There are very good reasons why tear-off menus are deprecated. They don't solve usability issues but introduce them. Please let us not even consider such ugly workarounds.

Sven

Hi,

On Sat, 2008-02-16 at 10:11 -0800, Akkana Peck wrote:

In a way, the mode list is like the font list in the text tool: that combobox, like the mode option menu, is way too long and unweildy to navigate, but for font choosing you have another option, the Fonts dialog, which makes the process a lot easier. I've always wished I could have something like that for the mode on the current layer, so I could easily try each layer mode sequentially.

Why don't you just focus the combo-box and use Cursor Up and Cursor Down to go through the layer modes? Or use your mouse-wheel?

Sven

On Feb 17, 2008 5:46 AM, Sven Neumann wrote:

Hi,

On Sat, 2008-02-16 at 10:47 -0800, Bill Skaggs wrote:

Well, it would be very easy to make the layer mode menu support a tearoff. It can literally be done by adding two lines of C code. (I just tested.)

There are very good reasons why tear-off menus are deprecated. They don't solve usability issues but introduce them. Please let us not even consider such ugly workarounds.

I agree that tear-off menus are ugly -- I think the sensible thing to do is tear-off toolbars. For this, of course it helps if every menu item has an icon assigned. I think that if tear-off behaviour was changed like this then it would encourage icon coverage, and particularly, encourage users to contribute icons. If we can then rearrange this toolbar and hide items from it*, that would be ideal for the modes menu. Is there a toolbar equivalent of separators?

* for example, I never use Hard Light, Soft Light, or Overlay; and scarcely use Screen. I use Normal, Grain Merge, Grain Extract, Darken Only, Lighten Only most, so I'd like them first on the toolbar. Similarly for the Select menu, I prefer my own potrace-based 'to path' command and find GIMP's sel2path plugin rather annoyingly inaccurate, and I also prefer my 'exact grow','exact shrink' commands to the GIMP grow/shrink commands.

hmm.
Maybe a popup toolbar would be best for common usage. So you could easily scroll it back and forth while it's just occupying only 1 button space, and get a visual menu with tooltips by activating it.

On Sat, 2008-02-16 at 10:11 -0800, Akkana Peck wrote:

dialog, which makes the process a lot easier. I've always wished I could have something like [a dialog] for the mode on the current layer, so I could easily try each layer mode sequentially.

Sven Neumann writes:

Why don't you just focus the combo-box and use Cursor Up and Cursor Down to go through the layer modes? Or use your mouse-wheel?

Honestly, it's because I didn't realize I could use up/down arrows in option menus without first popping up the menu. :)

That works well for going through modes sequentially. But there are other common issues a tear-off would solve, like when you want to go back and forth comparing two modes that aren't near each other in the menu.

There are very good reasons why tear-off menus are deprecated. They don't solve usability issues but introduce them.

They're deprecated? It figures that something so useful would be. Sigh.

Fortunately, python makes it pretty easy to work around that. If anyone besides me wishes for a tear-off modes menu, you can get one (Layer->Mode dialog...) at: http://shallowsky.com/software/gimp/mode-dialog.py

...Akkana

Hi,

On Sun, 2008-02-17 at 10:05 -0800, Akkana Peck wrote:

There are very good reasons why tear-off menus are deprecated. They don't solve usability issues but introduce them.

They're deprecated? It figures that something so useful would be.

Well, perhaps not deprecated in the "don't use this API" sense. Their use is discouraged. And not by the GTK+ developers but by usability experts. Tearoff menus might sometimes be useful for the power-user but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use. There's a tradeoff here between being useful every once in a while for a very small minority of users and being in the way for everyone almost all of the time.

Tear-off menus are disabled by default in GTK+. GIMP is one of the very few applications that enables them explicitly. If we wouldn't use it, perhaps the GTK+ developers would even have deprecated them in the meantime. At some point we should definitely try to come up with a better solution than tear-off menus for our overloaded menus. Until then we should try not to add them anywhere else.

Sven

On Tue, 19 Feb 2008 08:53:16 +0100, Sven Neumann wrote:

but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use. There's a tradeoff here between being useful every once in a while for a very small minority of users and being in the way for everyone almost all of the time.

Slight over statement about making a menu difficult to use! I used Gimp for years without even realising they were a tear off, I thought it was window decoration at the head of the menu. They never obstructed my usage but once I found out what it was I found it very useful.

I also think we need to be very careful about such hand-wavy hypothetical statements about how many users do or don't use something. Even now Peter has done some user observation which is valuable, the sample size hardly allows extrapolation of the results to the whole user base.

They are a very useful shortcut to the one or two things that a specific work load requires but find them selves buries 3 levels deep in a very crowded menu hierarchy.

One would not want to leave them sprinkled liberally around but they do provide a valuable time saving mechanism for tasks which will be as different as each users job.

My particular use is Edit | Paste as | Paste as new. This I use all the time. In 2.2 it is on the edit menu, so click-drag-release. Fine. Now all that zigzagging to get the extra menu is a major annoyance. A tear-off for this tiny menu would be great but I no longer see any tear-offs. Maybe I need to spend time finding how to get them back.

In any case that's just an example , another guy will want another sub-submenu all the time.

My main critisism of tear-offs is the lack of discoverability. The toilet-paper metaphore is less than obvious unless you've met it elsewhere.

regards /gg

On Tuesday 19 February 2008, Sven Neumann wrote:

They're deprecated? It figures that something so useful would be.

Well, perhaps not deprecated in the "don't use this API" sense. Their use is discouraged. And not by the GTK+ developers but by usability experts. Tearoff menus might sometimes be useful for the power-user but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use.

I have to object here, since I have never seen any user unintentionally use tearoff menus. On the other hand I find them very useful, especially with window manager features like window shading and unshade on mouse-over, I use them in my everyday work, not only in GIMP but also in e.g. xmgrace. Benefits I see are easy access to hidden parts of menus that are not used often enough (on the long term average) to deserve a key shortcut (I might need that special sub menu quite a few times only on this very special image) or for trying out several entries, as was discussed enough earlier in this thread.

I don't think that the issue of tearoffs should be seen as a field of conflict between "power users" and "normal users". As /gg has pointed out already, the latter probably won't even notice the tearoffs while the former still can deliberately decide for or against them.

Just my 2¢, Daniel

Hi,

On Tue, 2008-02-19 at 12:35 +0100, Daniel Hornung wrote:

Well, perhaps not deprecated in the "don't use this API" sense. Their use is discouraged. And not by the GTK+ developers but by usability experts. Tearoff menus might sometimes be useful for the power-user but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use.

I have to object here, since I have never seen any user unintentionally use tearoff menus.

That is not the point. The point is that almost all of the time you don't need the tear-off functionality. But it's there, and it is slowing you down because you have to move the mouse a little further and your eye has to skip the extra visual clutter that it adds.

On the other hand I find them very useful, especially with window manager features like window shading and unshade on mouse-over, I use them in my everyday work, not only in GIMP but also in e.g. xmgrace. Benefits I see are easy access to hidden parts of menus that are not used often enough (on the long term average) to deserve a key shortcut (I might need that special sub menu quite a few times only on this very special image) or for trying out several entries, as was discussed enough earlier in this thread.

Exactly. This is why GIMP still has them enabled by default. Note that I didn't suggest to turn them off. With our deep menu hierarchy, tear-off menus are definitely very useful.

Long term it would be nice if we could get rid of our insane menu hierarchies and at that point we should also consider to disable tear-off menus.

Sven

On Feb 20, 2008 5:24 AM, Sven Neumann wrote:

Hi,

On Tue, 2008-02-19 at 12:35 +0100, Daniel Hornung wrote:

Well, perhaps not deprecated in the "don't use this API" sense. Their use is discouraged. And not by the GTK+ developers but by usability experts. Tearoff menus might sometimes be useful for the power-user but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use.

I have to object here, since I have never seen any user unintentionally use tearoff menus.

That is not the point. The point is that almost all of the time you don't need the tear-off functionality. But it's there, and it is slowing you down because you have to move the mouse a little further and your eye has to skip the extra visual clutter that it adds.

On the other hand I find them very useful, especially with window manager features like window shading and unshade on mouse-over, I use them in my everyday work, not only in GIMP but also in e.g. xmgrace. Benefits I see are easy access to hidden parts of menus that are not used often enough (on the long term average) to deserve a key shortcut (I might need that special sub menu quite a few times only on this very special image) or for trying out several entries, as was discussed enough earlier in this thread.

Exactly. This is why GIMP still has them enabled by default. Note that I didn't suggest to turn them off. With our deep menu hierarchy, tear-off menus are definitely very useful.

Long term it would be nice if we could get rid of our insane menu hierarchies and at that point we should also consider to disable tear-off menus.

I think something that would help here is if we could bind keys to menus. For example, the GIMP-GAP 'video' menu -- it would be more practical to access this way. And in general, it would be pretty effective for common tasks, if we could also do things like defining a custom menu that includes

sel gauss blur selection to path
path to selection
fill selection with FG

and then bind it to '2', so commonly done tasks were quicker to do and required less thought. In my experience, it would be useful to be able to define menus per:

gimp -- ie tasks that are done a lot independent of what the current image is image -- common tasks for this specific ...image drawable -- ... drawable
path -- ... path

I'll have a go at making a mockup. My basic idea for this simple sort of menu editing is DnD based: open the 'gimp' custom menu, creating it if it doesn't exist, then leave it open in a window like a tearoff, and DnD menu items into it to add them, out of it to remove them, and move them in the normal DnD way.

As a whole, I believe this would allow us to leave a lot more out of the default menus, and have the removed items instead in something like an actions treeview dockable (using a treeview would hopefully allow easy DnD of submenus)

Sven

On Tue, 2008-02-19 at 09:52 +0100, gg@catking.net wrote: [...]

My main critisism of tear-offs is the lack of discoverability. The toilet-paper metaphore is less than obvious unless you've met it elsewhere.

This is where the push-pin is a real win.

Another example in GIMP is docking pallettes -- the only way you can tell that this is possible is because GIMP starts with some pallettes already docked.

Or because you read about it in "tip of the day", which really ought to have l"learn more" links into the documentation, so that e.g tear-off menus could be explained.

Liam