On Wed, Jun 20, 2012 at 7:53 PM, Guillermo Espertino (Gez) wrote:

But I just had an idea (sorry if anybody already suggested it and I missed it): What if the "merely harmeless to downright offensive" popup saying that Save is for XCF offers an extra button labeled "export anyway" or something similar?

A universally accepted truth is that users don't read warnings. This will surely freak out few geeks who do read warnings carefully and recite them occasionally over a pint of beer in a pub, but mostly people really try to make stupid dialogs go away ASAP.

Alexandre Prokoudine http://libregraphicsworld.org

On 06/20/2012 02:50 PM, Alexandre Prokoudine wrote:

A universally accepted truth is that users don't read warnings. This will surely freak out few geeks who do read warnings carefully and recite them occasionally over a pint of beer in a pub, but mostly people really try to make stupid dialogs go away ASAP.

Alexandre Prokoudine

I have to agree that most users don't read (or perhaps more correctly, don't comprehend) warnings. However, often in open-source development there seems to be a general attitude that the "quality" of the software should be primary and protecting users from their own stupidity should be secondary. In fact, in my observation of open source conversations over the years, including occasionally in the past by only one or two people that were on this list, there has been a general attitude on the part of a few individuals that "ordinary users" are morons and should be ignored. Yet in this situation, the developers are tripping over themselves to protect the users from their own ignorance and inattention.

It just seems so odd... I feel like I have fallen into software Wonderland.

It has been pointed out several times that most of the developers are located in Europe. Europe has a reputation of having much more stifling government regulations and rules than North America. Could this be related -- the concept that people must be protected from themselves?

Pretty soon there will be a law that coffee may only be served cold because somebody might burn their tongue.

People seem to learn best from adversity. If you corrupt your own image file and did not make a pre-editing backup copy, you just might learn something. However, if that same user is "protected" from doing something stupid, then the user will learn nothing. They will not become a better user. There is a fine line between successfully using the software and everything being a "learning by making mistakes" experience. However, if users are coddled, you will simply end up with users that become progressively even more ignorant. If users choose not to read warnings or don't take the time to think about and comprehend the meaning of warnings, then maybe the users deserve the spanking that they will receive as a result of their own action / inaction. Or is spanking illegal now too?

[Not a serious suggestion] Maybe Gimp should, upon opening a file, make an archival copy of that file so that he user who fails to make a pre-editing backup copy, the user will be protected from his/herself.

The bottom line of this change to best serve a particular "target user group" is that *my company* has fallen outside the definition decided by the developers. My company is now outside the "target user group".

IMHO I think the developers meant well to change the save/export situation, however, a mess has been made of it.

What's wrong with the Libre Office method: Open a non-ODX file, make a change, do a Save, get a dialog box that asks if you want to save in the old format (and lose any non-compatible changes) or in ODX format? The 'old format' button is already highlighted, so the user just has to hit the Enter key. Why is that approach so terrible? It seems to be okay for those (perhaps millions???) of users? And certainly users of word processing programs may possibly be less sophisticated than users of powerful image creation/editing software.

Unless something is done to arrive at a reasonable solution, my only remedy for my company is to lock down Gimp upgrades at the pre-change (save/export mess) level. When the time comes when the "old" Gimp will no longer run on our workstations, we will have to switch to another program ... and retrain staff on that other program. It is a real shame. I would much prefer that my staff would be able to use one SINGLE program for both highly productive workflow (open TIFF, make minor tweaks such as Curves, save/close as TIFF) and major editing/creation work that does need everything that XCF has to offer.

It is extremely valuable in a commercial environment to train on a SINGLE program, rather than duplicate training in multiple programs (to say nothing of maintaining, upgrading, etc.). The needs of commercial environments often seems to be forgotten in open source development planning.

ONE QUESTION... relating to locking down Gimp upgrades due to this situation: As of Gimp 2.6.6 (on Ubuntu Linux), the creation perms for TIFF (and I think some other) file types are wrong. I reported this bug (after being told that *I* must be doing something wrong) and the bug was quickly confirmed & fixed in development versions (thank you for that). However, what is the most recent (if there is one at all) non-development Gimp version (to run on Ubuntu 8.04 or 10.04) that contains the creation perms fix AND is BEFORE the new save-export-mess version?

Jay

On Wed, Jun 20, 2012 at 04:04:31PM -0400, Jay Smith wrote:

ONE QUESTION... relating to locking down Gimp upgrades due to this situation: As of Gimp 2.6.6 (on Ubuntu Linux), the creation perms for TIFF (and I think some other) file types are wrong. I reported this bug (after being told that *I* must be doing something wrong) and the bug was quickly confirmed & fixed in development versions (thank you for that). However, what is the most recent (if there is one at all) non-development Gimp version (to run on Ubuntu 8.04 or 10.04) that contains the creation perms fix AND is BEFORE the new save-export-mess version?

This is a question you should ask to the Ubuntu people, not here, however...just upgrade to last LTS version 12.04 will bring you last 2.6 GIMP version: 2.6.12.

See: http://packages.ubuntu.com/precise/graphics/gimp

bye

On Wed, 2012-06-20 at 16:04 -0400, Jay Smith wrote:

On 06/20/2012 02:50 PM, Alexandre Prokoudine wrote:

A universally accepted truth is that users don't read warnings. This will surely freak out few geeks who do read warnings carefully and recite them occasionally over a pint of beer in a pub, but mostly people really try to make stupid dialogs go away ASAP.

Alexandre Prokoudine

I have to agree that most users don't read (or perhaps more correctly, don't comprehend) warnings. However, often in open-source development there seems to be a general attitude that the "quality" of the software should be primary and protecting users from their own stupidity should be secondary. In fact, in my observation of open source conversations over the years, including occasionally in the past by only one or two people that were on this list, there has been a general attitude on the part of a few individuals that "ordinary users" are morons and should be ignored. Yet in this situation, the developers are tripping over themselves to protect the users from their own ignorance and inattention.

