El 16/11/12 11:45, Alberto Mardegan escribi:

Hi all!
I'm not here to reignite the discussion about the new save/export behaviour, don't worry. :-)
However, as many other users, I find the new behaviour not helping my workflow, so I'd like to do something about it.

I think that the "Save" command should just save the current file in whatever format the file originally had; so, if I open a PNG and crop it, then close the window and get prompted to save it, I should have the option to save it as PNG (and it should be the default choice for this image). I understand that you don't agree with this principle.

IMHO the older way was extremely faster than new way.

I must to do very much clics with 2.8 than 2.6 to close files. I think a configuration option will be a nice solution.

;)

So, given the inconcialiability of the opinions in the same UI, I propose to have an option in the preferences dialog to go back to the old behaviour (with the 2.8 behaviour as default). I'm willing to provide a patch myself, of course.

My question now is whether such a patch (provided that the code quality matches your requirements) would be accepted -- in which case I would go and file a bug for it, and assign it to myself --, or if I should not even give it a try.

I really hope that this effort will be welcome. :-)

Ciao, Alberto

On Fri, Nov 16, 2012 at 2:45 PM, Alberto Mardegan wrote:

I'm not here to reignite the discussion about the new save/export behaviour, don't worry. :-)

and

So, given the inconcialiability of the opinions in the same UI, I propose to have an option in the preferences dialog to go back to the old behaviour (with the 2.8 behaviour as default).

are mutually exclusive statements :)

We have discussed it in the future and decided against it.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 2:54 PM, Alexandre Prokoudine wrote:

We have discussed it in the future and decided against it.

Sorry, as a newbie to time traveling I easily get confused.

Alexandre Prokoudine http://libregraphicsworld.org

On 16 November 2012 11:54, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Fri, Nov 16, 2012 at 2:45 PM, Alberto Mardegan wrote:

I'm not here to reignite the discussion about the new save/export behaviour, don't worry. :-)

and

So, given the inconcialiability of the opinions in the same UI, I propose to have an option in the preferences dialog to go back to the old behaviour (with the 2.8 behaviour as default).

are mutually exclusive statements :)

We have discussed it in the future and decided against it.

With that being said, it is already easy to (mostly*) revert to the old-style behaviour:
http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes

* It will still prompt you about unsaved document but exported) as you close the image.

Jon Nordby - www.jonnor.com

Alberto Mardegan (mardy@users.sourceforge.net) wrote:

On 11/16/2012 12:54 PM, Alexandre Prokoudine wrote:

On Fri, Nov 16, 2012 at 2:45 PM, Alberto Mardegan wrote:

I'm not here to reignite the discussion about the new save/export behaviour, don't worry. :-)

and

So, given the inconcialiability of the opinions in the same UI, I propose to have an option in the preferences dialog to go back to the old behaviour (with the 2.8 behaviour as default).

are mutually exclusive statements :)

No, they aren't: I'm not proposing to remove or change the current behaviour. I'm proposing to add a configuration option (I don't care how hard it is to find) to re-enable the old behaviour.

We discussed adding a configuration option and decided against it, for reasons discussed in earlier threads about this.

So, it's an addition that doesn't collide with the UI decisions already taken.

It does.

Sorry for being terse, but we've been there...

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Fri, Nov 16, 2012 at 01:54:10PM +0200, Alberto Mardegan wrote:

No, they aren't: I'm not proposing to remove or change the current behaviour. I'm proposing to add a configuration option (I don't care how hard it is to find) to re-enable the old behaviour.

I also find the change frustrating for my workflow. I don't mind learning the export-instead-of-save command, but it's bad UI to always confirm on exit even after a file is saved -- and, for many actual real world user workflows, exported *is* saved for every practical purpose.

I understand that having a lot of options in a user interface is generally frowned upon, but this isn't a UI choice -- it's a workflow choice. This is explained in more detail at https://bugzilla.gnome.org/show_bug.cgi?id=687783

I really hope we can solve this upstream; otherwise I'll have to create a variant of GIMP and publish it into an Ubuntu PPA, which will be rather sad because it will be a feature accessible only by those using Ubuntu (I certainly don't have the energy to create a proper fork and maintain it).

It seems likely to be popular, and I think since the core developers here are pretty much set against the idea, it's probably more constructive than arguing.

Matthew Miller           mattdm@mattdm.org          

Matthew Miller (mattdm@mattdm.org) wrote:

I also find the change frustrating for my workflow. I don't mind learning the export-instead-of-save command, but it's bad UI to always confirm on exit even after a file is saved -- and, for many actual real world user workflows, exported *is* saved for every practical purpose.

Well, there also are many actual real world user workflows, where the export == save has resulted in loss of artwork. In its most trivial form it is "help, I can no longer edit the text in my jpeg".

We have decided to focus on loss-prevention. We have discussed and explained this ad nauseam.

So unless you come up with a real usability study within our target user group that shows that they can't handle this change we won't change this.

Bye,
Simon

simon@budig.de              http://simon.budig.de/

On Fri, Nov 16, 2012 at 02:11:45PM +0100, Simon Budig wrote:

I also find the change frustrating for my workflow. I don't mind learning the export-instead-of-save command, but it's bad UI to always confirm on exit even after a file is saved -- and, for many actual real world user workflows, exported *is* saved for every practical purpose.

Well, there also are many actual real world user workflows, where the export == save has resulted in loss of artwork. In its most trivial form it is "help, I can no longer edit the text in my jpeg".

Right, and that's fine. Put the option in "safe" by default. But right now, you're punishing everyone else. Forcing that workflow choice on everyone doesn't lead to a good user experience.

So unless you come up with a real usability study within our target user group that shows that they can't handle this change we won't change this.

Can users "handle" the change? Sure. But it's still a worse user experience.

I find it... almost shocking that you totally discount the fact that many users have been interested enough to go to the trouble of contacting you and asking for this fix to the regression as evidence that there's a need.

Maybe the problem is that your target user group is too small. This is the only viable photo editor on Linux (other software exists, but is either primative, aimed at painting/design, or just raw conversion), and while it's fine that you don't care, because you're under no obligation, it's painful for many actual users of your software.

I think the idea of a lightweight fork is a good one. It's the cheap, easy way to demonstrate user demand.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 5:35 PM, Matthew Miller wrote:

Right, and that's fine. Put the option in "safe" by default. But right now, you're punishing everyone else. Forcing that workflow choice on everyone doesn't lead to a good user experience.

"Forcing" would imply malice.

I find it... almost shocking that you totally discount the fact

We don't.

and while it's fine that you don't care

We never said that.

I think the idea of a lightweight fork is a good one.

What do you mean, idea? There is at least one existing fork called "noxcf-gimp".

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 5:47 PM, Alberto Mardegan wrote:

images in XCF files. Whether this category is big or small, I don't know for sure, but it's pretty reasonable to think that it's large enough to deserve a configuration option.

Where would you stop with configuration options, when masses dictate their wishes?

Can you please point me to the previous discussions where the idea of adding a configuration option for the non-XCF users was dismissed?

It's all over the mailing list. Get blindfolded, point your finger in an arbitrary direction, and you won't miss :)

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 05:48:45PM +0400, Alexandre Prokoudine wrote:

Right, and that's fine. Put the option in "safe" by default. But right now, you're punishing everyone else. Forcing that workflow choice on everyone doesn't lead to a good user experience.

"Forcing" would imply malice.

No, it simply means that you leave users with no other option.

I admire the willingness to make improvements even if doing so requires changes to the way things have been done before. But it'd also be nice if broader workflows could be taken into account. Here's mine:

1. Convert from RAW in other software. Save my originals there. 2. Select a dozen or so image for touchup work. Make jpg copies. (Occasionally, TIFF.)
3. Open all of those copies in gimp, make my adjustments (generally 5-15 minutes of work each), and close each as I'm done.

The prompt to "export" really throws a wrench in it. The recent addition of a note for when an image _has_ been exported is a big step forward, because now I can at least read the fine print, but early implementations left me keeping track by myself which images are completed.

If there were an option to not prompt when closing an exported image, I could (as before) be comfortable in knowing that any image that closes without prompting is safe, and that if I'm not done yet, I'll get a warning.

What do you mean, idea? There is at least one existing fork called "noxcf-gimp".

Well, cool. It's a good idea.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 05:53:22PM +0400, Alexandre Prokoudine wrote:

images in XCF files. Whether this category is big or small, I don't know for sure, but it's pretty reasonable to think that it's large enough to deserve a configuration option.

Where would you stop with configuration options, when masses dictate their wishes?

With some sensible discretion. Here, it's not just a "paint it pink please! no, it must be purple!" discussion. There's two valid use cases -- people who work in very different ways. It'd be easy to support both.

It's also worth noting that options to disable save confirmation in certain cases are a longstanding UI tradition. It's more surprising to see the lack of an option than to see one.

adding a configuration option for the non-XCF users was dismissed?

It's all over the mailing list. Get blindfolded, point your finger in an arbitrary direction, and you won't miss :)

Again: evidence that people care.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 6:03 PM, Matthew Miller wrote:

With some sensible discretion. Here, it's not just a "paint it pink please! no, it must be purple!" discussion. There's two valid use cases -- people who work in very different ways. It'd be easy to support both.

Would it?

adding a configuration option for the non-XCF users was dismissed?

It's all over the mailing list. Get blindfolded, point your finger in an arbitrary direction, and you won't miss :)

Again: evidence that people care.

And it means exactly what? :)

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 06:09:00PM +0400, Alexandre Prokoudine wrote:

With some sensible discretion. Here, it's not just a "paint it pink please! no, it must be purple!" discussion. There's two valid use cases -- people who work in very different ways. It'd be easy to support both.

Would it?

Uh. Yes.

adding a configuration option for the non-XCF users was dismissed?

It's all over the mailing list. Get blindfolded, point your finger in an arbitrary direction, and you won't miss :)

Again: evidence that people care.

And it means exactly what? :)

Simon asked for a usability study. This is no formal study, but there's plenty of direct feedback from actual users.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 6:00 PM, Matthew Miller wrote:

changes to the way things have been done before. But it'd also be nice if broader workflows could be taken into account. Here's mine:

1. Convert from RAW in other software. Save my originals there. 2. Select a dozen or so image for touchup work. Make jpg copies. (Occasionally, TIFF.)
3. Open all of those copies in gimp, make my adjustments (generally 5-15 minutes of work each), and close each as I'm done.

So you are dumping your changes after editing and can't adjust them later. It is precisely the kind of workflow we call unsafe. We provided a secondary workflow to deal with that to a certain extent. Beyond that it's in the hands of community if they want the old scenario back and maintain some sort of a fork.

Alexandre Prokoudine http://libregraphicsworld.org

Maybe it could be solved with a nice system I think could be fine:

Adding a simple configuration option: "Do not ask me about saving when close files that has not been saved XCF format"

In spanish: No preguntarme si deseo guardar al cerrar imgenes que no he guardado antes en formato XCF.

This solve all our problems:

- The GUI and the default workflow is mantained. - People like me, who still very tired to clic "cancel" button for any single image I have no intention to save on XCF format could mark this new option and never suffer anymore.

Really guys, I work with Gimp 8 hours at day, I create tons of web pictures every day, and the 99% of times, I not need at all saving on XCF but I must clic "Cancel" button again and again...

I understand the GUI and WorkFlow reasons and I'm not against it, but please, understand we, it is not very productive idea remind me one time and another about saving something I really want not to save. ;)

Cheers! jEsuSdA 8)

On Fri, Nov 16, 2012 at 4:11 PM, Matthew Miller wrote:

Simon asked for a usability study. This is no formal study, but there's plenty of direct feedback from actual users.

And there is also plenty of people that have showed up with "saved" files they want to change but cant, because they have them in jpg... And lots of people for whom the current Save/Export paradigm makes perfect sence. They just have no reason to come here and complain...

--Alexia

On Fri, Nov 16, 2012 at 6:11 PM, Matthew Miller wrote:

With some sensible discretion. Here, it's not just a "paint it pink please! no, it must be purple!" discussion. There's two valid use cases -- people who work in very different ways. It'd be easy to support both.

Would it?

Uh. Yes.

And this statement is based on what experience exactly? :)

adding a configuration option for the non-XCF users was dismissed?

It's all over the mailing list. Get blindfolded, point your finger in an arbitrary direction, and you won't miss :)

Again: evidence that people care.

And it means exactly what? :)

Simon asked for a usability study. This is no formal study

Precisely.

Direct feedback is OK to get an idea of what people do and what they think they want to do. Note the "what they think the want" part. This is exactly why usability studies matter.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 06:13:04PM +0400, Alexandre Prokoudine wrote:

1. Convert from RAW in other software. Save my originals there. 2. Select a dozen or so image for touchup work. Make jpg copies. (Occasionally, TIFF.)
3. Open all of those copies in gimp, make my adjustments (generally 5-15 minutes of work each), and close each as I'm done.

So you are dumping your changes after editing and can't adjust them later. It is precisely the kind of workflow we call unsafe. We

Right. It's like clearing my undo history. I understand that. However, in the case where I decide I want to do something different, it's easy for me to start from the original again. Since the one thing (close images after working on them) I do *all the time*, and the other is very rare, I want to optimize for my daily use. I'm clearly not alone in this.

provided a secondary workflow to deal with that to a certain extent.

How do I enable that secondary workflow?

Matthew Miller           mattdm@mattdm.org          

Oh, let me throw up this idea for you - you do not need a fork, just a script to override the default close... Very easy to install, maintain and distribute. No fork needed.

On Fri, 16 Nov 2012 18:13:04 +0400, Alexandre Prokoudine wrote:

On Fri, Nov 16, 2012 at 6:00 PM, Matthew Miller wrote:

changes to the way things have been done before. But it'd also be nice if broader workflows could be taken into account. Here's mine:

1. Convert from RAW in other software. Save my originals there. 2. Select a dozen or so image for touchup work. Make jpg copies. (Occasionally, TIFF.)
3. Open all of those copies in gimp, make my adjustments (generally 5-15 minutes of work each), and close each as I'm done.

So you are dumping your changes after editing and can't adjust them later. It is precisely the kind of workflow we call unsafe. We provided a secondary workflow to deal with that to a certain extent. Beyond that it's in the hands of community if they want the old scenario back and maintain some sort of a fork.

Yes, and if I'm doing something quick and dirty, I'll take my chances on it. I know it's unsafe, and I don't care in that situation. There are plenty of cases where I *do* care, and I use .xcf format, but lots where I don't.

It's also not always correct to say that they can't be adjusted later. They can in a lot of cases, with some loss of quality.

I suspect it would solve 90% of the problems for people if you're always allowed to save back to the file format that the image was originally opened in (or even just to save, rather than save as). So if I open a JPEG file, ctrl-s should simply save (or internally export, if you will, and clear the modified flag).

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Fri, Nov 16, 2012 at 06:16:01PM +0400, Alexandre Prokoudine wrote:

Uh. Yes.

And this statement is based on what experience exactly? :)

I've been involved in free software and maintaining software projects for many years, so I know that adding code to handle options adds maintenance. But, Gimp has had a similar but less useful option (prompt or never prompt at all) for basically all time. This would be a relatively small change with a big positive impact.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 04:20:13PM +0200, Alexia Death wrote:

Oh, let me throw up this idea for you - you do not need a fork, just a script to override the default close... Very easy to install, maintain and distribute. No fork needed.

Okay, awesome. I had no idea that was possible. Can you give me an idea of what that would look like? Specifically, the confirmation dialog should not be shown if the file has been either saved or exported since last change, but should in other cases.

I think the case is common enough that an option would be more sensible, but if there's a workaround it at least solves my *own* frustration.

Matthew Miller           mattdm@mattdm.org          

Alberto Mardegan (mardy@users.sourceforge.net) wrote:

Can you please point me to the previous discussions where the idea of adding a configuration option for the non-XCF users was dismissed?

Here is a mail where I explained why having a config option is bad:

https://mail.gnome.org/archives/gimp-user-list/2012-September/msg00109.html

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Fri, Nov 16, 2012 at 6:19 PM, Matthew Miller wrote:

provided a secondary workflow to deal with that to a certain extent.

How do I enable that secondary workflow?

Exporting/Overwriting + configurable shortcuts.

http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes

And there is Akkana's script:

http://shallowsky.com/blog/gimp/gimp-save-export-clean.html

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 03:31:05PM +0100, Simon Budig wrote:

Can you please point me to the previous discussions where the idea of adding a configuration option for the non-XCF users was dismissed?

Here is a mail where I explained why having a config option is bad:

That explains why config options have a cost, not why they are bad. I think that's well understood. All features have costs.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 6:37 PM, Matthew Miller wrote:

That explains why config options have a cost, not why they are bad. I think that's well understood. All features have costs.

But you want _us_ to pay that cost :)

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 06:37:38PM +0400, Alexandre Prokoudine wrote:

Exporting/Overwriting + configurable shortcuts. http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes

Right, that I'm familiar with.

And there is Akkana's script:
http://shallowsky.com/blog/gimp/gimp-save-export-clean.html

And that I wasn't. Nice. It is worth pointing out that Akkana articulates the two use cases nicely on that page:

Sometimes I use GIMP in the way the developers are encouraging, adding dozens of layers, fonts, layer masks and other effects. Much more often, I use GIMP to crop and rescale a handful of JPG photos I took with my camera on a hike.

I realize that this is a polarized issue. But I don't think the developers would lose any face to admit that, okay, this other use case is common and should be covered.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 06:40:54PM +0400, Alexandre Prokoudine wrote:

That explains why config options have a cost, not why they are bad. I think that's well understood. All features have costs.

But you want _us_ to pay that cost :)

I guess. That's why I'm asking nicely. :)

Some options have high cost and only benefit an obscure case. In *this* case, the cost is relatively small (one option which is a refinement of an option that's always been there) and the *reward for the project* is high.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 4:42 PM, Matthew Miller wrote:

Sometimes I use GIMP in the way the developers are encouraging, adding dozens of layers, fonts, layer masks and other effects. Much more often, I use GIMP to crop and rescale a handful of JPG photos I took with my camera on a hike.

I realize that this is a polarized issue. But I don't think the developers would lose any face to admit that, okay, this other use case is common and should be covered.

the second usecase is not a usecase for GIMP. Even I do not use GIMP in this maner. I use Digikam's builtin minieditor for this. Or phatch for batch work... You can use gimp for this, but do not expect it to be convenient. you are just using the wrong tool.

On Fri, Nov 16, 2012 at 6:45 PM, Matthew Miller wrote:

Some options have high cost and only benefit an obscure case. In *this* case, the cost is relatively small (one option which is a refinement of an option that's always been there) and the *reward for the project* is high.

The problem here is that you are thinking in terms of "one little switch can't do no harm". You are not considering all the planned work to make GIMP a truly non-destructive editor, all the corner cases like native CMYK support etc.

This has been discussed a dozen of times. One of these days I'll really finish the new FAQ so that we could prevent yet another "I'm not here to reignite the discussion about the new save/export behaviour, don't worry. :-)" thread.

Alexandre Prokoudine http://libregraphicsworld.org

On 11/16/2012 04:11 PM, Matthew Miller wrote:

On Fri, Nov 16, 2012 at 06:09:00PM +0400, Alexandre Prokoudine wrote:

With some sensible discretion. Here, it's not just a "paint it pink please! no, it must be purple!" discussion. There's two valid use cases -- people who work in very different ways. It'd be easy to support both.

Would it?

Uh. Yes.

AFAIK it is not easy to change the UI, at least at this moment. It is hardcoded in C, and there are plans for a new UI (something clutter based, or something else).

So maybe when that will be done it will be a good idea to have options like that.

On Fri, Nov 16, 2012 at 4:45 PM, Matthew Miller wrote:

Some options have high cost and only benefit an obscure case. In *this* case, the cost is relatively small (one option which is a refinement of an option that's always been there) and the *reward for the project* is high.

The issue is conceptual. You do not need to fire up the giant machine that is gimp to this little thing... GIMP is not a tool for this usecase. It is capable of doing it, but it will not be perfectly convenient. You can use a scalpel to cut bread. It will do the job, but it would be done better and faster with a bread knife. However you would not want this person cutting into your body with a breadknife, simply because it's unsafe. You try to make GIMP into a breadknife so you can more comfortably cut bread where as its intended purpose is to be a scalpel, a tool for thins where unsafe operations are a no-go....

--Alexia

On Fri, Nov 16, 2012 at 06:50:33PM +0400, Alexandre Prokoudine wrote:

The problem here is that you are thinking in terms of "one little switch can't do no harm". You are not considering all the planned work to make GIMP a truly non-destructive editor, all the corner cases like native CMYK support etc.

That's not a fair thing to say. This isn't a _generic_ "one little switch". It's a specific switch to not prompt on close of files which have been exported. Clearly, many workflows will do better with the xcf-centric approach.

A more sophisticated option might be: do not prompt on close when an image is exported to the same file it was imported from.

This is very narrow, and it in fact the future planned work *should* take it into account.

Matthew Miller           mattdm@mattdm.org          

If such an "option" ever sees the light of day, I think the button should show a poison symbol (skull and crossbones).

Or should it be a swastika?

:)

-----

The GIMP developers have a well developed vision.

By now, the only reasonable assumption is that every single one of them is fully aware that a number of committed users do not like their chosen workflow model. At the very least, you should assume that complaining about it on the gimp-developer forum will get you nowhere.

They know. They have made a thoughtful decision. And they won't change their mind without something bigger than "individual opinions".

Without their vision, they would not progress. Putting their vision into software, I imagine, is what drives them.

So, please, don't get in the way.

On Fri, 16 Nov 2012 16:56:09 +0200, Alexia Death wrote:

On Fri, Nov 16, 2012 at 4:45 PM, Matthew Miller wrote:

Some options have high cost and only benefit an obscure case. In *this* case, the cost is relatively small (one option which is a refinement of an option that's always been there) and the *reward for the project* is high.

The issue is conceptual. You do not need to fire up the giant machine that is gimp to this little thing... GIMP is not a tool for this usecase. It is capable of doing it, but it will not be perfectly convenient. You can use a scalpel to cut bread. It will do the job, but it would be done better and faster with a bread knife. However you would not want this person cutting into your body with a breadknife, simply because it's unsafe. You try to make GIMP into a breadknife so you can more comfortably cut bread where as its intended purpose is to be a scalpel, a tool for thins where unsafe operations are a no-go....

This is analogous to saying "don't use emacs just to do a quick edit; use vi for that". Different tools have different interfaces, and I don't want to learn two different interfaces to edit images just because I want to "quick and dirty".

I don't want to have to adjust curves, or unsharp mask, or anything else one way for quick and dirty editing and a different way for something else. It's the same operation.

I don't think Matthew wants to make GIMP into something other than what it is. But I don't think that an option to allow saving to a non-XCF file is fundamentally changing GIMP, either.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Fri, Nov 16, 2012 at 7:03 PM, Robert Krawitz wrote:

it is. But I don't think that an option to allow saving to a non-XCF file is fundamentally changing GIMP, either.

Robert, it's been stated so many times why it _is_ a fundamental thing :)

XCF is always the internal state of the document. Images get imported into an internal XCF, not opened and manipulated directly.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 5:03 PM, Robert Krawitz wrote:

This is analogous to saying "don't use emacs just to do a quick edit; use vi for that". Different tools have different interfaces, and I don't want to learn two different interfaces to edit images just because I want to "quick and dirty".

I take beef with this comparsion. its more like comparing GIMP and PS. fair compare would be nano vs emacs. And if its available, I use nano to edit a single line in a small conf file. If I want syntax higlight and all the fancyness of emacs, I fire it up. And I do not complayn that I have to press a few more keys to save and exit than in nano if I do.

--Alexia

On Fri, Nov 16, 2012 at 05:07:41PM +0200, Alexia Death wrote:

This is analogous to saying "don't use emacs just to do a quick edit; use vi for that". Different tools have different interfaces, and I don't want to learn two different interfaces to edit images just because I want to "quick and dirty".

I take beef with this comparsion. its more like comparing GIMP and PS. fair compare would be nano vs emacs. And if its available, I use nano to edit a single line in a small conf file. If I want syntax higlight and all the fancyness of emacs, I fire it up. And I do not complayn that I have to press a few more keys to save and exit than in nano if I do.

To run with this analogy: the problem is when you *frequently* need something that is more than nano provides. In the specific case of Gimp, I don't think there's anything else that offers layers, curves, and a healing brush. I use those things all the time in quick JPEG editing. (The layers only temporarily, of course -- I'll be looking forward to adjustment layers when that work is done.)

If we had a whole toolbox of photo editing tools at our disposal in Linux, I'd be less sad.

Matthew Miller           mattdm@mattdm.org          

On Fri, Nov 16, 2012 at 5:14 PM, Matthew Miller wrote:

To run with this analogy: the problem is when you *frequently* need something that is more than nano provides. In the specific case of Gimp, I don't think there's anything else that offers layers, curves, and a healing brush. I use those things all the time in quick JPEG editing. (The layers only temporarily, of course -- I'll be looking forward to adjustment layers when that work is done.)

If we had a whole toolbox of photo editing tools at our disposal in Linux, I'd be less sad.

There is quite a lot. Darktable and Digikam integrated editor both offer most of this(I thin latest digikam even had some healing) and are the breadknives of this workflow. Both can directly load RAW too, afaik....

--Alexia

On 16/11/12 15:46, Alexia Death wrote:

the second usecase is not a usecase for GIMP.[....] You can use gimp for this, but do not expect it to be convenient. you are just using the wrong tool.

To me it seems you have lost any perspective whatsoever why people would want to use GIMP - they do so because they know their way around the tool, if it doesn't declare war on their workflow - which you are doing by declaring it the "wrong tool" for small tasks. What makes you the judge, jury and executioner in this case of "developer opinion" against "user workflow"?
What if I want to add a layer with my watermark to every photo? That's something most other programs can't handle properly - these photos only exist for one purpose - to save them as JPEG to be uploaded into a web presentation. Will I ever need these as XCF? Heck no, the original is sufficient for me and the XCF is trivial but takes up too much space on the disk (I have the added layer stored once as well as the original photo, that's often enough).
If I am editing an image to my liking I usually need several sizes and sometimes even aspect crops. Since sharpening is the last step in almost all of my workflows I end up creating a master (saved as XCF) which I don't want to mess up further. That master I open and scale and sharpen as I like, save the result (err. export the result) and toss it to start again - now it prompts me to create yet another XCF which I will never ever need, I have a master copy - which I may in fact lose if I happen to hit the save short cut because being in a hurry! I could go on to describe additional uses where people that use GIMP even for small mundane tasks which never ever will prompt the requirement of using an XCF - people whose long loyalty to the GIMP you are now testing to the limit by declaring war on their specific and very valid use case.
For me this only means: I'm a book author for photography books and in these I usually add some sort of recommendations on which tools on the computer side would be worthwhile having around, my coauthor has up to now recommended Adobe programs and I was sort of inclined to include free alternatives like the GIMP. With GIMP 2.8 I have decided against doing that because I cannot support your narrowed view which workflow is worthwhile and which isn't...
--
regards
Karl Gnter Wnsch

On Fri, Nov 16, 2012 at 5:22 PM, Karl Gnter Wnsch wrote:

For me this only means: I'm a book author for photography books and in these I usually add some sort of recommendations on which tools on the computer side would be worthwhile having around, my coauthor has up to now recommended Adobe programs and I was sort of inclined to include free alternatives like the GIMP. With GIMP 2.8 I have decided against doing that because I cannot support your narrowed view which workflow is worthwhile and which isn't...

GIMP can not support all workflows equally well - it can not be a breadknife and a scalpel at the same time. Right now, GIMP is a lousy scalpel. It has a ton of flaws that makes many people use it as a breadknife. But at least it seems to know what it wants to be. Even among commercial producs there is specialization AFAIK. There is Painter, Photoshop and Lightroom - each with their own usecases - and I can not belive that you would recomend people use the wrong tool for the task at hand.

--Alexia

On Fri, Nov 16, 2012 at 7:22 PM, Karl Gnter Wnsch wrote:

To me it seems you have lost any perspective whatsoever why people would want to use GIMP - they do so because they know their way around the tool, if it doesn't declare war on their workflow - which you are doing by declaring it the "wrong tool" for small tasks. What makes you the judge, jury and executioner in this case of "developer opinion" against "user workflow"?

Oh hey! Some good old-fashioned overreacting right here :)

Alexia is one of GIMP developers. You've been using results of her work since 2.6 that you hold so dear to yourself.

What if I want to add a layer with my watermark to every photo?

Would you like me to introduce you to Phatch or dozens of other batch processing tools that are way better for that task than GIMP?

I dare say your example works perfectly to illustrate the "wrong tool" concept.

For me this only means: I'm a book author for photography books and in these I usually add some sort of recommendations on which tools on the computer side would be worthwhile having around, my coauthor has up to now recommended Adobe programs and I was sort of inclined to include free alternatives like the GIMP. With GIMP 2.8 I have decided against doing that because I cannot support your narrowed view which workflow is worthwhile and which isn't...

And I thank you for being honest with us.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 5:22 PM, Karl Gnter Wnsch wrote:

If I am editing an image to my liking I usually need several sizes and sometimes even aspect crops. Since sharpening is the last step in almost all of my workflows I end up creating a master (saved as XCF) which I don't want to mess up further. That master I open and scale and sharpen as I like, save the result (err. export the result) and toss it to start again - now it prompts me to create yet another XCF which I will never ever need, I have a master copy - which I may in fact lose if I happen to hit the save short cut because being in a hurry!

This is a familiar workflow for me. I do this very often. Exporting a view of the master is a task for the future nondestructive editing. It should not require a creation of a new document. Some day it probably wont. And you will be ble to create several export graphs for your image too... This export/save separation is just one step on this way. We wont get to fully nondestructive editing today, but we will, some day. And unless you do not wish us to release anything for a next decade or two untill we get there, the interim inconvenience needs to just be lived with...

--Alexia

On 16/11/12 16:39, Alexandre Prokoudine wrote:

Oh hey! Some good old-fashioned overreacting right here :)

No, just my honest opinion on what has happened. I'm a software developer myself and if I ever lose the perspective of how my programs are used by the users and place my notion of how they are supposed to be used over the feedback I get from them - well I'd be out of work fast, especially if I don't listen to them and if necessary put my own ego aside and do the right thing, even if this means revising decisions taken earlier...

Alexia is one of GIMP developers. You've been using results of her work since 2.6 that you hold so dear to yourself.

So she is infallible?

What if I want to add a layer with my watermark to every photo?

Would you like me to introduce you to Phatch or dozens of other batch processing tools that are way better for that task than GIMP?

They are? How would you make the batch processing tool chose position and type of watermark in a way that the photo remains presentable and on the other hand prevents theft at the same time? They can't so they are the wrong tool for the job at hand.
So you say that GIMP has become a bad tool for tasks that really need layers and you want to discourage me to use it in ways that previously worked flawlessly?
---
regards
Karl Gnter Wnsch

On Fri, Nov 16, 2012 at 8:15 PM, Karl Gnter Wnsch wrote:

Oh hey! Some good old-fashioned overreacting right here :)

No, just my honest opinion on what has happened.

Yes, you are honestly overreacting.

Alexia is one of GIMP developers. You've been using results of her work since 2.6 that you hold so dear to yourself.

So she is infallible?

And again

So you say that GIMP has become a bad tool for tasks that really need layers and you want to discourage me to use it in ways that previously worked flawlessly?

And again.

May I suggest that you take a deep breath or maybe go for a walk before rejoining the thread? I don't think that a constructive discussion is possible when one of the participants is overreacting that much.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, 16 Nov 2012 19:06:38 +0400, Alexandre Prokoudine wrote:

On Fri, Nov 16, 2012 at 7:03 PM, Robert Krawitz wrote:

it is. But I don't think that an option to allow saving to a non-XCF file is fundamentally changing GIMP, either.

Robert, it's been stated so many times why it _is_ a fundamental thing :)

XCF is always the internal state of the document. Images get imported into an internal XCF, not opened and manipulated directly.

Yes, I know. But the *option* isn't fundamental.

When you're driving a car, it's not a fundamental difference whether the powertrain is gasoline, diesel, steam, electric, hybrid, warp drive (well, maybe...). Working on the innards of the car, sure, and if you want to get optimum performance or efficiency, also true. But if you just want to putter around town -- or go on vacation -- it doesn't matter.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Fri, Nov 16, 2012 at 8:23 PM, Robert Krawitz wrote:

XCF is always the internal state of the document. Images get imported into an internal XCF, not opened and manipulated directly.

Yes, I know. But the *option* isn't fundamental.

When you're driving a car, it's not a fundamental difference whether the powertrain is gasoline, diesel, steam, electric, hybrid, warp drive (well, maybe...).

Your analogy is, frankly, weak. And hence the rest of it doesn't really apply.

What you are saying, basically, is that users should not care how things work inside GIMP, and GIMP should not dictate the users how to work.

The thing is, we do not dictate users how to work, and neither does GIMP. We just make an editor for a particular workflow. Whether users, who rely on a different workflow, adopt it or not, is entirely up to them.

I suggest you fork it to make it the way you want it to work. It's GPL.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, 16 Nov 2012 17:20:47 +0200, Alexia Death wrote:

On Fri, Nov 16, 2012 at 5:14 PM, Matthew Miller wrote:

To run with this analogy: the problem is when you *frequently* need something that is more than nano provides. In the specific case of Gimp, I don't think there's anything else that offers layers, curves, and a healing brush. I use those things all the time in quick JPEG editing. (The layers only temporarily, of course -- I'll be looking forward to adjustment layers when that work is done.)

If we had a whole toolbox of photo editing tools at our disposal in Linux, I'd be less sad.

There is quite a lot. Darktable and Digikam integrated editor both offer most of this(I thin latest digikam even had some healing) and are the breadknives of this workflow. Both can directly load RAW too, afaik....

Actually, that's the problem -- there *are* so many editors, and each one has a different interface and different limitations. I much prefer to just use one editor that has all the capabilities I need.

It's important to use the right tool for the job, certainly, but image editing has the same basic primitives regardless of whether it's quick and dirty or a major project. Having to remember different commands to do curves, sharpening, denoise, levels, and such isn't very productive.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Von: "Karl Günter Wünsch"

They are? How would you make the batch processing tool chose position and type of watermark in a way that the photo remains presentable and on the other hand prevents theft at the same time? They can't so they are the wrong tool for the job at hand.

I would have it add an invisible watermark to the image. This would not prevent theft - just as a visible watermark won't - but would make it a lot easier to track theft automatically with a crawler.

If a batch processing tool doesn't offer this sort of watermark, then it would be the wrong tool for this job, yes.

Regards, Michael

On Fri, 2012-11-16 at 10:14 -0500, Matthew Miller wrote:

In the specific case of Gimp, I
don't think there's anything else that offers layers, curves, and a healing brush.

If you are making use of layers, you're into GIMP territory, and into the territory where saving as JPEG and losing the layers can be a problem.

It might be that the long-term option is a different metaphor, in which the journal of GEGL operations is saved at a high level, and exporting to jpeg is no longer lossy because of the journal. The metaphor then would be that the image is being sculpted, but that anything can be undone or redone, even between editor sessions, perhaps with (named?) checkpoints/version-tags you can easily revisit.

For just levels, curves, white balance, gthumb is quite good and has good gnome integration.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
The barefoot typographer, http://www.holoweb.net/~liam/

On Fri, 2012-11-16 at 10:14 -0500, Matthew Miller wrote:

In the specific case of Gimp, I
don't think there's anything else that offers layers, curves, and a healing brush.

You'd be surprised ;)

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 11:40:41AM -0500, Liam R E Quin wrote:

It might be that the long-term option is a different metaphor, in which the journal of GEGL operations is saved at a high level, and exporting to jpeg is no longer lossy because of the journal. The metaphor then would be that the image is being sculpted, but that anything can be undone or redone, even between editor sessions, perhaps with (named?) checkpoints/version-tags you can easily revisit.

This sounds awesome.

In fact, in the meantime, an option where gimp automatically and transparently saves (versioned?) XCF copies of my files in a backup directory when I "save" to JPEG or PNG would be pretty cool. It'd eat up space, but I have *plenty* of temporary working space (and tools for cleaning up old files).

For just levels, curves, white balance, gthumb is quite good and has good gnome integration.

The problem with gthumb and digikam is that they are primarily image organizers, so using them as photo editors is fighting upstream. GIMP is an image manipulation program, so it seems to be _more_ the right tool for the job. I'm _surprised_ to be told otherwise. (And sad. It's great software that I advocate strongly for in photography circles.)

Matthew Miller           mattdm@mattdm.org          

On Fri, 16 Nov 2012 20:33:45 +0400, Alexandre Prokoudine wrote:

On Fri, Nov 16, 2012 at 8:23 PM, Robert Krawitz wrote:

XCF is always the internal state of the document. Images get imported into an internal XCF, not opened and manipulated directly.

Yes, I know. But the *option* isn't fundamental.

When you're driving a car, it's not a fundamental difference whether the powertrain is gasoline, diesel, steam, electric, hybrid, warp drive (well, maybe...).

Your analogy is, frankly, weak. And hence the rest of it doesn't really apply.

What you are saying, basically, is that users should not care how things work inside GIMP, and GIMP should not dictate the users how to work.

I'm saying that users shouldn't have to care how things work internally, yes. Users who know how it works internally can get better results using XCF, but even expert users don't need that all the time.

The thing is, we do not dictate users how to work, and neither does GIMP. We just make an editor for a particular workflow. Whether users, who rely on a different workflow, adopt it or not, is entirely up to them.

You're throwing a gratuitous roadblock in the way of people who want to use it differently.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Fri, 16 Nov 2012 11:40:41 -0500, Liam R E Quin wrote:

On Fri, 2012-11-16 at 10:14 -0500, Matthew Miller wrote:

In the specific case of Gimp, I
don't think there's anything else that offers layers, curves, and a healing brush.

If you are making use of layers, you're into GIMP territory, and into the territory where saving as JPEG and losing the layers can be a problem.

Emphasis on *can be*. But not always.

It might be that the long-term option is a different metaphor, in which the journal of GEGL operations is saved at a high level, and exporting to jpeg is no longer lossy because of the journal. The metaphor then would be that the image is being sculpted, but that anything can be undone or redone, even between editor sessions, perhaps with (named?) checkpoints/version-tags you can easily revisit.

But maybe I don't care about that. Maybe I'm creating a one-shot web graphic, or I'm using layers to selectively modify part of the image and am prepared to take the chance that I won't need to do anything too significant later.

For just levels, curves, white balance, gthumb is quite good and has good gnome integration.

But then I have to know two different tools to do the same thing.

I have most certainly used XCF format for a lot of bigger projects. I've built big panoramas, and most certainly save those in XCF format, since in many cases I do extensive work on them. However, I've also done things like tweaked less critical photos for web download, and the process overhead of having to deal with two files just isn't worth it.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Robert Krawitz (rlk@alum.mit.edu) wrote:

You're throwing a gratuitous roadblock in the way of people who want to use it differently.

We've heard from quite a lot of people that they disliked this change but still tried to adapt to it.

They did not necessary like it, but at least can live with it. In fact it turns out that at least some of them really liked it in the end.

So the ton of work Peter Sikking did to come up with a conceptually clear separation and sane shortcuts *did* benefit these people, including some who not even describe themselves as professionals.

If we add an option people will get annoyed, find the option, restore the old thing and *never* have the chance to benefit from the new concept.

Yes, we *are* trying to change habits here, because we believe it will be beneficial for all. This also is the reason for not providing a shortcut from the save dialog telling you that you can't save to "jpg" to the export dialog.

This huge discussion here is about a single dialog that warns you that you might lose work, which is dismissed easily. And yet we constantly hear that we destroy workflows, kill productivity, put roadblocks into our users ways of working, disregard most of our userbase, want to drive people away from gimp, eat babies and whatever.

To state that this is blown way out of proportion is understating it.

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Fri, Nov 16, 2012 at 9:11 PM, Alberto Mardegan wrote:

Just please don't tell people that their needs are wrong only because you don't feel the same needs.

We never said that.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, 2012-11-16 at 12:04 -0500, Robert Krawitz wrote:

On Fri, 16 Nov 2012 11:40:41 -0500, Liam R E Quin wrote:

If you are making use of layers, you're into GIMP territory, and into the territory where saving as JPEG and losing the layers can be a problem.

Emphasis on *can be*. But not always.

Of course. You can drive without seatbelts if you like. You're cleverer than I am and more careful, and never have accidents on those short trips. I've only been using GIMP since 1998. But there have been times I've regretted not having layers in the saved file.

GIMP isn't about to revert the change. Use a script, or get used to control-shift-e instead of control-shift-s.

I think it might be helpful if the gimp Save dialogue had a button to "export instead", rather like levels has "use these settings in curves". But I expect few if any of the developers are still reading this thread.

Liam

PS: hey, I have an MIT account too :-)

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Hi!

This huge discussion here is about a single dialog that warns you that you might lose work, which is dismissed easily.

Probably nothing in the world is more annoying than stupid pop-ups "are you sure?" without even an option to turn them off. I believe that:
- in the case user loaded flat image - no layers were applied OR image was flattened - exported as any supported format - the image SHOULD be marked as 'saved', no pop-ups appearing when closing this window.
And please - do not recommend scripting. I'd better correct source and start selling 'gimp with blackjack and whores'.

-- EV --

I didn't read all the coments (after the discussion got a bit personal), but I think, and I'm sure I said this before, that this problem can be solved easily by:
- adding a default shortcut for Overwrite (I use CTRL+SHIFT+E for that) - Mark the save flag after the overwrite, so GIMP doesn't ask for saving.

If you open a file to make minor tweaks and overwrite it, it's likely that you don't need to save it as XCF.
I think this would calm down all the people ranting because they can't just open their jpgs and save them back.

For the rest of the uses the separation between save and export is wise and safe.

My 2 cents,
Gez

2012/11/16 Liam R E Quin

On Fri, 2012-11-16 at 12:04 -0500, Robert Krawitz wrote:

On Fri, 16 Nov 2012 11:40:41 -0500, Liam R E Quin wrote:

If you are making use of layers, you're into GIMP territory, and into the territory where saving as JPEG and losing the layers can be a problem.

Emphasis on *can be*. But not always.

Of course. You can drive without seatbelts if you like. You're cleverer than I am and more careful, and never have accidents on those short trips. I've only been using GIMP since 1998. But there have been times I've regretted not having layers in the saved file.

GIMP isn't about to revert the change. Use a script, or get used to control-shift-e instead of control-shift-s.

I think it might be helpful if the gimp Save dialogue had a button to "export instead", rather like levels has "use these settings in curves". But I expect few if any of the developers are still reading this thread.

Liam

PS: hey, I have an MIT account too :-)

-- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

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

So unless you come up with a real usability study within our target user group that shows that they can't handle this change we won't change this.

Or, you can do what I've done-- build Gimp 2.6 and not take upgrades.

Monty

On Fri, Nov 16, 2012 at 03:55:01PM -0300, gespertino@gmail.com wrote:

- adding a default shortcut for Overwrite (I use CTRL+SHIFT+E for that) - Mark the save flag after the overwrite, so GIMP doesn't ask for saving.

Yeah, I guess that latter would handle pretty much all I want. I'm already comfortable with changing the default shortcuts around (since no one listed to me on '!' :) ).

The idea of combining all of the save/export paths into a combined dialog is intriguing.

Matthew Miller           mattdm@mattdm.org          

Date: Fri, 16 Nov 2012 18:50:33 +0400 From: alexandre.prokoudine@gmail.com To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Save/export, option to go back to old behaviour

This has been discussed a dozen of times. One of these days I'll really finish the new FAQ so that we could prevent yet another "I'm not here to reignite the discussion about the new save/export behaviour, don't worry. :-)" thread.

Yeah,
this topic really does need a highly-visible FAQ entry. Preferably something that mentions / links to the user-developed alternatives (like the plugin and fork).

From: rlk@alum.mit.edu
To: alexiadeath@gmail.com
Date: Fri, 16 Nov 2012 11:33:58 -0500 CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Save/export, option to go back to old behaviour

On Fri, 16 Nov 2012 17:20:47 +0200, Alexia Death wrote:

On Fri, Nov 16, 2012 at 5:14 PM, Matthew Miller wrote:

To run with this analogy: the problem is when you *frequently* need something that is more than nano provides. In the specific case of Gimp, I don't think there's anything else that offers layers, curves, and a healing brush. I use those things all the time in quick JPEG editing. (The layers only temporarily, of course -- I'll be looking forward to adjustment layers when that work is done.)

If we had a whole toolbox of photo editing tools at our disposal in Linux, I'd be less sad.

There is quite a lot. Darktable and Digikam integrated editor both offer most of this(I thin latest digikam even had some healing) and are the breadknives of this workflow. Both can directly load RAW too, afaik....

Actually, that's the problem -- there *are* so many editors, and each one has a different interface and different limitations. I much prefer to just use one editor that has all the capabilities I need.

To reference the scalpel-vs-breadknife analogy that was brought up, can I just add three words?

Swiss. Army.
Knife.

Sure, there are many tools out there whose efficiency derives from their specialization to a dedicated task -- but sometimes the user wants something that is competent on a variety of multiple tasks, if only because it's less "stuff" for them to lug around all the time and manage.

For example, I don't know about your usecases for one of these, but when I pull out my Victorinox 90% of the time it's because I need either a flatblade screwdriver or pair of scissors (which are no doubt more efficient for the task, but would require three or four times the pocketspace to be lugging around all the time, or a separate trip to the toolbox). As for the remaining 10% when I actually do need a knifeblade? It's because I'm trying to open some stupid plastic-shell packaging -- you know, the type of stuff that not even a nuclear bomb can open otherwise.

So it's not a perfect tool for every job, but it is an acceptable tool for many jobs, and especially for jobs that might otherwise require constantly switching between 3-5 different, separate tools every few minutes to get done.

And while I'm on the subject, before trying GIMP (2.2) for my first time, my image editing apps basically amounted to MS Paint. My dad had an image editor called iPhoto Plus from back in the Windows 3.x days which had TWAIN scanner access, levels adjustment and scaling/rotating/shear with linear resampling but its painting tools were barely any better than MSP. During the Windows 95 days I found a lightweight program called LView Pro (which has since gone trial/timerware, I think) that could input and output almost every file format of the day (barring animated GIF), but its editing features were otherwise far less than iPhoto and it basically lacked any editing capability beyond global image adjustments, many of which weren't that useful for me to begin with (though one exception was a YCC-based luma inversion called "Negative!", which I found highly interesting).
So GIMP had effectively the functionality of all those three apps, and more (like support for animated GIFs).

Date: Fri, 16 Nov 2012 09:58:44 -0500 From: nicolas.robidoux@gmail.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Save/export, option to go back to old behaviour

If such an "option" ever sees the light of day, I think the button should show a poison symbol (skull and crossbones).

.....or should it be a swastika?

:)

-----

Oh, a Mr. Godwin called while you were out, said something about suspending your debate license?

;)

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

