Date: Wed, 13 Jun 2012 19:21:47 -0400 From: kevin@ve3syb.ca
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Bring back normal save

On 12-06-06 12:21 PM, � wrote:

Btw, why can we "open" a JPG but not "save" a JPG, if we "export" to JPG should we than not has "import" JPG files to keep the logic?

That does seem like an inconsistency at first but a lot of other programs just use "open" for other file formats they can read instead of import.

The term "Import" also has the connotation of adding another file into the current document, instead of opening it as a completely new document entirely. GIMP's command for that purpose is "Open Image As (new layer/etc.)" .

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

Hi,

This whole idea of refusing it operate on other file formats is artificial, contrived and obstructive.

Yesterday I found some other corollary problems that this flawed behaviour introduces.

I was scanning some macro shots for file negative, the scanner software produces huge tiff files that I need to do some processing on and then store in a non-lossy *compressed* format. PNG seems the obvious choice and is the format that I usually work in.

The negs are scanned at 3200 dpi and the tiff files are huge and I *require* a compressed format. I have NO wish to create an alternative bloat format called xcf, one of the primary objectives of this processing is to make the file size more manageable not to make yet more bloated duplicates.

The first operation is usually to select a smaller region of the scan and save it as a new image before doing some further processing. This new image is saved as png, the non-lossy compressed format I require. Of course I can no longer "save" it with gimp , I have to "export" it.

AT this point, I often need to check the resulting file size.

If I go to Image | Properties I find the file name and file size empty. Ah-ha! it has not been "saved" yet. Of course if I had "saved" it I would just be seeing the size of the bloated xcf not the of the file I am trying to work with.

So to test, I open the new PNG file separately and again check Image | Properties

Its name and size are STILL empty.

Gimp's inability to work with standard formats is becoming a major PITA.

Perhaps gimp was not such a bad name for it after all, its functionality is becoming crippled.

This contrived attempt to force all users into importing and exporting everything and dealing with a shit load of stupid warning dialogues about not having saved something has just been save is getting worse as time goes on.

Is it really that desirable to have a "top-end" image processing tool that cannot deal effectively with processing standard image formats?

regards.

Date: Thu, 14 Jun 2012 10:03:41 +0200 From: gg@catking.net
To: gimp-developer-list@gnome.org
Subject: [Gimp-developer] Bring back normal handling of other file formats [...]

Gimp's inability to work with standard formats is becoming a major PITA.

Perhaps "gimp" was not such a bad name for it after all, its functionality

is becoming crippled.

Ouch, that is an awesome pun.

IMHO, limiting Save to XCF only invariably sends the conceptual message that GIMP is no longer the "GNU Image Manipulation Program" -- it is now the "GNU Image Making Program".

I still believe GIMP should, instead of merely informing the user that Save operates in XCF only, offer an export/save xcf/cancel option which would alleviate the need to go back and use a different dialog as a separate step. (You never know if a user might actually WANT to save their GIMP file under a non-XCF filename)

I doubt that would violate the terms of the Save/Export spec that the dev team swears by.

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

Date: Thu, 14 Jun 2012 10:03:41 +0200 From: gg@catking.net
To: gimp-developer-list@gnome.org
Subject: [Gimp-developer] Bring back normal handling of other file formats

AT this point, I often need to check the resulting file size.

If I go to Image | Properties I find the file name and file size empty. Ah-ha! it has not been "saved" yet. Of course if I had "saved" it I would just be seeing the size of the bloated xcf not the of the file I am trying to work with.

BTW, I was going to post this to Bugzilla but I cannot actually duplicate the behavior in my GIMP 2.8 .

- Import image -> Image Properties = shows imported filename/size

- new image -> save XCF -> Image Properties = shows XCF filename/size

- new image -> export -> Image Properties = shows exported filename/size

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

On Jun 14, 2012, at 16:37, Richard Gitschlag wrote:

I still believe GIMP should, instead of merely informing the user that Save operates in XCF only, offer an export/save xcf/cancel option which would alleviate the need to go back and use a different dialog as a separate step. (You never know if a user might actually WANT to save their GIMP file under a non-XCF filename)

I doubt that would violate the terms of the Save/Export spec that the dev team swears by.

yes it does. you cannot go through save if it is not safe.

--ps

founder + principal interaction architect man + machine interface works

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

"Bring Back Save" is the new CMYK. :-)

peter sikking wrote:

yes it does. you cannot go through save if it is not safe.

"Safe" is a value judgement. The assumption being made is that preserving every possible detail that gimp can create overrides every other consideration.

Many users will not agree that this is the case in every or even most situations. If they are opening a .jpg file, it's already in a lossy format, so it's quite possible (even probable) that they are happy if further loss occurs. If they open a .tiff, then they may be quite happy to save just what a .tiff will hold (ie. all the pixel values), and not care about what other stuff gimp has invented internally.

Certainly the utility of an image manipulation program seems impaired if it can't open/edit/save an image without jumping through hoops.

Graeme Gill.

Graeme Gill (graeme2@argyllcms.com) wrote:

Many users will not agree [...]

And many users will (and have even on this list) agreed, that this change makes sense.

Certainly the utility of an image manipulation program seems impaired if it can't open/edit/save an image without jumping through hoops.

I think we agree that the functionality is there, it has just shifted around in a manner that you dislike.

This discussion really boils down to a matter of taste and there are arguments for both ways. Unfortunately in your case you're taste weighs less than the taste of Peter to the developers.

Sorry, sometimes we can't make it right for everyone.

Bye, Simon

El 14/06/12 21:19, Graeme Gill escribi:

"Safe" is a value judgement. The assumption being made is that preserving every possible detail that gimp can create overrides every other consideration.

Many users will not agree that this is the case in every or even most situations. If they are opening a .jpg file, it's already in a lossy format, so it's quite possible (even probable) that they are happy if further loss occurs. If they open a .tiff, then they may be quite happy to save just what a .tiff will hold (ie. all the pixel values), and not care about what other stuff gimp has invented internally.

Certainly the utility of an image manipulation program seems impaired if it can't open/edit/save an image without jumping through hoops.

Yes, but as soon as you created an extra layer, a complex selection, channel or any other feature that is only saved in XCF files, saving to those formats becomes a potentially dangerous procedure. GIMP has something awesome that's also dangerous: a feature that saves (now exports) to the right format by detecting the extension used. That feature is extremely handy, but in my experience it proved to be the source of many headaches.
A simple example: Your client sent you a photo for a brochure in jpg format, you have to create a mask using bezier curves and layers masks and save the resulting image as PNG with transparent background. You create those complex beziers, you create several layers with masks and your work is done. Phone rings, you get distracted buy your muscle memory dictates that you have to save your work. Hit CTRL+S, accept the annoying popup and close GIMP.
Result: Now you have a flattened JPG with a white background, no more masks, no more bezier curves, nada.
I can't count how many times I did that accidentally, and that's something that won't happen again with the new workflow. It takes some time to rewrite the muscle memory and get used, but it certainly pays back.
That being said, I do agree that the overwrite function is somewhat odd (it hasn't a default keystroke, it disappears once you used it and becomes export). I guess that could be better, but I can't tell how. In my opinion the problem isn't the save vs. export function. Is the overwrite function. Probably it only needs to be a permanent option and a default shortcut and that's it.

Gez.

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

(Gez) wrote:

That being said, I do agree that the overwrite function is somewhat odd (it hasn't a default keystroke, it disappears once you used it and becomes export).

I did not put keystroke by default to be on the safe side. for those who overwriting is actually part of their routine, they can assign it themselves. on balance I think the effort involved in assigning is a good thing.

"disappears once you used" is a bug that has been fixed for 2.8.1.

--ps

founder + principal interaction architect man + machine interface works

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

On Fri, Jun 15, 2012 at 4:19 AM, Graeme Gill wrote:

Many users will not agree that this is the case in every or even most situations.

It's not about "many users", it's about the target audience whose interestes get the top priority.

The target audience has been consistently approving this change ever since 2.8 made its wau to the public, with very few exceptions.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Jun 15, 2012 at 5:06 AM, Alexandre Prokoudine wrote:

It's not about "many users", it's about the target audience whose interestes get the top priority.

I still wonder how much the target audience overlaps with the actual audience. :)

Rockwalrus

El 15/06/12 11:35, Nathan Summers escribi:

I still wonder how much the target audience overlaps with the actual audience. :)

