On Sun, Jul 25, 2010 at 3:04 PM, Vincent Beers wrote:

Hi, I have a feature/enhancement request.

Currently, the GIMP shows the program's menu when right-clicking within the drawing area. However, this seems superfluous as the menu is already displayed
at all times.

This is certainly false. You can hide the menu bar, as well in normal mode as in full screen mode, and you can handle an image so large that the menu bar is out of the screen. The menu bar available on a right click is absolutely necessary, it is the only certainly available way to get the menu bar.

On Sun, Jul 25, 2010 at 3:52 PM, Vincent Beers wrote:

While you have a point about being able to hide the menu bar, doesn't the main window never get larger than the screen size, meaning that your window title and everything in it will always be visible?

This limitation does not exist. Suppose I have an image 4000x6000 and I want to look at it at 100%, or an image 400x600 and I want to look at it at 800%. If I shrink wrap it (Ctrl+E with version 2.6, or Ctrl+J with version 2.8), certainly the window will be larger than my screen. Since I can easily move it using some key combination and the mouse, I can look at various parts of the image, and be not limited by my screen size.

Actually, I have encountered no other image manipulation suite that would obscure the menu bar like this other than the GIMP. I'm not saying that it is a bad thing, just that it removes the chance to do anything else with said button. For a mouse button, which is one of the buttons that is easily and quickly clickable, opening a menu might not be the most desired action to give it.

I cannot count how many times I have been happy to be able to reach almost everything from a simple right-click. If other image manipulation applications cannot offer this possibility, too bad for them.

If accessing the menu is absolutely necessary in this way, why not map it to another common key (like tapping the space bar) and leave an extra mouse button to added editing power? Or perhaps use the context menu button on the keyboard to good use.

The space bar is invaluable as a way to move the image withing its window. Why do you want to confiscate existing possibilties, instead of unused keyboard and mouse combinations?

If you really can't go without the right-click-menu thing, how about making it more context sensitive, then? Show appropriate options when you right-click a selection or a text box for example, with the original menus shown below the context sensitive options.

Same remark as above. I would suggest you to propose new combinations for

interesting, new capabilities, but not try to remove somewhat which has existed from the first version of GIMP, simply because you don't use it.

Vincent Beers

On 25 July 2010 15:15, Olivier wrote:

On Sun, Jul 25, 2010 at 3:04 PM, Vincent Beers wrote:

Hi, I have a feature/enhancement request.

Currently, the GIMP shows the program's menu when right-clicking within the
drawing area. However, this seems superfluous as the menu is already displayed
at all times.

This is certainly false. You can hide the menu bar, as well in normal

mode

as in full screen mode, and you can handle an image so large that the

menu

bar is out of the screen. The menu bar available on a right click is absolutely necessary, it is the only certainly available way to get the

menu

bar.
--
Olivier Lecarme

On 7/25/10, Olivier wrote:

I cannot count how many times I have been happy to be able to reach almost everything from a simple right-click. If other image manipulation applications cannot offer this possibility, too bad for them.

Don't use 2.7 and above then, 'cause Text tool now has its own right-click menu and its *useful*.

GIMP has three ways to access menu currently: menu bar, top-left button where ruler's origin is and right-click menu. This is bloat.

Besides, as already mentioned, some tools can make a much better use of right-click menu then simply duplicating contents of the whole app's menu. Consistence in UI is a number one priority.

interesting, new capabilities, but not try to remove somewhat which has existed from the first version of GIMP, simply because you don't use it.

Dear Olivier, the "because we always did so" kind of argumentation is an utter nonsense. Please never use it. It's wrong and causes holy wars, cancer, premature bald spots and heart attacks. Also, god kills a kitten every time you say that.

The history of GIMP has proved that some things that were understood as right turned out to be completely wrong.

Alexandre Prokoudine http://libregraphicsworld.org

Let me respond to the points that have been made in this thread. The first thing
to say is that there are solid arguments in both directions, and any decision is a
trade-off, so there is no need to insult one side or the other.