=

On Fri, Nov 16, 2012 at 1:02 PM, Monty Montgomery wrote:

So unless you come up with a real usability study within our target user group that shows that they can't handle this change we won't change this.

Or, you can do what I've done-- build Gimp 2.6 and not take upgrades.

Or, like I've done - install both ;) Sometimes when I *know* it's just going to be a one-shot operation and I don't give a damn about the source file*, I'll right-click and open in 2.6 instead of 2.8.

The downside of this is that I'm having to remember both behaviors. But I'm getting used to it and will probably stick with 2.8 only when next I upgrade my OS.

Chris

* for example: crappy JPEG, crop to some text, maybe chop letters apart, convert to grayscale, levels, save as PNG, upload to WTF font identifier. If disk space weren't cheap, I'd delete both the source and destination afterward: they are of no further use. In 2.8 I close without saving.

A couple of hours ago, when discussing this issue with Jesusda we both noticed (both noticed it for the very first time) the option in the preferences that disables the warning for unsaved XCF files.

After realizing the existence of that feature, I can't see why we should go back to the older behavior, since all that users want is having the export/overwrite features saving and not warning of the unsaved file right after the export.
Replacing the export accelerators for the current save accelerators and disabling the unsaved file warning is all you need if you want the old behavior back.

It brings the potential risk of loosing unsaved data, but if you're willing to go back to the old behavior, then you're accepting that danger in a certain degree, because the old method carried that risk.

So, what's all this discussion about after all? Do we need to revert to the old method? Answer seems no, not because nobody would want the old behavior back (there is a lot of people crying for it), but because it's pointless to use developer efforts and cluttering the UI with something that's already possible.

2012/11/16 Chris Mohler

On Fri, Nov 16, 2012 at 1:02 PM, Monty Montgomery wrote:

So unless you come up with a real usability study within our target user group that shows that they can't handle this change we won't change this.

Or, you can do what I've done-- build Gimp 2.6 and not take upgrades.

Or, like I've done - install both ;) Sometimes when I *know* it's just going to be a one-shot operation and I don't give a damn about the source file*, I'll right-click and open in 2.6 instead of 2.8.

The downside of this is that I'm having to remember both behaviors. But I'm getting used to it and will probably stick with 2.8 only when next I upgrade my OS.

Chris

