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 <peter@xxxxxxxxxxxx> 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 > > > > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