The global popup menu is certainly useful; I have used it very often. The context
menu for the text tool was introduced as part of on-canvas text editing. It was
introduced because on-canvas editing could not work without it -- there was no
reasonable way to access text versions of Copy and Paste and other essential commands except by using a context menu. Mitch has been working on a set of canvas widgets that may do the job, but they were not available when on-canvas
text editing was developed. Once they work well, it might be possible to get rid of
the text tool context menu.

There are other tools that also would benefit greatly from either a context menu
or an on-canvas control. The clearest is the paths tool -- for example, it would
be very valuable to be able to mark a path vertex as "smooth", by constraining the
two handles to always point in opposite directions. That would be easy to implement,
but there is currently no good way to give the user access to it. It is easy to come
up with other examples.

In summary, popup context menus and popup global menus are both useful; the only question is which one is more important.

-- Bill

On 7/25/10, Bill Skaggs wrote:

The global popup menu is certainly useful; I have used it very often. The context menu for the text tool was introduced as part of on-canvas text editing. It was introduced because on-canvas editing could not work without it -- there was no reasonable way to access text versions of Copy and Paste and other essential commands except by using a context menu. Mitch has been working on a set of canvas widgets that may do the job, but they were not available when on-canvas text editing was developed. Once they work well, it might be possible to get rid of the text tool context menu.

Well, if you try it right now you will also see commands like "Load text" or "Text along path". I'm not entirely sure that it's going to look good on canvas. Anyway the whole set of new features regarding Text tool from 2.7.1 hasn't gone though usability meat-grinder yet, afaik.

There are other tools that also would benefit greatly from either a context menu or an on-canvas control. The clearest is the paths tool -- for example, it would be very valuable to be able to mark a path vertex as "smooth", by constraining the two handles to always point in opposite directions.

I'm not sure about that one. Pippin's abandoned test tool for GEGL had a much simpler on-canvas implementation.

In summary, popup context menus and popup global menus are both useful; the only question is which one is more important.

I agree about trade-offs, the only thing I disagree with is the "we always did so/had it" argument. There are better ways to evaluate usefulness of a feature than that.

Another thing is that with all those ipads and other similar devices coming and taking over the market usefulness of right-click menu per se is becoming questionable.

Alexandre Prokoudine http://libregraphicsworld.org

Bill Skaggs wrote:

The global popup menu is certainly useful; I have used it very often. The context
menu for the text tool was introduced as part of on-canvas text editing. It was
introduced because on-canvas editing could not work without it -- there was no
reasonable way to access text versions of Copy and Paste and other essential
commands except by using a context menu.

hoho, when that was discussed I was there and I made it very clear that the
only acceptable way to do copy/paste in the text tool is via the standard
commands in the Edit menu, with their standard command keys.

Let me also give general guidance on what a right click menu is for, what
its place is in desktop UI systems.

The right click menu is a _secondary_ way to get things done. First of a primary way has to be UI designed to do something: like an item in the menu bar (see copy/paste), a tool options item, an on screen widget (text editing toolbar, a control node on a curve), widgets in dialogs.

Only after the primary way is designed and implemented, is it time to think what could be in the right click menu. It is an 'acceleration' mechanism (although I consider it slow and finicky) like command keys, although more locally targeted. So the choice to make becomes 'what are the limited number of items that are so important they need to be also here in this menu?'

One last note to those users who find right click menus incredibly useful and even perceive using them as fast (note, perceive): I do not have the numbers whether 30, 40 or an unbelievable 60 percent of users are like you, but it is certainly not more. So the rest of us is not enjoying using right click menus so much.

And the right attitude towards right click menus is always to try to solve it in a better way first (see above). SO for instance our full-screen mode and the menu bar. I am asking myself: could we not show the menu bar when the mouse sprite is moved against the top of the screen (after a short, 0.5s, timeout)? fading or sliding in would be nice...

--ps

founder + principal interaction architect man + machine interface works

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

Quoting Alexandre Prokoudine :

On 7/25/10, Olivier wrote:

I cannot count how many times I have been happy to be able to reach almost everything from a simple right-click. If other image manipulation applications cannot offer this possibility, too bad for them.