It just seems so odd... I feel like I have fallen into software Wonderland.

It has been pointed out several times that most of the developers are located in Europe. Europe has a reputation of having much more stifling government regulations and rules than North America. Could this be related -- the concept that people must be protected from themselves?

This might be the most stupid garbage that has ever been written on this list, but anyway...

I tried to make it clear once before but for the hard of hearing: the save/export stuff is going to stay, it will not become optional, and it will not go away.

If this doesn't please you, nobody forces you to use GIMP.

Can we now use the list for useful discussions again please?

Regards, --Mitch, stubborn European maintainer of this malware which gives a shit about your freedom to configure the crap out it.

On Wed, 20 Jun 2012 22:50:01 +0400, Alexandre Prokoudine wrote:

On Wed, Jun 20, 2012 at 7:53 PM, Guillermo Espertino (Gez) wrote:

But I just had an idea (sorry if anybody already suggested it and I missed it): What if the "merely harmeless to downright offensive" popup saying that Save is for XCF offers an extra button labeled "export anyway" or something similar?

A universally accepted truth is that users don't read warnings. This will surely freak out few geeks who do read warnings carefully and recite them occasionally over a pint of beer in a pub, but mostly people really try to make stupid dialogs go away ASAP.

If they don't, their bad fortune. Making a common operation less convenient for everyone because some user may not realize what's going on -- and no way to turn off the inconvenience -- is unnecessarily paternalistic, IMHO.

On Thu, Jun 21, 2012 at 12:04 AM, Jay Smith wrote:

In fact, in my observation of open source conversations over the years, including occasionally in the past by only one or two people that were on this list, there has been a general attitude on the part of a few individuals that "ordinary users" are morons and should be ignored.

This discussion won't move us forward if some vocal people keep assuming that developers treat users as morons. I've heard this argument over and over again with regards to people who would never think such a thing. Could you please accept this as a fact and move on?

People seem to learn best from adversity. If you corrupt your own image file and did not make a pre-editing backup copy, you just might learn something. However, if that same user is "protected" from doing something stupid, then the user will learn nothing.

Do you think you could ever get used to the idea that there's more than one way to teach people safety? :)

progressively even more ignorant. If users choose not to read warnings or don't take the time to think about and comprehend the meaning of warnings, then maybe the users deserve the spanking that they will receive as a result of their own action / inaction. Or is spanking illegal now too?

Dude, there's such a heap of lacking understanding in your case that I don't even know where to begin explaining. But let me try.

People don't choose not reading stuff per se. They do this subconciosly.

As an example, most recent eye-tracking studies show that users tend to avoid even looking at sidebars where adsense adverts typically are. They don't tell themselves: "Don't look! Don't look!", they just eventually stop looking there.

This is more or less what happens with warning dialogs. They are annoying, so people subcionciously learn to avoid paying attention to them.

What's wrong with the Libre Office method: Open a non-ODX file, make a change, do a Save, get a dialog box that asks if you want to save in the old format (and lose any non-compatible changes) or in ODX format? The 'old format' button is already highlighted, so the user just has to hit the Enter key. Why is that approach so terrible? It seems to be okay for those (perhaps millions???) of users? And certainly users of word processing programs may possibly be less sophisticated than users of powerful image creation/editing software.

This has been discussed a thousand times before. It's why Peter wrote this page: http://gui.gimp.org/index.php/Vision_briefing

I'm sorry, but even after reading that page you don't understand why the LibreOffice method doesn't work for GIMP, I'm going to have to assume that you are trying to annoyingly brute-force reverting the change. This is not going to work.

There's just one more thing. I'd like to introduce you to the concept of responsibility. Simply put, we are answerable for design decisions we make.

Whatever we do, it's us who are either praised or hated. People who try to talk us into something go away sooner or later, but _we_ stay.

You are basically telling us that our design decision is wrong even though we haven't even finished all of the work. If hell freezes, and we revert the change, _you_ won't be around to deal with annoyed target audience. _You_ won't have to deal with users on daily basis. _You_ won't take responsibility.

And that is precisely the reason why the team never blindly does everything it's told.

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, Jun 21, 2012 at 12:48 AM, Robert Krawitz wrote:

If they don't, their bad fortune. Making a common operation less convenient for everyone because some user may not realize what's going on -- and no way to turn off the inconvenience -- is unnecessarily paternalistic, IMHO.

Well, if you don't read warnings in this very list about http://gui.gimp.org/index.php/Vision_briefing, it's your bad fortune :)

It's been mentioned a thousand times that it's not just about making mistakes while saving, that there's also such a thing as creating complex images from scratch being the focus.

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 06/20/2012 04:40 PM, Marco Ciampa wrote:

On Wed, Jun 20, 2012 at 04:04:31PM -0400, Jay Smith wrote:

ONE QUESTION... relating to locking down Gimp upgrades due to this situation: As of Gimp 2.6.6 (on Ubuntu Linux), the creation perms for TIFF (and I think some other) file types are wrong. I reported this bug (after being told that *I* must be doing something wrong) and the bug was quickly confirmed& fixed in development versions (thank you for that). However, what is the most recent (if there is one at all) non-development Gimp version (to run on Ubuntu 8.04 or 10.04) that contains the creation perms fix AND is BEFORE the new save-export-mess version?

This is a question you should ask to the Ubuntu people, not here, however...just upgrade to last LTS version 12.04 will bring you last 2.6 GIMP version: 2.6.12.

See: http://packages.ubuntu.com/precise/graphics/gimp

bye

Marco,

Thanks for your quick reply to this, but I guess what I was asking was more general -- I am sorry that was not clear enough.

What is the latest non-development version (of which compilable source code can be obtained) that would include the perms fix, but be before the save/export change.

I do not know if the perms fix got into 2.6.12. Is there any way to know other than to install and find out? I imagine that here is a changelog somewhere but I am not sure where.

Thanks again.

Jay

On Thu, 21 Jun 2012 01:13:29 +0400, Alexandre Prokoudine wrote:

On Thu, Jun 21, 2012 at 12:48 AM, Robert Krawitz wrote:

If they don't, their bad fortune.  Making a common operation less convenient for everyone because some user may not realize what's going on -- and no way to turn off the inconvenience -- is unnecessarily paternalistic, IMHO.

Well, if you don't read warnings in this very list about http://gui.gimp.org/index.php/Vision_briefing, it's your bad fortune :)

It's been mentioned a thousand times that it's not just about making mistakes while saving, that there's also such a thing as creating complex images from scratch being the focus.

And that's fine, but surely experienced users will know this before long?

The real use case that I see is quick editing of a JPEG or PNG file. Something I suspect a lot of even hard core professional users do from time to time.

Am 20.06.2012 23:13, schrieb Alexandre Prokoudine:

On Thu, Jun 21, 2012 at 12:48 AM, Robert Krawitz wrote:

If they don't, their bad fortune. Making a common operation less convenient for everyone because some user may not realize what's going on -- and no way to turn off the inconvenience -- is unnecessarily paternalistic, IMHO.

Well, if you don't read warnings in this very list about http://gui.gimp.org/index.php/Vision_briefing, it's your bad fortune :)

It's been mentioned a thousand times that it's not just about making mistakes while saving, that there's also such a thing as creating complex images from scratch being the focus.

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list .