Let me put it this way: "I still wonder how can we attract our target audience if we do things for a different audience". GIMP project has chosen a sane path: to define a target audience and start designing the application around that audience. Our problem was always the lack of a target audience. That's why our current userbase (not audience) is an awful mix of users of all levels except serious artists and professionals. GIMP has to deliver solutions for this specialized audience instead of dealing with our current large and diverse userbase demanding for a free Photoshop clone.
Serious artists and professionals usually don't want feature X or a UI like program Y. They want a tool to get their job done, and if GIMP can make that happen, it will become a serious tool. The rest of the users will catch up later.

Gez

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

În data de Fri, 15 Jun 2012 02:33:54 +0200, Simon Budig a scris:

And many users will (and have even on this list) agreed, that this change makes sense.

I agreed with the actual change, which I find useful and on the "safe" side as mentioned here.

There is, however, a big annoyance in the following scenario: - open GIMP
- drop a (say) .png image
- change something there
- export the modified image to other (say) .png - close GIMP
- the program asks "Do you want to save the changes blah, blah ?"

Now *this* is annoying. I already have saved my changes, why should I give it written proof for that ?

If I use OpenOffice/LibreOffice and export a document to something different than OpenDocument format, if after export I just close the program, the program simply closes. _This_ is normal.

Cristi

Cristian Secară (liste@secarica.ro) wrote:

If I use OpenOffice/LibreOffice and export a document to something different than OpenDocument format, if after export I just close the program, the program simply closes. _This_ is normal.

This is just not true.

* open a .odt file into libreoffice * add some letters
* use "Export as PDF"
* close libreoffice
* Libreoffice asks for confirmation before closing.

Which is of course the sane thing to do.

Bye, Simon

Simon Budig (simon@budig.de) wrote:

Cristian Secară (liste@secarica.ro) wrote:

If I use OpenOffice/LibreOffice and export a document to something different than OpenDocument format, if after export I just close the program, the program simply closes. _This_ is normal.

This is just not true.

Ah, sorry, I missed that "Export as PDF" is not the same as "Export..." and then choosing PDF. Which is a big WTF to me...

Bye, Simon

from "Bring back normal handling of other file formats"

El 14/06/12 21:19, Graeme Gill escribi: > "Safe" is a value judgement. The assumption being made is that preserving > every possible detail that gimp can create overrides every other consideration.
>
> Many users will not agree that this is the case in every or even most situations.
> If they are opening a .jpg file, it's already in a lossy format, so it's quite
> possible (even probable) that they are happy if further loss occurs. If they open
> a .tiff, then they may be quite happy to save just what a .tiff will hold > (ie. all the pixel values), and not care about what other stuff gimp has > invented internally.
>
> Certainly the utility of an image manipulation program seems impaired if > it can't open/edit/save an image without jumping through hoops. >

I think the whole problem here is that there are two different uses which are being presented as one.

Save (as gimp internal format) and Export (to original format) is clear , though I would say it's back to front.

However, the ambiguity is in File | Open

In fact File | Open does not open the file for editing , it IMPORTS it, hence the need to export it later.

xcf saves lots of information which is useful for extended (time frame) work on an image. That is valuable but not always needed for shorted time frame work that may non the less require be non trivial, requiring the advanced features of gimp.

Another ambiguity is the idea of "opening a file" when what gimp is really doing operating on an image, not a file.

I think what is needed to clarify the situation and remove the ambiguity of open/import and file/image is close to what Nicholas suggested a week or two back on a similar discussion introducing the idea of a "desktop". It did not really stick but the I think it is the key.

xcf format is a format that saves a gimp image project , in all but name.

Gimp saves lots of information about the state of gimp and state of the editing session and temporary layers etc that are artefacts of the work in progress , not the original nor final image. It is valuable to be able to save exactly where one is at any stage of the job and pick it up later without losing anything. Fine.

What this calls for is the concept of a PROJECT as distinct from a file.

In this context the current File | Open becomes File | Import. Then Save becomes save_project that will save the current _project_ including any layers etc that are present. It will be clear in the interface that a new entity is being created and saved.

Opening a file and saving it should save the _file_ not create something else while _not_ saving the file.

File | Open would do just that and provide a mechanism for doing short term changes that do not require generation of a gimp project (xcf) file.

This would remove the arcane situation where one opens an image file but then have to export it instead of save it in order to change the actual file being worked on.

The advanced professional workflow would be served in the same way but would be explicitly presented as creating a project operating on an image. Then exporting the project's current content to a (flattened or lossy) format becomes logically coherent. Saving would be saving the project file (xcf).

Opening a _file_ other than xcf then indicates the explicit intention to operate directly on the _file_ without creating the overhead of a project. Saving saves to the file. Save_As could be used if we change our mind and want to create a project.

It seems a lot of the current contention comes from the attempt to unite two conflicting workfows and inherently makes one that should be simple complicated.

> Certainly the utility of an image manipulation program seems impaired if > it can't open/edit/save an image without jumping through hoops. >

Clear differentiation between file and image project should remove the hoops.

/gg

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

++
I think this hits it on the head.

Monty

* Monty Montgomery [06-16-12 07:47]:

++
I think this hits it on the head.

somehow the *argument* is quite empty of substance.

xcf *is* a *gimp* graphical file format.

it has been utilized for quite a long time in its present usage, therefore is not a "project file format".

http://en.wikipedia.org/wiki/XCF_%28file_format%29

it has been utilized for quite a long time in its present usage, therefore is not a "project file format".

As someone who's been using Gimp for coming up on 17 years, I have always thought of .xcf as the Gimp project file format. I only ever save in xcf when I want to save .... my project. It's not useful for anything else. Especially seeing as how ~ only the Gimp uses it.

I reiterate that IMHBCO gg hit the nail squarely on the head.

Monty

gg wrote:

I think the whole problem here is that there are two different uses which are being presented as one.

Save (as gimp internal format) and Export (to original format) is clear , though I would say it's back to front.

However, the ambiguity is in File | Open

lets get some facts clear:

- what you see inside a GIMP window is always, always, always in GIMP format, even if the only thing you did was open (= import, as it shows in the interaction) a png file and nothing more.

- it is 100% impossible to arrange it for popular non-GIMP files (png/jpeg/tiff) there would be a mode where one could Open one, make edits within the limits of the file format, and write the bits straight back to a file in the same format.

- I would be yanking the chain of one million users if I specced that the only way to get a non-GIMP file into GIMP is by File->Import... also drag and drop behaviour of start a new file from a non-GIMP file would come into question (at minimum, it would have become a curve ball).

- all we can do is make sure that every bit of interaction in GIMP communicates that there are no png/jpeg/tiff/etc files inside GIMP. anything that is not on-message? let me know, it is a bug.

as Kate confirmed, the concept of Work that Nicholas brainstormed his way into is exactly the line of our thinking at the moment. Work is so much better than Project because projects is an organisation form of (teams of) GIMP users and a project can contain many Works.

what bugs me right now is that the interaction of GIMP still talks about image when communicating about GIMP files. This could right now be migrated to talk about work, while still calling all non-GIMP files image.

--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

- what you see inside a GIMP window is always, always, always in GIMP format, even if the only thing you did was open (= import, as it shows in the interaction) a png file and nothing more.

- it is 100% impossible to arrange it for popular non-GIMP files (png/jpeg/tiff) there would be a mode where one could Open one, make edits within the limits of the file format, and write the bits straight back to a file in the same format.

Peter:

I think you misunderstood what gg is suggesting:

He is not suggesting direct manipulation in non GIMP-native format.

He is suggesting that there be a top-level "straight arrow" workflow where it is understood that the final product should be in the same format as the initial one, without saving in .xcf or having to "jump through hoops" to save in the original format.

And he is suggesting terminology to label the interactions (or non-interactions) between the two workflows (since somebody will often "switch" midstream), and to make things clearer.

Terminology matters.

A lot.

- I would be yanking the chain of one million users if I specced that the only way to get a non-GIMP file into GIMP is by File->Import...

I just don't understand this statement. If it is yanking their chain, when actually this is what is being done, there is cognitive dissonance. If "open" actually imports, call it import.

In addition: If your target users are happy with "export", they are happy with "import".

What would appear to me to be reasonable "compromise" is that "Open" be used to signal that you intend to save in the same format as the original, and "Import" to signal that XCF is to be used when saving.

"Save as" could then be used to change the preferred save type, however, in effect allowing one to switch mode between "XCF is saved" and "PNG-TIFF-JPG is saved", since really this has to do, strictly, with indicating what kind of object "save" is supposed to save.

also drag and drop behaviour of start a new file from a non-GIMP file would come into question (at minimum, it would have become a curve ball).

Indeed, this complicates non-menu/shortcut interaction, because you need two types of open/import instead of one.

- all we can do is make sure that every bit of interaction in GIMP communicates that there are no png/jpeg/tiff/etc files inside GIMP. anything that is not on-message? let me know, it is a bug.