* for example: crappy JPEG, crop to some text, maybe chop letters apart, convert to grayscale, levels, save as PNG, upload to WTF font identifier. If disk space weren't cheap, I'd delete both the source and destination afterward: they are of no further use. In 2.8 I close without saving.
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, 2012-11-16 at 19:54 -0300, gespertino@gmail.com wrote:

A couple of hours ago, when discussing this issue with Jesusda we both noticed (both noticed it for the very first time) the option in the preferences that disables the warning for unsaved XCF files.

That option has been removed from git master.

Everybody can start whining now, so it will be over when 2.10 is released.

--mitch

After realizing the existence of that feature, I can't see why we should go back to the older behavior, since all that users want is having the export/overwrite features saving and not warning of the unsaved file right after the export.
Replacing the export accelerators for the current save accelerators and disabling the unsaved file warning is all you need if you want the old behavior back.

It brings the potential risk of loosing unsaved data, but if you're willing to go back to the old behavior, then you're accepting that danger in a certain degree, because the old method carried that risk.

So, what's all this discussion about after all? Do we need to revert to the old method? Answer seems no, not because nobody would want the old behavior back (there is a lot of people crying for it), but because it's pointless to use developer efforts and cluttering the UI with something that's already possible.

2012/11/16 Chris Mohler

On Fri, Nov 16, 2012 at 1:02 PM, Monty Montgomery wrote:

So unless you come up with a real usability study within our target user group that shows that they can't handle this change we won't change this.

Or, you can do what I've done-- build Gimp 2.6 and not take upgrades.

Or, like I've done - install both ;) Sometimes when I *know* it's just going to be a one-shot operation and I don't give a damn about the source file*, I'll right-click and open in 2.6 instead of 2.8.

The downside of this is that I'm having to remember both behaviors. But I'm getting used to it and will probably stick with 2.8 only when next I upgrade my OS.

Chris

* for example: crappy JPEG, crop to some text, maybe chop letters apart, convert to grayscale, levels, save as PNG, upload to WTF font identifier. If disk space weren't cheap, I'd delete both the source and destination afterward: they are of no further use. In 2.8 I close without saving.
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

Modal menus that are not context sensitive ate nearly always a bad idea. On Nov 16, 2012 4:45 AM, "Alberto Mardegan" wrote:

Hi all!
I'm not here to reignite the discussion about the new save/export behaviour, don't worry. :-)
However, as many other users, I find the new behaviour not helping my workflow, so I'd like to do something about it.

I think that the "Save" command should just save the current file in whatever format the file originally had; so, if I open a PNG and crop it, then close the window and get prompted to save it, I should have the option to save it as PNG (and it should be the default choice for this image). I understand that you don't agree with this principle.

So, given the inconcialiability of the opinions in the same UI, I propose to have an option in the preferences dialog to go back to the old behaviour (with the 2.8 behaviour as default). I'm willing to provide a patch myself, of course.

My question now is whether such a patch (provided that the code quality matches your requirements) would be accepted -- in which case I would go and file a bug for it, and assign it to myself --, or if I should not even give it a try.

I really hope that this effort will be welcome. :-)

Ciao, Alberto

--
http://blog.mardy.it
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, 16 Nov 2012 12:36:30 -0500, Liam R E Quin wrote:

On Fri, 2012-11-16 at 12:04 -0500, Robert Krawitz wrote:

On Fri, 16 Nov 2012 11:40:41 -0500, Liam R E Quin wrote:

If you are making use of layers, you're into GIMP territory, and into the territory where saving as JPEG and losing the layers can be a problem.

Emphasis on *can be*. But not always.

Of course. You can drive without seatbelts if you like. You're cleverer than I am and more careful, and never have accidents on those short trips. I've only been using GIMP since 1998. But there have been times I've regretted not having layers in the saved file.

Well, as it happens, this *has* happened on occasion. But the current solution wouldn't have solved the problem for me anyway, since the regret was after the fact (after I already would have exported it and exited GIMP).

GIMP isn't about to revert the change. Use a script, or get used to control-shift-e instead of control-shift-s.

Which still doesn't solve the problem of an exported image not being considered saved, and prompting me.

I think it might be helpful if the gimp Save dialogue had a button to "export instead", rather like levels has "use these settings in curves". But I expect few if any of the developers are still reading this thread.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Simon Budig wrote:

We have decided to focus on loss-prevention. We have discussed and explained this ad nauseam.

And loss prevention has little or nothing to do with the decision to save or export. If you track what features an image uses, then you can by default save back to the file format used to open the image. Only if some processing operation is performed that takes the image outside the capabilities of the originally opened file do you have to get the user to decide whether to loose information or save as a different format.

Graeme Gill.

On Sat, Nov 17, 2012 at 4:11 AM, Graeme Gill wrote:

And loss prevention has little or nothing to do with the decision to save or export. If you track what features an image uses, then you can by default save back to the file format used to open the image. Only if some processing operation is performed that takes the image outside the capabilities of the originally opened file do you have to get the user to decide whether to loose information or save as a different format.

Even the act of loading a file into memory as pixel data and then recompressing on save is lossy for lossy formats and grayscale formats outright destroy information if the original is color. It is not realistic to keep track for each format feature by feature, if the image is now restorably exported or not, it would make maintaining gimp code and adding features a horror... Each change anywhere would recquire going over all export plugins making sure their supported feature lists are up to date... This separation makes it clear cut. The project file, the one that keeps ervery feature of gimp intact is the xcf and you save to it. Any rendering you export to. And this distinction will get even more important when we get to gegl backend in full.

In short, options were considered, arguments have been had. We didn't do this to anoy anybody, we did this based on alot of consideration and a future of GIMP as a nondestructive image editor.

--Alexia

Alexia Death wrote:

Even the act of loading a file into memory as pixel data and then recompressing on save is lossy for lossy formats and grayscale formats outright destroy information if the original is color. It is not

This type of argument simply doesn't hold water. A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends. They have chosen a certain image quality vs. file size tradeoff, and not maintaining this choice is discarding the users preferences.

To load a compressed image, and then simply invent 90% of the bits out of thin air, add the invented bits back into the image and then carefully preserve every one of them is just nonsense.

Honouring the idea of loss prevention when dealing with lossily compressed sources simply means (by default) maintaining the same level of quality/size traedoff. [ Of course the user should have the option of changing this tradeoff if they so desire. ]

realistic to keep track for each format feature by feature, if the image is now restorably exported or not, it would make maintaining gimp code and adding features a horror... Each change anywhere would recquire going over all export plugins making sure their supported feature lists are up to date... This separation makes it clear cut.

That's an implementation limitation, not a fundamental logical constraint. The internal storage just has to keep track of what image feature is being used (trivial to automatic), and for the various file format code to check whether they can save all the features used. There is nothing fundamentally hard about creating or maintaining such an approach, although I can well believe and accept that development history may prevent such an approach in Gimp with any ease. But if that is the case, the honest thing is to accept this and work towards overcoming it, rather than pointing to talk of "loss prevention".

The project file, the one that keeps ervery feature of gimp intact is the xcf and you save to it. Any rendering you export to. And this distinction will get even more important when we get to gegl backend in full.

So what ? You certainly don't want to create a superset storage file unless it contains more than the original file contains. To do so is simply wasteful and a burden on the user.

In short, options were considered, arguments have been had. We didn't do this to anoy anybody, we did this based on alot of consideration and a future of GIMP as a nondestructive image editor.

Not thought through with enough imagination or consideration of the users perspective, in my opinion.

Graeme Gill.

On Mon, Nov 19, 2012 at 6:08 AM, Graeme Gill wrote:

Even the act of loading a file into memory as pixel data and then recompressing on save is lossy for lossy formats and grayscale formats outright destroy information if the original is color. It is not

This type of argument simply doesn't hold water. A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends. They have chosen a certain image quality vs. file size tradeoff, and not maintaining this choice is discarding the users preferences.

It must be wonderful to live in a world where people work only on images they created themselves :)

The project file, the one that keeps ervery feature of gimp intact is the xcf and you save to it. Any rendering you export to. And this distinction will get even more important when we get to gegl backend in full.

So what ? You certainly don't want to create a superset storage file unless it contains more than the original file contains. To do so is simply wasteful and a burden on the user.

Um. Are you suggesting that GIMP should somehow begin to view files differently as soon as some unsupported (re original file) feature gets added? Like "Uh, oh, you added a layer, and PNG doesn't support layers, so let's treat this as XCF after all"? :)

Alexandre Prokoudine http://libregraphicsworld.org

Em 19-11-2012 00:08, Graeme Gill escreveu:

Alexia Death wrote:

Even the act of loading a file into memory as pixel data and then recompressing on save is lossy for lossy formats and grayscale formats outright destroy information if the original is color. It is not

This type of argument simply doesn't hold water. A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends. They have chosen a certain image quality vs. file size tradeoff, and not maintaining this choice is discarding the users preferences.

Sorry, I don't think is a good idea to base development decisions /suposing/ that the user knows /all/ of what he is doing. If an user don't understand loss of data and is never warned, he/she will keep saving over the file and increasingly losing data. It is much more 'humane' to start by the premise that the user should be warned. --
Thiago

Graeme Gill (graeme2@argyllcms.com) wrote:

This type of argument simply doesn't hold water. A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends.

...positively indicates that this is what the user intended to work with. Nothing more. The JPG comes from a digital camera, some random source in the internet, some marketing guy who hasn't got a clue.

We cannot just make the assumption that "oh, its a JPEG. *clearly* the user wants us to discard information on saving".

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Mon, 19 Nov 2012 00:47:53 -0200, libre wanderer wrote:

Em 19-11-2012 00:08, Graeme Gill escreveu:

Alexia Death wrote:

Even the act of loading a file into memory as pixel data and then recompressing on save is lossy for lossy formats and grayscale formats outright destroy information if the original is color. It is not

This type of argument simply doesn't hold water. A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends. They have chosen a certain image quality vs. file size tradeoff, and not maintaining this choice is discarding the users preferences.

Sorry, I don't think is a good idea to base development decisions /suposing/ that the user knows /all/ of what he is doing. If an user don't understand loss of data and is never warned, he/she will keep saving over the file and increasingly losing data. It is much more 'humane' to start by the premise that the user should be warned.

It's not very "humane" to keep warning the user even if the user knows perfectly well what s/he is doing and for one reason or another just doesn't care.

This whole notion of the .xcf file being the "project" file, and everything else being derivative, is fine in principle. But it's being taken to the extreme of not recognizing that some things just aren't worth making into a full-blown project.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Mon, 19 Nov 2012 06:46:35 +0400, Alexandre Prokoudine wrote:

On Mon, Nov 19, 2012 at 6:08 AM, Graeme Gill wrote:

The project file, the one that keeps ervery feature of gimp intact is the xcf and you save to it. Any rendering you export to. And this distinction will get even more important when we get to gegl backend in full.

So what ? You certainly don't want to create a superset storage file unless it contains more than the original file contains. To do so is simply wasteful and a burden on the user.

Um. Are you suggesting that GIMP should somehow begin to view files differently as soon as some unsupported (re original file) feature gets added? Like "Uh, oh, you added a layer, and PNG doesn't support layers, so let's treat this as XCF after all"? :)

That's exactly what GIMP t save the layers, and prompted for what to do. That was perfectly workable.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Mon, Nov 19, 2012 at 7:29 AM, Robert Krawitz wrote:

That's exactly what GIMP t save the layers, and prompted for what to do. That was perfectly workable.

I don't know if you read the *-users@ list, but "the perfectly workable" solution has just bit yet another user in the butt.

There are people, like yourself, who think it's workable. There are people who absolutely hate annoying "I'm a stupid software, tell me what to do" dialogs .

None of them hold the ultimate knowledge of what's right and what's wrong.

People who think they know what they need every single second of their lives are welcome to use Krita. People who don't mind a bit of assistance in decision-making are welcome to stick to GIMP.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 7:26 AM, Robert Krawitz wrote:

This reply:

It's not very "humane" to keep warning the user even if the user knows perfectly well what s/he is doing and for one reason or another just doesn't care.

and this reply:

That's exactly what GIMP t save the layers, and prompted for what to do. That was perfectly workable.

are mutually exclusive.

Unless, of course, you mean that "perfectly workable" can coexist with "not very humane".

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 07:40:52AM +0400, Alexandre Prokoudine wrote:

That's exactly what GIMP t save the layers, and prompted for what to do. That was perfectly workable.

I don't know if you read the *-users@ list, but "the perfectly workable" solution has just bit yet another user in the butt.

Sure. That doesn't mean you should optimize for protecting against mistakes like this *at the expense* of day to day use -- particularly if aiming at professionals. (A common user experience design mistake!)

There are people, like yourself, who think it's workable. There are people who absolutely hate annoying "I'm a stupid software, tell me what to do" dialogs .
None of them hold the ultimate knowledge of what's right and what's wrong.

Sure. That's exactly why it'd make sense to have an option. You can eat your cake *and* have it too.

People who think they know what they need every single second of their lives are welcome to use Krita. People who don't mind a bit of assistance in decision-making are welcome to stick to GIMP.

That would be fine thing to say if Krita were the same kind of software, but it is not. (Specifically, is "the full-featured painting application for digital artists".)

Matthew Miller           mattdm@mattdm.org          

On Mon, Nov 19, 2012 at 7:45 AM, Matthew Miller wrote:

I don't know if you read the *-users@ list, but "the perfectly workable" solution has just bit yet another user in the butt.

Sure. That doesn't mean you should optimize for protecting against mistakes like this *at the expense* of day to day use -- particularly if aiming at professionals. (A common user experience design mistake!)

Perhaps you came late to the discussion. Several team members including myself already mentioned before that we had observed professionals liking the change and not quite understanding what all this fuzz is about. You will find it difficult to explain how this was a figment of our imagination. Perhaps you could start with studying _actual_ response from the "day to day use" world?

That would be fine thing to say if Krita were the same kind of software, but it is not. (Specifically, is "the full-featured painting application for digital artists".)

I find it interesting that you rely on official statements rather that pure and unadorned reality.

While Krita indeed has a strong bias towards digital painting, it just so happens that quite a few universal and non-painting specific features managed to crawl inside the application over the last few year, including, but not limited to:

- PSD importing - color managed printing
- simple object selection tool (a-la GIMP) - unified transformation tool

AFAIK, Dmitry Kazakov's work on performance was triggered by his interest in Krita as a tool for digital photography.

Or here is an interview I did with the team lead and a major contributor in 2008:

http://libregraphicsworld.org/blog/entry/interview-with-krita-developers-2008

You will find 2nd and 3rd Q/A most enlightening.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 8:12 AM, Alexandre Prokoudine wrote:

Or here is an interview I did with the team lead and a major contributor in 2008:

http://libregraphicsworld.org/blog/entry/interview-with-krita-developers-2008

You will find 2nd and 3rd Q/A most enlightening.

Correction: 1st and 2nd.

Alexandre Prokoudine http://libregraphicsworld.org

Simon Budig wrote:

We cannot just make the assumption that "oh, its a JPEG. *clearly* the user wants us to discard information on saving".

You really think they want you to save a lot of invented bits and blow their file up in size with all that false data ?

They want you to save the same visible information, without any obvious further degradation. That's easily achieved by saving in a lossless format, but not very clever, and doesn't honour the quality/file size trade-off they've already agreed to and want, since they are saving back to the lossy file format they opened.

Graeme Gill.

Alexandre Prokoudine wrote:

Perhaps you came late to the discussion. Several team members including myself already mentioned before that we had observed professionals liking the change and not quite understanding what all this fuzz is about. You will find it difficult to explain how this was a figment of our imagination. Perhaps you could start with studying _actual_ response from the "day to day use" world?

It's tangential to the reason I commented on this list. There may or may not be good reasons for the change in Gimp, and some users may or may not cope with or even like the new workflow. But you can't keep on saying "it's because of data loss" when this reason doesn't seem to stack up. It's clearly possible to avoid inadvertent data loss while still keeping a conventional and familiar open/edit/save workflow, and without nagging users with unnecessary dialogs.

Graeme Gill.

Alexandre Prokoudine wrote:

It must be wonderful to live in a world where people work only on images they created themselves :)

Relevance ? (I can't see any).

Um. Are you suggesting that GIMP should somehow begin to view files differently as soon as some unsupported (re original file) feature gets added? Like "Uh, oh, you added a layer, and PNG doesn't support layers, so let's treat this as XCF after all"? :)

Such a thing comes without any further effort. The current state of the image either contains layers or it doesn't. It's simple for the PNG image code to check if there are layers, and return a status "can't save all of the current image info."

There are a variety of UI ways of handling this, from not offering any formats that will loose information to save to, to the simple "do you want to collapse into PNG format" etc.