All i would ask for is that the "Save Image" Dialog will always default to *.xcf, but still would provide some quick way to save (export) to another format at choice. At the moment i often find myself (purely out of habit, which isn't only Gimps "fault") in the position that i actually wanted to save in another format. Now i have to close the dialog and to open the export dialog. This seams a little bit overcomplicated (throw away of time).

Don't get me wrong. I like the concept, but sometimes i want to go against such concepts if they remove a certain degree of freedom. In this case it doesn't make much sense to me to give the user not the option to override the default. Either by adding the desired extension or by pressing a button like "export instead of saving" inside the same dialog.

Tobias Oelgarte

On Wed, Jun 20, 2012 at 05:15:53PM -0400, Jay Smith wrote:

On 06/20/2012 04:40 PM, Marco Ciampa wrote:

On Wed, Jun 20, 2012 at 04:04:31PM -0400, Jay Smith wrote:

ONE QUESTION... relating to locking down Gimp upgrades due to this situation: As of Gimp 2.6.6 (on Ubuntu Linux), the creation perms for TIFF (and I think some other) file types are wrong. I reported this bug (after being told that *I* must be doing something wrong) and the bug was quickly confirmed& fixed in development versions (thank you for that). However, what is the most recent (if there is one at all) non-development Gimp version (to run on Ubuntu 8.04 or 10.04) that contains the creation perms fix AND is BEFORE the new save-export-mess version?

This is a question you should ask to the Ubuntu people, not here, however...just upgrade to last LTS version 12.04 will bring you last 2.6 GIMP version: 2.6.12.

See: http://packages.ubuntu.com/precise/graphics/gimp

bye

Marco,

Thanks for your quick reply to this, but I guess what I was asking was more general -- I am sorry that was not clear enough.

What is the latest non-development version (of which compilable source code can be obtained) that would include the perms fix, but be before the save/export change.

I do not know if the perms fix got into 2.6.12. Is there any way to know other than to install and find out? I imagine that here is a changelog somewhere but I am not sure where.

Thanks again.

Sorry for the misunderstanding... ok try this: test it by yourself! Start a UBUNTU 12.04 live and install GIMP 2.6.12. Don't worry, it installs it in RAM not on disk... then try it out if the defect is still there... if it is still there...then you have to use the newer GIMP 2.8.0 ...

Go test and report about it!

bye

On 20 June 2012 22:04, Jay Smith wrote:

People seem to learn best from adversity.  If you corrupt your own image file and did not make a pre-editing backup copy, you just might learn something.  However, if that same user is "protected" from doing something stupid, then the user will learn nothing.  They will not become a better user.  There is a fine line between successfully using the software and everything being a "learning by making mistakes" experience.  However, if users are coddled, you will simply end up with users that become progressively even more ignorant.  If users choose not to read warnings or don't take the time to think about and comprehend the meaning of warnings, then maybe the users deserve the spanking that they will receive as a result of their own action / inaction.  Or is spanking illegal now too?

I do not believe punishment is not a good foundation for teaching users of software. While perhaps effective in isolation as a teaching tool, basing the teaching method on it will lead to users being worried or fearful (due to receiving or anticipating punishment) more often. We want people to enjoy their tools, not fear them.

Furthermore it encourages dangerous arguments around interaction design decisions like "we need to teach the user" -> "we need to punish him for wrong behavior" -> "there needs to be ample opportunity for wrong behavior" (otherwise he will not learn).

People also learn best when different outcomes follow clearly from difference actions. The new model of save/export/overwrite makes this clearer: save will now _always_ save all your data, export will never.

[Not a serious suggestion] Maybe Gimp should, upon opening a file, make an archival copy of that file so that he user who fails to make a pre-editing backup copy, the user will be protected from his/herself.

Making a "pre-editing backup copy" shall not be necessary in the first place. Just follow the model that opened files cannot be changed in a non-destructive fashion.

We are not there in the general case yet, but for the workflow you describe below, we are already there. And we have made this more clear in 2.8+

Open file "myfile.png" -> work -> Export As "myfile_withchange.png"

Unless something is done to arrive at a reasonable solution, my only remedy for my company is to lock down Gimp upgrades at the pre-change (save/export mess) level.  When the time comes when the "old" Gimp will no longer run on our workstations, we will have to switch to another program ... and retrain staff on that other program.  It is a real shame.  I would much prefer that my staff would be able to use one SINGLE program for both highly productive workflow (open TIFF, make minor tweaks such as Curves, save/close as TIFF) and major editing/creation work that does need everything that XCF has to offer.

The following article provides information about the workflow in 2.8+, and suggestions how to get the old one back if you really want it: http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes

On 06/21/2012 12:48 AM, Tobias Oelgarte wrote:

All i would ask for is that the "Save Image" Dialog will always default to *.xcf, but still would provide some quick way to save (export) to another format at choice. At the moment i often find myself (purely out of habit, which isn't only Gimps "fault") in the position that i actually wanted to save in another format. Now i have to close the dialog and to open the export dialog. This seams a little bit overcomplicated (throw away of time).

You already mentioned habit. Having such an option would allow you to keep what is now a bad habit (to not discern between saving the work and exporting), instead of forming a new, productive one.

On 21/06/12 10:20, Thorsten Wilms wrote:

You already mentioned habit. Having such an option would allow you to keep what is now a bad habit (to not discern between saving the work and exporting), instead of forming a new, productive one.

IMHO the distinction between saving and exporting is an artificial one no one
really should need to care about.
The old behavior was productive and never got into the way of performing the task at hand which was to save the edited image to a format of choice. Why the dialog had to be split eludes me completely and annoys the heck out of me.
If you want to add to the usability any file save operation should in some way or another save the image to a versioned database in whatever form is required to be able to continue from that place (let's call that a master copy). Then no one should need to remember to first save and then export the picture. If reopening an image in whatever format would then solicit to open the saved master copy instead if that master copy exists. This would make the use of the saved image implicit and remove the need for the artificial distinction between saving and exporting and image...
BTW: I asked a few of my friends (who are less into image editing but well capable of using a computer and who at most only knew the GIMP by name) what export was supposed to mean and they all responded that it was the use of external resources to store the image (FB, Flickr, Dropbox)...
--
regards
Karl Gnter Wnsch

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Am 21.06.2012 10:20, schrieb Thorsten Wilms:

On 06/21/2012 12:48 AM, Tobias Oelgarte wrote:

All i would ask for is that the "Save Image" Dialog will always default to *.xcf, but still would provide some quick way to save (export) to another format at choice. At the moment i often find myself (purely out of habit, which isn't only Gimps "fault") in the position that i actually wanted to save in another format. Now i have to close the dialog and to open the export dialog. This seams a little bit overcomplicated (throw away of time).

You already mentioned habit. Having such an option would allow you to keep what is now a bad habit (to not discern between saving the work and exporting), instead of forming a new, productive one.

I doubt that this will work for me since I'm not only working with Gimp. I also work with many other programs that don't follow this pattern. If thats good or not isn't the real issue. It makes Gimp stand out and also in some aspect a pain to use, especially if you worked with another program and now opened Gimp for a small correction.

On Thu, Jun 21, 2012 at 12:48 PM, Karl Gnter Wnsch wrote:

BTW: I asked a few of my friends (who are less into image editing but well capable of using a computer and who at most only knew the GIMP by name) what export was supposed to mean and they all responded that it was the use of external resources to store the image (FB, Flickr, Dropbox)...

And that proves exactly what? :)

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 21/06/12 12:02, Alexandre Prokoudine wrote:

On Thu, Jun 21, 2012 at 12:48 PM, Karl Gnter Wnsch wrote:

BTW: I asked a few of my friends (who are less into image editing but well capable of using a computer and who at most only knew the GIMP by name) what export was supposed to mean and they all responded that it was the use of external resources to store the image (FB, Flickr, Dropbox)...

And that proves exactly what? :)

IMHO it only shows that the split of the function is artificial in nature and that the chosen command name for one of the most used function (no matter what you do, you can't upload an xcf for presentation on the web nor can you send in an xcf to a printer nor can you do anything worthwhile with an xcf outside the very limited world of the GIMP - so saving under a different format is a must for any user and export isn't the first command name that comes to mind of anyone if searching for this option) is ambiguous at best and progressively misleading in todays environment...
--
regards
Karl Gnter Wnsch

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, Jun 21, 2012 at 2:31 PM, Karl Gnter Wnsch wrote:

BTW: I asked a few of my friends (who are less into image editing but well capable of using a computer and who at most only knew the GIMP by name) what export was supposed to mean and they all responded that it was the use of external resources to store the image (FB, Flickr, Dropbox)...

And that proves exactly what? :)

IMHO it only shows that the split of the function is artificial in nature and that the chosen command name for one of the most used function (no matter what you do, you can't upload an xcf for presentation on the web nor can you send in an xcf to a printer nor can you do anything worthwhile with an xcf outside the very limited world of the GIMP - so saving under a different format is a must for any user and export isn't the first command name that comes to mind of anyone if searching for this option) is ambiguous at best and progressively misleading in todays environment...

What you are saying is:

1. We made a clear separation between saving and exporting... 2... where saving means preserving all project data for internal use 3... and exporting means saving a new file that is typically a JPEG or PNG for external use.
4. Your friends actually understand that separation on a user level. 5. Which makes us wrong.

In other words, you've just given us an example that supports our vision, while claiming that it contradicts it. That's one hell of an IMHO from you :)

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 21 June 2012 10:48, Karl Günter Wünsch wrote:

On 21/06/12 10:20, Thorsten Wilms wrote:

You already mentioned habit. Having such an option would allow you to keep what is now a bad habit (to not discern between saving the work and exporting), instead of forming a new, productive one.

IMHO the distinction between saving and exporting is an artificial one no one
really should need to care about.

This is the goal to strive for. I think everyone agrees on that. This is however not something we can achieve within a month or two. Currently, and for the immediate future, there is a difference between export and save in GIMP, due to the following facts: [save]: only XCF can store all the information about the document which you have produced. Not storing as XCF means you lose/destroy data
[export]: there is a common need for exporting to PNG/TIFF etc. - because XCF documents are not supported everywhere

With these current facts, I do not think we shall try to deceive the user into thinking that save and export is the same. They are not and the consequence for mixing them up can result in a loss of data. None of these facts are unchangeable however.

We can improve the situation for [export] by identifying in which work-flows people commonly use GIMP and export, and work to simply eliminate the need to care about the PNG/JPEG/TIFF file. For example the user might export to be able to view or work on the document in another libre graphics application. A strategy to get rid of that already exists, just make them support XCF: https://mail.gnome.org/archives/gegl-developer-list/2012-June/msg00003.html