Don't use 2.7 and above then, 'cause Text tool now has its own right-click menu and its *useful*.

However, the Text tool's contextual menu is only presented when the right-click occurs within the text frame; right-clicking outside of the frame still provides access to main menu.

GIMP has three ways to access menu currently: menu bar, top-left button where ruler's origin is and right-click menu. This is bloat.

The first two methods are not always available.

Besides, as already mentioned, some tools can make a much better use of right-click menu then simply duplicating contents of the whole app's menu. Consistence in UI is a number one priority.

While not a sufficient reason for rejection, it should be noted that such a change (so that tools could have their own right- and/or middle-click functions) would require modifying the code of all the tools (currently all mouse click events are treated by tools as left-clicks since right- and middle-clicks would have already been intercepted).

"Consistence in UI" would seem to me an argument FOR the current behavior, especially if one considers that other types of input devices (pads, pens, touchscreens, etc) commonly share only a single type of triggering "click". Imposing a "left-click"-only constraint on tools is certainly limiting, but it simplifies the task of learning the interface (not to mention coding to it, maintaining it, and documenting it).

interesting, new capabilities, but not try to remove somewhat which has existed from the first version of GIMP, simply because you don't use it.

Dear Olivier, the "because we always did so" kind of argumentation is an utter nonsense. Please never use it. It's wrong and causes holy wars, cancer, premature bald spots and heart attacks. Also, god kills a kitten every time you say that.

Far from being "utter nonsense", consistency over time is a valid engineering consideration in any assessment of trade-offs of proposed product changes. This is especially true of user interface changes which have significant downstream impact upon other developers, document teams, and language translators (edit: I almost forgot, and users).

The history of GIMP has proved that some things that were understood as right turned out to be completely wrong.

Undoubtedly true. Nonetheless, the vast majority of the approaches taken by GIMP in the past were the result of sober appraisal and sound reasoning at the time. Certainly circumstances may change and opportunities arise to improve things; but decisions made previously by GIMP developers should not be dismissed lightly, and especially not without reasonable consideration of the original reasons behind them.

I have no real objection to modifying the image window context menu behavior. I will say that I often use windows which have neither rulers nor menubar displayed and it is absolutely critical that a way of accessing the menu be available. I'd have no objection to an ALT+right-click option or somesuch; however, I should not be surprised if, after due consideration, the costs of allowing tools to respond to middle- or right-button mouse events are deemed not to outweigh the benefits.

On 7/25/10, peter sikking wrote:

I am asking myself: could we not
show the menu bar when the mouse sprite is moved against the top of the screen (after a short, 0.5s, timeout)? fading or sliding in would be nice...

It should be possible. Firefox rolls out button bar and tabs when you hover mouse pointer at top of the full-screen window.

Alexandre Prokoudine http://libregraphicsworld.org

On 7/25/10, saulgoode wrote:

GIMP has three ways to access menu currently: menu bar, top-left button where ruler's origin is and right-click menu. This is bloat.

The first two methods are not always available.

As already mentioned above, menubar could simply roll out when needed. Needless to say, menu accelerators weren't invented out of curiosity :)

"Consistence in UI" would seem to me an argument FOR the current behavior,

Funny you should say that, because the current way it *is* inconsistent with the rest of UI. You see, the other word for "right click menu" is "context menu". Now let's have a look.

Layers dialog. Right-click displays items related only to layers. Check. Channels dialog. Right-click displays items related only to channels. Check. Paths dialog. Right-click displays items related only to paths. Check. Brushes dialog. Right-click displays items related only to brushes. Check.

And the list goes on.

Presumably right-click for canvas would display things related to objects on canvas. Does it? No.

See? :)

especially if one considers that other types of input devices (pads, pens, touchscreens, etc) commonly share only a single type of triggering "click".

So what you are saying is, in fact, that since other types of input devices do not provide ability to do right-click, the current menu on right-click is the right thing? Did I get that right? :)

Besides, I already mentioned that it is exactly the reason why usefulness of right-click menus is becoming questionable. So where exactly do we disagree and what are we arguing about? :)