Again, this is not an "inside GIMP" issue: This has to do with specifying what is "saved" by default: XCF or the original format of the most significant piece?

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

I also believe that gg hits an important point by suggesting that a clear choice be made w.r.t.

Are we opening and image, or a file?

They truly are not really the same thing.

Nicolas wrote:

Peter:
I think you misunderstood what gg is suggesting:

no I did not. I pointed out some facts that close many, many routes in this kind of reasoning. closed and done, yes.

let me first make a statement:

_every_ time (yes, that is around a hundred times now) that I see this kind of user feedback (that it is normal to open a non-GIMP file, do some edits, then save it to the same format) I start to think like interaction designers should:

lets assume he is right. make it just work.

and every time I run into the same problems, that are giant usability bloopers.

- to really Save the contents of the file has to match what is on the screen (save, quit, restart, open file: no change--undo history excepted). this is not just a good idea, this is the law. breaking the law: usability blooper.

- this means that either all users would have to have intimate knowledge of file formats to know why the option to save to them disappear as edits are done (usability blooper. bit of alpha is introduced? no more jpeg; any layers? no more png; paths and layers? tiff is still there???) or one is doing the whole export thing anyway, so what is the difference (exporting is not safe, remember?) where are the extra hoops?

- the alternative would be to limit things:

- it is 100% impossible to arrange it for popular non-GIMP files (png/jpeg/tiff) there would be a mode where one could Open one, make edits within the limits of the file format, and write the bits straight back to a file in the same format.

a multi-personality application: complete usability disaster.

and that is where it stops.

--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

Belated reply, but....

From: peter@mmiworks.net
Date: Thu, 14 Jun 2012 18:03:39 +0200 To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Bring back normal handling of other file formats

On Jun 14, 2012, at 16:37, Richard Gitschlag wrote:

> I still believe GIMP should, instead of merely informing the user that Save operates in XCF only, offer an export/save xcf/cancel option which would alleviate the need to go back and use a different dialog as a separate step. (You never know if a user might actually WANT to save their GIMP file under a non-XCF filename)

I doubt that would violate the terms of the Save/Export spec that the dev team swears by.

yes it does. you cannot go through save if it is not safe.

--ps

Well, the spec only says:

Save, ‘Save as’ and ‘Save a copy’ shall only save to (compressed) GIMP

formats, which shall be the only available format choices in

the Save

dialog. Only Save and ‘Save as’ shall change the saved-status of the document and replace the document–to–file association.

http://gui.gimp.org/index.php/Save_%2B_export_specification

It does NOT specify that GIMP must be a stick in the mud and refuse to delegate to the Export command if the user types in a non-XCF filename - which is part of the very vocal complaint about the fundamental change in file-writing behavior.

Things would be much easier on the end user if:

... If the user inputs a filename with a non-XCF extension into the Save dialog, GIMP must refuse to save the document, as GIMP documents should always be paired with an XCF extension (for system file-association). GIMP may, however, present a yes/no confirmation asking whether the user intended to Export the document instead; if yes, the document will not be saved as an XCF, but program flow will branch to the "Export" command and proceed from there instead.

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

On Fri, 2012-06-15 at 22:10 +0300, Cristian Secară wrote: [...]

There is, however, a big annoyance in the following scenario: - open GIMP
- drop a (say) .png image
- change something there
- export the modified image to other (say) .png - close GIMP
- the program asks "Do you want to save the changes blah, blah ?"

Now *this* is annoying. I already have saved my changes, why should I give it written proof for that ?

I'd be OK if it *told* me,

File Untitled has not been saved as xcf. It has been exported as paisley.jpg [300x500px]

so that I knew the status and the warning was useful.

Liam

Richard Gitschlag wrote:

I doubt that would violate the terms of the Save/Export spec that the dev team swears by.

yes it does. you cannot go through save if it is not safe.

Well, the spec only says:

Save, Save as and Save a copy shall only save to (compressed) GIMP formats, which shall be the only available format choices in the Save dialog. Only Save and Save as shall change the saved-status of the document and replace the documenttofile association.

that is why I wrote the clarification above.

it is the whole _route_ of Save that is off-limits to things that re not safe. see my other posts of today.

--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

Liam wrote:

I'd be OK if it *told* me,

File Untitled has not been saved as xcf. It has been exported as paisley.jpg [300x500px]

so that I knew the status and the warning was useful.

something similar to that (without the pixels) has been applied as a patch for 2.8.1. (Bug 675399)

--ps

founder + principal interaction architect man + machine interface works

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

Date: Sat, 16 Jun 2012 09:16:08 -0400 From: nicolas.robidoux@gmail.com
To: peter@mmiworks.net
CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] present xcf as what it is, a gimp project file format

Terminology matters.

A lot.

- I would be yanking the chain of one million users if I specced that the only way to get a non-GIMP file into GIMP is by File->Import...

I just don't understand this statement. If it is yanking their chain, when actually this is what is being done, there is cognitive dissonance. If "open" actually imports, call it import.

The term "Import" also has a well-entrenched meaning of "copy and paste from source file into current document". GIMP already has such a function, the "Open As (Layer/etc)..." commands.

From: peter@mmiworks.net
Date: Sat, 16 Jun 2012 16:23:57 +0200 To: nicolas.robidoux@gmail.com
CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] present xcf as what it is, a gimp project file format

let me first make a statement:

_every_ time (yes, that is around a hundred times now) that I see this kind of user feedback (that it is normal to open a non-GIMP file, do some edits, then save it to the same format) I start to think like interaction designers should:

let’s assume he is right. make it ‘just work.’

and every time I run into the same problems, that are giant usability bloopers.

- to really Save the contents of the file has to match what is on the screen (save, quit, restart, open file: no change--undo history excepted). this is not just a good idea, this is the law. breaking the law: usability blooper.

- this means that either all users would have to have intimate knowledge of file formats to know why the option to save to them disappear as edits are done (usability blooper. bit of alpha is introduced? no more jpeg; any layers? no more png; paths and layers? tiff is still there???) or one is doing the whole export thing anyway, so what is the difference (exporting is not safe, remember?) where are the extra hoops?

- the alternative would be to limit things:

- it is 100% impossible to arrange it for popular non-GIMP files (png/jpeg/tiff) there would be a mode where one could Open one, make edits within the limits of the file format, and write the bits straight back to a file in the same format.

a multi-personality application: complete usability disaster.

and that is where it stops.

--ps

Various apps that still support saving in other than their preferred native formats (e.g. MS Word) frequently detect and warn the user that the non-native format may not support some of the features in their document, in other words that what gets written to disk cannot necessarily be a perfect representation of the open document as it looks in the editor. It may be an ACCEPTABLE facsimile of it depending on how much was and was not recorded (i.e: the presence of an alpha channel means only that the image CAN contain transparent pixels; it does not mean the image DOES in fact contain transparent pixels), but it is the user's responsibility to make that call, not the program's.

Remember, GIMP up to 2.6 was perfectly capable of detecting whether or not the image contained data that could not be stored in the target file format and offering the user options to resolve these differences before writing to disk.

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

Richard Gitschlag wrote:

The term "Import" also has a well-entrenched meaning of "copy and paste from source file into current document". GIMP already has such a function, the "Open As (Layer/etc)..." commands.

I think you are very selective there what conventions surround Import. simply importing a an excel sheet into a non-ms program (open office, apples numbers) comes with a host of fears and promises. the fact that it has to be portrayed as an import (even though it can and is done via the Open command) meshes with the fact that these imports are lossy, non-perfect.

lets be clear: the primary reason that there is both Open and Open As (Layer/etc) is to steer new document creation or new layer/etc creation. the rest is secondary.

Various apps that still support saving in other than their preferred native formats

[snip]

I have already explained today where the flaw is in this (for GIMP, context is everything).

here we stop going in circles.

--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

- to really Save the contents of the file has to match what is on the screen (save, quit, restart, open file: no change--undo history excepted). this is not just a good idea, this is the law. breaking the law: usability blooper.

Indeed, if "Save is lossless" is a law, "Save" has to be to XCF, and something else has to be used to "save" to any other format.

Nonetheless, I can't help but think that few people would buy a gun that makes it hard to shoot yourself in the foot.

No matter how sensical the feature.

Because most of us like to shoot first and ask questions later.

* Nicolas Robidoux [06-16-12 12:55]:

- to really Save the contents of the file has to match what is on the screen (save, quit, restart, open file: no change--undo history excepted). this is not just a good idea, this is the law. breaking the law: usability blooper.