Another common workflow might be to export a document to get it onto the web. We can eliminate the problem here by creating "export handler" that will let you upload directly, from within GIMP, to online services like Wordpress, Picasa, Facebook and similar.

Considering the [save] situation, there is a technical specification GEGL that can help things. Realizing it would make it possible for GIMP to implement a workflow where saving explicitly is never needed. https://mail.gnome.org/archives/gegl-developer-list/2012-June/msg00004.html

I encourage everyone who wish to contribute to the future of GIMP to find ways to help realize these or other strategies fix the fundamental problems at hand. Arguing about the keyboard shortcut used for export does nothing to positively improve the situation in any significant way. In fact it kills the motivation of developers who are putting sizable parts of their life into creating, maintaining and improving GIMP. When you kill motivation in volunteer-driven project, you are not just destroying someones hobby - the project will eventually stagnate, wither and die.

I am done arguing. Lets work to make GIMP-based workflows that currently include export/save inefficiencies better.

In fact it kills the motivation of developers who are putting sizable parts of their life into creating, maintaining and improving GIMP. When you kill motivation in volunteer-driven project, you are not just destroying someones hobby - the project will eventually stagnate, wither and die.

Oh for fuck's sake.

I was happy to hold my tongue until this. The developers are *victims* of users being unhappy with a design decision?

0/10 is the best I give

/g/

Monty

On Thu, Jun 21, 2012 at 2:59 PM, Monty Montgomery wrote:

I was happy to hold my tongue until this. The developers are *victims* of users being unhappy with a design decision?

Well, there's always been a certain pressure on the team. It comes with maintaining a popular product. And since GIMP is not a commercial product, there's no support service between developers and users to be shouted at.

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, 21 Jun 2012 12:51:36 +0200 Jon Nordby wrote:

With these current facts, I do not think we shall try to deceive the user into thinking that save and export is the same. They are not and the consequence for mixing them up can result in a loss of data. None of these facts are unchangeable however.

An idea that someone mentioned earlier which appealed to me* was the idea of an associated "export" file which is automatically updated on save. This in itself has a risk (overwriting an exported version that needed to be archived), but would allow "me" (A user, not necessarily squarely in the target audience) to concentrate on my work without needing to remember to export. This should not be taken as a criticism of the current situation for which I am wholly in favour. I already had tried to push my workflow in this direction with 2.6 and so the nex version counts as a simplification for me, not a complication.

Jon

* For the record and to provide context, my workflow is as follows:

- Photo in (Either digital, usually from raw, or digitisation of an analogue image - scanning).
- Edits varying from tweaking curves to full-on retouching. - Archiving of these edits in xcf format. - Export to jpg at varying levels of quality and with resizing depending on target (print / web).

Am 21.06.2012 12:40, schrieb Alexandre Prokoudine:

On Thu, Jun 21, 2012 at 2:31 PM, Karl Gnter Wnsch wrote:

BTW: I asked a few of my friends (who are less into image editing but well capable of using a computer and who at most only knew the GIMP by name) what export was supposed to mean and they all responded that it was the use of external resources to store the image (FB, Flickr, Dropbox)...

And that proves exactly what? :)

IMHO it only shows that the split of the function is artificial in nature and that the chosen command name for one of the most used function (no matter what you do, you can't upload an xcf for presentation on the web nor can you send in an xcf to a printer nor can you do anything worthwhile with an xcf outside the very limited world of the GIMP - so saving under a different format is a must for any user and export isn't the first command name that comes to mind of anyone if searching for this option) is ambiguous at best and progressively misleading in todays environment...

What you are saying is:

1. We made a clear separation between saving and exporting... 2... where saving means preserving all project data for internal use 3... and exporting means saving a new file that is typically a JPEG or PNG for external use.
4. Your friends actually understand that separation on a user level. 5. Which makes us wrong.

In other words, you've just given us an example that supports our vision, while claiming that it contradicts it. That's one hell of an IMHO from you :)

Alexandre Prokoudine http://libregraphicsworld.org

I fully understand your reasoning, but the terms are rather ambiguous. Lets take a look at the "commands" available after creating a new image. (Terms might differ slightly since I'm translating back from the German translation)

* Save
* Save as...
* Save Copy as...
* Export to (Disabled)
* Export...

1. "Save" is exactly the same as "Save as..." because the location isn't known - yet. But "Export to" is disabled. Is there a good reason why it is that way? I would say: Disable or enable both commands in this situation.

2. "Save as..." is ambiguous because the wording alone could mean that you want to a) save the current project under a different name. b) save the current image (what you see) under a different name and in another format.

Option a) makes perfect sense for the user if he works on a bigger project. But often he only wants to create a simple file or make a small change to an existing file and then "save" (export) it directly without seeing it as a project (xcf).

3. I find the menu in this situation a bit confusing, especially due to the disabled items. "Save" and "Save as..." have eye catching icons, while "Export" is widely separated and "hidden": Way below and behind disabled commands, directly followed by "Create Template..." (???) and then overshadowed by the printing commands with eye catching icons again. In other words: If you don't think about it and search for it you will quickly miss it and use "save" instead, finding yourself in a dialog where you can't do what you wanted to.

If this new way of project/file managing is the way to go then there should be some effort to make this functionality more clear for users. The last weak i introduced some younger people to GIMP 2.8 and i had to explain them how "saving" is supposed to work. The first question i got was: "How do i save as JPEG?". With GIMP 2.6 i didn't need to explain that part.

I usually work on bigger projects and I'm quite happy that it is this way now. Just recently i saved a project in MyPaint as PNG and lost all my layers in progress. The old version still existed, but the new work was doomed after closing MyPaint. I guess that is exactly what you wanted to address with this change. It is great for bigger projects, but its bad for the casual things when you not think about it as "The Project".

I would somehow propose that Gimp would actually differentiate between projects and casual image editing, if that makes sense and isn't even more confusing.

