Re: [Gimp-developer] Negative Press
This is why I suspect it to be a transparency problem and not really a process problem. People actually Won't criticize a process if they think it is doing a good job. In the case of the GUI team, we don't know if it's doing a good job. In fact, we don't see a job being done at all. Who are these we? Clearly I am not one of them, because I benefit from new rectangle tools that come out of a spec created by the UI design team, because I can read things like http://gimp-brainstorm.blogspot.com/2007/10/team-review-contribution-2650.html etc. The we are the 80% users who expect UI improvement to be a lot more than just a new design for the rectangular tools, and won't bother reading every single post on the gimp-brainstorm blog, much more so since the only link is in the pile of ways to contribute list which does Not include Check here for future UI improvement plans. Solve the transparency problem, and the criticism will go away. You say what to do, but you don't say how. Yes I did, in perhaps such an extensive manner that you didn't bother reading it from my previous response to this topic. Here it is again since you've missed it: The easiest solution, as far as I can tell, is actually to apply the same principle that the GIMP site's Feature page and that the GIMP UI brainstorm blog apply themselves: using pictures to speak a thousand words. The summary would basically roughly serve the same purpose as a visible 2.6 milestone (which should also have mock-ups) would from a PR point-of-view: show people what's in planning so that people won't think of GIMP as a dead project that isn't moving anywhere. Inkscape has a screenshots section for future features, and that does wonders for showing people the future evolution of the program. Are there any plans for a Future feature page on the GIMP website? If there is, it could be made up of two sections: - Future features (with mock-ups based on the 2.6 milestone) - Future GUI improvements (a whole section dedicated to GUI improvement! This is sure to score points among critics of the GIMP interface) The future GUI improvement section could contain screenshots of a few key UI improvements in planning (they don't need to include everything), with eventually an explanation of dependencies such as GEGL. As long as people know that they Are being planned, they'll be relatively happy and not get the impression that GIMP doesn't care about UI improvements. If the features aren't planned for any time soon but Are on the long-term plans, an explanation is enough to let users know that the GUI team isn't GUI-stupid but simply isn't capable of implementing the changes Yet. Then add a call for help on implementing prior dependencies, and maybe you'll even get more developers. Said section could end with Got more ideas? Submit to the GUI-brainstorm! And that's it. PR problem solved. Lack manpower? Get someone else to do the mock-ups for you. Given the number of submissions to GUI-brainstorm, it should be easy enough to find someone. Add the occasional news update on GUI rework progress, and that's even better! GIMP is finally taking the GUI problem seriously! - would claim people who haven't noticed the work already under way. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
I suspect the true problem isn't one about the process, but one about the perceived results. When you think about it, people rarely criticize a project Just for the process. People criticize MS Windows for being closed-source and thus full of bugs and functionality problems, but nobody criticizes Apple, which is More closed-source in many aspects, because it actually does a good job. Basically, even though people do not realize it, their reaction may actually be something of the following: - GUI team: We can handle the work just fine right now, so we don't need extra people in our team. - Others: (Yeah? Then why's the interface still so bad?) I say this because after an amount of introspection, I realize that I might have been guilty of this. I short, I suspect that people are unconsciously blaming GIMP's Current GUI shortcomings on the GUI team, even though it's not their fault because: - they actually haven't had the opportunity to show what they're fully capable of - and many GUI problems are actually due to internal architecture limitations (layer groups, brush folders etc) This unconscious connection between the current GUI and the GUI team's possible accomplishments may give the impression that the GUI team is under-qualified or incapable of handling the job by themselves, which is why outsiders snipe at their reluctance to let others join their team in a more permanent way. At the base of the issue, there may be a transparency problem. Basically, there is no easy way of tracking the works of the GUI team right now. There are only three ways of seeing what exactly what they're up to: - reading the ideas they've come up with thanks to the GUI blog submissions (which are only made up of a few lines, aren't that easy to find back, and are relatively rare) - go to gui.gimp.org , click User evaluation notes, then click Notes for individual scenarios, then be confronted with a wall of text on technical evaluations that most users don't want to bother reading. - go to gui.gimp.org, go to UI specifications, and find... a total of 1 entry, for 2.4. Given this lack of easy, visible and regular updates, people conclude that little work is being done. The easiest solution, as far as I can tell, is actually to apply the same principle that the GIMP site's Feature page and that the GIMP UI brainstorm blog apply themselves: using pictures to speak a thousand words. The summary would basically roughly serve the same purpose as a visible 2.6 milestone (which should also have mock-ups) would from a PR point-of-view: show people what's in planning so that people won't think of GIMP as a dead project that isn't moving anywhere. Inkscape has a screenshots section for future features, and that does wonders for showing people the future evolution of the program. Are there any plans for a Future feature page on the GIMP website? If there is, it could be made up of two sections: - Future features (with mock-ups based on the 2.6 milestone) - Future GUI improvements (a whole section dedicated to GUI improvement! This is sure to score points among critics of the GIMP interface) The future GUI improvement section could contain screenshots of a few key UI improvements in planning (they don't need to include everything), with eventually an explanation of dependencies such as GEGL. As long as people know that they Are being planned, they'll be relatively happy and not get the impression that GIMP doesn't care about UI improvements. If the features aren't planned for any time soon but Are on the long-term plans, an explanation is enough to let users know that the GUI team isn't GUI-stupid but simply isn't capable of implementing the changes Yet. Then add a call for help on implementing prior dependencies, and maybe you'll even get more developers. Said section could end with Got more ideas? Submit to the GUI-brainstorm! And that's it. PR problem solved. Lack manpower? Get someone else to do the mock-ups for you. Given the number of submissions to GUI-brainstorm, it should be easy enough to find someone. Add the occasional news update on GUI rework progress, and that's even better! GIMP is finally taking the GUI problem seriously! - would claim people who haven't noticed the work already under way. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
Well, I agree with the gist of your message... but one thing needs to be said: Designing a good UI doesn't require the same amount of people that implementing it in code does. This is why I suspect it to be a transparency problem and not really a process problem. People actually Won't criticize a process if they think it is doing a good job. In the case of the GUI team, we don't know if it's doing a good job. In fact, we don't see a job being done at all. This, of course, is irrational behavior: just because you don't see it, it doesn't mean good work isn't being done. But as long as outsiders don't see what the GUI team is truly capable of -via a few terrific mock-ups or similar- they will simply assume the worst: that the GUI team isn't capable of handling the job on their own, And refuse outside help on top of that. Solve the transparency problem, and the criticism will go away. Of course, you can just ignore it all and let the results speak for themselves, but then expect to put up with a lot of negative press. Also, it might be a missed opportunity for getting more developers to work on the architectural dependencies needed for implementing some of the GUI changes. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap
Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. This makes sense. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases. It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap
So... Gimp currently has 4 major goals? - Cairo - GEGL - Add named parameters and default values to the PDB - 6 months development cycle. Wouldn't it be easier to treat them as Separate goals for separate releases? Once Cairo and GEGL (I have no idea for the Parameters feature, so apologies for not being able to say more about it) have been properly implemented, Gimp should have the foundations for rolling out features more quickly. Wanting two at the same time though seems to be asking too much, and proper implementation of GEGL in my opinion justifies one final long development cycle. Maybe something like this can be considered: Gimp 2.6: - implementation of Cairo (get this out of the way) - start background work on GEGL, by dedicating more developer resources (if possible) to actually coding GEGL without necessarily implementing it yet - bunch of other easier features to keep people happy - development cycle: 6 months to a year. Gimp 2.8: - GEGL integration - the background GEGL work that started with Gimp 2.6 should have paved the foundations for slightly faster integration - the development cycle will probably still be long, but this will be the last long release cycle. Gimp 3.0+: - with GEGL properly implemented, from now on, development cycles will be 6 months. Once GEGL has been implemented, the following features seem to be the most demanded ones: - CMYK - 16 bit - layer effects - layer groups Any one of the above could justify a minor release. Having the first GEGL-version of Gimp ship with one of the above features would justify the time spent on it, especially if the developers explain that the other features will follow fast. Having said first GEGL-version of Gimp ship with Two of the above would be fantastic. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] discussing the roadmap for 2.6
Gimp 2.4 is great! On roadmaps: could enhancement requests be grouped by category somewhere? Going through the list of enhancement proposals in Bugzilla is rather awkward to say the least. I do like how some programs have used a wiki, like Firefox 3 and Inkscape. Eventually, for Gimp, each wiki entry could link to a bugzilla entry. There can be the following categories for example: - Architecture (GEGL, and resulting features such as grouped layers and brushes) - GUI (with links to that GUI brainstorming blog by the way) - New [insert tool] options (ex: new paint options, I think it could be a good idea to list the tools individually or by category: selection tools, paint tools, etc) - New tools - New filters - New whatever - Color and format support: CMYK, obscure file formats, etc. - Inter-compatibility: Photoshop gradients, palettes, actions, .psd files, .psp files, enhanced inter-compatibility with other open-source drawing programs such as Inkscape, etc. After that, a target can be set for individual features (2.6, undefined). Then a separate list can be compiled to show just the features currently being worked on for the next release. Truth be told, I'd be glad to wait off any visible feature additions if work on GEGL progresses, as to my understanding it is necessary in order to implement some really handy interface enhancements such as grouped layers and grouped brushes. I'm also pro-shorter development cycles by the way. I really like how Ubuntu handles this for example: the new release doesn't bring a revolution in terms of new features, but it Does bring one or two new features that makes your life much easier, and just for that, people are happier. The single feature I had been waiting for a long time in Gimp 2.4 for example is brush scaling. If Gimp 2.6 were to come out fast with nothing but layer and brush groups as new features, I'm sure people would be very happy rather than complain about a rushed release with not enough new features. I've seen an article put it as Not biting off more than they can chew. so far we didn't have a well-defined development roadmap. I would like to propose that this is changed for GIMP 2.6 and beyond. Hopefully this can help to acomplish two goals: - GIMP 2.6 should not take too long to develop - we will get more developers Before we start the discussion of the roadmap, perhaps we should talk about how we should go about getting to a roadmap. Should we do it on this list, do we want to use a Wiki, Bugzilla or anything like that? IMO it would be best if people proposed features here so that they can be discussed on the list. We should then collect these proposals somewhere and try to decide on milestones for them later. It would probably help if we try to be strict bout only proposing a single feature per mail. What do you think? Sven __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] discussing the roadmap for 2.6
So, an important decision must be taken, imo. Plan the 2.6 version as a new core version (with important improvements in the technical area, but maybe not that visible for the final users), or a new features version. If this isn't defined, there is a risk to fall in a long development cycle again. How about a new core version, with just a few key features implemented on top of that? GEGL cant be delayed forever. Sooner or later the issue has to be tackled. In the meantime, many commonly asked features cant be implemented without more work on GEGL. Whenever theres a new version of Gimp, any given user usually only focuses on 3 or 4 of the new enhancements. The rest may have minimal impact for them. However, architectural enhancements can usually benefit everybody, so it fills half the new quota they expect from the program already. For example, the ability to configure keyboard shortcuts was for me a bigger improvement than any individual new filter. What stood out for me this version was brush-scaling, though thats less of an architectural issue. Point is, not all enhancements are of the same level. The basic issues are often the one affecting most people. A Gimp 2.6 release that says this: Gimp has finally implemented layer groups and brush groups. [insert explanation and photos] This was possible because Gimp has started significant architectural rework by commencing on the long-waited implementation of GEGL. GEGL is [insert short explanation]. In the near future, GEGL will allow the implementation of other long-awaited features such as native CMYK support, layer effects and other non-destructive editing, much improved image scaling, and more. Once migration to GEGL is complete, expect faster new features and shorter development cycles. Stay tuned! In the meantime, if you are a developer and wish to contribute to the development of Gimp, [see here]. ...will not be considered a poor release, especially since The developers have bothered to explain just Why GEGL Is being worked on. People will be a bit more patient with bland releases if they know that as a result, they Will get the features they had been waiting for soon enough later. That said, this also depends on the developers. They can't be forced to work on GEGL, either. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
How about creating the following buttons on the jpeg save console? - Save at original image compression value - Save at user-specified compression value (insert current value of used-specified quality) - Change user-specified compression value It can be abbreviated as the following: Save at the following compression value: - Original - User-specified (insert number, so users would know what that value is) I chose to replace default by user-specified to avoid confusion. I'm sorry if I'm repeating what someone else is saying, but all this cross-talk is leaving me a bit lost. :S Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top?10 GIMP user requests...
Quoting peter sikking's weblog: (http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project-overview.html) ALSO NOT PAINTER the focus for GIMP is to work with ?found? images; I do not understand the reason for this restriction. Myself, I am not a painter. I do not use the GIMP for painting but I recognize that there are many who do. It seems such a short stretch for the GIMP to extend its already powerful paintbox toolset to incorporate other painting concepts that I fail to see why development in this direction should not be encouraged. Well, I'm among those who would like to use GIMP for painting, and I have tried in the past. But having seen that blog recently, I can accept that the developers would like to concentrate their efforts in a particular direction, so recently I've been looking to other open source programs such as Inkscape instead. They have limited resources as is, so you can't blame them to want to do one thing Well, even if it means setting aside others for now. I think the best alternative as a result would be to create a separate, painting program, based on Gimp, but with more emphasis on painting options and less on filters and tools mostly used for photo manipulation. Maybe it could incorporate Martin Renold's Mypaint and Levien's Wet Dream for example. This could result in at least one major interface change: when you're manipulating photos, you're more likely to have several files open at the same time as you go from one to another. However, with painting, you're more likely to use only one file. So an interface like (in my opinion, in any case) Inkscape's would be more suitable. As said, I've been using Inkscape recently, and I'm simply in love with its interface: you barely ever need to access dialogs, you can access layers and palettes from a non-intrusive bar at the bottom, and tool options from a non-intrusive bar at the top. Add to that a shortcut system specifically designed around manipulating paths: I've never been so in love with an interface. Something similar could be achieved for an open-source painting tool, this time with all the interface centered around painting as easily as possible while cluttering the window as little as possible. So an Open Source painting program would center around things different than a photo manipulation program. I can imagine being able to easily access brush presets from a non-intrusive bar at the bottom, brush parameters from a non-intrusive bar from the top, with user-friendly brush categories such as watercolor, oil, etc, (as opposed to multiply, divide, and other terms that leave the average person completely lost :P ), with easy access to textures and the likes, and shortcuts set accordingly. Of course, as with everything, this would require developers that probably aren't available at the moment. Ah well. Maybe in the very long term. Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 release date
That's why we need a Gimp PRO, Inkscape PRO, Scribus PRO - someone, a Firm / Govern / Foundation / Linux Distro / Billionaire ...or a mixture of them must hire core developers of all 3 projects - put them into a big WEB / DTP Core Linux project and manage development and releases. If I remember correctly, there had been a bounty type system on things such as GEGL since forever (several years, I believe). Yet even that failed to motivate developers. Also, if you want a program that works closely with the industry, well... there's Cinepaint. That said, the idea of forming an alliance with other open source programs could be a nice idea. It might be a bit complicated in that there are many separate open source programs around... but having a single main website linking to each project, and vice versa, to let more people become aware of complimentary programs to Gimp, could be helpful. Personally, it's a pity I don't know how to program yet. I guess I'll have to try to learn one day. But I've been giving a lot of thoughts to user interfaces in general these days. One of the main things people complain about Gimp is its user interface. The way I see it, the problem is Not that it's different from Photoshop, but that Like Photoshop, it's a tool-centric interface and not a task-centric or even function-centric interface. Let me explain: years ago I remember a relative buying Photoshop for his Mac. Back then, I looked at him weird and warned him that he would never know how to use it. That turned out true: he's attempted to figure it out, and has never touched it since. Now he uses a program that shipped along with his digital camera. It does: - red eye removal - cropping - resizing - color adjustment - and that's about it. Everything is present as little buttons or the likes at the top. And whenever he shows digital photos to friends, he keeps saying how great that program is. Why? The answer is the task-centric approach. The program does one thing: help users do a quick fix of photos as easily as possible. That's it. You can't do anything professional about it, but it answers 90% of the needs of 90% of casual users in the easiest-to-use way. Similarly, I remember seeing this drawing program online... it has: a canvas, a color selector, a few paintbrushes in one small corner. That's it. Such task-centric interfaces are by far the most intuitive and user-friendly. But obviously, they have very limited options. Both Gimp and Photoshop, by contrast, are tool-centric approach. Basically, it goes like this: give users a bunch of tools. Put as many options on those tools as you can think of. Let users figure out what they want to do with those tools. Tool-centric approaches are by far the most powerful. Unfortunately... they're not very intuitive. The users see a multitude of tools and a dozen options... and don't know what to do with barely any of them. This is true of Photoshop as well. Photoshop just benefits from incredible documentation and training support. But examples such as the person I've mentioned show that no, it is Not an intuitive program either. Here's an example of where the two approaches would diverge: suppose a person wants to paint something. - in a task-centric interface, he'd be handed a few brushes entitled Pencil, charcoal, watercolor. - in Gimp, he'd be handed the brush tool, and told There are lots of modes you can chose from: multiply, divide, grain extract, grain merge, etc, etc. At this point, the person would start looking a bit lost. The weird thing is that tool-centric interfaces can actually accomplish much of the things the task-centric interface can (and much more). Take the paintbrush tool, for example, select an appropriate brush shape, modify the transparency and spacing, even add jitter, and suddenly you have watercolor, oil, pointillism. Not exactly on Procreate Painter level, but close enough for the user to finally go Ooooh! So I personally think that the future of Gimp is actually to make the interface as configurable as possible, then make all the settings savable and sharable. Then let people perhaps other than developers make up ideal settings for each type of task, maybe include a short tutorial for each (I should mention that I really like the tutorials included in Inkscape. I'd never have figured out how to use it if not for those). The best interfaces of each category should be included in each release. Users can go find other ones though, and can experiment with the normal setting once they're used to whichever one they like to use (thus making the learning curve less steep). So when a new user opens Gimp, he can choose the Gimp-quick photo adjust interface, and suddenly the interface changes to only show layers, masks, color adjustment tools, red eye removal, some commonly used filters such as Unsharp mask and blur etc. He choses the Gimp-paint setting and he has layers, color selectors, and a list of brushes that says watercolor, oil etc,
[Gimp-developer] Sub-modes for shortcuts
Thanks to Sven for pointing out that I initially posted in the wrong place! Also, I haven't used Gimp 2.3 yet, so I apologize if I'm repeating things that are already inside. Basically, while checking out Inkscape, I misunderstood its shortcut system at first and thought that the space button toggles between a general shortcut mode and a tool-specific shortcut mode. Back then, I thought: What a great idea! (It turned out that Selector just meant Selection tool, whoops). I think something like this could be usable in Gimp though. Such a system would free up many modifier keys and thus allow more functions to be accessed by keyboard (I'll take this occasion to say that I love Gimp's configurable shortcut system to death. Thumbs up to the developers!) I can personally think of 2 major possibilities: (by the way, I'm pretty aware that F1 is normally used for help. I'd move it to F12 though, but that's just me) 1. Use the function keys to toggle between tool modes, where applicable. This is basically a tool-centric approach. With this approach, most shortcuts remain the same. You just reserve the F keys for active tool options. Everything works as it currently does, except function keys modify the mode of the current active tool. Examples: - for a selection tool, F1 gives the normal mode, F2 the inclusion mode, F3 the exclusion mode and F4 the intersect mode. And I wouldn't mind an F5 for a fast total selection edit mode... - for the path tool, F1 gives design mode, F2 gives Edit mode, F3 Move mode. - other function keys can be programmed to chosen states. This could be especially useful for paintbrush settings: you can chose F1 for a normal brush with pressure sensitivity, F2 for a multiply brush with fade-out, and so on. If only the modes get modified, it's still fine. In the case of the selection tool for example, such an implementation would free up all the modifier keys for shape considerations instead. Possibilities include: - Shift: constrain shape (to square or sphere) - Alt: move selection and content - Shift+Alt: move only selection - Ctrl: selection from center outwards - etc? Same with path tool and the likes: more shortcuts are freed up. It might confuse some users at first, but then again, my experience is that people either take their time to learn shortcuts, or never use them at all... Ideally you can access these tool-specific shortcuts by a button in the Tool options tab, where you can create custom values as well. Pros: It's relatively simple in usage, as it doesn't differ from the current interface by That much. It frees up modifier keys to a point. Cons: It doesn't increase the number of options by that much. 2. Use the function keys to toggle between major tool types. This is a function-centric approach, with major functions including Paint, Selection, Text, Path... You can access a functions mode using the appropriate F button, or with a specific command while using a tool of that nature, or with a drop down menu (see image). Within each mode, the shortcuts change to offer the maximum amount of options suiting that particular task. Each set is modifiable though. Drop-down menu: http://img213.imageshack.us/img213/6582/shortcutmodeslr8.png Example: You press say... the space bar, while using a selection tool, or you just press F2, to access the Selection mode. You press another function button to access paint mode, or press the space bar while using a paint tool. This may be somewhat confusing, so here are two rough mock-ups to give you an idea (they're very rough. When I say 1 etc, I mean the [1] key): Selection mode: http://img182.imageshack.us/img182/3268/selectiongx6.png Paint mode: http://img170.imageshack.us/img170/9599/paintmodeak4.png Note: I presented it this way to make things clearer. You can add just about any function and assign them just about any shortcut though. Default values would try to use schemes as consistent as possible though, while users would be encouraged to follow them as well. This means using Alt when varying tool parameters, Ctrl for tool transformations, etc. Of course, users can add in shortcuts for other tools or filters in any mode as well, like start a shortcut for the crop tool or for the Unsharp Mask filter while in Selection mode, etc. In the same way, in a Paint mode, you can configure shortcuts for paint modes and the likes. Note some of the suggested modifiers usages: size, transparency, etc. The idea is that you hold down the key and drag the mouse right and left to increase or decrease the value manually. A small number appears by the side to tell you of the current value (eg: 66% for transparency). But that's another story. When you access a mode, the current mode must be indicated in some corner. Again, you can edit the shortcuts for each mode. At the same time, you can create your own mode (perhaps based on existing ones). Pros: It allows you to access much more options for any given type of task, and allows you to set