Indeed, if "Save is lossless" is a law, "Save" has to be to XCF, and something else has to be used to "save" to any other format.

Maybe "export to"

Nonetheless, I can't help but think that few people would buy a gun that makes it hard to shoot yourself in the foot.

No matter how sensical the feature.

Because most of us like to shoot first and ask questions later.

Perhaps YOU are not the "target audience".

On 16 June 2012 18:54, Nicolas Robidoux wrote:

- to really Save the contents of the file has to match what is on the screen (save, quit, restart, open file: no change--undo history excepted). this is not just a good idea, this is the law. breaking the law: usability blooper.

Indeed, if "Save is lossless" is a law, "Save" has to be to XCF, and something else has to be used to "save" to any other format.

Nonetheless, I can't help but think that few people would buy a gun that makes it hard to shoot yourself in the foot.

No matter how sensical the feature.

Most guns I know have the very sensible feature of a safety switch. It does make it harder to accidentally shoot oneself in the foot, but I have not heard very many people complain about it.

Most guns also have a shield in front of the trigger, and require a substantial force to actually trigger. The ease of shooting oneself in the foot is severely hampered by this, but again I do not see many complain about it.

Because most of us like to shoot first and ask questions later.

I think that "better safe than sorry" is a more sensible approach. One can in general not revive dead peop^Wdocuments.

On 06/16/12 16:23, peter sikking wrote:

Nicolas wrote:

Peter:
I think you misunderstood what gg is suggesting:

no I did not. I pointed out some facts that close many, many routes in this kind of reasoning. closed and done, yes.

I too thought you were misreading what I suggested.

let me first make a statement:

_every_ time (yes, that is around a hundred times now) that I see this kind of user feedback (that it is normal to open a non-GIMP file, do some edits, then save it to the same format) I start to think like interaction designers should:

lets assume he is right. make it just work.

encouraging

and every time I run into the same problems, that are giant usability bloopers.

- to really Save the contents of the file has to match what is on the screen (save, quit, restart, open file: no change--undo history excepted). this is not just a good idea, this is the law. breaking the law: usability blooper.

So now you are completely ignoring what I suggested and going off somewhere else.

I specifically said that saving the file should be separate from saving the entire working state of the image. Quite clearly this will not preserve layers alpha etc, your "top end" target users ought be able to cope with out with too much difficultly

Where did this save , restart, open : no change come from? Certainly not what I outlined..

On the contrary I was suggesting a clear demarcation between saving the edit state and saving back to the original format , with all that that implies. That that should be both clear and logical within the interface and that the user retains the choice of task in hand and not be forced into what someone else thinks they "should" be doing.

- this means that either all users would have to have intimate knowledge of file formats to know why the option to save to them disappear as edits are done (usability blooper. bit of alpha is introduced? no more jpeg; any layers? no more png; paths and layers? tiff is still there???) or one is doing the whole export thing anyway, so what is the difference (exporting is not safe, remember?) where are the extra hoops?

- the alternative would be to limit things:

Now you are deliberately constructing ridiculous scenarios that neither I nor anyone else suggested in order to knock them down. This generally known as a straw man argument.

- it is 100% impossible to arrange it for popular non-GIMP files (png/jpeg/tiff) there would be a mode where one could Open one, make edits within the limits of the file format, and write the bits straight back to a file in the same format.

a multi-personality application: complete usability disaster.

and that is where it stops.

I agree, functionality "modes" are definitely to be avoided. You will also note that I did not suggest any modal functionality to limit what can be done with gimp.

Another straw man.

Perhaps before dismissing my suggestion, you could actually comment on what I suggested rather than something else. It follows what Nicholas suggested recently and seems to make sense to a number of others.

An image manipulation program ought to have a simple way to handle std formats as someone said. I think this is what the gripes are about.

I have no preference as to actual name, whether it gets called "work" or "project" is immaterial , it is the function that is important.

/gg

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

On 06/16/12 19:58, Jon Nordby wrote:

One
can in general not revive dead peop^Wdocuments.

Which is why the don't give guns to children but top-end can be trusted to understand that jpeg is lossy and png does not store layers.

It seems the "target user" argument is often cited here but they still need to be prevented form doing something "unsafe".

do professional top end uses really need idiot proof software?

Given the functionality and a GUI that is not obstructive to the job in hand, I don't think many of the target audience will be shooting ourselves in the foot.

And if that happens I expect they would be suitably embarrassed and adult enough not to blame it on gimp.

/gg

On Sat, Jun 16, 2012 at 08:02:26PM +0200, gg wrote: [...]

I have no preference as to actual name, whether it gets called "work" or "project" is immaterial , it is the function that is important.

To add gasoline/petrol to fire: :-)

Thougth "work file" for xcf could be more precise than "project file" since in a "project" I think could be involved more than one file, instead (I think, correct me if I am wrong) that xcf will always be a one file "project".

so be "workfile"! :-)

Import->insert into GIMP xcf workfile Open->open GIMP xcf workfile (now also create a workfile without saving it and import the image in it immediatly) Export->extract info depending on format into the format chosen, eventually discarding some data/info Save->save GIMP workfile

I expect in a project file to save (more than in a workfile)

1) history 2) multiple work files

Peace ... :-)

bye

Omissis:

On Sat, Jun 16, 2012 at 08:55:47PM +0200, Marco Ciampa wrote:

1) history

^ undo

On Sat, Jun 16, 2012 at 12:33 PM, peter sikking wrote:

I think you are very selective there what conventions surround Import.

simply importing a an excel sheet into a non-ms program (open office, apple’s numbers) comes with a host of fears and promises.

And GIMP unnecessarily continues this tradition. If you open/import an indexed image, GIMP goes into this weird "Indexed" mode that makes editing all but impossible. This is very inconsistent with the asserted mental model.

And while I prefer having Export, one workflow is broken rather severely by this model: it is no longer possible to Import->Edit->Close->Export. The flow Import->Edit->Close-Save is available, but this is a fast flow that likely does not need to Save at all.

Chris

On Sat, Jun 16, 2012 at 10:16 PM, gg wrote:

It seems the "target user" argument is often cited here but they still need to be prevented form doing something "unsafe".

do professional top end uses really need idiot proof software?

Was it a deliberate attempt to spill some oil into the fire? Thank you for that. We are all extremely interested in another shout contest.

Given the functionality and a GUI that is not obstructive to the job in hand, I don't think many of the target audience will be shooting ourselves in the foot.

_Our_selves?

And if that happens I expect they would be suitably embarrassed and adult enough not to blame it on gimp.

Yes, I think _you_ would expect that.

Alexandre Prokoudine http://libregraphicsworld.org

On 06/16/12 21:54, Alexandre Prokoudine wrote:

It seems the "target user" argument is often cited here but they still need to be prevented form doing something "unsafe".

do professional top end uses really need idiot proof software?

Was it a deliberate attempt to spill some oil into the fire? Thank you for that. We are all extremely interested in another shout contest.

No, it was a deliberate attempt to point out that you (one) cannot constantly use the "top-end" target argument , then turn around and the GUI has to guide the user to know what is "safe" or not and must be prevented from saving work which has layers in anything but xcf because they won't realise that png , whatever, will loose the layers.

You (one) cannot use an argument when it suits you, then assume the opposite later.

No oil, just a simple statement of logic.

/gg

On 06/16/12 20:55, Marco Ciampa wrote:

On Sat, Jun 16, 2012 at 08:02:26PM +0200, gg wrote: [...]

I have no preference as to actual name, whether it gets called "work" or "project" is immaterial , it is the function that is important.

To add gasoline/petrol to fire::-)

Again , not oil, just common sense.

Arguing about the wording without accepting that the idea is good seems more than pointless.

/gg

Certainly the utility of an image manipulation program seems impaired if it can't open/edit/save an image without jumping through hoops.

I think we agree that the functionality is there, it has just shifted around in a manner that you dislike.

Yes, a manner that is non configurable, and takes away the keypresses people have been using for nearly two decades for no benefit to them. They don't realize it until repeatedly hitting a "I could save that file with this dialog, but I won't do that anymore." modal dialog that's akin to plastering a big 'PUSH' sign above a handle designed for pulling.

Yes the change was long planned. And I have only so much right to complain--- I'm a coder, I can rip this 'feature' out of my own copy (and post .debs/.prms for others) anytime I want. Hooray for source :-)

So please, take this as a well intentioned comment that simply tries to make the discontent clear. I very much dislike the change and many months on I still hit that 'HA HA! NO!' dialog regularly. The rationale behind the change has the best of intentions, but in the real world, it's merely dripping dogma onto my workflow.

Perhaps GNUClippy should pop up to say "I see you're stuck in your old habits..."