But all this is very elementary. I don't understand why you raise it as being any sort sort of problem.

Graeme Gill.

On Mon, Nov 19, 2012 at 8:38 AM, Graeme Gill wrote:

Alexandre Prokoudine wrote:

Perhaps you came late to the discussion. Several team members including myself already mentioned before that we had observed professionals liking the change and not quite understanding what all this fuzz is about. You will find it difficult to explain how this was a figment of our imagination. Perhaps you could start with studying _actual_ response from the "day to day use" world?

It's tangential to the reason I commented on this list.

Perhaps you didn't notice, but that was my reply to a different person. There are more than two people participating in this discussion.

But you can't keep on saying "it's because of data loss" when this reason doesn't seem to stack up.

I don't keep saying that. It's more than just data loss. It's workflow.

Seriously, you've been into this discussion long enough. Surely you've already read both
http://gui.gimp.org/index.php/Save_%2B_export_specification and http://gui.gimp.org/index.php/Vision_briefing to understand the intentions.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 8:41 AM, Graeme Gill wrote:

Alexandre Prokoudine wrote:

It must be wonderful to live in a world where people work only on images they created themselves :)

Relevance ? (I can't see any).

You can't? Do I really have to go back and point my finger at your earlier statements?

"A file that holds the image data in a lossily compressed format positively indicates that this is what the user intends. They have chosen a certain image quality vs. file size tradeoff, and not maintaining this choice is discarding the users preferences."

So what you are saying is that, correct me if I'm wrong, people never edit other people's pictures? Amazing. Talk about real life.

You see, where I work we produce an industry magazine and use Creative Commons licensed content from Flickr (properly attributed) which we clearly didn't produce and upload ourselves.

Editing other people's content is, frankly, quite a common activity. It's astounding that you dismiss it so easily.

Um. Are you suggesting that GIMP should somehow begin to view files differently as soon as some unsupported (re original file) feature gets added? Like "Uh, oh, you added a layer, and PNG doesn't support layers, so let's treat this as XCF after all"? :)

Such a thing comes without any further effort. The current state of the image either contains layers or it doesn't. It's simple for the PNG image code to check if there are layers, and return a status "can't save all of the current image info."

There are a variety of UI ways of handling this, from not offering any formats that will loose information to save to, to the simple "do you want to collapse into PNG format" etc.

But all this is very elementary. I don't understand why you raise it as being any sort sort of problem.

It was explained many times why we did it.

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine wrote:

So what you are saying is that, correct me if I'm wrong, people never edit other people's pictures? Amazing. Talk about real life.

Sorry, I'm not following you at all. What's the relevance ?

Editing other people's content is, frankly, quite a common activity. It's astounding that you dismiss it so easily.

And you haven't drawn any relevance between this and the subject at hand.

open/edit/save - you're content with the compression chosen for the original image.

open/edit/save-as (or change compression ratio & save), you've chosen to do override the default, because you have special requirements.

All good UI practice - don't trouble the user with stuff that's only needed for less common situations.

Graeme Gill

On Mon, Nov 19, 2012 at 9:14 AM, Graeme Gill wrote:

So what you are saying is that, correct me if I'm wrong, people never edit other people's pictures? Amazing. Talk about real life.

Sorry, I'm not following you at all. What's the relevance ?

Editing other people's content is, frankly, quite a common activity. It's astounding that you dismiss it so easily.

And you haven't drawn any relevance between this and the subject at hand.

open/edit/save - you're content with the compression chosen for the original image.

open/edit/save-as (or change compression ratio & save), you've chosen to do override the default, because you have special requirements.

All good UI practice - don't trouble the user with stuff that's only needed for less common situations.

I don't think I can provide a reasonable reply to this ridiculous mail. Perhaps you've had a hard day and hence can't see things clearly. So let's leave it at that, shall we?

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine wrote:

I don't think I can provide a reasonable reply to this ridiculous mail. Perhaps you've had a hard day and hence can't see things clearly. So let's leave it at that, shall we?

You've failed to indicate what is ridiculous about it, instead making a response about the person rather than the argument. I need say no more.

Graeme Gill.

On Mon, Nov 19, 2012 at 10:14 AM, Graeme Gill wrote:

Alexandre Prokoudine wrote:

I don't think I can provide a reasonable reply to this ridiculous mail. Perhaps you've had a hard day and hence can't see things clearly. So let's leave it at that, shall we?

You've failed to indicate what is ridiculous about it, instead making a response about the person rather than the argument. I need say no more.

You are basically providing a sophisticated version of "So what?" when I point out the flaw in your argumentation. There are only so many times I can explain the flaw without getting tired. So yes, you need say no more, please.

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine wrote:

when I point out the flaw in your argumentation.

Sorry, I must have missed that bit:-) As far as I recall, you basically said "but what about people opening files they didn't make", and I'm afraid I can see no obvious connection to the topic at hand, which is trying to unravel the logic of Gimp to switch to an import/export workflow, because "data loss".

As far as I can ascertain, the logic is broken in two places, one when the assumption is made that any file has to be automatically promoted to a superset format and therefore can't be save back to the file format that it was opened from without some sort of data loss because of that superset having the mere capability of holding information the format can't handle, and the other being that when lossily compressed images are opened, the lost bits have to be replaced with invented zero's and thereafter these plucked-out-of-the-air bits are simply assumed to be of absolute critical value to the user, in spite of any indication that they are content with that level of compression vs. file-size.

Graeme Gill.

On Mon, Nov 19, 2012 at 11:13 AM, Graeme Gill wrote:

As far as I can ascertain, the logic is broken in two places, one when the assumption is made that any file has to be automatically promoted to a superset format and therefore can't be save back to the file format that it was opened from without some sort of data loss because of that superset having the mere capability of holding information the format can't handle

Focusing on creating original art and complex editing that requires saving to XCF has been on our agenda since at least 2006, when the product vision was conceived.

and the other being that when lossily compressed images are opened, the lost bits have to be replaced with invented zero's and thereafter these plucked-out-of-the-air bits are simply assumed to be of absolute critical value to the user, in spite of any indication that they are content with that level of compression vs. file-size.

I haven't got a foggiest idea about what you were trying to say with that. English, please.

Alexandre Prokoudine http://libregraphicsworld.org

Graeme Gill (graeme2@argyllcms.com) wrote:

Simon Budig wrote:

We cannot just make the assumption that "oh, its a JPEG. *clearly* the user wants us to discard information on saving".

You really think they want you to save a lot of invented bits and blow their file up in size with all that false data ?

As soon as the User does some little tiny editing we no longer can discern reliably between invented bits and important bits.

They want you to save the same visible information, without any obvious further degradation. That's easily achieved by saving in a lossless format, but not very clever, and doesn't honour the quality/file size trade-off they've already agreed to and want, since they are saving back to the lossy file format they opened.

The whole point we're trying to make and which you refuse to understand is, that "they already agreed to and want" only applies for images they created themselves from scratch. It breaks down immediately when they're working with images from other sources, like the clueless marketing droid sending you a jpeg logo file.

Here the user does *not* do a concious descision towards a lossy file format. He did *not* agree to loose bits on saving even when he opened a JPEG. This whole "user indicates his intent by the file format he opens" just breaks down when working with images from other sources.

Bye, Simon

simon@budig.de              http://simon.budig.de/

Simon Budig wrote:

As soon as the User does some little tiny editing we no longer can discern reliably between invented bits and important bits.

You don't have to though - the lossy compression algorithm does that for you.

The whole point we're trying to make and which you refuse to understand is, that "they already agreed to and want" only applies for images they created themselves from scratch. It breaks down immediately when they're working with images from other sources, like the clueless marketing droid sending you a jpeg logo file.

I'm not following your logic at all. When all you've got is lossily encoded image source, you can't get the bits back again. You can choose to save back to the original file format or not. Unless you add something that needs lower compression or lossless storage and you know it, there is no reason not to save back to the original format with a similar compression ratio, since no visual information will be lost compared to the original, and that's the nature of what you are working with.

Here the user does *not* do a concious descision towards a lossy file format. He did *not* agree to loose bits on saving even when he opened a JPEG.

But low value information was missing from the start, and saving to jpeg isn't going to visibly loose any further information - that's the nature of the format, and the trade-off (given a certain quality setting) that it implies. If as a user you are not aware of the nature and side effects of lossy compression, then no making-it-hard to-save-in-jpeg-by-default is going to solve the that, it's just a meaningless obstacle that they will ignore.

This whole "user indicates his intent by the file format he opens" just breaks down when working with images from other sources.

I don't follow you at all. The lossy format implies that images are compressed. You can't get those bits back again. If you add stuff that benefits from less compression, then you need to be aware enough of it to change the compression ratio or save to a lossless file format, _but there's nothing special about that_ - you have to be aware enough to do that when creating something from scratch in the first place and going through the process of saving it in a portable file format.
99% of the time people opening jpegs will be adjusting and cropping photo's, so assuming they are doing something out of the ordinary and making it hard for them is simply bad UI IMHO.

Graeme Gill.

Graeme Gill (graeme2@argyllcms.com) wrote:

Simon Budig wrote:

The whole point we're trying to make and which you refuse to understand is, that "they already agreed to and want" only applies for images they created themselves from scratch. It breaks down immediately when they're working with images from other sources, like the clueless marketing droid sending you a jpeg logo file.

I'm not following your logic at all.

Obviously we're talking from quite different viewpoints.

When all you've got
is lossily encoded image source, you can't get the bits back again.

It is not about getting bits back, it is about the importance of the bits the user adds by editing the image. Each pixel added/changed by a contrast adjustment, each pimple cloned away immediately transforms the affected bits into important bits. We need to treat these with care.

For JPEG that means, that we cannot just decide "oh, only 0.63% of the pixels have been transformed to important bits, so we still can use JPEG for saving". This has to be made a concious descision by the user. We're aiding to make this concious by a clear separation between "save" - i.e. make sure that all bits are safe - and "export" where we ask the user to understand the implication of the export file format used.

This whole "user indicates his intent by the file format he opens" just breaks down when working with images from other sources.

I don't follow you at all. The lossy format implies that images are compressed. You can't get those bits back again. If you add stuff that benefits from less compression, then you need to be aware enough of it to change the compression ratio or save to a lossless file format,

People add layers and try to save back to jpeg, later wondering where their layers are. Yeah, it is easy to denounce them as clueless users, but this is thought too short. Assuming that people know about the lossy behaviour of jpeg is just wrong.

99% of the time people opening jpegs will be adjusting and cropping photo's, so assuming they are doing something out of the ordinary and making it hard for them is simply bad UI IMHO.

Where does this number come from?

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Mon, Nov 19, 2012 at 2:18 PM, Graeme Gill wrote:

99% of the time people opening jpegs will be adjusting and cropping photo's, so assuming they are doing something out of the ordinary and making it hard for them is simply bad UI IMHO.

The very same 99% of people who download pictures from camera into Picasa or iPhoto, crop and adjust in-place, and then upload to Facebook?

Yeeeees, I can see how the change is affecting them so badly :)

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 2:45 PM, Alberto Mardegan wrote:

for my needs was optimal; but I would also like to try to address the problems that the new export functionality tries to solve, except that I don' have a clear idea of what they are (except the image quality for compressed formats).

There must be a reason why one group of people keeps linking to http://gui.gimp.org/index.php/Save_%2B_export_specification and http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links.

Is it actually possible for a user to lose the layers when saving to JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which points the users would cancel the process if he really cares about them.

You seem to be under impression that people actually read text in prompts :)

Or do you have reports when this did not occur for some reasons?

https://mail.gnome.org/archives/gimp-user-list/2012-November/msg00190.html

Alexandre Prokoudine http://libregraphicsworld.org

On 19/11/12 11:30, Simon Budig wrote:

People add layers and try to save back to jpeg, later wondering where their layers are. Yeah, it is easy to denounce them as clueless users, but this is thought too short. Assuming that people know about the lossy behaviour of jpeg is just wrong.

Then by all means educate them, make it less easy for them to make a mistake but don't treat everybody as clueless idiots - which is your insistence on "we don't let you save to a lossy format" boils down to! It's so easy for you to make the behavior palatable for everybody, simply give those that know what they are doing a way of doing it in a way that is not impeded by the "clueless idiot mode"! Previously I saved to XCF if I suspected I'd ever will revisit the image and to PNG, JPEG, whatever when I knew that this is it. Not having the XCF was a conscious decision and I knew the ramifications of doing so. Now that I am asked when closing if I'd want to save I always have to look up if I saved to the correct format before. Worse still, since most of the time I am opening and preparing a preview image out of a previously created XCF via export - having the program prompt me to save to the original name resulted in overwritten valuable XCF with rubbish ones which only ever should exist in exported format! So basically because of your idiot proof mode prompted me to lose my time consuming work because it was overwritten with an inferior version from which I can not recover!
---
regards
Karl Gnter Wnsch

On Mon, Nov 19, 2012 at 3:11 PM, Karl Gnter Wnsch wrote:

but this is thought too short. Assuming that people know about the lossy behaviour of jpeg is just wrong.

Then by all means educate them

+

previously created XCF via export - having the program prompt me to save to the original name resulted in overwritten valuable XCF with rubbish ones which only ever should exist in exported format!

means that we should educate you :)

Alexandre Prokoudine http://libregraphicsworld.org

On 19/11/12 11:50, Alexandre Prokoudine wrote:

http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links.

I'm citing from the above: "GIMP is user-configurable to automate repetitive tasks;" - why then is it ignored when numerous people ask for a way make the export behave and be automatied in a way that "the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them"? --
regards
Karl Gnter Wnsch

On Mon, Nov 19, 2012 at 3:17 PM, Karl Gnter Wnsch wrote:

On 19/11/12 11:50, Alexandre Prokoudine wrote:

http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links.

I'm citing from the above: "GIMP is user-configurable to automate repetitive tasks;" - why then is it ignored when numerous people ask for a way make the export behave and be automatied in a way that "the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them"?

Because you understand this sentence arbitrarily while looking for offences.

"Automating repetitive tasks" refers to scripting and future "macros recording".

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 3:07 PM, Alberto Mardegan wrote:

There must be a reason why one group of people keeps linking to http://gui.gimp.org/index.php/Save_%2B_export_specification and http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links.

I swear I read them and I think that I understood the rationale. But that's note the same thing as saying that I understand what was wrong with the save functionality in 2.6 (because I still don't).

It's simple.

Primary workflow = creating original art from scratch, complex editing where preserving extras is a must. That's the workflow when you work iteratively. This workflow makes it easy to share your work in a delivery file format (e.g. exporting to a public Dropbox folder), while refining the actual project file. 2.6 didn't make it easy.

Secondary workflow = overwriting original files. 2.6 made it easier, but it's not the primary workflow, and there are well-known workarounds.

Is it actually possible for a user to lose the layers when saving to JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which points the users would cancel the process if he really cares about them.

You seem to be under impression that people actually read text in prompts :)

Maybe many don't, but at least they can't blame you for that, can they? :-) I mean, you can get burnt by this issue once, indeed.

Not once, not even by a long shot. People tend to relax and become overly confident.

and in any case you can't blame the gimp developers if you didn't read a questions which appeared while saving your extremely important file. :-)

Our job is not to point fingers and accuse. Our job is to create software for a certain target group of users described above.

Or do you have reports when this did not occur for some reasons?

https://mail.gnome.org/archives/gimp-user-list/2012-November/msg00190.html

It seems that it happened with 2.8

Does it? What makes you think so?

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 3:28 PM, Alberto Mardegan wrote:

Reformulating: is it possible for a user *who reads and understands all question dialogs which appear to him/her*, to actually lose the layers when saving to JPEG with gimp 2.6?

Yes.

If yes, how?

By being overly confident and not forward-thinking.

Alexandre Prokoudine http://libregraphicsworld.org

On 19/11/12 12:14, Alexandre Prokoudine wrote:

previously created XCF via export - having the program prompt me to save to the original name resulted in overwritten valuable XCF with rubbish ones which only ever should exist in exported format!

means that we should educate you :)

I lost my work not because I saved it to JPEG but because of the idiot way that saving to XCF is enforced.

On 19/11/12 12:20, Alexandre Prokoudine wrote:

On Mon, Nov 19, 2012 at 3:17 PM, Karl Gnter Wnsch wrote:

On 19/11/12 11:50, Alexandre Prokoudine wrote:

http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links.

I'm citing from the above: "GIMP is user-configurable to automate repetitive tasks;" - why then is it ignored when numerous people

ask for

a way make the export behave and be automatied in a way that "the tools get out of the way of getting things done and allow for

accelerating the

workflow for those who get to know them"?

