On 1/30/11, Bogdan Szczurek wrote:

Lately I've been discussing with a collegue of mine some differences between Gimp and Photoshop and how long-time Ps user feel when seated in front of Gimp. I know… I know… the neverending subject, but I'm not trying to start the flame again,

Do you genuinely expect us to believe it? :)))

So, how about a small extension to GUI to let one choose one of predefined shortcut sets and including “Photoshop compatible” shortcuts to the source tree? I know many people would be much pleased with that, since a seasoned Ps user tend to rather “just poke the right key” to do his bidding that to wander through the menu. I'm not trying to prove one shortcut scheme better than the other.

Now seriously… what do you think?

Being the utter bastard who updated the Photoshop mocking keyboard scheme file a while ago to match CS4 shortcuts I can only say that I'm terribly sorry about having done it.

Here is my reasoning.

Shortcuts are integral part of the whole thing that shapes habits of users, especially the motor function. If you keep a bug chunk of interaction from one application and replace one of its integral parts with a bit from a different application with different approach to user interfaces, you get a monster of a very nearly tentacular nature.

By adding the scheme switch you advertize this monster (well, a halfhearted measure at best). As we use to say in Uberwald, if you don't want a monster, you don't pull a lever :)

P.S. So, should I go ahead and update it again to match CS5? :)

Alexandre Prokoudine http://libregraphicsworld.org

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Sun, 2011-01-30 at 01:43 +0100, Bogdan Szczurek wrote:

The thing is, that we concluded that permamenet transition or even occasional use of Gimp would be much more appealing for Ps-bred guys (like me ;)) if one would have possibility to use the same (or at least much similar) keyboard shortcuts.

There's some danger here -- as people in Germany found when they compared moving to KDE or Gnome from Windows: when the new system is too similar to the old, people start going into automatic mode, and trip up much more over the differences.

When I first started using the "evolution" gnome mail program, I couldn't at first figure out why I kept sending out unedited drafts... then I realised it was because it was enough like Sun's mailtool I'd used a decade earlier that without thinking, I was pressing the command to go to the start/top of my message, to re-read before sending, but in evolution that same keypress meant "send immediately without asking for confirmation"! I'd used a non-gui mailer for about 10 years in the meantime, and had totally forgotten.

So, how about a small extension to GUI to let one choose one of predefined shortcut sets and including “Photoshop compatible” shortcuts to the source tree? I know many people would be much pleased with that, since a seasoned Ps user tend to rather “just poke the right key” to do his bidding that to wander through the menu. I'm not trying to prove one shortcut scheme better than the other.

Getting people started using gimp can be a good thing, although this can also make it harder for them to progress beyond the intersection of PhotoShop and GIMP. One also has to be aware that Adobe has in the past filed (successfully) law suits against competitors who were copying PhotoShop user interface features -- the key bindings are part of Adobe's intellectual property, they would probably argue.

Given those things, I'd prefer to provide a really good "Libre Graphics for Photoshop Users" that talks also about when to use GIMP and when to use Inkscape, ImageMagick, darktable (if you can figure the damn thing out). The "default image" in krita is one good example of how to give useful information, even though I'd still prefer a blank image.

So, how about Help->Getting Started ? I'll help write it, if there's agreement that it could be included.

I dare say that "Adobe-style keybindings" could be included too, since the GIMP project isn't very rich (and therefore Adobe would be unlikely to recoup their legal costs if they went after us) -- if there are objections, we could just remove the bindings.

Liam

As we use to say in Uberwald, if you

don't want a monster, you don't pull a lever :)

It's just a matter of thunderstomrs, really!

On Jan 30, 2011, at 12:12 PM, Liam R E Quin wrote:

On Sun, 2011-01-30 at 01:43 +0100, Bogdan Szczurek wrote:

The thing is, that we concluded that permamenet transition or even occasional use of Gimp would be much more appealing for Ps-bred guys (like me ;)) if one would have possibility to use the same (or at least much similar) keyboard shortcuts.

There's some danger here -- as people in Germany found when they compared moving to KDE or Gnome from Windows: when the new system is too similar to the old, people start going into automatic mode, and trip up much more over the differences.

This came up at linux.conf.au this week. I had a chance to talk with a couple of users and graphic designers about UI, including the issue of being made similar to Adobe products. The almost immediate response was that if the program is not going to behave *exactly* as the Adobe one does, in smallest detail, then it is far better to have an explicitly distinct UI.

Being "close" just leaves the end user with a vague feeling of incompleteness and that the software is not really ready for serious use.