reasoning at the time. Certainly circumstances may change and opportunities arise to improve things; but decisions made previously by GIMP developers should not be dismissed lightly, and especially not without reasonable consideration of the original reasons behind them.

Which is exactly my point. Once again: what are we arguing about? :)

Alexandre Prokoudine http://libregraphicsworld.org

Quoting Alexandre Prokoudine :

GIMP has three ways to access menu currently: menu bar, top-left button where ruler's origin is and right-click menu. This is bloat.

The first two methods are not always available.

As already mentioned above, menubar could simply roll out when needed.

That would only cover full-screen mode (and might create difficulty with GIMP deployments on operating systems where the Display Manager is already employing rollout menus for the system menus). It does not solve the problem created by windowed Views that don't have rulers or menubar; and it does not solve the problem of windows which are not wide enough to accommodate the menubar.

Needless to say, menu accelerators weren't invented out of curiosity :)

I prefer not to use menu decelerators, and I do not think they constitute a discoverable interface when the menu is not accessible. Shouldn't we consider the case of view windows so small that the some of the Layer|Colors|Tools|Filters|Windows|Help menus aren't available?

"Consistence in UI" would seem to me an argument FOR the current behavior,

Funny you should say that, because the current way it *is* inconsistent with the rest of UI. You see, the other word for "right click menu" is "context menu". Now let's have a look.

Layers dialog. Right-click displays items related only to layers. Check. Channels dialog. Right-click displays items related only to channels. Check. Paths dialog. Right-click displays items related only to paths. Check. Brushes dialog. Right-click displays items related only to brushes. Check.

And the list goes on.

Presumably right-click for canvas would display things related to objects on canvas. Does it? No.

Actually, in all of those examples it is the particular tab's window menu which is displayed when right-clicking anywhere within the tree view -- entirely consistent with the image menu being displayed when right-clicking on the canvas. To my knowledge there is NO instance of right-clicking on an object in GIMP raising a context menu (unless you consider the treeview area or canvas area an object).

I see no reason this can't change, even in the Image window -- the Text and Paths tools have already been presented as providing useful examples. However, I do think that right-clicking on the image canvas raising the Image menu is important, and would propose that only Tool controls be treated as "objects" which can have their own context menus. Having particular graphical elements of the image itself (layers, text, paths) display a context menu seems misguided.

especially if one considers that other types of input devices (pads, pens, touchscreens, etc) commonly share only a single type of triggering "click".

So what you are saying is, in fact, that since other types of input devices do not provide ability to do right-click, the current menu on right-click is the right thing? Did I get that right? :)

Besides, I already mentioned that it is exactly the reason why usefulness of right-click menus is becoming questionable. So where exactly do we disagree and what are we arguing about? :)

I'm not sure to what extent we disagree, other than I see very little reason to eliminate the canvas context menus, some potential problems if they are removed, and a few reasons (ones important to me) to keep them.

I have been more and more moving away from using the main menu as I become more proficient at GIMP -- finding the use of tear-offs and the context menu quite beneficial to my workflow. The main menu is, to me, often just wasted screen space and I find the ability to hide worthwhile. I don't expect that GIMP should be catering to my own needs or expectations, but if functionality is being considered for removal from GIMP, I think it is appropriate for those who appreciate that functionality to say so.

My apologies if my post was too much of a "knee-jerk" reaction to the proposal.

First off, sorry for the top post, but I thought this is isn't directly related to the question "what to do with the right mouse button / context menu". It was, however, something that hit me while I was thinking about it. When I read this list, I normally just read the emails consider some different approaches to the problems, and then shut up anyway, since there are a lot more intelligent people here anyway so I don't need to pollute the list.

I don't know if this has been discussed before (although I have been around for a couple of years now, I forget stuff), so if it's been discussed and thrown out before, just ignore me and I'll crawl back underneath that rock again.