Anyway, no sense going around in circles, I've said my piece. Any further commentary will come through github (yeah... not actually likely).

Cheers,
Monty

On Sun, Jun 17, 2012 at 1:02 AM, gg wrote:

Was it a deliberate attempt to spill some oil into the fire? Thank you for that. We are all extremely interested in another shout contest.

No, it was a deliberate attempt to point out that you (one) cannot constantly use the "top-end" target argument , then turn around and the GUI has to guide the user to know what is "safe" or not and must be prevented from saving work which has layers in anything but xcf because they won't realise that png , whatever, will loose the layers.

You (one) cannot use an argument when it suits you, then assume the opposite later.

No oil, just a simple statement of logic.

Logic? Awesome joke, gg.

You are basically saying that professionals don't make mistakes, and if they do, it's all right, they don't fret. This is just silly.

First of all, everyone makes mistakes, professionals are not robots. But this is not the point.

The point is that saving means being able to have access to all the project/work data in the future. This has been stated millions of times, and the fact that you keep going on and on about this can only mean that you are trying to be a pain in the arse.

The current behavior is designed for people who work on multiple layers and, generally, make the most of GIMP features. Noone says you've got to love it. Feel free to hate it, just do it elsewhere.

Alexandre Prokoudine http://libregraphicsworld.org

On Sat, Jun 16, 2012 at 7:19 PM, peter sikking wrote:

something similar to that (without the pixels) has been applied as a patch for 2.8.1. (Bug 675399)

Could we please just have 2.8.1 released?

The amount of applied patches fully justifies that.

Alexandre Prokoudine http://libregraphicsworld.org

gg wrote:

So now you are completely ignoring what I suggested and going off somewhere else.

yes.

because it is not fruitful to have a line-by-line refuting match.

instead, I showed where the real meat of the argument is.

the match is played in a completely different ballpark than where you wanted to kick around a bit with this topic. sorry.

this is the best I could do to keep things constructive here.

--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

On 06/16/12 23:51, Alexandre Prokoudine wrote:

Logic? Awesome joke, gg.

What's the joke? You think it is fine to adopt contrary positions as it suits you and go "there I win". Perhaps there is a different idea of humour in your country.

You are basically saying that professionals don't make mistakes, and if they do, it's all right, they don't fret. This is just silly.

First of all, everyone makes mistakes, professionals are not robots. But this is not the point.

I never said "they don't fret" I said they are big enough to know what a png is and if they make a mistake they assume the responsibility.

The point is that saving means being able to have access to all the project/work data in the future. This has been stated millions of times,

No, if I open a png to edit it, save means save my png.

The current attempt to redefine that is what a lot of people are trying to discuss.

Stating outright the "save now mean use xcf" and there fore I am right is more of your personal logic.

and the fact that you keep going on and on about this can only mean that you are trying to be a pain in the arse.

No the fact that I "keep going on about it" means the software is becoming a PITA and I wish to help improve it.

I started this thread with a cogent , concrete suggestion about what was causing conflict in the GUI and suggested a possible approach to making it suit both extended and short term processing in a coherent way.

So far I have Peter intent on throwing up all sorts of issues that were not related to what I said and your illogical and now insulting behaviour.

That is a fairly good indication that neither of you have anything to say other than "I know best and that's as far as it goes".

Impressive guys.

On 06/17/12 00:32, peter sikking wrote:

yes.

because it is not fruitful to have a line-by-line refuting match.

I was not expect or seeking a refuting match, I made constructive suggestion.

I was naively expecting it to be considered and possibly discussed. Not refuted or ignored. Or attract insults.

instead, I showed where the real meat of the argument is.

the match is played in a completely different ballpark than where you wanted to kick around a bit with this topic. sorry.

this is the best I could do to keep things constructive here.

--ps

founder + principal interaction architect man + machine interface works

So you seem to be saying this is not the place to discuss the way gimp UI is being developed. Refuting matches are held elsewhere. Sorry, private party.

May as well shut down the list. then.

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

On Sun, 17 Jun 2012 01:51:30 +0400, Alexandre Prokoudine wrote:

On Sun, Jun 17, 2012 at 1:02 AM, gg wrote:

Was it a deliberate attempt to spill some oil into the fire? Thank you for that. We are all extremely interested in another shout contest.

No, it was a deliberate attempt to point out that you (one) cannot constantly use the "top-end" target argument , then turn around and the GUI has to guide the user to know what is "safe" or not and must be prevented from saving work which has layers in anything but xcf because they won't realise that png , whatever, will loose the layers.

You (one) cannot use an argument when it suits you, then assume the opposite later.

No oil, just a simple statement of logic.

Logic? Awesome joke, gg.

You are basically saying that professionals don't make mistakes, and if they do, it's all right, they don't fret. This is just silly.

First of all, everyone makes mistakes, professionals are not robots. But this is not the point.

The point is that saving means being able to have access to all the project/work data in the future. This has been stated millions of times, and the fact that you keep going on and on about this can only mean that you are trying to be a pain in the arse.

The current behavior is designed for people who work on multiple layers and, generally, make the most of GIMP features. Noone says you've got to love it. Feel free to hate it, just do it elsewhere.

It's designed for people who work on multiple layers and don't realize that saving in other formats destroys those layers.

In 2.6, if you try to save an image with multiple layers as a JPEG, the save dialog warns you that you need to collapse them. If you save a single layer image as a JPEG, no warning.

That seems like reasonable behavior. Forcing you to do something non-obvious in the case of doing a quick edit to a JPEG isn't.

On Sun, Jun 17, 2012 at 3:01 AM, gg wrote:

That is a fairly good indication that neither of you have anything to say other than "I know best and that's as far as it goes".

You know, I've thought of a few answers to your quite arrogant mail, and I don't think I have a solution. No matter what I say you always get wrong and interpret in some utterly pervert way. Best I can do is stop participating.

Good day to you.

Alexandre Prokoudine http://libregraphicsworld.org

On Sun, Jun 17, 2012 at 3:28 AM, Robert Krawitz wrote:

It's designed for people who work on multiple layers and don't realize that saving in other formats destroys those layers.

In 2.6, if you try to save an image with multiple layers as a JPEG, the save dialog warns you that you need to collapse them. If you save a single layer image as a JPEG, no warning.

That seems like reasonable behavior. Forcing you to do something non-obvious in the case of doing a quick edit to a JPEG isn't.

*sigh*

I did say that professionals have been consistently approving the change with few exceptions, didn't I? That is, the very same folks it was designed for.

What is the reason for having an argument then? Do you think that if you push hard enough, the team will say "Okay, we are reverting this so you could finally stop bitching and cut us a slack"?

This is not going to work. You see, the harder you push, the less people are inclined to continue the conversation. Maybe you could stop pushing while it's still possible to have a conversation?

Alexandre Prokoudine http://libregraphicsworld.org

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

Hi,
rlk@alum.mit.edu (2012-06-16 at 1928.37 -0400):

The current behavior is designed for people who work on multiple layers and, generally, make the most of GIMP features. Noone says you've got to love it. Feel free to hate it, just do it elsewhere.

It's designed for people who work on multiple layers and don't realize that saving in other formats destroys those layers.

In 2.6, if you try to save an image with multiple layers as a JPEG, the save dialog warns you that you need to collapse them. If you save a single layer image as a JPEG, no warning.

That seems like reasonable behavior. Forcing you to do something non-obvious in the case of doing a quick edit to a JPEG isn't.

2.6 allows the following two workflows when putting data into storage:

A. The simple thing: Save (ie, PNG).

B. The keep lots of your work data, even when working also with limited formats, way: Save (XCF) and in parallel Save a Copy (PNG).