Tobias Oelgarte

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, 21 Jun 2012 14:40:09 +0400, Alexandre Prokoudine wrote:

On Thu, Jun 21, 2012 at 2:31 PM, Karl Günter Wünsch wrote:

BTW: I asked a few of my friends (who are less into image editing but well capable of using a computer and who at most only knew the GIMP by name) what export was supposed to mean and they all responded that it was the use of external resources to store the image (FB, Flickr, Dropbox)...

And that proves exactly what? :)

IMHO it only shows that the split of the function is artificial in nature and that the chosen command name for one of the most used function (no matter what you do, you can't upload an xcf for presentation on the web nor can you send in an xcf to a printer nor can you do anything worthwhile with an xcf outside the very limited world of the GIMP - so saving under a different format is a must for any user and export isn't the first command name that comes to mind of anyone if searching for this option) is ambiguous at best and progressively misleading in todays environment...

What you are saying is:

1. We made a clear separation between saving and exporting... 2... where saving means preserving all project data for internal use 3... and exporting means saving a new file that is typically a JPEG or PNG for external use.

No, "export" means the act of *sending* the image to the external resource, not converting the format. If a service provider accepts XCF files directly for download, the act of transferring the file is still an "export" by this definition.

Think in physical terms. Transporting an object from country A to country B is "exporting" it from country A, whether or not anything is changed about the object (repackaging, changing the electrical plug, etc).

4. Your friends actually understand that separation on a user level. 5. Which makes us wrong.

In other words, you've just given us an example that supports our vision, while claiming that it contradicts it. That's one hell of an IMHO from you :)

On Thu, Jun 21, 2012 at 4:33 PM, Robert Krawitz wrote:

Think in physical terms.

There's no way I will think about files in physical terms. It doesn't make any sense whatsoever and it's going to only to complicate an already annoying discussion.

I hereby resign from this thread.

Alexandre Prokoudine http://libregraphicsworld.org

Von: Alexandre Prokoudine

Well, there's always been a certain pressure on the team. It comes with maintaining a popular product. And since GIMP is not a commercial product, there's no support service between developers and users to be shouted at.

And the few people who consider themselves the closest thing to a support service are very, very calm and relaxed :)

Regards, Michael

Date: Wed, 20 Jun 2012 16:04:31 -0400 From: jay@JaySmith.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Bring back normal handling of other file formats

People seem to learn best from adversity. If you corrupt your own image file and did not make a pre-editing backup copy, you just might learn something. However, if that same user is "protected" from doing something stupid, then the user will learn nothing.

"Once bitten, twice shy."

Or as I like to say to myself, the smarter the technology the dumber the user.

It also relates to my complaint of why the "Export [filename]" command should be separate from the "Overwrite [filename]" command. One of the responses I got (on the bugtracker, in fact) was "accidental overwrites are bad" -- why is that? If you were working on an XCF file and make a significant, possibly destructive change (like changing to indexed-color mode), there is no mechanism to "protect" you from accidentally selecting Save if you really meant Save As, and this is not considered a problem. So why is the equivalent scenario in the import/export case suddenly a problem?

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Von: Richard Gitschlag

-- why is that? If you were working on an XCF file and make a significant, possibly destructive change (like changing to indexed-color mode), there is no mechanism to "protect" you from accidentally selecting Save if you really meant Save As, and this is not considered a problem.

I consider that a problem, and one that has to be solved sooner or later.

There are several suggestions in Bugzilla (auto-saving: https://bugzilla.gnome.org/show_bug.cgi?id=138373; saving the undo history: https://bugzilla.gnome.org/show_bug.cgi?id=148930) - see the discussions of the bugs for more insight in their respective challenges.

I've already mentioned in a previous mail that I can imagine a future GIMP version that won't need and won't have a dedicated Save command anymore, because you will be able to go back in time during your image manipulation, and maybe from any place within the image composition graph.

In short: do not expect this to be the last radical change in GIMP.

Regards, Michael

The first time I encountered the new "export/save" options, for some reason I got angry. Odd, don't you think, getting angry at an interface?

At one point I needed to open 9 screen-saved pngs in order to zealous crop the margins and export back to the original pngs. Dismissing the persistent "save in xcf" offers got a little tiresome. I could have waited until the end and killed them all in one swoop, but I was trying to regain a little screen space.

But after extensive testing with Gimp 2.9, and after finishing up an article for my website which involved creating, modifying, and saving a whole of images in diverse formats, I honestly don't notice the new export/save so much any more.

There is one little interface change that would make things easier for me. I'll suggest it, most tentatively. At present, the order in the Gimp 2.9 drop-down menu is "Save, Save as, Save a Copy, Revert, then a big line in the sand, then "Export to, Export, Create Template" (I can't check the 2.8 drop-down because I accidentally destroyed my 2.8 installation).

This may sound trivial, but the line between "Revert" and "Export to" makes my brain stop, like anything below the line isn't relevant to the act of writing an altered image out to disk. On that drop-down menu, it's a long way, visually and as the mouse travels, from "Save" to "Export to".

I will guess that for most users, definitely including myself, "Save a Copy" and "Revert" are not used nearly as much as "Save," "Export to" and "Export".

So how would it be if the line between the "Save" options and the "Export" options disappeared? And if "Revert" and maybe "Save a copy" got moved to down below "Export" and "Export to"?

It also might ease the pain of transitioning to a new way of doing things if "Save" read as "Save xcf", "Save a Copy" read "Save xcf Copy", "xcf" serving as a gentle reminder of what will really will happen.

Kind regards,
Elle

On 06/21/2012 10:58 AM, Elle Stone wrote:

It also might ease the pain of transitioning to a new way of doing things if "Save" read as "Save xcf", "Save a Copy" read "Save xcf Copy", "xcf" serving as a gentle reminder of what will really will happen.

+1

Elle wrote:

There is one little interface change that would make things easier for me. I'll suggest it, most tentatively. At present, the order in the Gimp 2.9 drop-down menu is "Save, Save as, Save a Copy, Revert, then a big line in the sand, then "Export to, Export, Create Template" (I can't check the 2.8 drop-down because I accidentally destroyed my 2.8 installation).

you can see the old state also in the spec:

So how would it be if the line between the "Save" options and the "Export" options disappeared? And if "Revert" and maybe "Save a copy" got moved to down below "Export" and "Export to"?

first of all: why are there separators (that line) in menus? it is to divide menus in sections that can be readily digested by users. al lot of menu items in a row take longer to scan,and to find your way back when you choose a menu item for the 100th time.

a lot starts fundamentally at 7. keeping 5 or less items in section is a good design goal.

I was not going to stick 7 items in a section, thus the separator is there.

also of course the items in a section belong together. this helps users to faster figure out what items stand for.

so I needed to distribute 7 items over 2 sections and take 28 years of established File menu history into account.

All the 3 Saves belong together, really no doubt about that. Revert belongs to the Saves, because it is Revert to saved it is often even labeled like that.

this is a nice demonstration of the value of the new save + export. in 2.6 you have the strudel that if you Saved to png (with losses) and you Revert, what are you going to get? your paths and layers? in 2.8 the situation is 100% clear: the last save to the xcf, which contains everything.

thus the Save section is getting full, and the 2 Export items go in the second section. it is really something different. Modern apps using Export do the same. Create template is also a derivation process, so I put it also in the second section.

btw: putting the Export items in their own section makes users find and hit them faster than when they were the Nth items in the Save section.

It also might ease the pain of transitioning to a new way of doing things if "Save" read as "Save xcf", "Save a Copy" read "Save xcf Copy", "xcf" serving as a gentle reminder of what will really will happen.

28 years of File menu say that that is too much belts and braces.

--ps

founder + principal interaction architect man + machine interface works

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

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Am 21.06.2012 18:38, schrieb Michael Schumacher:

I've already mentioned in a previous mail that I can imagine a future GIMP version that won't need and won't have a dedicated Save command anymore, because you will be able to go back in time during your image manipulation, and maybe from any place within the image composition graph.

glad (again) to hear that. I really hope that our grandchildren will have a hard time to understand why those 'applications' once burned up a dozen commands just to manage the _storage_ of data.

-yahvuu

Am 21.06.2012 19:58, schrieb Elle Stone:

The first time I encountered the new "export/save" options, for some reason I got angry. Odd, don't you think, getting angry at an interface?

At one point I needed to open 9 screen-saved pngs in order to zealous crop the margins and export back to the original pngs. Dismissing the persistent "save in xcf" offers got a little tiresome. I could have waited until the end and killed them all in one swoop, but I was trying to regain a little screen space.

But after extensive testing with Gimp 2.9, and after finishing up an article for my website which involved creating, modifying, and saving a whole of images in diverse formats, I honestly don't notice the new export/save so much any more.

There is one little interface change that would make things easier for me. I'll suggest it, most tentatively. At present, the order in the Gimp 2.9 drop-down menu is "Save, Save as, Save a Copy, Revert, then a big line in the sand, then "Export to, Export, Create Template" (I can't check the 2.8 drop-down because I accidentally destroyed my 2.8 installation).

This may sound trivial, but the line between "Revert" and "Export to" makes my brain stop, like anything below the line isn't relevant to the act of writing an altered image out to disk. On that drop-down menu, it's a long way, visually and as the mouse travels, from "Save" to "Export to".

I will guess that for most users, definitely including myself, "Save a Copy" and "Revert" are not used nearly as much as "Save," "Export to" and "Export".

So how would it be if the line between the "Save" options and the "Export" options disappeared? And if "Revert" and maybe "Save a copy" got moved to down below "Export" and "Export to"?

It also might ease the pain of transitioning to a new way of doing things if "Save" read as "Save xcf", "Save a Copy" read "Save xcf Copy", "xcf" serving as a gentle reminder of what will really will happen.

Kind regards,
Elle

I entirely agree with the observation that the "export" entry in the menu is badly positioned. It really "disappears" between the icon heavy "save" and "print" sections, which really seduces me to accidentally switch off my brain and select the "save as..." entry.

Tobias Olegarte

On 6/21/12, Tobias Oelgarte wrote:

I entirely agree with the observation that the "export" entry in the menu is badly positioned. It really "disappears" between the icon heavy "save" and "print" sections, which really seduces me to accidentally switch off my brain and select the "save as..." entry.

Tobias, that is an excellent observation - the heavy Save, Save as icons (plus two options seldom used, then a line) and No icons for Export to, Export - that would help explain why my eyes just don't "see" the export options - they do disappear behind all the visual competition.

El 21/06/12 20:22, Elle Stone escribi:

On 6/21/12, Tobias Oelgarte wrote:

I entirely agree with the observation that the "export" entry in the menu is badly positioned. It really "disappears" between the icon heavy "save" and "print" sections, which really seduces me to accidentally switch off my brain and select the "save as..." entry.

Tobias, that is an excellent observation - the heavy Save, Save as icons (plus two options seldom used, then a line) and No icons for Export to, Export - that would help explain why my eyes just don't "see" the export options - they do disappear behind all the visual competition

Notice that gnome-based desktops don't show icons in menus anymore (at least in the default form), so that isn't always true. But it's a good point anyway, probably against the inclusion of icons in menus.

Gez

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Am 22.06.2012 01:39, schrieb Guillermo Espertino (Gez):

El 21/06/12 20:22, Elle Stone escribi:

On 6/21/12, Tobias Oelgarte wrote:

I entirely agree with the observation that the "export" entry in the menu is badly positioned. It really "disappears" between the icon heavy "save" and "print" sections, which really seduces me to accidentally switch off my brain and select the "save as..." entry.

Tobias, that is an excellent observation - the heavy Save, Save as icons (plus two options seldom used, then a line) and No icons for Export to, Export - that would help explain why my eyes just don't "see" the export options - they do disappear behind all the visual competition

