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