Given those things, I'd prefer to provide a really good "Libre Graphics for Photoshop Users" that talks also about when to use GIMP and when to use Inkscape, ImageMagick, darktable (if you can figure the damn thing out). The "default image" in krita is one good example of how to give useful information, even though I'd still prefer a blank image.

So, how about Help->Getting Started ? I'll help write it, if there's agreement that it could be included.

Artists and designers I get to talk to have stated that such guides would be very good ideas, and could avoid much of the call for compatible keybindings, etc. It also would be very helpful if some common Adobe-user use cases that were more complex in Photoshop yet easier in GIMP were highlighted. Such improvements in workflow tend to give the transitioning users a better feeling and a more positive migration experience.

On Sat, Jan 29, 2011 at 9:12 PM, Liam R E Quin wrote:

On Sun, 2011-01-30 at 01:43 +0100, Bogdan Szczurek wrote:

The thing is, that we concluded that permamenet transition or even occasional use of Gimp would be much more appealing for Ps-bred guys (like me ;)) if one would have possibility to use the same (or at least much similar) keyboard shortcuts.

There's some danger here -- as people in Germany found when they compared moving to KDE or Gnome from Windows: when the new system is too similar to the old, people start going into automatic mode, and trip up much more over the differences.

I think the problem then is the differences; creating more differences isn't a good solution.

Things tend to converge over time, and that's a good thing. The key is almost universally known as the help key today. Having each application provide it's own "Help" accelerator is to nobody's benefit.

The world would be better if each application domain had a consistent set of core accelerators. File->New, File->Save, Cut/Copy/Paste, etc. are good for most all applications. For a graphics program, common tools like Pencil, Eraser, Move, Crop, etc. should have consistent accelerators. Accelerators can diverge where the application domain differs of course (e.g. raster versus vector editors) and where applications specialize (tablet support versus not), but within each sub-domain consistent cross-application accelerators would be better.

