Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
> 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? This is why I said *tapping* the space bar. Since moving around the image is strictly a hold button action, the space bar could still have the secondary action of showing the menu when it's tapped. Not the best idea, perhaps, but certainly accessible. > 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. But the thing is, I did not expect that many people actually *are* using it. Sure, I have a personal perspective, but general imporoved usability for everyone is what I'd think about first. And about this point itself, in the suggestion this was a reply to, none of the original functionality *was* actually removed. I suggested to have the context menu with the original options (File, ...) below the context-sensitive options. At this point, I think a context-sensitive context menu would work better than my initial suggestion about having a secondary tool, because a context menu certainly is more useful. But I also think it would be useful if there was a way to save your current tool/color settings and then load them later, for a quick switch between them. But that's a different suggestion now. > we could have another key do the secondary tool thing. Yeah, that would work nicely. I'm glad there is a discussion going on about the context menu now, because such a feature could definitely come in useful (as long as it's executed right). 2010/7/26 Alexia Death : > 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. > > -- > --Alexia > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > -- http://davince.tengudev.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
On Sunday 25 July 2010 18:37:09 Bill Skaggs wrote: > the only question is which one is more important. Or how they can be combined in a clever way ;) UI designers to the rescue, but I'm certain that restricting the future to either possibility is not the optimum. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 > > > -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