Notice that gnome-based desktops don't show icons in menus anymore (at least in the default form), so that isn't always true. But it's a good point anyway, probably against the inclusion of icons in menus.

Gez

Actually i love icons and would miss them. If they are placed wisely and are easily distinguishable then i don't even need to read the text, which improves my working speed significantly. A good example for the use of icons is nearly every media player. Who does not understand the "play/stop/pause/..." buttons that just use a typical icon instead of text? I compare icons to Japanese kanji where recognizing a single character is a whole different experience compared to reading latin letters that form a word.

But in case of Gimps File menu we have not very well distinguishable icons, placed in a bad way (wrong weighting) and not really good placed items in general. I mean what has "Export..." to do with "Create Template..." to be inside the same section, or why is "export to" disabled if "Save" isn't?

I would recommend to give the export functionality a useful icon and to seperate it from "Create Template", while renaming "Save" to "Save xcf" or "Save project" and "Save as..." to "Save project as/under...".

Tobias Oelgarte

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

El 22/06/12 05:30, Tobias Oelgarte escribi:

Actually i love icons and would miss them. If they are placed wisely and are easily distinguishable then i don't even need to read the text, which improves my working speed significantly. A good example for the use of icons is nearly every media player. Who does not understand the "play/stop/pause/..." buttons that just use a typical icon instead of text? I compare icons to Japanese kanji where recognizing a single character is a whole different experience compared to reading latin letters that form a word.

I don't have anything against icons, but I do agree with gnome folks (or was it free desktop?) regarding how much they clutter menus if every item has one and how they "hide" functions when an item hasn't an icon and the rest have.
Icons in a quick bar are indeed useful and help to reduce interruptions, but in menus thet are problematic (they have to be very small and still recognisable, if you have dozens of them in every section it becomes pretty hard to identify them).
Of course a "play, stop, pause" set of icons is easy to identify. They're simple geometric shapes illustrating simple concepts. But what about "crop layer to selection" or "add mask to selection"? What about filters? When the concept to illustrate becomes more complex, it's harder to create a identifiable icon. Check inkscape, for instance.

What's the criterion to choose which commands have icons and which don't? Frequency of use? For whom? Different kind of users use different kind of tools. What's useful for me can be something rarely used for you.

But in case of Gimps File menu we have not very well distinguishable icons, placed in a bad way (wrong weighting) and not really good placed items in general. I mean what has "Export..." to do with "Create Template..." to be inside the same section, or why is "export to" disabled if "Save" isn't?

I would recommend to give the export functionality a useful icon and to seperate it from "Create Template", while renaming "Save" to "Save xcf" or "Save project" and "Save as..." to "Save project as/under...".

Just keep in mind that Gnome users won't see it. Personally, I didn't miss them when I moved to Gnome 3 (actually, I didn't realize they were gone at first). I helped in the development of a tangoified set of icons for inkscape and I can remember how much work and how hard it was to come up with something reasonably good for menus, and I'm not sure we met the goal.
Relying on icons for menus takes a lot of effort nobody seems to be willing to make, and in my honest opinion it doesn't make a real difference.

Gez.

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Am 22.06.2012 18:20, schrieb Guillermo Espertino (Gez):

El 22/06/12 05:30, Tobias Oelgarte escribi:

Actually i love icons and would miss them. If they are placed wisely and are easily distinguishable then i don't even need to read the text, which improves my working speed significantly. A good example for the use of icons is nearly every media player. Who does not understand the "play/stop/pause/..." buttons that just use a typical icon instead of text? I compare icons to Japanese kanji where recognizing a single character is a whole different experience compared to reading latin letters that form a word.

I don't have anything against icons, but I do agree with gnome folks (or was it free desktop?) regarding how much they clutter menus if every item has one and how they "hide" functions when an item hasn't an icon and the rest have.
Icons in a quick bar are indeed useful and help to reduce interruptions, but in menus thet are problematic (they have to be very small and still recognisable, if you have dozens of them in every section it becomes pretty hard to identify them). Of course a "play, stop, pause" set of icons is easy to identify. They're simple geometric shapes illustrating simple concepts. But what about "crop layer to selection" or "add mask to selection"? What about filters? When the concept to illustrate becomes more complex, it's harder to create a identifiable icon. Check inkscape, for instance.

At the same time icons can provide a basic idea on what to expect. They are only bad if they are not of the same style, badly designed or incomplete. In the current situation i tried to add icons to all relevant (mostly used) entries and it looked way better and intuitive. In situations with a list of similar commands an icon should focus on the difference between this commands, especially if the commands are named in a similar way. A good example would be mask or boolean operations.

http://i1-win.softpedia-static.com/screenshots/Windows-Portable-Applications-Portable-Inkscape_7.png

What's the criterion to choose which commands have icons and which don't? Frequency of use? For whom? Different kind of users use different kind of tools. What's useful for me can be something rarely used for you.

I guess we can agree that the save and export functions are important for everyone. Thats why i would propose to give it a icon, even so on some systems/desktops they might not be visible.

But in case of Gimps File menu we have not very well distinguishable icons, placed in a bad way (wrong weighting) and not really good placed items in general. I mean what has "Export..." to do with "Create Template..." to be inside the same section, or why is "export to" disabled if "Save" isn't?

I would recommend to give the export functionality a useful icon and to seperate it from "Create Template", while renaming "Save" to "Save xcf" or "Save project" and "Save as..." to "Save project as/under...".

Just keep in mind that Gnome users won't see it. Personally, I didn't miss them when I moved to Gnome 3 (actually, I didn't realize they were gone at first). I helped in the development of a tangoified set of icons for inkscape and I can remember how much work and how hard it was to come up with something reasonably good for menus, and I'm not sure we met the goal. Relying on icons for menus takes a lot of effort nobody seems to be willing to make, and in my honest opinion it doesn't make a real difference.

In that case i have to congratulate you for the useful and well distinguishable icons. They are really good help for beginners. From my experience beginners tend to remember icons much faster as the name of the function itself.

Tobias Oelgarte

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list