I don't know what (each version of) Ps uses, but it would be beneficial to look at what they are, how they compare to other apps (PSP, Paint.Net, iPhoto, Krita, etc.) and see if they make sense for GIMP as well. This should probably be done periodically to promote application convergence for the general users' benefit (i.e: don't think of them as application accelerators, but as accelerators for graphics professionals) even if it means that accelerators occasionally change between versions.

Chris

The world would be better if each application domain had a consistent set of core accelerators.  File->New, File->Save, Cut/Copy/Paste, etc. are good for most all applications.  For a graphics program, common tools like Pencil, Eraser, Move, Crop, etc. should have consistent accelerators.  Accelerators can diverge where the application domain differs of course (e.g. raster versus vector editors) and where applications specialize (tablet support versus not), but within each sub-domain consistent cross-application accelerators would be better.

But they don't. Maintaining legacy shortcuts prevents moving forward with new features.

I still know the ctrl+k codes required for the first editor I used - I've never expected every other editor I use to support them.

Even M$oft changes their own shortcuts all the time. We moved to Office 2007 at my work, and most of the shortcuts have changed. Part of it is intentional - by breaking the habits of users you can move them to new paradigms of UI.

Just my 2 bits.

-Rob A>

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Sun, 2011-01-30 at 12:35 -0500, Christopher Curtis wrote:

The world would be better if each application domain had a consistent set of core accelerators. File->New, File->Save, Cut/Copy/Paste, etc. are good for most all applications. For a graphics program, common tools like Pencil, Eraser, Move, Crop, etc. should have consistent accelerators.

There's no short answer beyond, "GIMP's primary goal is not being a PhotoShop clone."

Here are some longer notes...

One trouble here is that there is tension between cross-platform consistency and within-platform consistency.

For example, yes, control-{x, c, v} are supported by gimp for cut/copy/paste following the lead set by Apple in 1984. GIMP does not seem to use control-insert or shift-insert for cut/paste, a slightly older convention set by Microsoft.

On the GNOME platform, the Human Interface Guidelines (HIG) list primary key bindings so that Gnome applications will work in the same way; Windows does the same, and so does KDE and so does the Mac. They are not all the same, however, and there do tend to be conflicts.

When Word Perfect moved from MS-DOS to Windows, they favoured the Windows-compatible shortcuts over the older DOS ones. It sounded like the right thing to do, but all Microsoft had to do was add a preference, "use Word Perfect for DOS keys" and they stole a huge proportion of the Word Perfect user base, because it was seen as cheaper (less training) to move to Word than to the new WP. So there is a cost in changing, which is that you hurt your existing user base (which is quite large for GIMP).

GIMP does let you set preferences, so you can change the keys, or use a pre-packaged set, and maybe it would be worth shipping key bindings for Photoshop and Corel Draw and maybe even PaintShop Pro. Do be aware it can make it harder to get help and follow tutorials, but maybe if the status-bar showed when you were using non-default key bindings it'd be OK? Adding modes to a GUI is always a problem.

Yes, perhaps it might be nice if the key to get the eraser was the same in inkscape and gimp and blender and gedit and krita and mypaint, but it could no longer be "E" because that inserts text in gedit, so we'd end up using conrtol-shift-e or something. But that's already Export in gimp now, and what if it does something in Blender? I don't know if it'd be worth having a key binding day at LGM this Spring in Montreal. I think most of the developers probably would rather be doing more architectural work together.

Liam

On Sun, Jan 30, 2011 at 12:55 PM, Rob Antonishen wrote:

The world would be better if each application domain had a consistent set of core accelerators.  File->New, File->Save, Cut/Copy/Paste, etc. are good for most all applications.  For a graphics program, common tools like Pencil, Eraser, Move, Crop, etc. should have consistent accelerators.  Accelerators can diverge where the application domain differs of course (e.g. raster versus vector editors) and where applications specialize (tablet support versus not), but within each sub-domain consistent cross-application accelerators would be better.

But they don't.  Maintaining legacy shortcuts prevents moving forward with new features.

What don't what? I'm not at all suggesting immutable accelerators - in the next paragraph I clearly state: "even if it means that accelerators occasionally change between versions."

As one example (likely not the best one, I'm sure), GIMP uses +, for FG Color Fill and +. for BG Color Fill. I assume these keys are near each other on all keyboards...

PhotoShop uses + for FG Fill and + for BG Fill. + pulls up the Fill Dialog. These seem like reasonable accelerators that don't conflict with GIMP's. I used this for reference:
http://morris-photographics.com/photoshop/shortcuts/index.html

Paint Shop Pro doesn't seem to have a "fill" accelerator, but it looks like Paint.NET uses :
http://www.keyxl.com/aaad5b6/325/Paint-Dot-Net-keyboard-shortcuts.htm

Confusingly, Ps uses unmodified as a synonym for . But based on my sample size of 3, one could say that there may be a convergence towards as having something to do with fills. This is hardly overwhelming evidence of anything, but if we as a graphics-software producing community can all agree that = "Fills", that will only help the users of our collective software.

This suggestion isn't so much about cloning "competitive" software but of recognizing that graphics professionals may use many different (but similar) tools and the more similarity there is among them the better off they will be in producing their works.

Chris

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Sun, Jan 30, 2011 at 1:33 PM, Liam R E Quin wrote:

Yes, perhaps it might be nice if the key to get the eraser was the same in inkscape and gimp and blender and gedit and krita and mypaint, but it could no longer be "E" because that inserts text in gedit, so we'd end up using conrtol-shift-e or something. But that's already Export in gimp now, and what if it does something in Blender?

I don't know if you're intentionally setting up a stawman here, but inkscape is a vector editor, blender is a 3D modeler, and gedit is a text editor. These applications aren't in the same domain as GIMP and MyPaint.

Exercising my bad analogy skills, I would expect GIMP, MyPaint, and PhotoShop accelerators to all "speak" English, though one might be American, another British, and another Australian. Inkscape may sound a bit more like Jamaican and Blender would be German (or perhaps Navajo, since they don't even honor as help).

So all I'm suggesting is that instead of simply producing PhotoShop keybindings (which is a fine idea, IMO) that an interested person actually look at the broader picture to see if there is any accelerator convergence among peer applications and propose bringing GIMP into alignment where it makes sense to do so.

Chris

On Sun, Jan 30, 2011 at 1:33 PM, Liam R E Quin wrote:

Yes, perhaps it might be nice if the key to get the eraser was the same in inkscape and gimp and blender and gedit and krita and mypaint, but it

[...]

I overlooked Krita. Krita uses as a BG Color Fill and + as a FG Color Fill according to:
http://community.kde.org/Krita/Shortcuts

MyPaint doesn't seem to have a 'fill' accelerator: http://wiki.mypaint.info/Documentation/Shortcuts

So it looks to me like Krita and PhotoShop agree that + is FG Color Fill; Krita and Paint.NET agree that is BG Color Fill (with PhotoShop the outlier using ); and GIMP thinks that is good for nothing.

Chris

On Sun, 2011-01-30 at 13:59 -0500, Christopher Curtis wrote:

On Sun, Jan 30, 2011 at 1:33 PM, Liam R E Quin wrote:

Yes, perhaps it might be nice if the key to get the eraser was the same in inkscape and gimp and blender and gedit and krita and mypaint, but it could no longer be "E" because that inserts text in gedit, so we'd end up using conrtol-shift-e or something. But that's already Export in gimp now, and what if it does something in Blender?

I don't know if you're intentionally setting up a stawman here, but inkscape is a vector editor, blender is a 3D modeler, and gedit is a text editor. These applications aren't in the same domain as GIMP and MyPaint.

Actually no, I'm being entirely serious - they are often used together, just as Photoshop and Illustrator are used together. (and gedit, like GIMP and Inkscape, is a GNOME program, hosted on www.gnome.org)

So all I'm suggesting is that instead of simply producing PhotoShop keybindings (which is a fine idea, IMO) that an interested person actually look at the broader picture to see if there is any accelerator convergence among peer applications and propose bringing GIMP into alignment where it makes sense to do so.

I'm actually Ok with this. But we have to agree what we mean by "peer applications" - I'd say gimp and inkscape are, for example, and not gimp and photoshop.

Liam

On 1/30/11, Christopher Curtis wrote:

So all I'm suggesting is that instead of simply producing PhotoShop keybindings (which is a fine idea, IMO)

They already are produced

that an interested person actually look at the broader picture to see if there is any accelerator convergence among peer applications and propose bringing GIMP into alignment where it makes sense to do so.

You can start from here:

http://create.freedesktop.org/wiki/User_interaction_implementations

Alexandre Prokoudine http://libregraphicsworld.org

On Sun, Jan 30, 2011 at 8:51 PM, Liam R E Quin wrote:

I'm actually Ok with this. But we have to agree what we mean by "peer applications" - I'd say gimp and inkscape are, for example, and not gimp and photoshop.

So your argument is that on the "Software Spectrum" GIMP is not a graphics application but is first a GNOME application. For the people who want, you know, to create GNOME. It just happens to create GNOME using graphics.

That's sarcasm of course - you say that primary platform trumps application domain, and GIMP is GNOME because that's where it's hosted; a rather myopic and user-hostile view, IMHO. Most people don't care one whit about GNOME or where GIMP is hosted. They want software that is better than what they currently have, fits the way they work, and is relatively familiar ... which is going to lead down an ugly road.

So let me ask you this instead: Are you going to oppose a patch that changes the GIMP shortcut for FG/BG fill to match PhotoShop's on the basis that Backspace does something completely different in GEdit? Or on the basis that GIMP is not a PS clone? Or some other reason? Or would you have no opposition at all?

Chris

On 31 January 2011 17:33, Christopher Curtis wrote:

On Sun, Jan 30, 2011 at 8:51 PM, Liam R E Quin wrote:

I'm actually Ok with this. But we have to agree what we mean by "peer applications" - I'd say gimp and inkscape are, for example, and not gimp and photoshop.

So your argument is that on the "Software Spectrum" GIMP is not a graphics application but is first a GNOME application.  For the people who want, you know, to create GNOME.  It just happens to create GNOME using graphics.

No, I am quite certain the argument is that GIMP users workflow/pipeline is more likely to also include Inkscape than Photoshop.
Which in my experience is fairly sound.

On Mon, Jan 31, 2011 at 6:33 PM, Christopher Curtis wrote:

On Sun, Jan 30, 2011 at 8:51 PM, Liam R E Quin wrote:

I'm actually Ok with this. But we have to agree what we mean by "peer applications" - I'd say gimp and inkscape are, for example, and not gimp and photoshop.

So your argument is that on the "Software Spectrum" GIMP is not a graphics application but is first a GNOME application.  For the people who want, you know, to create GNOME.  It just happens to create GNOME using graphics.

That's sarcasm of course - you say that primary platform trumps application domain, and GIMP is GNOME because that's where it's hosted; a rather myopic and user-hostile view, IMHO.  Most people don't care one whit about GNOME or where GIMP is hosted.

Let's start with the fact that Inkscape isn't a GNOME application (though it uses GIO, AFAIK).

Now, there is nothing bad about following UI conventions set by umbrella organization such as GNOME as long as they make sense. Do we have agreement on that?

Furthermore, collaborating with Inkscape *instead* makes a lot of sense, because GIMP + Inkscape are a usual combo. Blindly reusing shortcuts from old Adobe products doesn't make a lot of sense. I'd have to look at Ps again to make sure nothing changed, but Illustrator carries around somewhat inconsistent shortcuts exactly because old habits die hard. I'd say that the idea of reusing shortcuts from an application where they had been stacked on top of each other over years without review is a bit on the crazy side.

The very same "many people" who don't care about GNOME want GIMP to be a drop-in Photoshop replacement. Needless to say, this is not the point why GIMP exists and is being worked on. One would have to lose all self-respect and joy of life to work on a free drop-in replacement for *any* software project.

Alexandre Prokoudine http://libregraphicsworld.org

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Christopher Curtis gmail.com> writes:

I don't know if you're intentionally setting up a stawman here, but inkscape is a vector editor, blender is a 3D modeler, and gedit is a text editor. These applications aren't in the same domain as GIMP and MyPaint.

Don't dismiss it so quickly. It may not be very important for a 2D graphic artist, but for a 3d artist, to have the same keybindings in their 2d and 3d apps would be very useful. I work with 3ds Max and Photoshop on a daily basis and I have to switch between the two often. even after 10 years It gets annoying that simple tasks like "panning the view" or "cloning a selection" is completely different in the two (Autodesk is mostly to blame in this case). When you work with a number of apps, and you need to work fast, having to shift mental gears between apps always slows you down. I still occasionally use Ctrl-alt-z to undo more than one step when I'm in 3ds max because this is how it's done in Photoshop, and I end up zooming to the scene extents instead. I try my best to synchronize keybindings where I can.

Let me start off by saying that this conversion is exasperating, and this will likely be my last message on the topic.

Firstly, let me define "peer group": Any set of applications that interpret data in a specific way and allows the user to view or manipulate said interpretation in any specific way.

As an example, all applications which interpret data as pixel information form a peer group. Common features such as panning and zooming should be the same across all these applications. These groups can be broken down further into "viewers" and "editors". Editors can be broken down further into "raster" and "vector". And then "layered" versus "flat", etc. As application groups get more specific their shortcuts will by necessity diverge, but these peers should have more shortcuts in common than not.

What does not matter within a peer group is what programming language the application uses, what libraries it uses, what the primary deployment platform is, what other applications someone may or may not use with it, or what license the application is distributed under. These are all immaterial to what the application _is_ or _does_ (which also defines who uses it).

If there's confusion because I'm posting in a thread called "Photoshop compatibility mode" let me apologize for confusing anyone and clearly state that I am not suggesting this mode be adopted as the default mode for GIMP.

I am also not suggesting blindly following "old Adobe products". However, it is equally a mistake to blindly follow "old GIMP products" when it's clear the rest of the world is moving to another set of default keybindings. The crux of my argument is simply that - regardless of what we've become used to - it is beneficial to all users - existing and future - to monitor default keybindings across peer applications and mimic each other where appropriate.

I do like the page Alexandre put together on the Create wiki, but I do not like that closed-source applications appear to have been excluded. I don't want to diverge into a Free Software "Purity" versus Open Source "Practicality" debate but closed source applications are an important part of the software ecosystem -- if for no other reason than we're trying to provide a better alternative to them. And "better alternative" in no way, shape, or form means "clone".

One example given - the idiotic Microsoft + shortcuts for cut/copy/paste - is a classic NIH problem, just like this might be considered to be. Maybe they thought they were saving DVORAK users (where +X,C,V isn't at all intuitive) when the rest of world had moved on to QWERTY, but now there are keyboards that have moved the key onto the row and doubled the size of the key! (Mine is one of these monstrosities.) The simple reality is that things get easier for users when common assumptions are shared.

Some say that smart people learn from their mistakes; wise people learn from the mistakes of others.

As to the GNOME HIG, that is a much broader topic. If the GNOME HIG has an entry that says "The 'R' key shall select the 'Rectangle Selection' tool", I would say that it is over-specified and doomed to failure. Note that I am not saying that it is the case that it is - just that it would be.

However, if an application is intended to be cross-platform, it should conform to the conventions of that platform. Very broadly, that means on MacOS it should do the weird titlebar thing by default; it would do single window mode on Windows; Ok/Cancel conventions would match the platform; and as there really aren't that many expectations of what a *nix system looks like, it can pretty much be whatever - but should follow the GNOME HIG on GNOME and the KDE HIG on KDE ... ideally. And these HIGs should not have sections called anything like "Keyboard shortcuts for raster image editors".

Chris

And all this conversation is because you think CTRL+Backspace makes more sense than CTRL+. (because you're used to that combination) and you don't want to take 30 seconds of your time to personalize the accelerators?
Seriously?
GIMP accelerators are customizable using a visible option from the Edit menu, and you can even choose to assign accelerators dinamically from the preferences.
The menurc file in the prefs folder has the list of accelerators. You could create a custom version with the combinations you want (or google for it, just to find that someone already did it).

A couple of days ago a voluntary coder (with an impressive CV) arrived to this list offering his help and he only got a couple of replies. This pointless discussion got a lot more of attention.

Just my 2 cents.

On Mon, Jan 31, 2011 at 9:39 PM, gespertino@gmail.com wrote:

And all this conversation is because you think CTRL+Backspace makes more sense than CTRL+. (because you're used to that combination) and you don't want to take 30 seconds of your time to personalize the accelerators?

By "you" are you referring to me?

If I've used Photoshop it hasn't been in the past decade. I'm not saying any particular keystroke makes any sense whatsoever. It doesn't make any sense to me that keyboard shortcuts tend to assume the user speaks English.

A couple of days ago a voluntary coder (with an impressive CV) arrived to this list offering his help and he only got a couple of replies.

I would agree that there are problems with the way people tend to interact on this list. One of which is the knee-jerk reaction whenever an email comes across with the word Photoshop in it.

Chris

On 2/1/11, Christopher Curtis wrote:

I would agree that there are problems with the way people tend to interact on this list. One of which is the knee-jerk reaction whenever an email comes across with the word Photoshop in it.

What you call "knee-jerk reaction" is the result of generations of users coming and telling the team to just make GIMP like Photoshop or make it easy to make it behave like Photoshop (which is the same thing really). Would you like to lead this project for the next dozen of years to get an idea? :)

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Feb 1, 2011 at 2:39 AM, gespertino@gmail.com wrote:

A couple of days ago a voluntary coder (with an impressive CV) arrived to this list offering his help and he only got a couple of replies. This pointless discussion got a lot more of attention.

This discussion is almost entirely thin air and bikeshedding, I spent a couple of days formulating one of the texts linked to in one of those replies. (http://gegl.org/contribute.html) People serious about contributing would perhaps have to spend quite a bit of time thinking, investigating and digesting before being able to follow up. I am glad that discussion tapered out; and maybe have responses in the terms of actual code.

/Øyvind Kolås

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, Feb 1, 2011 at 4:00 AM, Alexandre Prokoudine wrote:

On 2/1/11, Christopher Curtis wrote:

interact on this list.  One of which is the knee-jerk reaction whenever an email comes across with the word Photoshop in it.

What you call "knee-jerk reaction" is the result of generations of users coming and telling the team to just make GIMP like Photoshop or

I recognize the root of the issue, but that makes it no less an issue. What may seem to you like bikeshedding seems to me like the immortal remnants of the Carol Spears hydra.

I asked if anyone would complain about a patch that brings GIMP in line with every other program that I could find wrt using Backspace as color fill. One person objected, nobody said it would be a fine patch -- they'd rather complain about Photoshop users.

Chris

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, 1 Feb 2011 09:30:05 -0500 Christopher Curtis wrote:

I asked if anyone would complain about a patch that brings GIMP in line with every other program that I could find wrt using Backspace as color fill. One person objected, nobody said it would be a fine patch -- they'd rather complain about Photoshop users.

So to answer your question (albeit in a statistically insignificant way), no-one wants the patch.

The problem is that you have a definition of what constitutes the peer-group of an application that no-one else seems to agree with. But since your argument is predicated on your definition, you're not going to make any headway.

And I'm inclined to agree that the peer-group of an application is those applications likely to be found in the same environment. The proportion of use-time spend adjusting to a new application will (in most cases I hope) be a fraction of the total use-time of that application. So why configure an application in order to improve that small period? I'm not sure that many people use both PS and gimp. The scale of the applications and UIs means that most people will be using one or the other. However, it's likely that users of gimp will also be users of gedit (substitute any other OSS app here). gimp's immediate peer-group would be those non-overlapping but related applications (blender, inkscape), followed by other unrelated applications likely to be found in the same working environment. It's not going to be other applications that fulfill more or less the same niche.

My 2c (as a regular and long-term reader of this group, but a non-contributing one).

Jon

Alexandre Prokoudine gmail.com> writes:

On 2/1/11, Christopher Curtis wrote:

I would agree that there are problems with the way people tend to interact on this list. One of which is the knee-jerk reaction whenever an email comes across with the word Photoshop in it.

What you call "knee-jerk reaction" is the result of generations of users coming and telling the team to just make GIMP like Photoshop or make it easy to make it behave like Photoshop (which is the same thing really). Would you like to lead this project for the next dozen of years to get an idea? :)

Alexandre Prokoudine http://libregraphicsworld.org

How about this as a suggestion:
Find an existing menuRc files with photoshop key bindings. Ask the author if it can be included in a Gimp release. Include it as a renamed file so its not loaded by default. find a maintainer for it (the original author if possible, but if not, I can do it).

Add a single "For Photoshop users" page to the help file. There, tell users how to change the menurc file so they have photoshop-like keys. This won't change the application in any way, and will enable those who insist on it to have photoshop key bindings. I can't see any downside and it's very easy to implement.

On Tue, Feb 1, 2011 at 5:17 PM, Michael Grosberg wrote:

Add a single "For Photoshop users" page to the help file. There, tell users how to change the menurc file so they have photoshop-like keys. This won't change the application in any way, and will enable those who insist on it to have photoshop key bindings. I can't see any downside and it's very easy to implement.

I see no reason why this mod should be maintained in the GIMP tree. It's an optional mod and as such, along with other PS specific customizations should belong in a separate project, just like GPS presets(that are valuable even on vanilla gimp, instead of the patched one) and FX foundry.

On Tue, Feb 1, 2011 at 6:17 PM, Michael Grosberg wrote:

How about this as a suggestion:
Find an existing menuRc files with photoshop key bindings. Ask the author if it can be included in a Gimp release. Include it as a renamed file so its not loaded by default. find a maintainer for it (the original author if possible, but if not, I can do it).

*sigh*

http://git.gnome.org/browse/gimp/tree/etc/ps-menurc

Alexandre Prokoudine http://libregraphicsworld.org

As it was stated before, making applications act "similar" doesn't turn out in "familiarity", but in a percepction of incompleteness. The most our applications looks like others, the most former users of other applications will spot what's missing, perceiving differences as limitations.
When I switched from GIMP after almost 15 years of Photoshop the first reaction was the same. I wanted GIMP to behave like photoshop, because I considered Photoshop's the right way of doing things. Now I'm glad it didn't work that way, because it forced me to understand that I was using a different program.

In the future I'd love to see even more differences. Who knows, maybe a node UI instead of layers, for instance ;-) Moving in that direction, imho, would stop this endless and pointless flamewar about GIMP vs. Photoshop, and people who moves to GIMP would be doing an informed choice instead of seeking a free-of-charge Photoshop.

On Tue, Feb 1, 2011 at 5:30 PM, Christopher Curtis wrote:

What you call "knee-jerk reaction" is the result of generations of users coming and telling the team to just make GIMP like Photoshop or

I recognize the root of the issue, but that makes it no less an issue.  What may seem to you like bikeshedding seems to me like the immortal remnants of the Carol Spears hydra.

I asked if anyone would complain about a patch that brings GIMP in line with every other program that I could find wrt using Backspace as color fill.  One person objected, nobody said it would be a fine patch -- they'd rather complain about Photoshop users.

Because people talk about the big picture. Pretty please carefully reread what Jon Cruz wrote in the thread. It's a spot-on message.

Alexandre Prokoudine http://libregraphicsworld.org

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, Feb 1, 2011 at 1:45 PM, Alexandre Prokoudine wrote:

Because people talk about the big picture. Pretty please carefully reread what Jon Cruz wrote in the thread. It's a spot-on message.

You mean Jon Senior?

js
->

Alexandre Prokoudine
http://libregraphicsworld.org
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tue, Feb 1, 2011 at 6:55 PM, Joao S. O. Bueno wrote:

On Tue, Feb 1, 2011 at 1:45 PM, Alexandre Prokoudine wrote:

Because people talk about the big picture. Pretty please carefully reread what Jon Cruz wrote in the thread. It's a spot-on message.

You mean Jon Senior?

Nope. I did mean Jon Cruz :)

http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-January/026174.html

--- snip ---

This came up at linux.conf.au this week. I had a chance to talk with a couple of users and graphic designers about UI, including the issue of being made similar to Adobe products. The almost immediate response was that if the program is not going to behave *exactly* as the Adobe one does, in smallest detail, then it is far better to have an explicitly distinct UI.

Being "close" just leaves the end user with a vague feeling of incompleteness and that the software is not really ready for serious use.

--- snip ---

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine gmail.com> writes:

*sigh*

http://git.gnome.org/browse/gimp/tree/etc/ps-menurc

Alexandre Prokoudine http://libregraphicsworld.org

I will refrain from expressing my opinion on undocumented, undiscoverable features.
Now only a help page is needed. I think I'll go and join the Gimp-Docs mailing list and take it from there. This is an area in which I have a lot of experience (I've been documenting graphic apps for several years now).

On Tue, 1 Feb 2011 19:01:12 +0300 Alexandre Prokoudine wrote:

On Tue, Feb 1, 2011 at 6:55 PM, Joao S. O. Bueno wrote:

On Tue, Feb 1, 2011 at 1:45 PM, Alexandre Prokoudine wrote:

Because people talk about the big picture. Pretty please carefully reread what Jon Cruz wrote in the thread. It's a spot-on message.

You mean Jon Senior?

Nope. I did mean Jon Cruz :)

But thank you Joao for categorizing what I had to say "spot-on". :-)

Jon

On Tue, Feb 1, 2011 at 8:16 PM, Michael Grosberg wrote:

I will refrain from expressing my opinion on undocumented, undiscoverable features.
Now only a help page is needed. I think I'll go and join the Gimp-Docs mailing list and take it from there. This is an area in which I have a lot of experience (I've been documenting graphic apps for several years now).