Anyway, back to the right mouse button / context menu. The entire point of having the right mouse button map to a secondary tool, for me anyway, would be speed. At first, I though, well we have that, although they're predefined (ctrl/alt/shift/etc will sometimes switch to different tools), we could have another key do the secondary tool thing. Someone suggested space, but I've got to agree, space for moving around is *awesome*. I really miss that when I'm working with Photoshop, so please don't change that. :) So, speed. Blender has a different approach, where different keys bring up different menu's around the mouse, and although it takes a while to learn, once you have, it's fairly easy and fast to switch back and fourth between a bunch of modes. Then again, I don't think we want that kind of steep learning curve for GIMP. So my mind wandered a bit and I got to thinking about the UI in some computer games I've seen which could be really cool. The toolbox is usually far away, and each tool is a fairly small button (which aren't on the edge of the screen, which would make them fairly large, in UI design terms), how about we move them in closer? Consider a button/key which you press, which brings up a circle of tools around the mouse pointer, perhaps an inch or two in diameter (keeping it animated improves visual coherence, or so I've been told, perhaps have them zoom out from under the cursor), move your mouse to your tool (which could expand a little to make it a bigger target) and let go of the button/key to choose it. Sub-tools/variants could be a bit farther away (perhaps a bit smaller, and a bit transparent), in the same direction.

Computer games do have a knack of finding UIs which are fast and easy to learn. The only thing they're not is 'conforming' to standard UI elements (not that they'd want to).

I'm not saying the right mouse button is the best use for such a feature (I actually think it wouldn't be, I prefer the keyboard), but it might be a good option. I'd be willing to work on such a feature.

Greetings, Fredrik.

On Sun, Jul 25, 2010 at 19:35, peter sikking wrote:

Bill Skaggs wrote:

The global popup menu is certainly useful; I have used it very often.  The context
menu for the text tool was introduced as part of on-canvas text editing.  It was
introduced because on-canvas editing could not work without it -- there was no
reasonable way to access text versions of Copy and Paste and other essential
commands except by using a context menu.

hoho, when that was discussed I was there and I made it very clear that the
only acceptable way to do copy/paste in the text tool is via the standard
commands in the Edit menu, with their standard command keys.

Let me also give general guidance on what a right click menu is for, what
its place is in desktop UI systems.

The right click menu is a _secondary_ way to get things done. First of a primary way has to be UI designed to do something: like an item in the menu bar (see copy/paste), a tool options item, an on screen widget (text editing toolbar, a control node on a curve), widgets in dialogs.

Only after the primary way is designed and implemented, is it time to think what could be in the right click menu. It is an 'acceleration' mechanism (although I consider it slow and finicky) like command keys, although more locally targeted. So the choice to make becomes 'what are the limited number of items that are so important they need to be also here in this menu?'

One last note to those users who find right click menus incredibly useful and even perceive using them as fast (note, perceive): I do not have the numbers whether 30, 40 or an unbelievable 60 percent of users are like you, but it is certainly not more. So the rest of us is not enjoying using right click menus so much.

And the right attitude towards right click menus is always to try to solve it in a better way first (see above). SO for instance our full-screen mode and the menu bar. I am asking myself: could we not show the menu bar when the mouse sprite is moved against the top of the screen (after a short, 0.5s, timeout)? fading or sliding in would be nice...

    --ps

        founder + principal interaction architect             man + machine interface works

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

2010/7/26 Fredrik Alströmer :

Consider a button/key which you press, which brings up a circle of tools around the mouse pointer, perhaps an inch or two in diameter (keeping it animated improves visual coherence, or so I've been told, perhaps have them zoom out from under the cursor), move your mouse to your tool (which could expand a little to make it a bigger target) and let go of the button/key to choose it. Sub-tools/variants could be a bit farther away (perhaps a bit smaller, and a bit transparent), in the same direction.

I personally quite like the idea but GIMP currently lacks the infrastructure to have such feature. Computer games have a slight advantage of not having to deal with window managers and toolkit limitations as a rule. The whole UI is custom rendered anyway. There seems to be a consensus that on canvas widgets are needed however. There is GSoC project slightly related, but I dont know how that progresses. Guiguru has final word on these things usually, so discussing this in depth with him might be good, if you plan to have a go at it.