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 pe...@mmiworks.net 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
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
2010/7/26 Fredrik Alströmer r...@excu.se: 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
[Gimp-developer] Bug Bug 568150 With 'Resize window on zoom', zoom focus does not work when window is of maximum size
Hi, I think this bug can be fixed by the attached patch. The function gimp_display_shell_scale () is modified so that when the window if of the maximum size, zoom in will be processed in the same way as the situation that Resize window on zoom is not selected. I have checked Photoshop CS5 and found it has a similar behavior. This patch is just the illustration of the idea. I am happy to make any modification to it if there are any mistakes. Cheers, Xianghang patch Description: Binary data ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug Bug 568150 With 'Resize window on zoom', zoom focus does not work when window is of maximum size
xianghang liu wrote: I think this bug can be fixed by the attached patch. great. I trust that the solution is the right thing because Martin pointed out in the bug what should happen and where to repair it. I have checked Photoshop CS5 and found it has a similar behavior. uhm, can I (without drama) say that that proves exactly nothing for us? in general, a the right UI solution for us is: - good UI design in general - fits the context of GIMP (metaphors, models, legacy) on both counts ps can be pointing in exactly the wrong direction. --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
[Gimp-developer] Please fix Color and/or Value transfer mode
Hello all, I've joined up with this list to make an important suggestion for improvement. In short, the Color and Value blending, transfer modes in GIMP do not work as they should. The problem is compounded by the fact that there seems to be no application on Linux where these transfer modes work correctly. In fact, it seems all the major applications use the same or very similar algorithms. So the problem is the same in Krita (which uses GEGL as far as I know) and in ImageMagick. To confirm the problem, try this: * Open an image in GIMP, preferrably one that has noticeable noise, and the noise should be coloured, not merely monochromatic. * Duplicate the image into a new layer and blur it, say by 5 points. * Set the transfer mode of the blurred layer to Color. What should happen is that the colour component of the noise should be eliminated, but the luminance/value should remain the same. This is not the case, the result worsens the luminance noise! If you have trouble seeing this, zoom into the image up to 400% or try an image with more obvious noise. Also, try increasing the blur factor. Now by comparison, repeat the experiment in Photoshop. You won't fail to notice that in Photoshop this works correctly. The colours are more muted, perhaps 'leaking' over colour boudaries, but the luma noise is not made worse. The same effect is at play the other way round, if Value is used instead of Color (and it's the bottom layer that is blurred). And the same effect is also at play if instead of layer blending, the blending is done in the Fade command dialog. In short, there is no correct way yet of using these transfer modes on Linux and a proper solution is desperately needed. By the way, I'm using GIMP 2.6.8. I appreciate that 2.7.1 is using GEGL as will 2.8, but I doubt that will in itself offer the solution, because Krita is using GEGL and the problem there is the same. Thank you for listening and good luck with the coding. Charlie ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please fix Color and/or Value transfer mode
I believe you're asking for http://bugzilla.gnome.org/show_bug.cgi?id=325564 http://bugzilla.gnome.org/show_bug.cgi?id=325564which has been addressed when using GEGL. Seth On Mon, Jul 26, 2010 at 6:33 AM, Charlie De charlieco...@yahoo.com wrote: Hello all, I've joined up with this list to make an important suggestion for improvement. In short, the Color and Value blending, transfer modes in GIMP do not work as they should. The problem is compounded by the fact that there seems to be no application on Linux where these transfer modes work correctly. In fact, it seems all the major applications use the same or very similar algorithms. So the problem is the same in Krita (which uses GEGL as far as I know) and in ImageMagick. To confirm the problem, try this: * Open an image in GIMP, preferrably one that has noticeable noise, and the noise should be coloured, not merely monochromatic. * Duplicate the image into a new layer and blur it, say by 5 points. * Set the transfer mode of the blurred layer to Color. What should happen is that the colour component of the noise should be eliminated, but the luminance/value should remain the same. This is not the case, the result worsens the luminance noise! If you have trouble seeing this, zoom into the image up to 400% or try an image with more obvious noise. Also, try increasing the blur factor. Now by comparison, repeat the experiment in Photoshop. You won't fail to notice that in Photoshop this works correctly. The colours are more muted, perhaps 'leaking' over colour boudaries, but the luma noise is not made worse. The same effect is at play the other way round, if Value is used instead of Color (and it's the bottom layer that is blurred). And the same effect is also at play if instead of layer blending, the blending is done in the Fade command dialog. In short, there is no correct way yet of using these transfer modes on Linux and a proper solution is desperately needed. By the way, I'm using GIMP 2.6.8. I appreciate that 2.7.1 is using GEGL as will 2.8, but I doubt that will in itself offer the solution, because Krita is using GEGL and the problem there is the same. Thank you for listening and good luck with the coding. Charlie ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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
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 alexiade...@gmail.com: 2010/7/26 Fredrik Alströmer r...@excu.se: 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] Creating unique file names with Script-Fu
saulgo...@flashingtwelve.brickfilms.com wrote: I hadn't realized that the TinyScheme Extensions had been enabled for Script-fu. Script-Fu in GIMP uses a subset of the TSX (TinyScheme eXtensions) module. The 'getenv', 'system', and various additional functions which supported use of sockets were left out. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