So far it looks like the best outcome of the thread :) Thank you.

Alexandre Prokoudine http://libregraphicsworld.org

On 02/01/2011 06:25 PM, Alexandre Prokoudine wrote:

On Tue, Feb 1, 2011 at 8:16 PM, Michael Grosberg wrote:

I will refrain from expressing my opinion on undocumented, undiscoverable features.
Now only a help page is needed. I think I'll go and join the Gimp-Docs mailing list and take it from there. This is an area in which I have a lot of experience (I've been documenting graphic apps for several years now).

So far it looks like the best outcome of the thread :) Thank you.

Let's remove one stroke from the name of the program.

Let's call it GINP.

GINP Is Not Photoshop.

On Tue, 2011-02-01 at 17:16 +0000, Michael Grosberg wrote:

Alexandre Prokoudine gmail.com> writes:

*sigh*

http://git.gnome.org/browse/gimp/tree/etc/ps-menurc

Alexandre Prokoudine http://libregraphicsworld.org

I will refrain from expressing my opinion on undocumented, undiscoverable features.

This is documented in the user manual even: http://docs.gimp.org/en/gimp-introduction-history-2-0.html

I am sure the gimp-docs team will appreciate a patch that moves this information to a better place though. It's somewhat difficult to locate it in the list of changes for GIMP 2.0.