Because you understand this sentence arbitrarily while looking for

offences.

"Automating repetitive tasks" refers to scripting and future "macros

recording".
Still the unconditional enforcing to have to save to XCF violates the section "the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them" - It is very much getting into the way of getting things done and the only way of accelerating the workflow for "those who know" would be to add an option to disable the "everybody who doesn't save XCF all of the time is an idiot" mode! Thus on one hand you want the users to believe in the vision you put forward but on the other hand you violate it in a way to alienate those experienced users...

regards
Karl Gnter Wnsch

On 19 November 2012 11:50, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Mon, Nov 19, 2012 at 2:45 PM, Alberto Mardegan wrote:

Is it actually possible for a user to lose the layers when saving to JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which points the users would cancel the process if he really cares about them.

You seem to be under impression that people actually read text in prompts :)

In fairness, that also applies to the prompt that now reminds the user of exported-but-not-saved images.
A difference is perhaps that closing an image/application (which is when this prompt is shown) is expected to be potentially destructive (where as saving is not), so the prompt gets more attention.

Jon Nordby - www.jonnor.com

On 19 November 2012 12:11, Karl Günter Wünsch wrote:

Worse still, since most
of the time I am opening and preparing a preview image out of a previously created XCF via export - having the program prompt me to save to the original name resulted in overwritten valuable XCF with rubbish ones which only ever should exist in exported format! So basically because of your idiot proof mode prompted me to lose my time consuming work because it was overwritten with an inferior version from which I can not recover!

This is a real issue. It is caused mainly by GIMP not having a good way of creating/exporting multiple views of a document. It is further exacerbated by us not storing undo/redo history in the document. Both these are things to fix on the path to less/non-destructive workflows.

Jon Nordby - www.jonnor.com

On Mon, Nov 19, 2012 at 3:34 PM, Karl Gnter Wnsch wrote:

"Automating repetitive tasks" refers to scripting and future "macros recording".

Still the unconditional enforcing to have to save to XCF violates the section "the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them" - It is very much getting into the way of getting things done and the only way of accelerating the workflow for "those who know" would be to add an option to disable the "everybody who doesn't save XCF all of the time is an idiot" mode! Thus on one hand you want the users to believe in the vision you put forward but on the other hand you violate it in a way to alienate those experienced users...

Only _some_ of those experienced users, and, it seems, the most vocal ones. The ones who won't stop even when facing a lack of plans to adjust GIMP's behavior.

I think I already understand that you dismiss existence of other experienced users who like the change. Do you really need to remind about that over and over again?

One a more personal note, it's all right to exercise the freedom of speech, but do you think you could use a personal blog instead?

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Nov 19, 2012 at 3:37 PM, Jon Nordby wrote:

You seem to be under impression that people actually read text in prompts :)

In fairness, that also applies to the prompt that now reminds the user of exported-but-not-saved images.

True :) If you can think of cleaner way to notify the user about images that were only exported, speak up :)

Alexandre Prokoudine http://libregraphicsworld.org

On 19/11/12 12:45, Alexandre Prokoudine wrote:

I think I already understand that you dismiss existence of other experienced users who like the change.

I don't dismiss their existence, there are workflows that this change fits perfectly in, but you dismiss that there are users - very experienced users I might add - whose workflows at times conflicts with the change.

Do you really need to remind about that over and over again?

You on the other hand do seem to require a reminder that you are dismissing the existence of experienced users who don't like the change at all! It's not as if this topic comes up every now and then because everybody and his dog is happy! It's not as if you should completely revert the behavior, just adding a simple tiny option to make the export suffice in not triggering the "not saved" warning would make the whole issue disappear.
It's so annoying that you spend more time trying to dispute away the issue or even personally attack the people who bring up the issue rather than take a dispassionate look at the issue as something that can be resolved easily, just by allowing for a small option to be added... --
regards
Karl Gnter Wnsch

On Mon, Nov 19, 2012 at 4:09 PM, Karl Gnter Wnsch wrote:

On 19/11/12 12:45, Alexandre Prokoudine wrote:

I think I already understand that you dismiss existence of other experienced users who like the change.

I don't dismiss their existence

Then please stop generalizing.

You on the other hand do seem to require a reminder that you are dismissing the existence of experienced users who don't like the change at all!

We know. We said so. The only effect you are likely to achieve is that we get tired and stop replying.

It's so annoying that you spend more time trying to dispute away

Then stop giving us the reason for the dispute.

Switch to 2.6. Use no-xcf fork. Start your own fork. Do something constructive.

Alexandre Prokoudine http://libregraphicsworld.org

Hi Alexandre.

It looks to me you're one of the still most motivated developers to defend and explain the changes the developers made to Gimp 2.8, while Michael Natterer asked the debate to be over.. My deep respect for that. Far from me to throw gas where one needs water but I also feel, like you and other Gimp developers, probably, this discussion is likely to never end.

I'd just like to add my 2 again -- I haven't followed the whole discussion nor all the previous threads that relate to the topic, I'm sorry. However I have noticed what I think are a few inconsistencies that I would like to share.

First an example, fictional and stupid. Yet a plausible example.

-- Story 1 --

User: Gimp 2.6. I've saved my image as a JPG file. How do I recover my layers? Alexandre: It's impossible. You should save in XCF to save your layers along. User: Ah? Didn't know that. Thanks.

Morality: - the project lost its layers
- but the user learnt one of the differences between XCF and JPG

-- Story 2 --

User picks an image on the net, does changes. Wants to save, presses Ctrl+S then sends the XCF file to his friend.

Friend: I can't open your file! Can't you simply send me a JPG? User: Uh...? Sure, I will send you a JPG.

** Tries to find how to save as JPG ***

Variant 1: figures the export menu on his own. (Eventually ranting.)

Variant 2: asks another friend or Gimp forums or Gimp users list. Gets the answer: the Export menu.

User: Exports as JPG, deletes the XCF (useless anyway).

** Later **

User A: Gimp 2.8. I've saved my image as a JPG file. How do I recover my layers? Alexandre: It's impossible. You should save in XCF to save your layers along. User: Ah? Didn't know that. Thanks.

Morality: - one project lost its layers
- but the user learnt one of the differences between XCF and JPG

My deductions:

- Did the new "Save" workflows help? No. - Does the new "Save" menu workflow help learning the differences between XCF and JPG? No. - Did Gimp behave as expected? Yes.
- Did the developers put every effort in making Gimp a lossless imaging application? Yes. - Did the user miss anything? Yes.
- Did the developers miss anything? Yes.

You *will* run into such a life use-case. Will probably take time but you will.

If you want your users to make the difference between destructive and non-destructive file formats, why not just teach them directly so? Changing the UI won't for sure and it's not the prime requirement (the UI serves driving the softare, not teaching purposes). What changing the UI will do is raise questions, not necessarily the most appropriate ones.

Now.

Gimp is said to be a high-end [imaging] application. On the other hand there are people who don't read messages when prompted.

But [the developers of] a high-end application need to make at least a few assumptions. If one of these assumptions is users have to understand the differences between destructive [JPG] and non-destructive [XCF] then it is acceptable to me and to other people who have posted here, correct me if I'm wrong, guys.

I'm not saying Photoshop is right or wrong. It's just a different approach, similar to what Gimp 2.6 did. In PS there is Save and Save As... and also an Export function. Optionally there is a Save for the web option. There are hence less Save paths.

If you open a layer-less file, make changes but don't add a layer and then save the file, it's saved keeping the initial format, destroying quality even more, as expected. If you make changes and add one or more layers and save, PS suggests to save as a PSD. In both cases the internal structure is PS native. And Photoshop is also a high-end application used by many professionals. But you know that.

As a Gimp user, from what I have read so far, I have the impression you guys (developers) have wanted to conciliate two opposite goals: professional (high-end) imaging application and ready-for-everyone (or *any*one). It's only an impression so I could be wrong.

But there's at least two facts:

1 - there are too many paths to save an image to the user's perspective 2 - the new file > save menu workflow won't help people understand the implications between file formats.

If the reason was people need to make the difference between destructive and non-destructive then explaining that difference is always possible without a change in the UI: just *tell* them.

Now if people don't read the prompts...

-- Story 3 --

Dummy: but I wasn't told my cat would die if I put him in the microwave oven! Whirlpool: make manuals and disclaimers!

** Later **

Dummy: but I wasn't told my cat would die if I put him in the microwave oven! Whirlpool: didn't you read the manuals and disclaimers? Dummy: what the...? Ma...?
Whirlpool: make ovens smaller.

(repeat with decreasing in size: chiuahua, guinea pig, mouse...)

** Later **

Cook: how come can't I put a cake in my microwave oven? It's too small and there's no bigger device! Whirlpool: ...

Morality:
- pet dead. dummy unhappy.
- oven too small. cook unhappy.

Some people must learn the hard way.

Cheers, Vince C.

Alberto Mardegan (mardy@users.sourceforge.net) wrote:

Is it actually possible for a user to lose the layers when saving to JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which points the users would cancel the process if he really cares about them. Or do you have reports when this did not occur for some reasons?

* User creates a multi-layered image * User saves to JPG, gets prompted for flattening * User either does not understand about layers or flattening or does understand it, but really just wants the JPEG file for sharing. * JPEG file gets saved
* Gimp 2.6 marks the image as saved.

Layer information lost.

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Mon, 19 Nov 2012 14:44:12 +0100, Simon Budig wrote:

Alberto Mardegan (mardy@users.sourceforge.net) wrote:

Is it actually possible for a user to lose the layers when saving to JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which points the users would cancel the process if he really cares about them. Or do you have reports when this did not occur for some reasons?

* User creates a multi-layered image * User saves to JPG, gets prompted for flattening * User either does not understand about layers or flattening or does understand it, but really just wants the JPEG file for sharing. * JPEG file gets saved
* Gimp 2.6 marks the image as saved.

Layer information lost.

Fine. But after this happens once or twice, users will understand what's going on. It really isn't necessary for everyone to be inconvenienced, with no way out, just to protect inexperienced users.

(And yes, I have read the vision document. I understand the save vs. export issue -- or at least, I believe I do -- but it is not at all apparent to me why users must be forcibly restrained in this manner. And if you're really targeting professional users, they're going to understand the layers issue, no?)

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Mon, 19 Nov 2012 15:45:24 +0400, Alexandre Prokoudine wrote:

On Mon, Nov 19, 2012 at 3:34 PM, Karl Günter Wünsch wrote:

"Automating repetitive tasks" refers to scripting and future "macros recording".

Still the unconditional enforcing to have to save to XCF violates the section "the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them" - It is very much getting into the way of getting things done and the only way of accelerating the workflow for "those who know" would be to add an option to disable the "everybody who doesn't save XCF all of the time is an idiot" mode! Thus on one hand you want the users to believe in the vision you put forward but on the other hand you violate it in a way to alienate those experienced users...

Only _some_ of those experienced users, and, it seems, the most vocal ones. The ones who won't stop even when facing a lack of plans to adjust GIMP's behavior.

I think I already understand that you dismiss existence of other experienced users who like the change. Do you really need to remind about that over and over again?

*No one's dismissing the existence of other users who like the change.* We're simply saying that some like it and some utterly detest it. Different people, and it's *not* experienced vs. inexperienced users (people like Graeme are *very* experienced), have different ideas about how they like to work, and have reasons why. Do you understand that?

It's analogous to click to focus vs. mouse follows focus. Some people like one, some like the other. One's not "right" and the other's not "wrong", whichever side you come down on. That's why both GNOME and KDE have options to let the user select focus policy.

And yes, I know you've said interminably that you have no plans to change it. But the amount of heat this has generated ever since GIMP 2.8 came out should suggest to you that perhaps your initial assumptions were incomplete and should be revisited.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Mon, 19 Nov 2012 15:30:38 +0400, Alexandre Prokoudine wrote:

On Mon, Nov 19, 2012 at 3:28 PM, Alberto Mardegan wrote:

Reformulating: is it possible for a user *who reads and understands all question dialogs which appear to him/her*, to actually lose the layers when saving to JPEG with gimp 2.6?

Yes.

If yes, how?

By being overly confident and not forward-thinking.

And guess what? I've done that on occasion myself. But I don't blame my tool for that. What's more, the GIMP 2.8 solution wouldn't have prevented this, because I'd have done exactly the same thing anyway (that's the "overly confident and not forward-thinking" bit), just with a bit more inconvenience and grumbling on my part. Because my intent *at the time* was to just write out the JPEG or PNG without worrying about the layers.

I repeat: *the new GIMP 2.8 behavior would not have prevented me from making this mistake, because the "mistake" was in fact my intention at the time, and it was only because I wasn't thinking forward in the specific case that it happened*. This was when I was well aware of layers and XCF files, so it wasn't ignorance -- it was that I didn't expect to need the layer information again.

As it happens, nothing drastic happened as a result. I just had to repeat some work on another copy of the original, to my (minor) annoyance. But at least 99% of the time, when I want to save an image as a JPEG, I have no regrets later. I don't want to pay the price in workflow efficiency for that 1% or less where I'm mistaken.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Mon, 19 Nov 2012 15:29:25 +0400, Alexandre Prokoudine wrote:

On Mon, Nov 19, 2012 at 3:07 PM, Alberto Mardegan wrote:

There must be a reason why one group of people keeps linking to http://gui.gimp.org/index.php/Save_%2B_export_specification and http://gui.gimp.org/index.php/Vision_briefing, and another group of people carefully ignores these links.

I swear I read them and I think that I understood the rationale. But that's note the same thing as saying that I understand what was wrong with the save functionality in 2.6 (because I still don't).

It's simple.

Primary workflow = creating original art from scratch, complex editing where preserving extras is a must. That's the workflow when you work iteratively. This workflow makes it easy to share your work in a delivery file format (e.g. exporting to a public Dropbox folder), while refining the actual project file. 2.6 didn't make it easy.

OK, fine. That's a fully persuasive argument for the *ability* to separate export from save. I understand that part of your case, and it makes perfect sense.

Secondary workflow = overwriting original files. 2.6 made it easier, but it's not the primary workflow, and there are well-known workarounds.

What it is *not*, however, is an argument for making it impossible *not* to separate export from save -- particularly for the special case where you're saving back to the original file, and the slightly more general case where you're saving back to a different filename in the same format.

Is it actually possible for a user to lose the layers when saving to JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which points the users would cancel the process if he really cares about them.

You seem to be under impression that people actually read text in prompts :)

Maybe many don't, but at least they can't blame you for that, can they? :-) I mean, you can get burnt by this issue once, indeed.

Not once, not even by a long shot. People tend to relax and become overly confident.

And as I noted before, the GIMP 2.8 behavior does not protect against the kind of overconfidence where you think you're just not going to need the layer information in the future. You've made a conscious choice at that point not to save it.

and in any case you can't blame the gimp developers if you didn't read a questions which appeared while saving your extremely important file. :-)

Our job is not to point fingers and accuse. Our job is to create software for a certain target group of users described above.

Or do you have reports when this did not occur for some reasons?

https://mail.gnome.org/archives/gimp-user-list/2012-November/msg00190.html

It seems that it happened with 2.8

Does it? What makes you think so?

https://mail.gnome.org/archives/gimp-user-list/2012-November/msg00193.html

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Robert Krawitz (rlk@alum.mit.edu) wrote:

On Mon, 19 Nov 2012 14:44:12 +0100, Simon Budig wrote:

[...]

Layer information lost.

(Note that this was just a specific scenario to answer Albertos Question if there is a workflow that actually loses data. Not intended as a new argument or anything)

Fine. But after this happens once or twice, users will understand what's going on. It really isn't necessary for everyone to be inconvenienced, with no way out, just to protect inexperienced users.

That the "saved" flag gets set after an export to JPEG is just wrong. It has bitten users regardless of their experience. Even worse: Even typing a filename ending in ".xcf" doesn't guraantee that a xcf actually gets saved: you could have selected the jpeg filetype manually in the drop down box manually.

True, this is a contrieved example, but the whole point is, that it is not easy to tell at any given time, if an image currently is saved "safely" or "unsafely". Sure, people with good memorizing capabilities can track the state, but they shouldn't have to.

Bye, Simon

simon@budig.de              http://simon.budig.de/

Von: Robert Krawitz

And as I noted before, the GIMP 2.8 behavior does not protect against the kind of overconfidence where you think you're just not going to need the layer information in the future. You've made a conscious choice at that point not to save it.

This may change in future versions - where maybe you won't even have the choice not to save, because saving has become so cheap that it can be done any time, and the program just does it for you.

The 2.8 changes are a step in that direction.

On Mon, 19 Nov 2012 15:33:06 +0100, Simon Budig wrote:

Robert Krawitz (rlk@alum.mit.edu) wrote:

On Mon, 19 Nov 2012 14:44:12 +0100, Simon Budig wrote:

[...]

Layer information lost.

(Note that this was just a specific scenario to answer Albertos Question if there is a workflow that actually loses data. Not intended as a new argument or anything)

Fine. But after this happens once or twice, users will understand what's going on. It really isn't necessary for everyone to be inconvenienced, with no way out, just to protect inexperienced users.

That the "saved" flag gets set after an export to JPEG is just wrong. It has bitten users regardless of their experience. Even worse: Even typing a filename ending in ".xcf" doesn't guraantee that a xcf actually gets saved: you could have selected the jpeg filetype manually in the drop down box manually.

If a JPEG was opened, edited, and saved via file/save (rather than file/save as), particularly if no layers have been added, I think it's a reasonable assumption that that was the user's intention. If not, there could be a checkbox "Warn me next time" that the user could uncheck. Firefox does this when you try to close a window with a lot of tabs open; if you uncheck the box, you don't get the warning next time. But in that case you've made a conscious decision to ignore the warning.

Note that this doesn't apply if you've actually opened an XCF file, or have ever in the session saved the file as an XCF file. In that case, I think you have a completely valid point.

True, this is a contrieved example, but the whole point is, that it is not easy to tell at any given time, if an image currently is saved "safely" or "unsafely". Sure, people with good memorizing capabilities can track the state, but they shouldn't have to.

Perhaps it was never their intention to *ever* have an XCF file.

By the way, I suggest reading up on "alarm fatigue". This is a problem in hospitals, where there are lots of monitors designed to detect changes in a patient's condition and sound an alarm. This happens so much that staff often ignore alarms just because they simply cannot process them all. It isn't even necessarily conscious; it's just that after a while the alarms become so repetitive that they get ignored.

I suggest that the 2.8 behavior may inadvertently have the same result: you get so many "unsaved file" dialogs thrown in your way to save a file as a JPEG and never save as an XCF that you inadvertently forget to save an *actual* open .XCF file (as opposed to 10 JPEGs you've been editing that you never intended to save as an XCF in the first place).

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On 19 November 2012 15:21, Robert Krawitz wrote:

On Mon, 19 Nov 2012 15:30:38 +0400, Alexandre Prokoudine wrote:

On Mon, Nov 19, 2012 at 3:28 PM, Alberto Mardegan wrote:

Reformulating: is it possible for a user *who reads and understands all question dialogs which appear to him/her*, to actually lose the layers when saving to JPEG with gimp 2.6?

Yes.

If yes, how?

By being overly confident and not forward-thinking.

And guess what? I've done that on occasion myself. But I don't blame my tool for that.

I blame the tool for that, even if this is the status quo in most of todays desktop applications. Software tools should take into account and be able to compensate for our sometimes flawed behaviour.

In a future fairytale non-destructive world that we are moving towards, it could perhaps work something like this:

* All actions the user does to a document inside GIMP is automatically stored.
* "Save As" would become an *optional* action, allowing to chose where the document is stored.
* "Save" would be come an *optional* action that allows to describe that particular state of the document, so that particular revisions are easy to find.
* Export would work like now.

In this model, if you you opened a JPEG file, added some layers, did some processing and then exported to another JPEG and quit GIMP - nothing would be lost[1].
All the actions of the document would be stored. The document would appear in
"Recently used Documents" or similar. Exactly like a document that you have explicitly saved.

Such a work-flow would mean that the user is not required to be forward thinking in order to preserve his work. He or she can focus 100% on the task at hand (here, creating a derivate JPEG file from an original JPEG image), without having to actively keep in mind to not make destructive actions.

1. Tthere would of course be no prompt in this case. Alexandre: this is my proposal for the better image-exported-but-not-saved prompt. Make it obsolete.

Jon Nordby - www.jonnor.com

On Mon, Nov 19, 2012 at 7:01 PM, Jon Nordby wrote:

1. Tthere would of course be no prompt in this case. Alexandre: this is my proposal for the better image-exported-but-not-saved prompt. Make it obsolete.

It's a noble goal :)

Alexandre Prokoudine http://libregraphicsworld.org

I know I shouldn't comment on this thread, but I think everyone is missing an important point.

If you simply open a jpeg, and then save it as a jpeg without modification, you will lose data. Jpeg is always lossy. More compression artifacts will be introduced in the saved image. There is no sane way to avoid this behavior.

If you allow the user to save back to jpeg, then you will not "honour the quality/file size trade-off" because the user will be slowly destroying their image every time they save and re-open.

We're not saying that you can't slowly destroy your image - you still have the freedom to do that. We just want you to click a single button that says, "yes, I want to destroy my image", if you really do like destroying images.

I don't think that's too much for us to ask of the user. I don't think that clicking a single button is something to get worked up about.

I'm going to stop reading this thread now, so don't bother to reply to me.

-- drawoc

On Sun, Nov 18, 2012 at 11:29 PM, Graeme Gill wrote:

Simon Budig wrote:

We cannot just make the assumption that "oh, its a JPEG. *clearly* the user wants us to discard information on saving".

You really think they want you to save a lot of invented bits and blow their file up in size with all that false data ?

They want you to save the same visible information, without any obvious further degradation. That's easily achieved by saving in a lossless format, but not very clever, and doesn't honour the quality/file size trade-off they've already agreed to and want, since they are saving back to the lossy file format they opened.

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

drawoc wrote:

If you simply open a jpeg, and then save it as a jpeg without modification, you will lose data. Jpeg is always lossy. More compression artifacts will be introduced in the saved image. There is no sane way to avoid this behavior.

Technically that's true (but see below), but have you actually seen this ? Given a certain moderate compression ratio, how many open/slight edit/save cycles does it take before you can visually notice that the quality is worse than what you started with ? 2 ? 5 ? 10 ?

If you allow the user to save back to jpeg, then you will not "honour the quality/file size trade-off" because the user will be slowly destroying their image every time they save and re-open.

It turns out that (typically) open/save of a jpeg does not cause a steady decrease in quality, instead it asymptotes to a steady state. That's because once DCT coefficients have been quantised, they tend to get re-quantised to the same values. There is no question that a lossily compressed format is not what you want to use to create original artwork or do high quality editing or re-purposing, but I think I can be confident that the vast majority of image use is casual and non critical and in the jpeg format - all those billions of digital photo's taken every day by ordinary people.

We're not saying that you can't slowly destroy your image - you still have the freedom to do that. We just want you to click a single button that says, "yes, I want to destroy my image", if you really do like destroying images.

But you're saving to a lossy compressed file format - by doing that you have made that choice. Having a nag telling you all the time that "you do realise that jpeg is lossy, don't you?" seems fairly pointless.

Graeme Gill.

Am 19.11.2012 12:48, schrieb Alexandre Prokoudine:

True :) If you can think of cleaner way to notify the user about images that were only exported, speak up :)

Hello,

I really tried to stay out of this thread until now, but this is a subtopic I'm quite interested in.

I'd recommend a two-step approach: 1. Introduce an export-icon in the file-menu. This will help newcomers to easily find the export-option since options without icons are often dismissed as unimportant or seldom-used. One might argue that it just adds visual clutter, but to be honest: that war has been lost long ago, at least in that particular menu. Looking at other applications (openOffice, inkscape) the blank sheet ("New ...") with an arrow to the right might be a good choice for this.

2. When closing, reuse the save- and export-icons paired with checkmark and cross to indicate whether a image has been saved and/or exported (naturally, save will always say no, but it's good to show it anyway so that the user will understand why the prompt pops up). If possible, one could even add the dates of the last save and export so that the user can compare these. People might not read the text in prompts, but it's pretty hard not to see a huge, iconic image right in front of you. In case this should not be formulated clearly, here is a very quick, very dirty sketch of the concept:
http://tobl.deviantart.com/art/exported-but-not-saved-prompt-338649284

Personally, I've never really understood why GIMP doesn't use more graphical elements in its UI (yes, I know, GIMP already uses quite a bit, but given that it's a program for photo-manipulation, we can assume that most of it's users are inclined towards visual information as opposed to textual). They seem to be quite busy at the moment, but it'd sure be nice to hear about this from someone on the UI-team.

Also, I unfortunately am not enough of a programmer to implement this myself. However, should you decide to implement it, I would, of course, be willing to provide the assets.

bw, Tobias Lunte//Tobl

Tobias Lunte (tobias.lunte@hfg-gmuend.de) wrote:

Personally, I've never really understood why GIMP doesn't use more graphical elements in its UI (yes, I know, GIMP already uses quite a bit, but given that it's a program for photo-manipulation, we can assume that most of it's users are inclined towards visual information as opposed to textual).

In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past, I wouldn't be surprised if too much icon clutter would impact the usability badly.

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Mon, 19 Nov 2012 15:35:59 +0100, Michael Schumacher wrote:

Von: Robert Krawitz
And as I noted before, the GIMP 2.8 behavior does not protect against the kind of overconfidence where you think you're just not going to need the layer information in the future. You've made a conscious choice at that point not to save it.

This may change in future versions - where maybe you won't even have the choice not to save, because saving has become so cheap that it can be done any time, and the program just does it for you.

This can become really annoying, really fast...

Applications that helpfully save their constantly can cause a lot of grief if I change something I really, really didn't want to change that causes something very strange to happen. Yes, I know about the undo stack and all that, but...

Hopefully, it will be something like an incremental (journaling) save with periodic compaction/resave, so that if something goes wrong all I have to do is roll back the journal.

There's also the problem that this will quickly consume a lot of disk space. Again, I'm well aware that disk space is cheap, but when you're editing 100 megapixel panoramas (which I do quite a bit of), it can chew up disk space in a hurry.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Em 19-11-2012 19:46, Graeme Gill escreveu:

drawoc wrote:

If you simply open a jpeg, and then save it as a jpeg without modification, you will lose data. Jpeg is always lossy. More compression artifacts will be introduced in the saved image. There is no sane way to avoid this behavior.

Technically that's true (but see below), but have you actually seen this ? Given a certain moderate compression ratio, how many open/slight edit/save cycles does it take before you can visually notice that the quality is worse than what you started with ? 2 ? 5 ? 10 ?

If you allow the user to save back to jpeg, then you will not "honour the quality/file size trade-off" because the user will be slowly destroying their image every time they save and re-open.

It turns out that (typically) open/save of a jpeg does not cause a steady decrease in quality, instead it asymptotes to a steady state. That's because once DCT coefficients have been quantised, they tend to get re-quantised to the same values. There is no question that a lossily compressed format is not what you want to use to create original artwork or do high quality editing or re-purposing, but I think I can be confident that the vast majority of image use is casual and non critical and in the jpeg format - all those billions of digital photo's taken every day by ordinary people.

We're not saying that you can't slowly destroy your image - you still have the freedom to do that. We just want you to click a single button that says, "yes, I want to destroy my image", if you really do like destroying images.

But you're saving to a lossy compressed file format - by doing that you have made that choice. Having a nag telling you all the time that "you do realise that jpeg is lossy, don't you?" seems fairly pointless.

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

Well, I have a couple of opinions of my own for why I liked the new workflow.

Supose you are using Blender. Blender is a 3d modeller. 3d files aren't image files, so the default save is for a 3d Blender file. While you have a lot of ways for exporting it - you can render and export an image, or even export to a 3d file format different than the native Blender one. Basically, this is the same for Gimp - XCF files are not regular image files, they're Gimp files. So, like in Blender, you save the program's data on a program's file, while the export generates files that are for viewing or interchanging. If you create a Blender file, export an image and try to close it, you will receive an alert message (ok, /bad/ example. Blender by default /don't/ ever asks if you really want to close the program before saving. But that feature is already implemented for windows and there's progress to another platforms too. I think that not asking is really really bad... the default behavior *should* be asking, even with the auto-save I think. You got the point, I guess :P). So I was already familiarized with this way of doing things when the change came.

I guess Inkscape have this same behavior (and would be a very better example, because it do ask before closing :P).

Also, I nearly always save a file that I edited, even if it's for small changes. I usually keep the .xcf and the export image in the same folder. It's like a posture, an attitude. I don't rely on myself on doing things right every time, because I am a human being. So I prefer to choose the caution way, and I think this is the most secure workflow.

Of course, not everyone have to work the way I do, or plan things the same way I do... But if a software would have to choose for the default way of action, it should be the way with more caution.

So, for advanced users, why wouldn't it be possible to just making Gimp stop asking if you want to save an exported image? Well, if you think about the /Blender/ and /Inkscape/ case, the answer would be obvious - if you exported an image, you didn't saved the blender/svg/xcf file. So having that option native in the software would be a conceptual mistake by the developers. It cannot be there while Gimp makes that file differentiation.

So, if the message box is **really** getting in the way of your workflow, you can uncheck the "/Confirm closing of unsaved images/" box in the Environment preferences. When you change to an important .xcf file, you check it back again. It's a little confusing I guess, but at least it would let you export files without being annoyed - I am suposing that you and the users that like the 2.6 behavior do a lot of quick edits instead of spending reasonable amounts of time editing the images. I might be wrong.

So, for closing my arguments, I think it would not be hard to do a *script* that checks and unchecks that save confirmation preference for you when you open a .xcf file and a common image file. That would solve the problem AND be conceptually correct, at least in my humble point of view (I might be wrong with the "easy to do script" part :P ). BUT it cannot be native to the software, that is conceptually incorrect - at least in my way of seeing things.

Well, I made my attempt in providing a solution... Hope that helped in some way :)

Regards to all,

-- Thiago

On Tue, Nov 20, 2012 at 12:13:35AM +0100, Simon Budig wrote:

Tobias Lunte (tobias.lunte@hfg-gmuend.de) wrote: In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past, I wouldn't be surprised if too much icon clutter would impact the usability badly.

Yes, definitely. This is important.

Matthew Miller           mattdm@mattdm.org          

On Mon, 19 Nov 2012 23:07:35 -0200, wanderer wrote:

Well, I have a couple of opinions of my own for why I liked the new workflow.
...
I guess Inkscape have this same behavior (and would be a very better example, because it do ask before closing :P).

Also, I nearly always save a file that I edited, even if it's for small changes. I usually keep the .xcf and the export image in the same folder. It's like a posture, an attitude. I don't rely on myself on doing things right every time, because I am a human being. So I prefer to choose the caution way, and I think this is the most secure workflow.

There's nothing wrong with that. It's a perfectly good workflow. It's just not the one I (and apparently many other people) always want to use.

My own safety mechanism is to simply never edit originals. I always export a copy out of kphotoalbum before editing it in any way (even EXIF rotating it). In fact, I keep files within my image tree read only, so the OS protects me. That, in fact, is one reason I like kphotoalbum: it does not, under any circumstances, modify the file under management in any way. And with big projects (like panoramas or other images I care about), I almost always edit .xcf files. But for smaller things, or throwaways that I'm just going to email someone or stuff on a web site, it simply isn't worth the bother. I know full well that editing a JPEG file is the Wrong Thing To Do, but again, the loss of quality simply doesn't matter in that case. Says me, and I'm the one doing it, so I'm right by definition :-) If someone then wants to take that JPEG, jack up the contrast something ridiculous, and observe artifacts, tough on them.

Of course, not everyone have to work the way I do, or plan things the same way I do... But if a software would have to choose for the default way of action, it should be the way with more caution.

I have no problem with that as a *default*. The problem is having no way to turn it off.

So, for advanced users, why wouldn't it be possible to just making Gimp stop asking if you want to save an exported image? Well, if you think about the /Blender/ and /Inkscape/ case, the answer would be obvious - if you exported an image, you didn't saved the blender/svg/xcf file. So having that option native in the software would be a conceptual mistake by the developers. It cannot be there while Gimp makes that file differentiation.

And here's where we part company. Software, like any tool, is used by people, and putting architectural purity above usability is missing the point.

So, if the message box is **really** getting in the way of your workflow, you can uncheck the "/Confirm closing of unsaved images/" box in the Environment preferences. When you change to an important .xcf file, you check it back again. It's a little confusing I guess, but at least it would let you export files without being annoyed - I am suposing that you and the users that like the 2.6 behavior do a lot of quick edits instead of spending reasonable amounts of time editing the images. I might be wrong.

EEEK!!!!

Earlier today, I posted a comment about "alarm fatigue". This is a serious problem in hospitals, where there are so many alarms that are set to such a high sensitivity that medical staff often shut them off when they "know" that there isn't really a problem. Unfortunately, it leads to a good number of patient deaths: http://www.imsbundle.com/Blog/index.php/03/alarm-fatigue-blamed-in-hospital-deaths/wireless-communications