At some point I thought that was the first steps to a better and automated system, some kind of multiple save (like B, but once set up, all the outputs would be updated automatically by a single save trigger). Instead with 2.8 we got manual export. :(

GSR

On Sun, Jun 17, 2012 at 6:04 AM, GSR - FR wrote:

B. The keep lots of your work data, even when working also with limited formats, way: Save (XCF) and in parallel Save a Copy (PNG).

At some point I thought that was the first steps to a better and automated system, some kind of multiple save (like B, but once set up, all the outputs would be updated automatically by a single save trigger). Instead with 2.8 we got manual export. :(

Now that is actually an interesting point :)

Alexandre Prokoudine http://libregraphicsworld.org

gg wrote:

I was naively expecting it to be considered and possibly discussed. Not refuted or ignored. Or attract insults.

ignored? what I did in return is spell out the basic facts and usability considerations that put hard boundary conditions on this design problem.

I expected you to be able to make the next step and adjust your brainstorming idea to these conditions.

instead, you wanted to argue these away. either because you dont get it or because it does not suit your argument.

So you seem to be saying this is not the place to discuss the way gimp UI is being developed.

it is, but it has to be with respect towards those who can, and do, the contributions. if you want to be heard, stop the continuous flow of vitriol, especially towards anything that has a design and/or architectural approach.

now, back to your mail of yesterday, the constructive one.

I am going to summarise it because you are doing some catching up in there that bloats the mail:

- you recognise that there is a competing situation between two different types of use
- you say there is a problem with File->Open importing non-GIMP images - you have realised that xcf files are great for persisting work and are acknowledging the Project reality of graphics work. - you want to relabel: File->Open to File->Import, File->Save to File->Save project
- you want a new File->Save to to work in the old way: write to GIMP file or export to non-GIMP file, depending on the type of file associated with what is in the main window - you want a new File->Open that explicitly says that this is a non-GIMP file workflow

here is my reaction to that:

in short you want the old situation back, with the clear and unambiguous working-on-a-GIMP-file workflows being secondary to the one-shot png-in, png-out (same for jpeg, tiff, etc) workflows. this is clear from how you label the menus.

I have two reasons to say: no way.

the first one is how GIMP works: it can only edit GIMP files. sure, this is a superset of the simple file formats that we all like to take as examples: jpeg/png/tiff. it is not for other ones (ps to start with, there must be more import/export supported formats that have things GIMP cannot do). the old fudge that we got rid of in 2.8 is GIMP communicating that it is editing a non-GIMP file, when it is not.

so you either import/export into GIMP format at the boundaries of the GIMP app and be clear about it. this is what we do now.

or you do your plan, build in non-GIMP-file-workflows, where for each non-GIMP file type, you have to build a mode for GIMP where what is on the screen matches what is in the file, right after invoking Save. remember, this is the law.

the second reason for saying no is checking the vision and what it means:

this makes me 100% sure that the Project/Work workflow with persisted GIMP files is number one for our target user groups. one-shot working is a distant second.

save + export has been designed for that, with added benefits of independently saving and exporting the same Work, and no more lost Work.

the success of this design is validated by the reaction of the target user groups, which get it instantly, although I also changed _their_ keyboard shortcuts and put unsaved changes dialogs in their way.

--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

On Sun, 17 Jun 2012 12:55:56 +0200, peter sikking wrote:

I am going to summarise it because you are doing some catching up in there that bloats the mail:

- you recognise that there is a competing situation between two different types of use

There are more than two different types of use.

- you say there is a problem with File->Open importing non-GIMP images - you have realised that xcf files are great for persisting work and are acknowledging the Project reality of graphics work.

Absolutely. But sometimes the "project" is very simple, such that I'm very confident I'm not going to need to revisit it (or that I'm just going to tweak the curves or otherwise do something that doesn't need layers -- when GIMP has 16 or 32 bit depth, that might be a different matter, and if I think I might want to revisit it later, I'll simply save it as an XCF file).

Certainly there are other tools around that are designed for simple things like that, but if I'm familiar with GIMP, it's easier to use the same tool for both.

here is my reaction to that:

in short you want the old situation back, with the clear and unambiguous working-on-a-GIMP-file workflows being secondary to the one-shot png-in, png-out (same for jpeg, tiff, etc) workflows. this is clear from how you label the menus.

I have two reasons to say: no way.

the first one is how GIMP works: it can only edit GIMP files. sure, this is a superset of the simple file formats that we all like to take as examples: jpeg/png/tiff. it is not for other ones (ps to start with, there must be more import/export supported formats that have things GIMP cannot do). the old fudge that we got rid of in 2.8 is GIMP communicating that it is editing a non-GIMP file, when it is not.

How GIMP operates *internally* and what it presents to the user don't have to be one and the same. Libre/OpenOffice use ODF as the native file format, but if I want to save it as a Word file, I simply Save As, or Save if what I originally opened was a Word file. Internally, though, I believe it's operating on (a representation of) an ODF file.

so you either import/export into GIMP format at the boundaries of the GIMP app and be clear about it. this is what we do now.

or you do your plan, build in non-GIMP-file-workflows, where for each non-GIMP file type, you have to build a mode for GIMP where what is on the screen matches what is in the file, right after invoking Save. remember, this is the law.

Why is that the "law"? If I'm saving as a JPEG, I know that there will be loss. But that's my lookout.

the second reason for saying no is checking the vision and what it means:

this makes me 100% sure that the Project/Work workflow with persisted GIMP files is number one for our target user groups. one-shot working is a distant second.

That's fine, but how does preventing "Save" to a JPEG file interfere with that? Your target audience knows that a JPEG file will lose information. What it does is require using a separate operation for exporting, which would seem to get in the way of "speed, speed, speed".

save + export has been designed for that, with added benefits of independently saving and exporting the same Work, and no more lost Work.

In 2.6, JPEG save already warns if the image has multiple layers.

the success of this design is validated by the reaction of the target user groups, which ‘get it’ instantly, although I also changed _their_ keyboard shortcuts and put ‘unsaved changes’ dialogs in their way.

I'm following the whole discussion and I'm more and more convinced that a default keyboard shortcut for overwrite would solve this. People is basically complaining because they lost a handy way to save lossy formats back after simple editing. Typical example: open a JPG file, adjust curves, save over. I agree 100% with the separation between save and export because it kind of forces me to work in a more organized way and helps me avoid mistakes that costed me a lot of time before. I understand that it takes some time to get used to that separation, but in my opinion is a minor compromise if we consider the benefits. That being said, I also find annoying that in a fresh install I have to go to the menu in order to overwrite files. As Peter already pointed out, assigning a shortcut for that is easy and permanent, but I wonder how bad it would be to assign one by default, so users get used to that combination for that specific procedure instead of customizing it. I think that it would have a couple of benefits: - The old lossy workflow would be back (it never went away, but now it takes a couple of extra clicks). After learling the new shortcut, I'm sure it will feel as natural as CTRL+S. - Consistency through different GIMP installs (if you have to use a friend's GIMP you don't have to worry about what shortcut s/he used for that command).

What about using CTRL+ALT+E for that? I guess that using something recognizable as an alternative to CTRL+E would make it easy to memorize since it's one of the exporting variants.

I understand the reasons behind not having a default shortcut, but I'm not sure if it really prevents a problem. I'd say that having a shortcut would be a reasonable compromise to help the introduction of the new save/export workflow in a less painful way for people used to lossy workflows.

Gez.

It also appears to me that a dedicated "export and close" shortcut pretty much kills this debate.

On 17 June 2012 15:24, Robert Krawitz wrote:

On Sun, 17 Jun 2012 12:55:56 +0200, peter sikking wrote:

I am going to summarise it because you are doing some catching up in there that bloats the mail:

- you recognise that there is a competing situation between two different types of use

There are more than two different types of use.

- you say there is a problem with File->Open importing non-GIMP images - you have realised that xcf files are great for persisting work and are acknowledging the Project reality of graphics work.

Absolutely.  But sometimes the "project" is very simple, such that I'm very confident I'm not going to need to revisit it (or that I'm just going to tweak the curves or otherwise do something that doesn't need layers -- when GIMP has 16 or 32 bit depth, that might be a different matter, and if I think I might want to revisit it later, I'll simply save it as an XCF file).

Certainly there are other tools around that are designed for simple things like that, but if I'm familiar with GIMP, it's easier to use the same tool for both.

here is my reaction to that:

in short you want the old situation back, with the clear and unambiguous working-on-a-GIMP-file workflows being secondary to the one-shot png-in, png-out (same for jpeg, tiff, etc) workflows. this is clear from how you label the menus.

I have two reasons to say: no way.

the first one is how GIMP works: it can only edit GIMP files. sure, this is a superset of the simple file formats that we all like to take as examples: jpeg/png/tiff. it is not for other ones (ps to start with, there must be more import/export supported formats that have things GIMP cannot do). the old fudge that we got rid of in 2.8 is GIMP communicating that it is editing a non-GIMP file, when it is not.

How GIMP operates *internally* and what it presents to the user don't have to be one and the same.  Libre/OpenOffice use ODF as the native file format, but if I want to save it as a Word file, I simply Save As, or Save if what I originally opened was a Word file.  Internally, though, I believe it's operating on (a representation of) an ODF file.

You are right that there does not need to be a direct match between the application internals and what is presented to the user. What is important is that the user interface does not give any expectations that the application cannot fulfill.

When LibreOffice allows you to save your work as a Word document, it is making the user expect that the work (not just a subset of it) is saved.
In the case of GIMP and "saving to" PNG/JPEG that is not an expectation it can fulfill.

so you either import/export into GIMP format at the boundaries of the GIMP app and be clear about it. this is what we do now.

or you do your plan, build in non-GIMP-file-workflows, where for each non-GIMP file type, you have to build a mode for GIMP where what is on the screen matches what is in the file, right after invoking Save. remember, this is the law.

Why is that the "law"?  If I'm saving as a JPEG, I know that there will be loss.  But that's my lookout.

the second reason for saying no is checking the vision and what it means:

this makes me 100% sure that the Project/Work workflow with persisted GIMP files is number one for our target user groups. one-shot working is a distant second.

That's fine, but how does preventing "Save" to a JPEG file interfere with that?  Your target audience knows that a JPEG file will lose information.

The target audience knows that JPEG will lose information. But if one is basing the interaction design on that foundation, the user will be required to not only know this, but to always keep this information in mind when interacting with the software.

Is this a burden we want to put on the user? Will he always make the right decision? Is it responsible software engineering to assume so?

What it does is require using a separate operation for exporting, which would seem to get in the way of "speed, speed, speed".

Triggering an "export" or "overwrite" action (once you have set up the key binding) is just as fast as a "save action".

Nicolas wrote:

It also appears to me that a dedicated "export and close" shortcut pretty much kills this debate.

you are on a roll with brainstorming, arent you?

taking that a bit further, that would be export + force close or overwrite and force close.

the combinations; the integration in the file menu; and the edge case-ness all give me stomach ache. interaction stomach ache.

but Force close,

that could be useful to a lot more people.

--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

On 17 June 2012 00:22, Alexandre Prokoudine wrote:

On Sat, Jun 16, 2012 at 7:19 PM, peter sikking wrote:

something similar to that (without the pixels) has been applied as a patch for 2.8.1. (Bug 675399)

Could we please just have 2.8.1 released?

The amount of applied patches fully justifies that.

I suspect if you want to say something to mitch, this is not the thread to do it in :).

În data de Sun, 17 Jun 2012 02:22:56 +0400, Alexandre Prokoudine a scris:

Could we please just have 2.8.1 released?

The amount of applied patches fully justifies that.

Is the script-fu translation fixed ? (intltool related, however I don't see significant positive feedback here https://bugs.launchpad.net/ubuntu-translations/+bug/986897)

I see there are still only 61 strings in the stable version http://l10n.gnome.org/POT/gimp.gimp-2-8/gimp-script-fu.gimp-2-8.pot

Cristi

Am 17.06.2012 23:29, schrieb peter sikking: > you are on a roll with brainstorming, arent you?

taking that a bit further, that would be export + force close or overwrite and force close.

the combinations; the integration in the file menu; and the edge case-ness all give me stomach ache. interaction stomach ache.

but Force close,

that could be useful to a lot more people.

possibly, even like http://gimp-brainstorm.blogspot.de/2010/01/behind-bars.html ?!?

A pop-up is certainly appropriate for preventing _accidental_ data loss via Close. But for Force Close, i see no justification to interrupt the train of thought by raising a pop-up.

best regards, yahvuu

PS: In retrospect, it does not seem very clever to propose adjacent keys for the Force Close hot key chording. Too easy to accidentally hit both of them in sequence.

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

On Tue, 2012-06-19 at 21:59 +0200, yahvuu wrote:

A pop-up is certainly appropriate for preventing _accidental_ data loss via Close. But for Force Close, i see no justification to interrupt the train of thought by raising a pop-up.

Years ago I used a mailer called elm, in which "x" was the eXpunge command for saving changes.

Then I moved to mutt, in which "x" meant "quit immediately without saving anything."

Similarly, I used Sun's "mailtool" open look UI mailer for a long time, in which shift-return moved you to the start of your message, e.g. so you could review it before sending... when I switched to gnome evolution, shift-return sends the message without prompting.

In a project-based workflow a "force quit" might leave a journal on disk that can be used to reconstitute changes. Otherwise, I want the dialogue, especially if it tells me the filename I last exported to as well as when I last saved.

A compromise might be to add a Force Quit menu item but not give it a keybinding by default.

Liam

Simon Budig wrote:

This discussion really boils down to a matter of taste and there are arguments for both ways. Unfortunately in your case you're taste weighs less than the taste of Peter to the developers.

If it was purely taste, I wouldn't bother commenting. It's a lack of logic though - just because there are situations where loss of information that the user values can occur, doesn't mean that every situation is like that.

Sorry, sometimes we can't make it right for everyone.

And that's my point - it could be made right for everyone.

Graeme Gill.

peter sikking wrote:

- this means that either all users would have to have intimate knowledge of file formats to know why the option to save to them disappear as edits are done (usability blooper. bit of alpha is introduced? no more jpeg; any layers? no more png; paths and layers? tiff is still there???) or one is doing the whole export thing anyway, so what is the difference (exporting is not safe, remember?) where are the extra hoops?

Or you get the computer to do the hard work, and indicate what of the current image state would get dropped if forced to saved to that format.

Graeme Gill.

On Wed, Jun 20, 2012 at 09:32:36AM +1000, Graeme Gill wrote:

peter sikking wrote:

- this means that either all users would have to have intimate knowledge of file formats to know why the option to save to them disappear as edits are done (usability blooper. bit of alpha is introduced? no more jpeg; any layers? no more png; paths and layers? tiff is still there???) or one is doing the whole export thing anyway, so what is the difference (exporting is not safe, remember?) where are the extra hoops?

Or you get the computer to do the hard work, and indicate what of the current image state would get dropped if forced to saved to that format.

Peter: am I wrong if I say that, with the newer versions of GIMP, due to the final integration with GEGL, saving png to png or jpg to jpg has even less sense, since GIMP inerently import into an internal rappresentation that is no more constituited by 8 bit planes like tiff/png/jpg images but 16 or even 32 bit float?

On Wed, Jun 20, 2012 at 3:46 AM, Marco Ciampa wrote:

Or you get the computer to do the hard work, and indicate what of the current image state would get dropped if forced to saved to that format.

Peter: am I wrong if I say that, with the newer versions of GIMP, due to the final integration with GEGL, saving png to png or jpg to jpg has even less sense, since GIMP inerently import into an internal rappresentation that is no more constituited by 8 bit planes like tiff/png/jpg images but 16 or even 32 bit float?

Yeah, GIMP should start telling people about lossy saving again, but this time it should add "And by the way, you are going to lose precision, idiot" :) 'Coz we are designing idiotproof software round here ;)

Alexandre Prokoudine
http://libregraphicsworld.org

On Wed, 2012-06-20 at 01:46 +0200, Marco Ciampa wrote:

[...] am I wrong if I say that, with the newer versions of GIMP, due to the final integration with GEGL, saving png to png or jpg to jpg has even less sense, since GIMP inerently import into an internal rappresentation that is no more constituited by 8 bit planes like tiff/png/jpg images but 16 or even 32 bit float?

TIFF can contain 32-bit float if it wants; 16-bit per channel PNG and JPG exist too.

The real change will be the non-destructive editing. But one thing at a time.

Date: Wed, 20 Jun 2012 09:22:43 +1000 From: graeme2@argyllcms.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Bring back normal handling of other file formats

Simon Budig wrote:

This discussion really boils down to a matter of taste and there are arguments for both ways. Unfortunately in your case you're taste weighs less than the taste of Peter to the developers.

If it was purely taste, I wouldn't bother commenting. It's a lack of logic though - just because there are situations where loss of information that the user values can occur, doesn't mean that every situation is like that.

Sorry, sometimes we can't make it right for everyone.

And that's my point - it could be made right for everyone.

Graeme Gill. _______________________________________________ gimp-developer-list mailing list

Agree wholeheartedly. There are parties on both sides of the debate, and we certainly know which side's opinions have (pun totally intended) more "volume".

The (as someone so pithily phrased it) "Ha ha ha - No way am I letting you do that" manner in which GIMP informs you of the Save/Export distinction can be anything from merely harmless to downright offensive, depending on your individual workflow (and peculiar temperament).

So if I may throw an echo into the room and ask why the particular message box CAN NOT provide a yes/no prompt, with "Yes" transferring control to the Export box and "No" cancelling back to the Save dialog?

- It could be maybe three lines of program code and one string resource, tops - It would NOT in any manner affect users who do a lot of XCF work and/or prefer the new save/export model in any manner. They're not likely to get the distinction mixed up. - It would accommodate users who have difficulty adjusting to the save/export distinction, reducing the number of extra clicks by up to three.

What is there that makes this not desirable?

As an analogue: If I typed a word like "hotmali" into Google, the search engine has no reason to assume that maybe I was trying to type "hotmail" instead and got my keys mixed up by mistake. But it does. Its keyword database knows that this could be a plausible misspelling of a much more popular search query, so it searches for the more popular term but also discloses that it did so (with an option to search for the keyword as originally spelled, in the case that actually was what I wanted).

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

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

Richard Gitschlag wrote:

So if I may throw an echo into the room and ask why the particular message box CAN NOT provide a yes/no prompt, with "Yes" transferring control to the Export box and "No" cancelling back to the Save dialog?

as I said before: no trip through Save if it is not safe.

it is simply not allowed to feel safe. seriously.

in the long run (and that is how I am thinking) going cold turkey on this, with no fudges, is in the best interest of users.

one of the biggest usability attributes of save + export is that the model is very clean: inside GIMP there is only xcf, which can be safely saved. everything else is import/export.

no gotchas.

no fudging.

--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

El 20/06/12 12:58, peter sikking escribi:

Richard Gitschlag wrote:

So if I may throw an echo into the room and ask why the particular message box CAN NOT provide a yes/no prompt, with "Yes" transferring control to the Export box and "No" cancelling back to the Save dialog?

as I said before: no trip through Save if it is not safe.

it is simply not allowed to feel safe. seriously.

in the long run (and that is how I am thinking) going cold turkey on this, with no fudges, is in the best interest of users.

one of the biggest usability attributes of save + export is that the model is very clean: inside GIMP there is only xcf, which can be safely saved. everything else is import/export.

no gotchas.

no fudging.

I understand your point and I do agree, it's in the best interest of users. The solution I proposed in my last message doesn't break this safer workflow, but allows users to say "I know the risks and I still want to do it this way" (it takes two extra actions: marking "don't ask me again" and choosing "save anyway").
After that, it's their responsability. If they want to go unsafe, it's their call. If something goes wrong the finger will point in only one direction.

Again, I don't think this is necessary, but some people seem to find it essential for their work, and since it doesn't break the proposed workflow and doesn't add extra dialogs or clutter, it's probably a reasonable compromise.

I think this is pretty much like the single-window discussion. When you started the specification it was the #1 user request, although a lot of people was happy with the good-old floating windows (myself included). You came up with a solution that doesn't break the floating windows UI and we have an extra mode which is also very handy. Having both and a checkbox was, in some way, a reasonable compromise. Well, there's no chance to destroy work with the window mode toggle, of course. I mean it was a compromise to conciliate the new workflow with the old workflow and don't leave people out of the picture (people who are also part of the target group).

Gez.

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

From: peter@mmiworks.net
Date: Wed, 20 Jun 2012 17:58:33 +0200 To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Bring back normal handling of other file formats

Richard Gitschlag wrote:

So if I may throw an echo into the room and ask why the particular message box CAN NOT provide a yes/no prompt, with "Yes" transferring control to the Export box and "No" cancelling back to the Save dialog?

as I said before: no trip through Save if it is not safe. it is simply not allowed to ‘feel’ safe. seriously.

in the long run (and that is how I am thinking) going cold turkey on this, with no fudges, is in the best interest of users.

no gotchas. no fudging.

Except for the cold-turkey part, I disagree.

But thanks for the answer, I must've missed it in all the discussion.

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

Now I remembered what I wanted to say earlier. I can't remember in response to whom exactly, but here goes.

"Save must record everything that is part of the document; that is the law."

That law also works in reverse.

If you write to a file format that cannot support everything in the open image (i.e. any format but XCF), this means the open image contains still-unsaved elements, and thus, the image as a whole is still dirty. In GIMP 2.6, the only situation in which you lost work by saving a file as a non-XCF is if you saved and quit without saving an XCF copy in the meantime. It is not the saving vs. export that resulted in loss of work, it was GIMP wiping the image state clean again regardless of whether or not everything in the open image was stored on disk.

Consider what happens in 2.6 if an image is first saved as XCF, some changes are made, then saved as a PNG. If you "Save A Copy..." as PNG, then: -> current image still associated with the XCF file, not the PNG -> current image still dirty.
-> GIMP asks to save changes to the associated (XCF) file

But if you "Save As..." PNG, then: -> current image becomes associated with the PNG file -> current image marked clean
-> GIMP does not ask to save changes -> Even if GIMP does, it saves changes to the PNG file, not the XCF

And it is easy to see how this can become a problem.

In 2.8, an image's clean/dirty state is decided only in respect to saving as an XCF. If you saved an XCF then quit, everything's good, no lost work, XCF contains everything (even the current selection!). If you export and quit, whether you're losing any work that couldn't be written to the desired file format is on your head alone, GIMP is not responsible for that, but GIMP asks anyway just to be on the safe side, because only by saving as an XCF can it be guaranteed that absolutely nothing in the current session will be lost if the image is closed.

So if we evaluate the (improbable) hypothesis where the Save and Export functionality is expressed using a single set of menu commands (as in 2.6), it should also hold true that (as in 2.8) only saving as an XCF will clean the image state. If you save to a non-XCF file and quit, the image is still dirty and GIMP must still ask whether to save changes. In XCF. Only XCF is guaranteed to save all data. But this creates a logical inconsistency where if the Save filepicker appears in the context of selecting it from the menu you can select any format (as in 2.6) but if it appears in the context of a close/quit prompt the only format available is XCF?

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

On Wed, Jun 20, 2012 at 11:58 AM, peter sikking wrote:

Richard Gitschlag wrote:

So if I may throw an echo into the room and ask why the particular message box CAN NOT provide a yes/no prompt, with "Yes" transferring control to the Export box and "No" cancelling back to the Save dialog?

as I said before: no trip through Save if it is not safe.

it is simply not allowed to feel safe. seriously.

If I open a PNG, adjust the curves, and serialize it to the filesystem as a PNG, and then open that in GIMP, there isn't anything meaningfully different between that and if I serialized it to XCF and opened it. So I have a hard time calling one safe and the other not. In both cases, I get all of the adjusted image data. In neither case do I get the curve that I used to adjust the image back, or the old image data back.

I really don't care one way or another about whether GIMP goes the "everything is save" route or the "export if it's not native" route. I've used plenty of software that goes each way. But let me throw in a few points of data.

My wife is the kind of person that would be in GIMP's official target audience. She's asked me three times how to save something as PNG since I installed 2.8. While my living room is hardly a usability lab, I've been behind the one-way glass in one enough to say there is probably a discoverability issue there.

Furthermore, even after I showed her how to export as PNG and she asked why they changed, I tried explaining the rationale and that other programs did it, and she still seemed unimpressed. She is quite aware of the differences between different file formats, and I get the impression that she finds the distinction between serializing as XCF and other formats to not warrant different treatment. On the other hand, she tends to use several applications in a workflow, and when your workflow isn't GIMP-centric, the XCF doesn't really contain much of the state of the workflow anyway.

Rockwalrus

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

Am 20.06.2012 00:31, schrieb Liam R E Quin:

On Tue, 2012-06-19 at 21:59 +0200, yahvuu wrote:

A pop-up is certainly appropriate for preventing _accidental_ data loss via Close. But for Force Close, i see no justification to interrupt the train of thought by raising a pop-up.

Years ago I used a mailer called elm, in which "x" was the eXpunge command for saving changes.

Then I moved to mutt, in which "x" meant "quit immediately without saving anything."

the idea is actually to shortcut Force Close by a longer key sequence which is very unlikely to be hit accidentally or by old habits.

For example, Alt-F2 Alt-F4 to Force Close a window as suggested in the brainstorm item. Or something like CTRL-F2 CTRL-F4 to Force Close a tab/image in GIMP.

To contrast with Close: An image with unsaved changes can be closed via CTRL-W (Close) and
ALT-W (Confirm)

The difference to Force Close is that the latter works unconditionally, also for images whithout unsaved changes. This saves you from thinking about the saved/unsaved state -- in case you are absolutely sure that the data can be discarded.

best regards, yahvuu

On Sun, 2012-06-24 at 23:51 +0200, yahvuu wrote:

the idea is actually to shortcut Force Close by a longer key sequence which is very unlikely to be hit accidentally or by old habits.

For example, Alt-F2 Alt-F4 to Force Close a window as suggested in the brainstorm item.

Which in fact my cat can press when she curls up on the keyboard, one paw on Alt and another on f2 and f3 more or less at the same time.

I hope this mis-feature can be disabled, if we get it.

To be fair, although a previous cat sometimes shut the computer down (power-off button on th keyboard, tab, then space or enter) I've never had one do control-alt-backspace.

But one hour of lost work is worth 72,000 saved half-seconds, so I'd rather get the dialogue.

Thanks for replying.

Liam