Sven

On Wednesday, February 02, 2011 01:28:04 Bogdan Szczurek wrote:

This pointless discussion got a lot more of attention.

Pointless it is if it doesn't bring any changes but that can be said only after it's over. Right now I can see that there's at least a will to at least make things clearer about the subject in documentation.

Well, on developer side there seems to be a consensus forming that this ps- menurc file should and will be removed from git and I personally agree. such enhancements should be maintained outside gimp. So most likely, once this is over you are furher away from what you came here for than before.

If you are interested in such enhacncements, you may want to offer&maintain a tool that creates for the user that runs it a PS-ified profile. it would be relatively easy to make.

-- Alexia

ROFL

On 02/01/2011 03:54 PM, Ofnuts wrote:

On 02/01/2011 06:25 PM, Alexandre Prokoudine wrote:

On Tue, Feb 1, 2011 at 8:16 PM, Michael Grosberg wrote:

I will refrain from expressing my opinion on undocumented, undiscoverable features.
Now only a help page is needed. I think I'll go and join the Gimp-Docs mailing list and take it from there. This is an area in which I have a lot of experience (I've been documenting graphic apps for several years now).

So far it looks like the best outcome of the thread :) Thank you.

Let's remove one stroke from the name of the program.

Let's call it GINP.

GINP Is Not Photoshop.

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Alexia Death wrote:

Well, on developer side there seems to be a consensus forming that this ps-
menurc file should and will be removed from git and I personally agree. such
enhancements should be maintained outside gimp. So most likely, once this is
over you are furher away from what you came here for than before.

right, and I do not only think it is the right move (for GIMP to signal "here is a free as in beer ps copy" is exactly against the vision that GIMP is not a ps clone), I also initiated it.

let me clarify that author/contributor Alexandre Prokoudine wholly agrees with the removal.

now if nobody is faster than me, I will do this remove as my first act as resource maintainer.

The docs will have to be updated to reflect this. what is the best procedure to set this in motion?

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On 2/2/11, Bogdan Szczurek wrote:

different after all. Please don't be mad at me for saying that for I don't intend to offend anybody.

Nobody's mad at you :) I see where you are coming from, I even spent some time in the past providing this kind of solutions for e.g. Inkscape users (http://bit.ly/i2HJeR), but you see, the whole topic is really about near-term outlook vs. long-term outlook.

Providing an easy way to switch to Ps shortcuts scheme is a near-term solution, i.e. useful for people who just need GIMP once or twice in their life after having used Ps for a decade or so. For people who want to switch from Ps to GIMP this near-term solution will do a terrible job: they will never get full mapping of keys (believe me, I know what I'm saying), they won't be motivated enough to move to native shortcuts, and they will find it difficult to follow all kinds of documentation.

(I'm not even saying how introducing this switch will motivate everyone to ask the team to provide Ps-like menus using the very same reasoning.)

Alexandre Prokoudine http://libregraphicsworld.org