What you're proposing here is exactly that -- disable a useful alarm and rely on the user to then re-enable it when it matters. One thing is, though, it's very easy to forget to re-enable it.

If you decide that it's too dangerous to shut off confirmation of closing unsaved images -- and that's a pretty dangerous thing to do -- you open yourself up to another data loss situation. If your workflow is to edit JPEG files and re-export them, you'll get a warning message when you don't save to an XCF file. The problem is that it doesn't tell you whether you've actually exported to the JPEG file or not. If you thought you did, and you didn't, then again you've just lost your work.

And there's another danger scenario, if you do things the way the GIMP developers intend, and always save to an XCF file. Suppose you forget to export back to the JPEG file (overwriting the previous version). I don't think GIMP warns you that you haven't exported it; there's no reason that it should, since you may well not want to export the file until you've done editing it. Now, let's suppose the edit that you did is to crop something out that you really, really didn't want to be in there (like your credit card, with the number visible), and you post that to the net. Oops...

My point here is that a feature that was devised with the good intention of preventing data loss has multiple scenarios where the feature itself, in conjunction with common working habits, results in either data loss or unintended data disclosure. And don't say people should always be careful about what they do -- they aren't, which is exactly why this feature was devised, and the phenomenon of alarm fatigue is very real.

I sometimes do quick edits and sometimes spend a lot of time editing an image ("reasonable" is in the eye of the beholder -- some people prefer to process lots of images, some people prefer to craft a single image with the utmost of care, and some people sometimes do both). For the latter, the new behavior is good, but for doing quick edits, it's very, very frustrating.

So, for closing my arguments, I think it would not be hard to do a *script* that checks and unchecks that save confirmation preference for you when you open a .xcf file and a common image file. That would solve the problem AND be conceptually correct, at least in my humble point of view (I might be wrong with the "easy to do script" part :P ). BUT it cannot be native to the software, that is conceptually incorrect - at least in my way of seeing things.

NO! NO! A THOUSAND TIMES, NO!!!!

Apologies for the shouting, but this is absolutely *NOT* the way to do things! It's a great way to lose data, since you may have both .xcf files and JPEG files open in the same session, and you *don't* want to change that kind of a global preference for this purpose! The decision about save vs. export is a decision about an individual image, although many people may prefer to work one way or the other most or even all of the time.

My suggestion, for what it's worth, is as follows:

By default, GIMP uses the 2.8 behavior. However, an option is provided such that if the user opens a non-XCF file, edits it, and saves it back to another non-XCF format (lossy or lossless), no alarm is triggered (unless the image contains something that the format can't handle, such as layers, as 2.6 does).

If an XCF file is opened, or an image is saved as an XCF file, then GIMP changes to the 2.8 behavior for that image for the duration of the session (it's meaningless to talk about it across sessions -- if you've saved it as an XCF file, exit, and edit the XCF file in a new session, it's an XCF file). No escape mechanism for that. By editing an XCF file, the user has clearly stated the desire to work that file in the native GIMP format, and conversion to any other format is then clearly an export.

As far as lossless vs. lossy image formats, though, there's a much bigger problem than the slow decay of lossy formats (and that decay is pretty slow if you're starting from a 98 quality setting): 8-bit quantization. If you're doing curve manipulations, that often bits hard right from the get-go. Botching a curve edit is the most common reason to have to start over from scratch for me if I've lost the undo. Even if I haven't done that, it still causes severe quantization in a lot of cases. If the GIMP folks are worried about data loss, I suggest getting high bit depth working ASAP.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Am 20.11.2012 00:13, schrieb Simon Budig:

In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past, I wouldn't be surprised if too much icon clutter would impact the usability badly. Bye, Simon

Yes, I understand that distraction should be avoided. However, there are many great ways to design non-distracting graphical UIs. A grayscale icon theme could be one part of such an interface, further alterations can tone down distractions while increasing usability by using more graphical elements, not less.

To get back to the original case: the prompt pops up when the artist tries to close an unsaved image. He has therefore already decided to end his work on the image, what flow is there left to disrupt? concerning the icon clutter: The file menu is actually so full of icons already that the lack of icons in the export-section is a stronger disruption than the presence of icons in the other sections is. I'd assume the effect is related to the "rivers of white" one can get when using the "filled" text-alignment.

Nonetheless, thanks a lot everyone for your great work, GIMP most certainly has come a long way because of you.

bw, Tobl

I understand the worry about losing work, but the change has almost caused me to lose work, here's how:

1) I open an XCF file I've been working on and make some changes. 2) Before I'm finished, I'm distracted with another task: I have to crop/resize a bunch of images.
3) I export each of those images, since I can't just "Save As". 4) I publish all those images. While publishing, I leave the images open in Gimp, so I have the undo history in case of a last-minute emergency. 5) Satisfied, I quit Gimp. Of course, it tells me I have a whole bunch of images that are unsaved, but I'm expecting that, because those images were merely exported, not saved. Lost in that big list of files is the original XCF file I forgot I was working on.

Luckily I wasn't in a hurry, and I decided to carefully close the windows one by one, just in case.

A naive fix for this particular problem would be to split the lists in the quit warning into two separate lists: files that haven't been saved, and files that have been neither saved nor exported.

But that's treating the symptom rather than the disease. To be honest, I *really* like the separation of saving and exporting, and I applaud the Gimp devs for implementing it. It's a powerful idiom for those who understand it.

I also understand that the Gimp devs are worried that (a) this idiom is alien to a lot of users, and (b) it's easy to accidentally save instead of export. Those are valid concerns.

But idiomatically, I really did want to "Save As" above. It's a way of explicitly stating "This is the official file. I don't want you to warn me when I close this."

Now, elsewhere in this thread an idea was floated that perhaps future versions of Gimp could transparently save XCF versions of files that haven't been saved as such.

I really like this idea. You could "undo close" a file, and even do that in a persistent way. Now *that* would be powerful, because as useful as it is to sway users away from making mistakes, being able to undo mistakes is always better.

And if this was implemented, there would be no danger in letting the user save to whatever format they want, unlocking the full potential of the save/export idiom.

Em 20/11/2012 00:02, Robert Krawitz escreveu:

It's a great way to lose data, since you may have both .xcf files and JPEG files open in the same session, and you*don't* want to change that kind of a global preference for this purpose!

Well, at least theoretically you could make an add-on or something that didn't change this option globally, but instead did it locally over the files you're working on - so if you open a .jpg and a .xcf file, it would warn for saving a .xcf but not the .jpg.

As it concerns the alarm in the .jpg file, I agree that working without any warning is pretty dangerous. This add-on or script could include a warning if you try to close a .jpg before exporting after any changes in the file. And if the file was saved to .xcf, it would go back to the default behavior. That way it would solve this issue, but I don't know if a script or add-on like that is possible to be made.

And here's where we part company. Software, like any tool, is used by people, and putting architectural purity above usability is missing the point.

Well, I think it's more than merely architectural purity. Like I said, it make no sense for an inkscape file to be marked as saved if an image is exported, it's kind of logical to me... I think it is a good thing for the user, too - that don't get file formats mixed up. But I can be mind-imprisoned by the way I am used to do things. Still, this is the development decision of the Gimp team, this is the way they are doing thing in this version - I don't believe that anything in this world is unchangeable, and they might change their minds if someone realizes that that is a big issue.

In short, I still think that an add-on is the way to go with this issue.

Hope I am not being disrespectful in any way, I am just exposing my opinion. :)

Regards,
--
Thiago

A naive fix for this particular problem would be to split the lists in the quit
warning into two separate lists: files that haven't been saved, and files that
have been neither saved nor exported.

Or, maybe even better, there could be a warning dialog with a list of preview snapshots of the unsaved images, possibly each with a list of options like "Examine image" and "Ignore this image" and whatever seems sensible (saving without closely examining the current state does not seem sensible to me, btw.).

Cheers, Daniel

On Tue, Nov 20, 2012 at 3:13 AM, Simon Budig wrote:

In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past

And it's in the works.

Alexandre Prokoudine http://libregraphicsworld.org

Just pointing this out again - in the future vision, that we are approaching step by step, the export operation with it's tasks, like scale etc should not require you creating a new image for this process... It would just be a view on top of the existing xcf project - very much like a target complation is in IDE-s. But this future can not happen in one single release. It will come iteratvely. This separation is just one step on a long way. First mandatory step...

On Tue, Nov 20, 2012 at 5:02 AM, Robert Krawitz wrote:

This may change in future versions - where maybe you won't even have the choice not to save, because saving has become so cheap that it can be done any time, and the program just does it for you.

This can become really annoying, really fast...

Applications that helpfully save their constantly can cause a lot of grief if I change something I really, really didn't want to change that causes something very strange to happen. Yes, I know about the undo stack and all that, but...

Are you familiar with the concept of saving history stack into project files?

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, 20 Nov 2012 12:24:59 +0200, Alexia Death wrote:

Just pointing this out again - in the future vision, that we are approaching step by step, the export operation with it's tasks, like scale etc should not require you creating a new image for this process... It would just be a view on top of the existing xcf project - very much like a target complation is in IDE-s. But this future can not happen in one single release. It will come iteratvely. This separation is just one step on a long way. First mandatory step...

"Existing XCF project".

Here's the thing: not every image I want to edit is something I think of as a "project". Sometimes it's just a "bug fix" or minor enhancement (such as crop/unsharp mask/rescale). I'm starting from a JPEG file and ending up with one, and have no practical reason to ever have an XCF file since I'm pretty confident I'm not going to be making a lot of further changes.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Tue, 20 Nov 2012 11:15:19 +0100, Daniel Hornung wrote:

A naive fix for this particular problem would be to split the lists in the quit warning into two separate lists: files that haven't been saved, and files that have been neither saved nor exported.

Or, maybe even better, there could be a warning dialog with a list of preview snapshots of the unsaved images, possibly each with a list of options like "Examine image" and "Ignore this image" and whatever seems sensible (saving without closely examining the current state does not seem sensible to me, btw.).

Think about how this scales up to 20-100 images (and yes, it's not uncommon for me to have this many open).

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

On Tue, 20 Nov 2012 14:42:05 +0400, Alexandre Prokoudine wrote:

On Tue, Nov 20, 2012 at 5:02 AM, Robert Krawitz wrote:

This may change in future versions - where maybe you won't even have the choice not to save, because saving has become so cheap that it can be done any time, and the program just does it for you.

This can become really annoying, really fast...

Applications that helpfully save their constantly can cause a lot of grief if I change something I really, really didn't want to change that causes something very strange to happen. Yes, I know about the undo stack and all that, but...

Are you familiar with the concept of saving history stack into project files?

I presume you mean appending journal entries to the file? Yes, and that's a lot safer than other ways of doing it. But make sure that you handle situations of high latency (NFS/Samba) and low disk space well.

Also, there needs to be a way to remove particular entries from the project file. Say I accidentally add a layer from a file that I *really* don't want to be in there (a scan of my credit card, for example). I want to be able to completely purge it.

Robert Krawitz                                     

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Daniel Hornung gmx.de> writes:

Or, maybe even better, there could be a warning dialog with a list of preview

snapshots of the unsaved

images, possibly each with a list of options like "Examine image" and "Ignore

this image" and whatever

seems sensible (saving without closely examining the current state does not

seem sensible to me, btw.).

That's an interesting idea, but it's an awful lot of work, and I'm not sure it's significantly better than simply closing each image one by one.

It also kind of misses the point of my post, which was that if users can undo their mistakes, we don't need to worry so much about preventing them from making mistakes.

An "undo close" feature would be a game changer, and, among other things, would answer the question of "what if the user accidentally saves to an 'unsafe' format?"

On Tue, 2012-11-20 at 14:24 +0400, Alexandre Prokoudine wrote:

On Tue, Nov 20, 2012 at 3:13 AM, Simon Budig wrote:

In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past

And it's in the works.

I've used Jakub Steiner's greyscale gimp theme for several years, although it really could do with updating because it doesn't have all the toolbox icons. I seem to remember I also edited the Curves icon so it wasn't square, making it easier to find. But I do agree it helps.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Tue, Nov 20, 2012 at 8:05 PM, Liam R E Quin wrote:

In fact *because* we're dealing with lots of graphical elements we have to avoid distracting from the image the artist is working on. We had requests for a grayscale icon theme in the past

And it's in the works.

I've used Jakub Steiner's greyscale gimp theme for several years, although it really could do with updating because it doesn't have all the toolbox icons. I seem to remember I also edited the Curves icon so it wasn't square, making it easier to find. But I do agree it helps.

I was referring to ongoing work on stencil version of Art Libre Set.

Alexandre Prokoudine http://libregraphicsworld.org

On Tuesday, 20. November 2012 08:24:56 Robert Krawitz wrote:

On Tue, 20 Nov 2012 11:15:19 +0100, Daniel Hornung wrote:

A naive fix for this particular problem would be to split the lists in the quit warning into two separate lists: files that haven't been saved, and files that have been neither saved nor exported.

Or, maybe even better, there could be a warning dialog with a list of preview snapshots of the unsaved images, possibly each with a list of options like "Examine image" and "Ignore this image" and whatever seems sensible (saving without closely examining the current state does not seem sensible to me, btw.).

Think about how this scales up to 20-100 images (and yes, it's not uncommon for me to have this many open).

Good point, but certainly one the UI team could solve. My argument was mainly that the problem about many warnings at once could be solved in a save/export- agnostic way.

Cheers,
Daniel

Mein öffentlicher Schlüssel / My public key: 4096R/600ACB3B 2012-04-01
Fingerabdruck / Fingerprint:
9902 575B B9A0 C339 CFDF  250B 9267 CA6B 600A CB3B
Runterladen z.B. bei/ Get it e.g. from:
pgp.mit.edu, subkeys.pgp.net, pgp.uni-mainz.de, pool.sks-keyservers.net, ...

* Alberto Mardegan [11-20-12 12:11]:

As suggested, I went and created my own branch: please let me announce the GIMB! :-)

http://blog.mardy.it/2012/11/gimb.html

note: not intended for under educated individuals who's language skills do not include Italian.

(paka)Patrick Shanahan       Plainfield, Indiana, USA      HOG # US1244711
http://wahoo.no-ip.org        Photo Album: http://wahoo.no-ip.org/gallery2
http://en.opensuse.org                           openSUSE Community Member
Registered Linux User #207535                    @ http://linuxcounter.net

On Tue, Nov 20, 2012 at 10:17 PM, Paka wrote:

* Alberto Mardegan [11-20-12 12:11]:

As suggested, I went and created my own branch: please let me announce the GIMB! :-)

http://blog.mardy.it/2012/11/gimb.html

note: not intended for under educated individuals who's language skills do not include Italian.

"this blog post is written in interlingua, an international language which you should be able to partially understand without previous study, with varying effort depending on your linguistic background..."

Alexandre Prokoudine http://libregraphicsworld.org

On 11/19/2012 05:06 AM, Vincent Cadet wrote:

Morality:
- pet dead. dummy unhappy.
- oven too small. cook unhappy.

Some people must learn the hard way.

Cheers, Vince C.

+10

-- Burnie

--- En date de: Mar 20.11.12, Alberto Mardegan a crit:

As suggested, I went and created my own branch: please let me announce
the GIMB! :-)

http://blog.mardy.it/2012/11/gimb.html

Ciao, Alberto

Maybe (I hope) it's a false positive but clicking the link at the company I'm working at threw an error saying the URL ( http://blog.mardy.it/2012/11/gimb.html ) is infected by a virus called JS/FBJack.A . Our firewall is Astaro with the latest updates. I'm not the one who frantically waves his arms in the air for no specific reason but here it raises my attention. Please advise if no there's no threat.

Cheers, Vince C.

Hi Alberto.

--- En date de : Mer 21.11.12, Alberto Mardegan a écrit :

On 11/21/2012 11:53 AM, Owen wrote:

--- En date de : Mar 20.11.12, Alberto Mardegan

a écrit :

As suggested, I went and created my own branch: please let me announce
the GIMB!

http://blog.mardy.it/2012/11/gimb.html

Ciao,    Alberto

[...] clicking the link at the
company I'm working at threw an error saying the URL ( http://blog.mardy.it/2012/11/gimb.html ) is infected by a virus called JS/FBJack.A . [...]

Opened ok here, checking the source of the page would suggest that your firewall maybe getting confused with the javascript at the start.

What happens if you fetch the page with wget?

-- Owen

I tried again opening the URL with my browser and there's no more warning message. Either the anti-virus database has been updated (for which I need more time to check) or the “threat” has gone (aka "changing the suspected script did the trick" :D). It seems Ok now.

Good day, Vince C.