[Gimp-developer] Enhancement request: better utilization of mouse buttons
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. I think the GIMP's usability could be enhanced if instead, the right mouse button did something more useful. Here's my suggestion: - You can map a secondary drawing tool and color by right-clicking a tool or the color palette. - You can use this secondary tool by using it as usual, with the difference that you use the right mouse button instead of the left one. This adds convenience to the GIMP by allowing you to use two different tools (or drawing colors) without having to constantly switch, and it also keeps compatibility with (for example) 1-button mice as it's only an added convenience. Besides the right mouse button, there are more buttons on some multimedia mice that could be put to good use. For example, the middle mouse button and scroll wheel are already used in a good manner, but perhaps the next/previous buttons that some mice have could have actions bound to them too (like undo/redo?). Vincent Beers -- 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
On Sun, Jul 25, 2010 at 3:04 PM, Vincent Beers vincentbe...@gmail.comwrote: 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
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
On Sun, Jul 25, 2010 at 3:52 PM, Vincent Beers vincentbe...@gmail.comwrote: 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 oleca...@gmail.com wrote: On Sun, Jul 25, 2010 at 3:04 PM, Vincent Beers vincentbe...@gmail.com 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 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
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 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
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
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
Quoting Alexandre Prokoudine alexandre.prokoud...@gmail.com: 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] Help a newbie fill in some holes
I want to thank everyone who responded. The AutoRotate script does what I want, pretty much. I am studying Scheme, which looks adequate to handle my desire for drawing shapes to call out parts of screen captures. Afterwards, I plan to start trying to comprehend the GIMP project, which seems necessary for drawing arrows. I'm finding the documentation difficult. I don't mean that I don't understand the vast amount of work put into it nor the completeness of what's there. I think my problem is more a matter of a beginner being overwhelmed by the size and the number of choices. What I've found very helpful in other projects of this type is a community wiki, where a beginner like me can submit a here's how I took my first step tutorial. The problem is the first steps are incomprehensible until you take them, then they become trivial. People who know the project can't really think up the questions, although they are the ones with the answers. (Rereading that, I hope it makes sense to someone besides me). Just for the record, I've been using GIMP almost exclusively these days and hopefully will be contributing to the project soon. Joe ___ 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
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] about getting involved in developing Gimp
Sven Neumann sven at gimp.org writes: Despite the fact that GIMP has a very clearly defined vision and very interesting features on the roadmap, it may be true that this isn't communicated well enough. But this is a matter that should be discussed on the gimp-web mailing-list. What we are lacking even more than programmers is a capable and thrust-worthy sysadmin to overhaul our web services. Sven isn't communicated well enough Is an understatement. If there is a roadmap or a vision somewhere, it is completely invisible to anyone outside the team. What I had in mind by restart is to present a future vision of GIMP in a manner so attractive that it would find its way into relevant blogs and websites such as slashdot. This vision should be used as a recruitment tool: it should be made clear that the project is actively seeking new developers so people that click the link to see what GIMP has in store. Speaking of which, the current state of GIMP can also be used to raise some excitement, but that won't happen unless you supply easily installed test development builds for Linux and Windows. It took me some time to compile 2.7.1 myself, and while I assume any developer should be able to do that as well, not supplying development binaries can raise some doubts: do you have something to hide? do you distrust your users? do you want to make it hard on them on purpose? It's all a matter of public perception. PS: Could you pretty please learn to spell the name of the program properly? It is called GIMP or GNU Image Manipulation Program and not Gimp. Ah, capitalization... yes, that is not my strong point. Don't take it personally, I also forget to capitalize sentences and proper names sometimes. I will see to it that I don't make that mistake again. Hey, at least I didn't use a definite article. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about getting involved in developing Gimp
On 7/22/10, Michael Grosberg wrote: Forgive me for my presumption... I'd like to use this thread to address this lack of programmers. Don't you find it weird that a project like Gimp, which in theory is a very useful application, with a very broad appeal, draws less programmers than, say, Blender or Inkscape? Inkscape doesn't really draw many more programmers. It's a very small team that is currently in flux. I think the reason is lack of vision http://gui.gimp.org Please read it carefully isn't out of the question - Blender did it. A logo and/or website redesign contest might help in engaging the artist user base. There is a website redesign in progress. Check 'html5' gimp-web branch. What do you think? I think that you are volunteering to do some of marketing work :) 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] about getting involved in developing Gimp
On 7/26/10, Michael Grosberg wrote: What I had in mind by restart is to present a future vision of GIMP in a manner so attractive that it would find its way into relevant blogs and websites such as slashdot. Slashdot. Right. That's where GIMP developers are blamed every time whatever they do. What a nice idea :) As a matter of fact, GIMP is rather regularly and nicely covered by Ars Technica. Check :) unless you supply easily installed test development builds for Linux and Windows. It took me some time to compile 2.7.1 myself, and while I assume any developer should be able to do that as well, not supplying development binaries can raise some doubts: do you have something to hide? Michael, dealing with people who have this sort of doubts is not the job for programmers. It's psychiatry. You need a special training for that. Let's not dive into the pool of amusing misconceptions. Providing nightly builds or dev builds is not a programmers job. If somebody wants to do it, let this person speak up and bloody well do it. It's been stated in public many times that GIMP team needs all kinds of help. In my experience it doesn't make any sense telling the team what to do. Now what *does* make sense is step up and say Hi, I want to help you by doing this and that. How do I proceed? So I'm tempted to ask: do you volunteer to help the team with raising awareness of things? 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] about getting involved in developing Gimp
On Sun, Jul 25, 2010 at 10:52 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Michael, dealing with people who have this sort of doubts is not the job for programmers. It's psychiatry. You need a special training for So true. -- Branko Vukelić bg.bra...@gmail.com stu...@brankovukelic.com Check out my blog: http://www.brankovukelic.com/ Check out my portfolio: http://www.flickr.com/photos/foxbunny/ Registered Linux user #438078 (http://counter.li.org/) I hang out on identi.ca: http://identi.ca/foxbunny Gimp Brushmakers Guild http://bit.ly/gbg-group ___ 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 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 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
