Quoting Alexandre Prokoudine <alexandre.prokoud...@gmail.com>:

>>> 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  

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  

Gimp-developer mailing list

Reply via email to