I couldn't agree more!

Could the developers possibly add an option to revert back to the old system?

Sent from my iPod

On May 2, 2012, at 8:45 PM, Jonathan Kamens wrote:

I hate the new Save vs. Export behavior. It is completely non-intuitive to me, it makes my brain stumble every time I try to do just about any of the things that I do in GIMP on a regular basis, and it makes most of my workflows take more thought and more button clicks / key presses than they used to.

Here's just one use case that is completely destroyed by this change... Loading a JPG to edit and save back to JPG. Old way: "gimp file.jpg".
Make changes.
Type ctrl-s periodically while working to save progress. Type ctrl-q.
New way:
"gimp file.jpg".
Make changes.
Open File menu and select "Overwrite" (no keyboard shortcut for that!). Periodically type ctrl-e to save further progress (because for some inexplicable reason, once you use the "Overwrite" command it disappears and is replaced with the "Export" command which appears to do exactly the same thing, but this one has a keyboard shortcut; how does that make sense, exactly)? Type ctrl-q.
GIMP tells me I have unsaved changes, even though I just saved them with ctrl-e. Click "Discard Changes" to really exit. If I can't remember whether I've saved already or not and hit ctrl-e instead of using File | Overwrite, an export dialog pops up and if I just accept the file name in it, I am asked to confirm that I want to replace the file. Then I'm prompted for export settings. This is absurd.

Here's another use case that's rendered more complex by this change... Load an image, edit, and save in a different format. Old way: "gimp image.fmt1".
Make changes.
ctrl-shift-s.
Modify extension in save dialog.
ctrl-q.
New way:
"gimp image.fmt1".
Make changes.
ctrl-shift-e. (and, mind you, I have to remember that it's shift-ctrl-e, instead of shift-ctrl-s like in every other freakin' application I use on either Linux and Windows) Modify extension in save dialog.
Type ctrl-q.
GIMP tells me that I have unsaved changes, even though I just saved them with shift-ctrl-e. Click "Discard Changes" to really exit. But what about when I do want to load an image in a non-XCF format and then save as XCF? Well, Ctrl-shift-e won't work for that, because the export dialog doesn't let you export as XCF. I see no advantage whatsoever to this restriction. So I have to remember that in this one special case of changing the format of an image, I have to use ctrl-s instead of ctrl-shift-e.

There isn't a single thing that I use GIMP for that is made easier or faster by this interface change. Not one thing.

I understand that there is "information loss" when an image is saved as a format other than XCF. But the fact of the matter is that when all I'm doing is retouching an image, which is what I do most with gimp, I don't give a flying fig about that "information loss." I just want the image to save, nice and easy, when I'm done editing it. And I don't want to have to remember different commands for GIMP than for every other program I use. And I don't want the command I have to use the first time I save an image to be different from the command I use the next time; that just makes no sense. Because of this particular "feature," I can't even make this problem less onerous by swapping the ctrl-s/ctrl-e and shift-ctrl-s/shift-ctrl-e bindings. Brilliant!

I understand that the GIMP developers consider XCF a "special" format which deserves special treatment. Well, I don't, and I'm sure there are many, many users like me who don't either. This change is just sticking a thumb in all of our eyes.

You could have done this the LibreOffice way... When you try to save an image loaded from a format with information loss, you get a pop-up warning you and giving you the choice of whether to proceed or save as XCF (and also giving you the choice to make this warning go away in the future and just save like you told it to). This is what LibreOffice does, e.g., when you load and then try to save a DOC file.

Or you could have made this change at least a little bit less onerous by making the save dialog default to XCF but allowing the user to edit the extension to save to another format. But no, if you try to do that, it tells you, "Sorry, this dialog only saves in XCF format," and you have to cancel out of it and export instead.

In my opinion, this change is a huge, huge step backward in useability.

Jonathan Kamens

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

Add another vote for the old way.

Please, Mr Developers, listen to the user base.

Kev

On Wed May 2 2012 20:45:16 Jonathan Kamens wrote:

I hate the new Save vs. Export behavior. It is completely non-intuitive to me, it makes my brain stumble every time I try to do just about any of the things that I do in GIMP on a regular basis, and it makes most of my workflows take more thought and more button clicks / key presses than they used to.

I love the new way much much more logical and easier and effective to use Please dont remove this feature.
Paul
On May 3, 2012 2:31 AM, "Kasim Ahmic" wrote:

I couldn't agree more!

Could the developers possibly add an option to revert back to the old system?

Sent from my iPod

On May 2, 2012, at 8:45 PM, Jonathan Kamens wrote:

I *hate* the new Save vs. Export behavior. It is completely non-intuitive to me, it makes my brain stumble every time I try to do just about any of the things that I do in GIMP on a regular basis, and it makes most of my workflows take more thought and more button clicks / key presses than they used to.

Here's just one use case that is completely destroyed by this change... Loading a JPG to edit and save back to JPG. Old way:

1. "gimp file.jpg". 2. Make changes.
3. Type ctrl-s periodically while working to save progress. 4. Type ctrl-q.

New way:

1. "gimp file.jpg". 2. Make changes.
3. Open File menu and select "Overwrite" (no keyboard shortcut for that!).
4. Periodically type ctrl-e to save further progress (because for some inexplicable reason, once you use the "Overwrite" command it disappears and is replaced with the "Export" command which appears to do exactly the same thing, but *this* one has a keyboard shortcut; how does that make sense, exactly)?
5. Type ctrl-q.
6. GIMP tells me I have unsaved changes, even though I just saved them with ctrl-e.
7. Click "Discard Changes" to really exit.

If I can't remember whether I've saved already or not and hit ctrl-e instead of using File | Overwrite, an export dialog pops up and if I just accept the file name in it, I am asked to confirm that I want to replace the file. Then I'm prompted for export settings. This is absurd.

Here's another use case that's rendered more complex by this change... Load an image, edit, and save in a different format. Old way:

1. "gimp image.fmt1". 2. Make changes.
3. ctrl-shift-s.
4. Modify extension in save dialog. 5. ctrl-q.

New way:

1. "gimp image.fmt1". 2. Make changes.
3. ctrl-shift-e. (and, mind you, I have to *remember* that it's shift-ctrl-e, instead of shift-ctrl-s like in every other freakin' application I use on either Linux and Windows) 4. Modify extension in save dialog. 5. Type ctrl-q.
6. GIMP tells me that I have unsaved changes, even though I just saved them with shift-ctrl-e.
7. Click "Discard Changes" to really exit.

But what about when I *do* want to load an image in a non-XCF format and then save as XCF? Well, Ctrl-shift-e won't work for that, because the export dialog doesn't let you export as XCF. I see no advantage whatsoever to this restriction. So I have to remember that in this one special case of changing the format of an image, I have to use ctrl-s instead of ctrl-shift-e.

There isn't a single thing that I use GIMP for that is made easier or faster by this interface change. Not one thing.

I understand that there is "information loss" when an image is saved as a format other than XCF. But the fact of the matter is that when all I'm doing is retouching an image, which is what I do most with gimp, I don't give a flying fig about that "information loss." I just want the image to save, nice and easy, when I'm done editing it. And I don't want to have to remember different commands for GIMP than for every other program I use. And I don't want the command I have to use the first time I save an image to be different from the command I use the next time; that just makes no sense. Because of this particular "feature," I can't even make this problem less onerous by swapping the ctrl-s/ctrl-e and shift-ctrl-s/shift-ctrl-e bindings. Brilliant!

I understand that the GIMP developers consider XCF a "special" format which deserves special treatment. Well, I don't, and I'm sure there are many, many users like me who don't either. This change is just sticking a thumb in all of our eyes.

You could have done this the LibreOffice way... When you try to save an image loaded from a format with information loss, you get a pop-up warning you and giving you the choice of whether to proceed or save as XCF (and also giving you the choice to make this warning go away in the future and just save like you told it to). This is what LibreOffice does, e.g., when you load and then try to save a DOC file.

Or you could have made this change at least a *little* bit less onerous by making the save dialog *default* to XCF but allowing the user to edit the extension to save to another format. But no, if you try to do that, it tells you, "Sorry, this dialog only saves in XCF format," and you have to cancel out of it and export instead.

In my opinion, this change is a huge, huge step backward in useability.

Jonathan Kamens

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

On Thu, May 3, 2012 at 6:10 AM, Jonathan Kamens wrote:

Could you elaborate on why it is more logical and easier and effective to use? What use cases do you perform on a regular basis which are improved by the new interface?

Working on a multilayer composition and quickly non-disruptively exporting to a Dropbox folder. Which is what like 99,99999% designers do today.

Alexandre Prokoudine http://libregraphicsworld.org

ooops... sorry. must've hit "reply" instead of "reply all." there... this should be right. ;-)

On Wed, May 2, 2012 at 8:38 PM, Jonathan Kamens wrote:

Say it on the list, not to me privately. :-)

On 05/02/2012 10:17 PM, Christen Anderson wrote:

+1 to everything you said.

On 5/2/2012 6:45 PM, Jonathan Kamens wrote:

I *hate* the new Save vs. Export behavior. It is completely non-intuitive to me, it makes my brain stumble every time I try to do just about any of the things that I do in GIMP on a regular basis, and it makes most of my workflows take more thought and more button clicks / key presses than they used to.

Here's just one use case that is completely destroyed by this change... Loading a JPG to edit and save back to JPG. Old way:

1. "gimp file.jpg". 2. Make changes.
3. Type ctrl-s periodically while working to save progress. 4. Type ctrl-q.

New way:

1. "gimp file.jpg". 2. Make changes.
3. Open File menu and select "Overwrite" (no keyboard shortcut for that!).
4. Periodically type ctrl-e to save further progress (because for some inexplicable reason, once you use the "Overwrite" command it disappears and is replaced with the "Export" command which appears to do exactly the same thing, but *this* one has a keyboard shortcut; how does that make sense, exactly)?
5. Type ctrl-q.
6. GIMP tells me I have unsaved changes, even though I just saved them with ctrl-e.
7. Click "Discard Changes" to really exit.

If I can't remember whether I've saved already or not and hit ctrl-e instead of using File | Overwrite, an export dialog pops up and if I just accept the file name in it, I am asked to confirm that I want to replace the file. Then I'm prompted for export settings. This is absurd.

Here's another use case that's rendered more complex by this change... Load an image, edit, and save in a different format. Old way:

1. "gimp image.fmt1". 2. Make changes.
3. ctrl-shift-s.
4. Modify extension in save dialog. 5. ctrl-q.

New way:

1. "gimp image.fmt1". 2. Make changes.
3. ctrl-shift-e. (and, mind you, I have to *remember* that it's shift-ctrl-e, instead of shift-ctrl-s like in every other freakin' application I use on either Linux and Windows) 4. Modify extension in save dialog. 5. Type ctrl-q.
6. GIMP tells me that I have unsaved changes, even though I just saved them with shift-ctrl-e.
7. Click "Discard Changes" to really exit.

But what about when I *do* want to load an image in a non-XCF format and then save as XCF? Well, Ctrl-shift-e won't work for that, because the export dialog doesn't let you export as XCF. I see no advantage whatsoever to this restriction. So I have to remember that in this one special case of changing the format of an image, I have to use ctrl-s instead of ctrl-shift-e.

There isn't a single thing that I use GIMP for that is made easier or faster by this interface change. Not one thing.

I understand that there is "information loss" when an image is saved as a format other than XCF. But the fact of the matter is that when all I'm doing is retouching an image, which is what I do most with gimp, I don't give a flying fig about that "information loss." I just want the image to save, nice and easy, when I'm done editing it. And I don't want to have to remember different commands for GIMP than for every other program I use. And I don't want the command I have to use the first time I save an image to be different from the command I use the next time; that just makes no sense. Because of this particular "feature," I can't even make this problem less onerous by swapping the ctrl-s/ctrl-e and shift-ctrl-s/shift-ctrl-e bindings. Brilliant!

I understand that the GIMP developers consider XCF a "special" format which deserves special treatment. Well, I don't, and I'm sure there are many, many users like me who don't either. This change is just sticking a thumb in all of our eyes.

You could have done this the LibreOffice way... When you try to save an image loaded from a format with information loss, you get a pop-up warning you and giving you the choice of whether to proceed or save as XCF (and also giving you the choice to make this warning go away in the future and just save like you told it to). This is what LibreOffice does, e.g., when you load and then try to save a DOC file.

Or you could have made this change at least a *little* bit less onerous by making the save dialog *default* to XCF but allowing the user to edit the extension to save to another format. But no, if you try to do that, it tells you, "Sorry, this dialog only saves in XCF format," and you have to cancel out of it and export instead.

In my opinion, this change is a huge, huge step backward in useability.

Jonathan Kamens

_______________________________________________ gimp-user-list mailing listgimp-user-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gimp-user-list

On Thu, May 3, 2012 at 6:38 AM, Jonathan Kamens wrote:

This use case does not explain why it makes sense for the first time you save a file you loaded from JPG, the command is "Overwrite", which has no key binding, and after that first time the "Overwrite" command disappears and is replaced by "Export" and "Overwrite" is no longer available.

This use case does not explain why it makes sense for an image which was loaded from JPG, was never an XCF, and does not have multiple layers, to default to saving as XCF rather than JPG.

This use case does not explain why it makes sense for an image which was loaded from JPG, was never an XCF, and is saved back to the JPG from which it was loaded, to be considered unsaved and modified when you try to quit from GIMP.

Aside from all of that, what percentage of the GIMP user base is "designers" for whom this functionality makes sense? The GIMP web site lists "photo retouching" first on the list of tasks that GIMP is good for, which would seem to imply that it is also the most common task that GIMP is used for, and the new interface is vastly inferior to the old for that task.

I thought of the best reply to all of this, and I think the shortest way to explain it is to tell you that you are probably not a targeted GIMP user.

Further reading:

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

By the way, you can freely map any shortcut to any menu command. Try it :)

Other than that, if you don't do complex work and don't care about accidentally not saving non-destructive changes such as layers and masks, perhaps you don't really need GIMP. There is a fair amount of free image editors that will suit simpler workflows just fine.

Alexandre Prokoudine http://libregraphicsworld.org

On Thu, May 3, 2012 at 5:30 AM, Kasim Ahmic wrote:

I couldn't agree more!

Could the developers possibly add an option to revert back to the old system?

It would

1) contradict the product vision 2) conflict with further planned changes

Alexandre Prokoudine http://libregraphicsworld.org

I was just thinking like a toggle in the Preferences saying something like "Use old save/export method". But by default it's set to the new method.

Sent from my iPod

On May 2, 2012, at 11:05 PM, Alexandre Prokoudine wrote:

On Thu, May 3, 2012 at 5:30 AM, Kasim Ahmic wrote:

I couldn't agree more!

Could the developers possibly add an option to revert back to the old system?

It would

1) contradict the product vision 2) conflict with further planned changes

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

On Thu, May 3, 2012 at 7:14 AM, Kasim Ahmic wrote:

I was just thinking like a toggle in the Preferences saying something like "Use old save/export method". But by default it's set to the new method.

Kasim.

I encourage you to carefully read intro at http://gui.gimp.org/index.php/Save_%2B_export_specification. It really explains why this option wouldn't make a lot of sense.

Alexandre Prokoudine http://libregraphicsworld.org

Honestly, this new export/save method is pointless to me. I rarely ever use XCF files unless I'm working with a project that stretches over days and I need to constantly make changes to a file with many layers.

99.9% of the time I simply import a PNG or JPEG, edit what I need to edit, and Save (well export rather). Then I check it in a browser and if there's a mistake, I go back fix it and hit Save. It's just so much simpler that way without all the extra "features" like Export, Export To, and Overwrite.

Sent from my iPod

On May 2, 2012, at 11:21 PM, Alexandre Prokoudine wrote:

On Thu, May 3, 2012 at 7:14 AM, Kasim Ahmic wrote:

I was just thinking like a toggle in the Preferences saying something like "Use old save/export method". But by default it's set to the new method.

Kasim.

I encourage you to carefully read intro at http://gui.gimp.org/index.php/Save_%2B_export_specification. It really explains why this option wouldn't make a lot of sense.

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

On Wed, May 2, 2012 at 11:21 PM, Jonathan Kamens wrote:

I use many of GIMP's features. I'm not just removing red-eyes from my family photos. Yeah, I'm not a professional designer; no one is paying me for the output of my work, nor am I publishing it as art. But it feels to me like perhaps the GIMP team's vision of its target audience is overly limiting and in the end will benefit neither GIMP nor its user base.

I have to ask, do really not save your edits as XCF files? Even if I am doing a red eye removal, I duplicate the layer and work on that, saving the file as an XCF, so I can always revert back, if needed....

I find the new paradigm quite intuitive, once I thought about it and gave it a try. The native format is XCF, which is the only thing you save. Everything else is an export to a lossy (in some manner) format.

The inconsistent behaviour of the overwrite should probably be brought up to the gimp devs, if it doesn't line up with the outline.

-Rob A>

On Thu, May 3, 2012 at 11:21 AM, Jonathan Kamens wrote:

It is certainly important for the authors and developers of an application to know who their targeted audience is.

I'm curious, though... Do you know what percentage of the people who actually use GIMP now are part of that target audience?

I mean, let's just say, for the sake of argument, that 50% of your current users are not part of the target audience you envision and will find GIMP harder and harder to use as it is further and further optimized for its target audience, until in the end they go use something else.

Not everyone within that hypothetical 50% is going to hate the new changes. I'm quite okay with them (and I do purely jpeg/png editing as well...)

On Thu, May 3, 2012 at 7:21 AM, Jonathan Kamens wrote:

It is certainly important for the authors and developers of an application to know who their targeted audience is.

I'm curious, though... Do you know what percentage of the people who actually use GIMP now are part of that target audience?

This is simply not the point.

Let's face it: GIMP is mostly misused. People got used to it, because if they needed a free app with few extra features, they simply had no choice. Especially on Linux.

If Pinta was released 5 years earlier, the amount of GIMP users on Linux would probably be a half of what it is now.

Still with me?

The aim is to meet the demands of professionals. Users have a choice: migrate to simpler apps like Pinta, migrate to complex apps with familiar workflow such as Krita, or stick to GIMP and adapt their workflows.

The adaptation is really not as bad as you are trying to picture it. I know it, because I've gone through this two years ago, and I'm neither supersmart nor extraflexible.

Also, it seems to me from the stuff at the URLs you sent that the potential size of the user base for the audience you are targeting is much smaller than the potential user base of more "casual" image editors like me. Do I understand correctly that you are consciously aiming to design the application to be attractive primarily to that much smaller user base?

It's a matter of perspective. As far as I can tell, users who try to think and act big gravitate to more sophisticated software. That automatically expands the audience (far) beyond hi-end users. But the development focus is still on hi-end users, because focus is important.

Alexandre Prokoudine http://libregraphicsworld.org

My use case: I use GIMP for its mult-layer features, creating images from scratch and I want to save all my work in this multi-layer format (XCF) but I need to send draft versions and the finished image to friends/customers/websites etc as a flat image (e.g. an exported PNG)

So the new interface significantly helps me work much more effectively

(If I want to edit a jpg photo I normally use other tools, though I probably only cut/crop/red eye so hardly a fair comparision)

Paul

On 3 May 2012 04:48, Alexandre Prokoudine wrote:

On Thu, May 3, 2012 at 7:21 AM, Jonathan Kamens wrote:

It is certainly important for the authors and developers of an

application

to know who their targeted audience is.

I'm curious, though... Do you know what percentage of the people who actually use GIMP now are part of that target audience?

This is simply not the point.

Let's face it: GIMP is mostly misused. People got used to it, because if they needed a free app with few extra features, they simply had no choice. Especially on Linux.

If Pinta was released 5 years earlier, the amount of GIMP users on Linux would probably be a half of what it is now.

Still with me?

The aim is to meet the demands of professionals. Users have a choice: migrate to simpler apps like Pinta, migrate to complex apps with familiar workflow such as Krita, or stick to GIMP and adapt their workflows.

The adaptation is really not as bad as you are trying to picture it. I know it, because I've gone through this two years ago, and I'm neither supersmart nor extraflexible.

Also, it seems to me from the stuff at the URLs you sent that the

potential

size of the user base for the audience you are targeting is much smaller than the potential user base of more "casual" image editors like me. Do I understand correctly that you are consciously aiming to design the application to be attractive primarily to that much smaller user base?

It's a matter of perspective. As far as I can tell, users who try to think and act big gravitate to more sophisticated software. That automatically expands the audience (far) beyond hi-end users. But the development focus is still on hi-end users, because focus is important.

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

Wow it seems those in disfavour of the new "save-export" function are pretty agro. I was like that before getting used to new workflows. It took a lot of me moving from Illustrator and Photoshop to inkscape and Gimp. Although I still prefer the way the pen tool works in Adobe I'm getting used to the way they ( gimpscape :) ) work.

The beauty of the open source model is that if you prefer a certain way of doing things you have the source of the application at your disposal, tweek it, change it, redo it.

I'd do that if I were in your (The One's who don't like the new 'export-save' dialogue) shoes

I still use 2.6.1 and it seems that once I update, if I ever do, that function makes a lot more sense.

If I export an image to jpg or png hitting ctrl+w exits Gimp without option to save as xcf(which would be the photoshop version of psd). Any layers or masks are lost.
The new version seems to make this occurance an impossibility. I'm doing my update this weekend :)

Jonathan Kamens writes:

I hate the new Save vs. Export behavior. It is completely non-intuitive to me, it makes my brain stumble every time I try to do just about any of the things that I do in GIMP on a regular basis, and it makes most of my workflows take more thought and more button clicks / key presses than they used to.

I love the new behaviour :)

Here's just one use case that is completely destroyed by this change... Loading a JPG to edit and save back to JPG. Old way:

1. "gimp file.jpg". 2. Make changes.
3. Type ctrl-s periodically while working to save progress. 4. Type ctrl-q.

New way:

1. "gimp file.jpg". 2. Make changes.
3. Open File menu and select "Overwrite" (no keyboard shortcut for that!). 4. Periodically type ctrl-e to save further progress (because for some inexplicable reason, once you use the "Overwrite" command it disappears and is replaced with the "Export" command which appears to do exactly the same thing, but this one has a keyboard shortcut; how does that make sense, exactly)? 5. Type ctrl-q.
6. GIMP tells me I have unsaved changes, even though I just saved them with ctrl-e. 7. Click "Discard Changes" to really exit.

If I can't remember whether I've saved already or not and hit ctrl-e instead of using File | Overwrite, an export dialog pops up and if I just accept the file name in it, I am asked to confirm that I want to replace the file. Then I'm prompted for export settings. This is absurd.

Here's another use case that's rendered more complex by this change... Load an image, edit, and save in a different format. Old way:

1. "gimp image.fmt1". 2. Make changes.
3. ctrl-shift-s.
4. Modify extension in save dialog.

… and click away the warning about flattening / losing information ;)

5. ctrl-q.

New way:

1. "gimp image.fmt1". 2. Make changes.
3. ctrl-shift-e. (and, mind you, I have to remember that it's shift-ctrl-e, instead of shift-ctrl-s like in every other freakin' application I use on either Linux and Windows)

You can always rebind it, but is it really that difficult to remember?

4. Modify extension in save dialog. 5. Type ctrl-q.
6. GIMP tells me that I have unsaved changes, even though I just saved them with shift-ctrl-e.

This new warning replaces the old warning about flattening / losing information.

7. Click "Discard Changes" to really exit.

But what about when I do want to load an image in a non-XCF format and then save as XCF? Well, Ctrl-shift-e won't work for that, because the export dialog doesn't let you export as XCF. I see no advantage whatsoever to this restriction. So I have to remember that in this one special case of changing the format of an image, I have to use ctrl-s instead of ctrl-shift-e.

For those who use GIMP a lot, XFC is the default case, not the special case.

There isn't a single thing that I use GIMP for that is made easier or faster by this interface change. Not one thing.

I won't argue against that, but at the same time I don't see the big problem. It seems the users most likely to argue against it are those who don't do more than minor touch-ups in GIMP. Those who use GIMP more extensively, do gain a lot from the new functionality.

I understand that there is "information loss" when an image is saved as a format other than XCF. But the fact of the matter is that when all I'm doing is retouching an image, which is what I do most with gimp, I don't give a flying fig about that "information loss." I just want the image to save, nice and easy, when I'm done editing it. And I don't want to have to remember different commands for GIMP than for every other program I use. And I don't want the command I have to use the first time I save an image to be different from the command I use the next time; that just makes no sense. Because of this particular "feature," I can't even make this problem less onerous by swapping the ctrl-s/ctrl-e and shift-ctrl-s/shift-ctrl-e bindings. Brilliant!

I understand that the GIMP developers consider XCF a "special" format which deserves special treatment. Well, I don't, and I'm sure there are many, many users like me who don't either. This change is just sticking a thumb in all of our eyes.

You could have done this the LibreOffice way... When you try to save an image loaded from a format with information loss, you get a pop-up warning you and giving you the choice of whether to proceed or save as XCF (and also giving you the choice to make this warning go away in the future and just save like you told it to). This is what LibreOffice does, e.g., when you load and then try to save a DOC file.

Oh, no, please don't. Doc's at least retain _most_ of the information, now if you'd said .rtf you'd be closer to the truth …

Or you could have made this change at least a little bit less onerous by making the save dialog default to XCF but allowing the user to edit the extension to save to another format. But no, if you try to do that, it tells you, "Sorry, this dialog only saves in XCF format," and you have to cancel out of it and export instead.

In my opinion, this change is a huge, huge step backward in useability.

Jonathan Kamens

The ui docs linked to in this thread argue quite well for the change, I'll just describe my main use case: I love being able to both save and export as I go along. Working on a web site, I definitely want to keep layer info available, so I need the XCF, but to see how it looks in Firefox, I need the PNG there too. So as I change something, and I want to quickly see how it looks in Firefox, I can just ctrl+shift+e (then click reload in Firefox). And it'll retain the path I last specified, so I don't have to enter anything. And as I go along, I click ctrl+s to keep the main XCF up-to-date, again without having to re-enter the path.

With the old method, I would work on an XCF, then I had to save as, select PNG, ignore warnings, then, _very importantly_, I had to remember to switch back to XCF before I exited GIMP (or had a crash or power-loss or whatever), otherwise I'd lose the last steps. If I had GIMP focused but thought I had Firefox focused, and pressed Ctrl+W to close a tab, it'd take down the image instead with no warning about unsaved changes, and all the steps after I switched to "preview mode" would be lost. Pure danger. A graphical program shouldn't make you have to remember not to shoot yourself in the foot like that.

best regards, Kevin Brubeck Unhammer

I also hate the save/export feature, that does not bring any convenience at all, and causes lots of errors when you are tying to "save" an image. In former Gimp versions, typing the file name without extension was enough to "save" the file in xcf. Now, the program has gone STUPID enough to bring you a useless explanation when you (ARRGH!) "saved" instead of "exporting" and (maybe nobody tried yet), if you chose "export" and type xcf or no extension, you are also entitled to a little explanation telling that you should have selected the "save" option and saving is forbidden too. So that the fix I was about to propose (modify the sources, renaming "export" as "save", and "save" as, say "xcf save") is not as simple as I thought, as you also should avoid the dumb explanatory message and allow saving in xcf even if you are "exporting". I would like to know who introduced this new "feature": to my mind, it must be an infiltrated saboteur from Adobe.

On Thu, May 3, 2012 at 11:02 AM, Francois wrote:

I would like to know who introduced this new "feature":

Just read the release notes :)

to my mind, it must be an infiltrated saboteur from Adobe.

No, actually it's an alien conspiracy. First they sent us a death threat, but we called it dubstep and started dancing to it. So they tried a more intricate approach.

Alexandre Prokoudine http://libregraphicsworld.org

On Thu, May 3, 2012 at 7:14 AM, Kasim Ahmic wrote:

I was just thinking like a toggle in the Preferences saying something like "Use old save/export method". But by default it's set to the new method.

Kasim.

I encourage you to carefully read intro at http://gui.gimp.org/index.php/Save_%2B_export_specification. It really explains why this option wouldn't make a lot of sense.

Alexandre Prokoudine
http://libregraphicsworld.org

I had a look to that page, and it made me understand that this option had been chosen by stiff, dogmatic and narrow-minded people who consider us, the users, vile and mentally limited cattle who needs to be evangelized by you, the programmers, enjoying the holy light and full understanding of the world's arcana...

On Thu, May 3, 2012 at 11:02 AM, Francois wrote:

I would like to know who introduced this new "feature":

Just read the release notes :)

to my mind, it must be an infiltrated saboteur from Adobe.

No, actually it's an alien conspiracy. First they sent us a death threat, but we called it dubstep and started dancing to it. So they tried a more intricate approach.

Alexandre Prokoudine
http://libregraphicsworld.org

No. Reading your notes is not agreeing to them. This is always your answer, Alexandre: read the Holy Scripture I have just written, and if you don't agree, it means you didn't understand. This is your unvarying attitude, Alexandre: I wrote it => this is truth. Your constant error is you think that reasoning is truth.

"Judah Kleinveldt" writes:

Wow it seems those in disfavour of the new "save-export" function are pretty agro.

Although I don't have a neutral stance on it, I also see it as a _trivial_ change; and when I reflect a bit, I don't think it deserves this much discussion. As http://bikeshed.com/ (well worth the read) beautifully explains, "the amount of noise generated by a change is inversely proportional to the complexity of the change".

-Kevin

On Thu, May 3, 2012 at 11:32 AM, Francois wrote:

No. Reading your notes is not agreeing to them. This is always your answer, Alexandre: read the Holy Scripture I have just written, and if you don't agree, it means you didn't understand.
This is your unvarying attitude, Alexandre: I wrote it => this is truth. Your constant error is you think that reasoning is truth.

Dear Francois, let's get back to this discussion when you calmed down and stopped punching the air.

There is no single truth, but there is what we think is our way of doing things, and we follow it. It could be wrong for you, but it's right for us. Whether you stick with us or whether you depart is entirely up to you.

Alexandre Prokoudine http://libregraphicsworld.org

Ah, this is the second time that I peep in this discussion list and find the "save vs export" battle raging :-) . It would have been nice if somebody had made a pool, with the two obvious choices and as a third having a switch in the preferences. For the record, I like better how it works now, even if I feel a bit annoying the a-program-that-forces-me-to-do-the-right-thing bit.

On Thu, May 3, 2012 at 10:08 AM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Thu, May 3, 2012 at 11:32 AM, Francois wrote:

No. Reading your notes is not agreeing to them. This is always your

answer,

Alexandre: read the Holy Scripture I have just written, and if you don't

agree,

it means you didn't understand.
This is your unvarying attitude, Alexandre: I wrote it => this is truth.

Your

constant error is you think that reasoning is truth.

Dear Francois, let's get back to this discussion when you calmed down and stopped punching the air.

There is no single truth, but there is what we think is our way of doing things, and we follow it. It could be wrong for you, but it's right for us. Whether you stick with us or whether you depart is entirely up to you.

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

On Thu, May 3, 2012 at 3:04 PM, Jonathan Kamens wrote:

If a user loads an image in a non-XCF format, ask at load time whether the image is intended to be loaded or imported. If it's being loaded, then save goes back to the original file. If it's being imported, then save goes to XCF. Keep the warning about information loss in the former case if, e.g., the user tries to save an image with layers (i.e., if there is significant information loss, over and above any information loss like compression that is inherent in the format being used).

In other words, just when we got rid of disruptive warnings you are siggesting to return one of them and add another one so that the first one wouldn't feel lonely? :)

Alexandre Prokoudine http://libregraphicsworld.org

Jonathan Kamens (jik@kamens.us) wrote:

It seems clear to me at this point that either you are too invested in your work and backed into a corner at this point to be able to admit that there is any room for improvement, or you really /are/ trying to drive away users who aren't part of your target audience.

Well, some of us have been involved with the Gimp project for >= 15 years. We certainly won't assume that there is no more room for improvement. We're software engineers after all and we know that software development is an incremental effort.

However, there has been significant work been going into the new save behaviour and we won't easily give up on this after someone came to a judgement on that after thinking for maybe 20 minutes about it, apparently unwilling to see the benefits.

So yeah, in the next few weeks we will be stubborn and try to get a bigger picture on the reception. We certainly won't hastily revert everything to the old state or carelessly introduce new options.

If you can't handle this, please feel free to continue using the old version.

Bye,
Simon

On 05/02/2012 08:45 PM, Jonathan Kamens wrote:

New way:

1. "gimp file.jpg". 2. Make changes.
3. Open File menu and select "Overwrite" (no keyboard shortcut for that!).
4. Periodically type ctrl-e to save further progress (because for some inexplicable reason, once you use the "Overwrite" command it disappears and is replaced with the "Export" command which appears to do exactly the same thing, but /this/ one has a keyboard shortcut; how does that make sense, exactly)?

Jonathan, I hope that you realized that when editing a JPG, repeatedly saving/exporting to JPG (your step 4) reduces the quality (actually compresses / deletes data). Maybe this has been working for what you are doing, but I beleive it is contrary to what most users do -- because they don't want to diminish quality/data.

5. Type ctrl-q.
6. GIMP tells me I have unsaved changes, even though I just saved them with ctrl-e.
7. Click "Discard Changes" to really exit.

On Thursday 03 May 2012 10:15:29 Jay Smith wrote:

when editing a JPG, repeatedly
saving/exporting to JPG (your step 4) reduces the quality (actually compresses / deletes data).

Having been away I've just been reading this thread, and would like to add my wish to those others who are unhappy at the sudden change in the Save dialogue.
In my case, I am not "repeatedly saving/exporting' to JPG", but only once per image (to write annotation), and I would guess that applies to many other users of Gimp - though possibly a minority. Having thus introduced myself to the wonderful Gimp, I am tempted to go on to make use of more powerful functions.

Is there really no room for a simple compromise that would satisfy both the more professional and the more casual users?

"Where there's a will there's a way"...

Regards,

Hi,
paul@readiescards.co.uk (2012-05-03 at 0703.06 +0100):

My use case: I use GIMP for its mult-layer features, creating images from scratch and I want to save all my work in this multi-layer format (XCF) but I need to send draft versions and the finished image to friends/customers/websites etc as a flat image (e.g. an exported PNG)

So the new interface significantly helps me work much more effectively

In the old one, you could do this with Save a Copy.

GSR

I'm on the fence. On one hand, I fully understand the reason for this change; on the other, it's such a sudden change (compared to every previous version of GIMP ever) that it CAN (and, really, should) be handled better:

When you use the "Save As" command and type a filename other than XCF, I would personally want to see, instead of simply telling you that Save is only for GIMP's native .xcf format and use the "Export" command for other formats, give it a prompt -- have it ask something like " 'Save' uses GIMP's internal image format only - would you like to Export a copy in [file format]? [export / cancel]"

Likewise, if you've opened up an image from a non-XCF format, the "Save" (not "Save As") command should ask whether you intend to save the file in GIMP's native XCF format or re-export it back to the original file format. (Current behavior is to pop up the "Save As" dialog box, just the same as with a new image -- which tends to result in situation #1 described above)

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

From: maurice@bcs.org.uk
To: gimp-user-list@gnome.org
Date: Thu, 3 May 2012 15:53:31 +0100 Subject: Re: [Gimp-user] HATE the new save vs. export behavior

On Thursday 03 May 2012 10:15:29 Jay Smith wrote:

when editing a JPG, repeatedly
saving/exporting to JPG (your step 4) reduces the quality (actually compresses / deletes data).

Having been away I've just been reading this thread, and would like to add my wish to those others who are unhappy at the sudden change in the Save dialogue.
In my case, I am not "repeatedly saving/exporting' to JPG", but only once per image (to write annotation), and I would guess that applies to many other users of Gimp - though possibly a minority. Having thus introduced myself to the wonderful Gimp, I am tempted to go on to make use of more powerful functions.

Is there really no room for a simple compromise that would satisfy both the more professional and the more casual users?

"Where there's a will there's a way"...

Regards, --
/\/\aurice (Retired in Surrey, UK)

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

In other words, just when we got rid of disruptive warnings you are siggesting to return one of them and add another one so that the first one wouldn't feel lonely? :)

Alexandre Prokoudine

I never found the "need to flatten layers before exporting" warnings to be particularly disruptive. Would be nice to have an option to suppress it, but it was doing it's job and warning me that I would be losing layers, etc. As someone else said, LibreOffice handles this perfectly with a single warning when you try to save a file in a non-native format.

I do use .XCF files and it is a good format. But that is only 10-20% of the files I work on and I certainly don't want to use it as an intermediary format on every image I edit.

It seems to me that the issue is less about the mechanics of saving/exporting and more about the implied repositioning of GIMP itself. It was/is a high-end image editor supporting multiple formats including it's own comprehensive one. With this change however you seem to be saying that you are now a powerful .XCF editor that can import/export other formats too. The replies above saying maybe people should be using other software for pure jpeg edits back this feeling up. The message we general users get from that is simple - "Use mainly .XCF files, or live with the discomfort, or leave". It is a clear split in the userbase and the aggression behind people opposing the change is understandable.

This is the 37th message in this series.

I love the "new" save vs. export behavior, which has existed for one year and half now, and thus is not so new after all. I'm completely accustomed to the simple idea that you don't save to Jpeg of PNG, you export to these formats, and you save only to the only format that saves almost everything in your image, i.e. XCF.

When I'm simply changing some simple things to several Jpeg photos, I'm accustomed to simple key sequences: Alt-F W for overwriting the photo, Ctrl+Shift+E for exporting it to another format, Ctrl+W then Alt-W for closing the image without saving it. Alt-key combinations are very useful and easy to remember.

Just my one cent addition to the discussion...

Olivier Lecarme

In 05/2012 a lot of people wrote:

Wait, the Save dialog changed? OH NOES!!

My position can be guessed from the workflow I have followed since somewhere the first ports of the GIMP to Win32 (Tor Lillqvist ruined me for life):

1. Open an image file. 2. Save as .xcf
3. [everything else]
4. Do Control-s
5. Export as target image format.

There are two reasons to save as XCF, both have been mentioned in this thread: To save all the "state" of the image in progress so you can pick up where you left off and make more changes if/as required later, and to avoid cumulative compression artifacts.

The cost of doing it this way, is that you have to do a couple more commands per image worked on, and you end up with an additional file at the end of it all.

I can see this as a potential annoyance to people who routinely do a few simple, repetitive operations on a large number of images that will always and only be saved once and never edited again. The extra step of exporting to save could add up to a small but noticeable increase in time to complete a large number of edits. My crystal ball tells me, "Watch the plugin registry for a drop in solution to instant easy export."

Also, for those who need to do the same operations repeatedly to a large number of images, a suggestion: Look into imagemagick. It might be possible to fully automate all or a large part of that work.

:o)

Steve

On Thursday 03 May 2012 14:48:47 Steve Kinney wrote:

Look into imagemagick. It
might be possible to fully automate all or a large part of that work.

I already use Imagemagick's 'Convert' as the 1st part of my task, the 2nd part of which needs Gimp.

Or instead of the GIMP developers assuming that the users of GIMP are too stupid to know what they want, they could just let the user make all the decisions in a modal fashion.

If I start GIMP and generate a New file, bring up the usual file dialog with all the types of files that GIMP knows how to save and let the user select one filetype -- .xcf, jpeg, tiff -- whatever. Then when the user eventually clicks Save, the file is saved as that type of file -- .xcf, jpeg, tiff -- whatever.

If the user wants to save it as a different type of file he clicks Save As and proceeds similarly to just about every other computer program that allows saving of work. I am the better judge of what file format I want to save my work as than a programmer somewhere else in time and space.

Why are the GIMP developers interposing their own preferences on all the people who use and support GIMP? They are making this a much more complicated and contentious problem than it needs be

Alex Vergara Gil wrote:

El 03/05/2012 09:42 a.m., Richard Gitschlag escribi:

I'm on the fence. On one hand, I fully understand the reason for this change; on the other, it's such a sudden change (compared to every previous version of GIMP ever) that it CAN (and, really, should) be handled better:

When you use the "Save As" command and type a filename other than XCF, I would personally want to see, instead of simply telling you that Save is only for GIMP's native .xcf format and use the "Export" command for other formats, give it a prompt -- have it ask something like " 'Save' uses GIMP's internal image format only - would you like to Export a copy in [file format]? [export / cancel]"

Likewise, if you've opened up an image from a non-XCF format, the "Save" (not "Save As") command should ask whether you intend to save the file in GIMP's native XCF format or re-export it back to the original file format. (Current behavior is to pop up the "Save As" dialog box, just the same as with a new image -- which tends to result in situation #1 described above)

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

+1 with this
this seems to be the best approach I've seen in this discussion

Alex

From: maurice@bcs.org.uk
To: gimp-user-list@gnome.org
Date: Thu, 3 May 2012 15:53:31 +0100 Subject: Re: [Gimp-user] HATE the new save vs. export behavior

On Thursday 03 May 2012 10:15:29 Jay Smith wrote:

when editing a JPG, repeatedly
saving/exporting to JPG (your step 4) reduces the quality (actually compresses / deletes data).

Having been away I've just been reading this thread, and would like to add my wish to those others who are unhappy at the sudden change in the Save dialogue.
In my case, I am not "repeatedly saving/exporting' to JPG", but only once per image (to write annotation), and I would guess that applies to many other users of Gimp - though possibly a minority. Having thus introduced myself to the wonderful Gimp, I am tempted to go on to make use of more powerful functions.

Is there really no room for a simple compromise that would satisfy both the more professional and the more casual users?

"Where there's a will there's a way"...

Regards, --
/\/\aurice (Retired in Surrey, UK)

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

------------------------------------------------------------------------

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

The lack of an ability to "save" in any file type but GIMP's native XCF is a necessary drawback for the change, but I do agree that it is an uncomfortable one for many users (myself sometimes included).

If you compare Inkscape, it's a vector editor so its "Save" commands, despite all of the file formats it supports, are all vector document formats so if you want to rasterize it you use the "Export" command (which only supports PNG).

It is true, however, that many professional and commercial apps do not make a save/export distinction and allow you to "save" your document in any supported filetype -- MS Word, for example. You can open/save a document in a non-native format at any time, all you get is an extra prompt when using the "Save" command which basically asks whether you do want to save it in a non-native format, noting that the format chosen may or may not support "some features" that your actual document may or may not even use.

I saw a blog entry once criticizing open-source software in general on the grounds that many open-source developers don't take the users' interests as seriously as commercial devs do. Used the metaphor that "if your program can't do it right by your old Aunt Betty, then you're not doing it right at all". I don't want to criticize GIMP devs (beyond lightly, anyway) but I can definitely see where that blogger was coming from.

In the meantime I can confirm (and have reported) that the current save/export distinction has actual, bonafide bugs in it -- for example, the reason why the "Overwrite [filename]" command doesn't show a keyboard shortcut like the "Export (Ctrl+E)" command does is because the Overwrite and Export options are actually TWO separate commands (check your Keyboard Shortcuts preferences screen and see for yourself). That's right: GIMP has three menu commands for exporting non-XCF files when there should only be two ("Export" and "Export as", the analogue for "Save" and "Save As"). And even though GIMP only ever shows two on the menu at any time, you can access all three at any time via shortcuts and they have subtle differences in behavior that range from inconsistent to counter-intuitive.

For example, if you open a non-XCF image and immediately pound Ctrl+E you are prompted for the filename, prompted to overwrite the existing file, and then prompted for your format options. That's three extra clicks that have no logical reason to even exist, because had you selected the "Overwrite [filename]" command instead, GIMP would have simply saved the file back to its original format with No Questions Asked. And it gets better: Hit Ctrl+E a second time after all this, now GIMP saves the image back to its non-XCF format with no prompts whatsoever.

On the sunny side though ... at least the keyboard shortcut issue has a partial workaround: Go to your Keyboard Shortcuts Preferences and switch Ctrl+E from "Export to" to "Overwrite [filename]". This will eliminate a lot of clicks when all you want to do is open a non-XCF file, change some pixels and resave.

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

Date: Thu, 3 May 2012 18:38:08 -0700 From: kwarner000@verizon.net
To: alex@cphr.edu.cu; gimp-user-list@gnome.org Subject: Re: [Gimp-user] HATE the new save vs. export behavior

Or instead of the GIMP developers assuming that the users of GIMP are too stupid to know what they want, they could just let the user make all the decisions in a modal fashion.

If I start GIMP and generate a New file, bring up the usual file dialog with all the types of files that GIMP knows how to save and let the user select one filetype -- .xcf, jpeg, tiff -- whatever. Then when the user eventually clicks Save, the file is saved as that type of file -- .xcf, jpeg, tiff -- whatever.

If the user wants to save it as a different type of file he clicks Save As and proceeds similarly to just about every other computer program that allows saving of work. I am the better judge of what file format I want to save my work as than a programmer somewhere else in time and space.

Why are the GIMP developers interposing their own preferences on all the people who use and support GIMP? They are making this a much more complicated and contentious problem than it needs be

Alex Vergara Gil wrote:

El 03/05/2012 09:42 a.m., Richard Gitschlag escribió:

I'm on the fence. On one hand, I fully understand the reason for this change; on the other, it's such a sudden change (compared to every previous version of GIMP ever) that it CAN (and, really, should) be handled better:

When you use the "Save As" command and type a filename other than XCF, I would personally want to see, instead of simply telling you that Save is only for GIMP's native .xcf format and use the "Export" command for other formats, give it a prompt -- have it ask something like " 'Save' uses GIMP's internal image format only - would you like to Export a copy in [file format]? [export / cancel]"

Likewise, if you've opened up an image from a non-XCF format, the "Save" (not "Save As") command should ask whether you intend to save the file in GIMP's native XCF format or re-export it back to the original file format. (Current behavior is to pop up the "Save As" dialog box, just the same as with a new image -- which tends to result in situation #1 described above)

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

+1 with this
this seems to be the best approach I've seen in this discussion

Alex

From: maurice@bcs.org.uk
To: gimp-user-list@gnome.org
Date: Thu, 3 May 2012 15:53:31 +0100 Subject: Re: [Gimp-user] HATE the new save vs. export behavior

On Thursday 03 May 2012 10:15:29 Jay Smith wrote:

when editing a JPG, repeatedly
saving/exporting to JPG (your step 4) reduces the quality (actually compresses / deletes data).

Having been away I've just been reading this thread, and would like to add my wish to those others who are unhappy at the sudden change in the Save dialogue.
In my case, I am not "repeatedly saving/exporting' to JPG", but only once per image (to write annotation), and I would guess that applies to many other users of Gimp - though possibly a minority. Having thus introduced myself to the wonderful Gimp, I am tempted to go on to make use of more powerful functions.

Is there really no room for a simple compromise that would satisfy both the more professional and the more casual users?

"Where there's a will there's a way"...

Regards, --
/\/\aurice (Retired in Surrey, UK)

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

------------------------------------------------------------------------

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

On Fri, May 4, 2012 at 5:38 AM, Ken Warner wrote:

Or instead of the GIMP developers assuming that the users of GIMP are too stupid to know what they want, they could just let the user make all the decisions in a modal fashion.

If I start GIMP and generate a New file, bring up the usual file dialog with all the types of files that GIMP knows how to save and let the user select one filetype -- .xcf, jpeg, tiff -- whatever. Then when the user eventually clicks Save, the file is saved as that type of file -- .xcf, jpeg, tiff -- whatever.

If the user wants to save it as a different type of file he clicks Save As and proceeds similarly to just about every other computer program that allows saving of work. I am the better judge of what file format I want to save my work as than a programmer somewhere else in time and space.

Why are the GIMP developers interposing their own preferences on all the people who use and support GIMP? They are making this a much more complicated and contentious problem than it needs be

Dear Ken,

You simply don't understand the feature design process, and that leads to all kinds of amusing interpretations such as the one you suggested above.

Let me explain you.

GIMP developers don't "interpose" their preferences on people these days. Instead we go to our interaction architect and tell him: Hey Peter, there is one more thing we don't like in GIMP, because it causes certain issues for people. Can you provide as a solution.

Next thing that happens is that Peter asesses the situation, collects information, listens to different opinions, analyzes all of that and provides a specification.

This is how we do things. Whether you like the result or not is an entirely different thing.

I can't demand that from you, but it would be nice if you asked first and drew conclusions next.

Alexandre Prokoudine http://libregraphicsworld.org

gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

On Fri, May 4, 2012 at 7:26 AM, Richard Gitschlag wrote:

The lack of an ability to "save" in any file type but GIMP's native XCF is a necessary drawback for the change, but I do agree that it is an uncomfortable one for many users (myself sometimes included).

If you compare Inkscape, it's a vector editor so its "Save" commands, despite all of the file formats it supports, are all vector document formats so if you want to rasterize it you use the "Export" command (which only supports PNG).

I think I can provide you some insight here.

Saving/exporting system in Inkscape is stuck in the middle of a change. The proposal is to save only what Inkscape can really edit (SVG, maybe EPS) and export everything it can't edit completely (DXF, PDF etc) or can't edit at all (PNG). It hasn't been done yet, but it will be done.

Alexandre Prokoudine http://libregraphicsworld.org

On Thu, May 3, 2012 at 11:11 PM, Maurice wrote:

On Thursday 03 May 2012 14:48:47 Steve Kinney wrote:

Look into imagemagick. It
might be possible to fully automate all or a large part of that work.

I already use Imagemagick's 'Convert' as the 1st part of my task, the 2nd part of which needs Gimp.

The problem I see in this thread is that few people tell us exactly what they do and then complain that we don't do the right thing for them.

How can we possibly analyze the issues they are having? We can't.

We don't know exactly what you do ing GIMP during those unsafe workflows. We don't know if the sequence of actions you do can only be performed in GIMP. We don't know if your choice of GIMP as a tool is justified by logic, habit or accident.
We don't know if you need this unsafe workflow all the time or half the time.

Folks, you can tell us that, and then we can have a constructive discussion. Or you can keep telling us how we ignore you.

We've heard all sorts of curious accusations, but it's raw facts that we are interested in. We are listening.

Alexandre Prokoudine http://libregraphicsworld.org

gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

Ken Warner writes:

Why are the GIMP developers interposing their own preferences on all the people who use and support GIMP? They are making this a much more complicated and contentious problem than it needs be

I have not used the newer version of GIMP yet, but I have to ask the same question.

I am a Solaris user, but I have to support a few Windows boxes in the office. After using XP for many years, I just got in a Windows 7 system, and I have spend untold days -- maybe weeks -- trying to get the simplest things to work. MS has made one gratuitous change after another with absolutely no improvement in functionality. Years of hard learned knowledge has gone down the drain. And this affects everything from system administration to adding a new song to Media Player. Just wait until a user in my office has to use the "ribbon" in Word or Excel. Slit my wrists now!

It seems to me that this Save change in GIMP falls into the same category. We users have years of experience learning work flow procedures. It is a simple matter to save to any format you like by specifying the file extension. The problem this change now creates is that it destroys all those years of learning, replacing something that works fine with a different procedure that will not offer any improved functionality.

If the designers want a function that only saves to xcf format, then leave Save as is and add a new SaveXCF option. Then, anyone who cares can map Ctrl-S to this new function and the rest of us can continue working as we have in the past, possibly migrating to the new method at our own pace. As a programmer myself, I can understand the technical arguments for making changes to a complex program like GIMP. However, when it comes to the GUI, there really needs to be a different mindset brought to bear.

Regards,

On 5/3/2012 8:15 AM, Jay Smith wrote:

Jonathan, I hope that you realized that when editing a JPG, repeatedly saving/exporting to JPG (your step 4) reduces the quality (actually compresses / deletes data). Maybe this has been working for what you are doing, but I beleive it is contrary to what most users do -- because they don't want to diminish quality/data.

I've always been puzzled by statements like this.

GIMP doesn't reload the file after exporting, does it? If not, then the image in the GIMP's buffer should be the same high quality image it was prior to the export. Given that, as long as you don't exit the GIMP or reload the image from the exported file, multiple exports to a lossy format shouldn't cause loss of quality.

For example, if you do an export to jpeg and compress down to 15%, with the preview option set you can clearly see the loss of quality in the written image. However, when the export is complete, the image in the buffer reverts to the high quality it was prior to the export.

Is there something I'm missing?

Gary

Alexandre Prokoudine writes:

The problem I see in this thread is that few people tell us exactly what they do and then complain that we don't do the right thing for them.

Haven't tried 2.8 yet, but as I understand it:

- XCF is the native format for GIMP This is how e.g. OpenOffice does it. And this will be disliked by some.

As far as I can see it the new save will take a little time to get used to, but it seems the right approach. It will definitely prevent loss of image information when you least expect it.

-- Johan

Richard Gitschlag writes:

It is true, however, that many professional and commercial apps do not make a save/export distinction and allow you to "save" your document in any supported filetype -- MS Word, for example. You can open/save a document in a non-native format at any time, all you get is an extra prompt when using the "Save" command which basically asks whether you do want to save it in a non-native format, noting that the format chosen may or may not support "some features" that your actual document may or may not even use.

The main problem is that this file format is then silently used for subsequent saves, and that may not have been the intent.

-- Johan

Thanks for asking, Alexandre!
1) Currently I'm using GIMP mostly (95% of the time) for photo retouching. The rest is mostly image adjustment for scientific visualization and for presentations. More complex works that need multilayer etc.: only 2 last year.
2) Photo: I always start from RAW format and use UFraw from GIMP as first step. So no need to save intermediate steps (RAW images are already big enough!). For the other images, never touch the original, but the steps are usually quite simple to redo. 3) Massive changes: I use ImageMagick 4) Why GIMP? I'm using it since 2000 if I recall correctly, so I'm used to it. It has invaluable set of plugins I can load and experiment with. It (plus ImageMagick) covers all my needs. 5) Why not another tool? I'm on Windows, so cannot use nice Linux tools (In my work I tend to use only tools that runs on all platforms). Tried various other tools but found they limited. Almost all are at the level of MS Paint, and now I'm too lazy to explore again. 6) I'm using GIMP in the wrong way? Maybe. But for more than ten years it has helped me immensely. Also, at least for me, it is important to reduce the number of tools to know. More or less this is my list in the image processing area: GIMP for raster, InkScape for vector, AVIdemux for movies, mencoder for all encoding. 7) Maybe could help everyone to collect a list of tools "more correct" for tasks for which people is currently using GIMP. For example I love to find something like darkroom for Windows. 8) For now I will stay with GIMP 2.6.12 Cleaning all these unwanted .xcf from C:\Photo is really too much for me.

Hope to have answered your questions Alexandre. And hope more people will answer your call instead of fighting.

And BTW: thanks for your work with GIMP! mario

On 04-May-12 07:52, Alexandre Prokoudine wrote:

On Thu, May 3, 2012 at 11:11 PM, Maurice wrote:

On Thursday 03 May 2012 14:48:47 Steve Kinney wrote:

Look into imagemagick. It
might be possible to fully automate all or a large part of that work.

I already use Imagemagick's 'Convert' as the 1st part of my task, the 2nd part of which needs Gimp.

The problem I see in this thread is that few people tell us exactly what they do and then complain that we don't do the right thing for them.

How can we possibly analyze the issues they are having? We can't.

We don't know exactly what you do ing GIMP during those unsafe workflows. We don't know if the sequence of actions you do can only be performed in GIMP. We don't know if your choice of GIMP as a tool is justified by logic, habit or accident.
We don't know if you need this unsafe workflow all the time or half the time.

Folks, you can tell us that, and then we can have a constructive discussion. Or you can keep telling us how we ignore you.

We've heard all sorts of curious accusations, but it's raw facts that we are interested in. We are listening.

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

Hi Alexandre,

On 04 May 12 06:52 Alexandre Prokoudine said:

The problem I see in this thread is that few people tell us exactly what they do and then complain that we don't do the right thing for them.

80% of the time I load a .jpg to make some minor edits (use the Curves tool to adjust brightness, contrast or white balance, Crop to control composition and Scale to size an image for web use).

When doing that task the only change with 2.8 is that I must select "Export", instead of "Save As" from the File menu. No sweat!

Almost all of the other 20% of my time with the GIMP is making up collages of images or using the tools from producing fancy text or buttons or similar small decorative graphics for web sites.

In the past, I have sometimes regretted that I have not saved an .xcf, when I come to make changes to those images. The new approach the GIMP forces on me will encourage better practice.

In short, it makes perfect sense to me that a high end bitmap editor should, by default, save in its native format and export to other formats.

Just about every other program I know uses this pattern. Yes, it may mean I need to change my practices slightly, but it's hardly a chore and the change the GIMP team has decided to make, makes perfect sense to me.

Keep up the good work!

Greg Chapman http://www.gregtutor.plus.com
Helping new users of KompoZer and The GIMP

I have already made my thoughts known - I don't like the new system.

That said, I have three options: (1) adapt my work habits, (2) stay on 2.6. or (3) change the source.

There is a fourth option: the dev's revert to the old functionality. But, clearly, this is not going to happen.

Of the three options, I can do (3) but don't want the hassle of maintaining my local patches for evermore. Plus I'm too lazy. Option (2) just isn't practical. So, in a very Sherlock Holmes fashion, that leaves me with option (1).

I'm sure that, ultimately, this precisely what everyone is going to have to do.

But the number of posts over the last couple of days tell a story: This obviously is a very invasive and unwelcome change to the workflow of many people.

We have heard of how the GIMP change process works. I have no idea of what can be done to prevent a repeat of this type of issue.

But I humbly suggest that something must change.

The positive is that the dev's have responded in a balanced and informative way.

Finally, to the dev's: thanks for a great product - with one exception. ;) I have already made my thoughts known - I don't like the new system.

That said, I have three options: (1) adapt my work habits, (2) stay on 2.6. or (3) change the source.

There is a fourth option: the dev's revert to the old functionality. But, clearly, this is not going to happen.

Of the three options, I can do (3) but don't want the hassle of maintaining my local patches for evermore. Plus I'm too lazy. Option (2) just isn't practical. So, in a very Sherlock Holmes fashion, that leaves me with option (1).

I'm sure that, ultimately, this precisely what everyone is going to have to do.

But the number of posts over the last couple of days tell a story: This obviously is a very invasive and unwelcome change to the workflow of many people.

We have heard of how the GIMP change process works. I have no idea of what can be done to prevent a repeat of this type of issue.

But I humbly suggest that something must change.

The positive is that the dev's have responded in a balanced and informative way.

Finally, to the dev's: thanks for a great product - with one exception. ;)

Kev

---- kevin wrote:

I have already made my thoughts known - I don't like the new system.

That said, I have three options: (1) adapt my work habits, (2) stay on 2.6. or (3) change the source.

There is a fourth option: the dev's revert to the old functionality. But, clearly, this is not going to happen.

Of the three options, I can do (3) but don't want the hassle of maintaining my local patches for evermore. Plus I'm too lazy. Option (2) just isn't practical. So, in a very Sherlock Holmes fashion, that leaves me with option (1).

I'm sure that, ultimately, this precisely what everyone is going to have to do.

But the number of posts over the last couple of days tell a story: This obviously is a very invasive and unwelcome change to the workflow of many people.

some != many(relatively speaking of course)...

From my reading(I did not do a count), but it seemed that more people accepted the change as "it make sense even if I have to spend some time adjusting" vs "I can't live with this change".

I am not a dev on gimp, but I personally like the change. I HATE, HATE, HATE the damned popups in < 2.8 when I save jpeg/png files EVERY TIME!! For me, that really slows down "my" workflow. 99% of the work I do in gimp is with layers and is either editing an existing work(sometimes jpeg/png format, sometimes xcf) or creating something whole cloth from nothing.

Many times I take images other people are working on and perform a sample few operations on it to show a technique and then repost to a forum. Previously, if I edited a jpeg/png and exited, gimp would silently quit and I would loose my edit stack... now, I am properly warned that I modified a file and did not save to GIMP's internal format which would preserve that information. This is critical for me since there are times when the other person want's to know the steps as opposed to just seeing the end result. I do a LOT of editing where I add shadows to someone else's art work(again, as in to provide an example) and most of the time I create a 50% grey layer and use the dodge/burn tools to discretely build up high/lowlights. The main point here is not what is being done, but that I NEVER, EVER modify the original image if I can figure out a way around it(same thing with layer masks... never "erase" something, mask it!!!!)

All in all, I have still not gotten used to the change as of yet, but no matter what, it was the right thing to do.

For 2.10, perhaps, just perhaps I can see another solution to add a "open for quick edit" type menu item which would just open the file in native format and save out to same with no prompts(since it's an explicit action).

I do agree however with whoever said Overwrite is broken(based solely on their description). If you select Overwrite via menu or keyboard shortcut, you are explicitly telling GIMP you are sure of what you are doing, so why the prompts....

In short, it makes perfect sense to me that a high end bitmap editor should, by default, save in its native format and export to other formats.

Just about every other program I know uses this pattern.

What about Adobe Photoshop? Or doesn't proprietary software count? because that's the high end bitmap editor the vast majority of professionals use.

Just wondering. I'm not against the change; in my workflow it hardly makes any difference.

I.

From: jvromans@squirrel.nl
To: gimp-user-list@gnome.org
Date: Fri, 4 May 2012 08:28:36 +0200 Subject: Re: [Gimp-user] HATE the new save vs. export behavior

Richard Gitschlag writes:

It is true, however, that many professional and commercial apps do not make a save/export distinction and allow you to "save" your document in any supported filetype -- MS Word, for example. You can open/save a document in a non-native format at any time, all you get is an extra prompt when using the "Save" command which basically asks whether you do want to save it in a non-native format, noting that the format chosen may or may not support "some features" that your actual document may or may not even use.

The main problem is that this [non-native] file format is then silently used for subsequent saves, and that may not have been the intent.

-- Johan

That is actually a moot point in practice - the win32 "Save" dialog always defaults to the application's native format, so a random Save command will always use the app's native format unless the user explicitly selects otherwise. Most apps will also double-check the typed filename and append a matching extension if the user typed something else, just to prevent mistakes. E.g. if I want to save a "filename.jpg" in MS Paint but the filetype dropdown still said "bitmap", Paint won't save my "filename.jpg" in BMP format, it will save "filename.jpg.bmp" in BMP format.

-- Stratadrake strata_ranger@hotmail.com
--------------------

On Thursday 03 May 2012 15:53:31 (in 'Hate the new...' thread) I wrote:

I am not "repeatedly saving/exporting' to JPG", but only once per image (to write annotation),

Using Gimp 2.6 on a Mandriva system. I have happily been using a combination of Imagemagick's 'Convert' and Gimp to write annotation at the foot of certain directories of .jpg images:

(1) Place a white panel at the foot of each image:

--------------------------------------------- for img in *.jpg
do convert $img -gravity South -background White -splice 0x50 $img done
---------------------------------------------

(2) Take each image into Gimp (2.6), select Text, click on the white panel, and write the annotation into the white panel, then save/export (or whatever).
A very simple, smooth, and effective solution.

Now, however, I am working on Mageia-2 (Beta3), which provides Gimp 2.7.4, and - guess what - the Text function now works differently and (for my purpose) more clumsily, tripling the effort needed to write the text.

With 2.6, selecting Text and clicking on the white panel brought up a text-entry window, such that any text entered also appeared in a dynamic window in the white panel.
However, with 2.7.4, the text-entry window is much smaller, with no apparent adjustment control, and any text entered does *not* appear in the white panel.
(But I did discover that one could cut-paste from one to the other, though the dynamic box seems more difficult to adjust.)

So the previously simple process has become a messy slog.

Have I misssed some setting/adjustment in the new Text function?

(Alternatively, could anyone recommend a package that could perform the function of writing text into these image panels, please?)

Regards,

First off, I'll say that I understand the rationale for the newer save/export behavior, and even if it needed to be tweaked a little to provide a better user experience it's best for devs to see how people adjust and look at how feedback develops over the next months rather than simply giving up on their vision and reverting immediately because of a few naysayers.

(Someone could argue that the GIMP could identify times when other formats will serve just as well as xcf and then allow for saving. For instance, if you load a png, do a bunch of editing, and arrive at something that has only one layer, "saving" as png might seem appropriate. OpenRaster especially would usually do fine as a "save" format. But this might lead to complications, esp. because allowing saves to "weaker" lossless formats whenever you aren't using things that format is missing would mean whether you can save in your original format could change a lot during the course of editing an image.)

My main reason for writing here is to warn about the elitist attitude starting to show itself, which would harm the project in the long run. It's fine to target high-end use, but acting as though uses fall into two sharply distinct categories of "high-end" and "casual" and that one kind of user always uses it in "high-end" ways while others always use it in "casual" ways is totally farcical and counterproductive. The truth of the matter is that there is no sharp distinction. It's a continuum, both among uses and among users. Even a professional user may often want to use their favorite image editor to take care of some work that doesn't really require "high-end" capabilities. Appeal to the most technical professional users isn't a dominating reason for Photoshop's huge success or for whatever popularity the GIMP now enjoys. That success is at least as much because they give users whose needs could usually have been satisfied by something simpler an app with room to grow -- and the confidence that if something they're working on proves to be more demanding they won't be suddenly crashing against the limitations of their software.

Saying "Look, your use case means you might not understand the reasons behind our design decision right now" is perfectly fine. But some posts here have gotten way too close to "You're not 'high-end' enough to be a gimp user, so go away" which is destructive.

On Fri, May 4, 2012 at 9:17 PM, Daniel Jensen wrote:

My main reason for writing here is to warn about the elitist attitude starting to show itself, which would harm the project in the long run.

Saying "Look, your use case means you might not understand the reasons behind our design decision right now" is perfectly fine. But some posts here have gotten way too close to "You're not 'high-end' enough to be a gimp user, so go away" which is destructive.

Daniel,

Every change that touches workflows causes hatefests. In any software. Always. As a rule :) Even though we didn't so much _change_ workflows as _introduced_ one at last.

That change is there for a reason. And the reason is that we are trying to target a special group of users who have certain workflows and work on files in certain ways.

It's not possible to make this change without losing part of the user base. This had been understood from the very beginning. The work on usability improvement started in 2006 from interviews with _professionals_. If we targeted people with unsafe workflows, we would interview non-professionals. The direction of the development was publicly declared years ago (OK, it does sounds a bit like Vogons destroying Earth, I admit :)).

Now, personally, that is, not on behalf of the team, I think that anyone who is trying to imply that we hate users, or ignore users, or try to force something on them simply needs to calm down, go outside, breath some fresh air and spend a great time with friends or family. Then go back and discuss this as a grown-up person.

Honestly, I'm quite tired of all the shouting. If we didn't care about users, we wouldn't make this software freely available for everyone in the first place, or write the docs or do technical support, or answer the question why we made this change again and again and again. Somehow people tend to forget such things.

So, again, we never expected everyone to just love this change -- we have neither will nor means to enforce GIMP loving. But so far this change is an integral part of the product vision. It could be adjusted in the future. Or maybe not.

Simply put, it's all a matter of perspective and really boils down to how one approaches things that happen in life. One could view this as an opportunity to create an awesome image editor for people who never save project files, or start using such an editor. Or one could view this as another sign that the end of the world is rapidly approaching, and it's about time to start wearing paper bags on the head.

Alexandre Prokoudine http://libregraphicsworld.org

kevin writes:

I have already made my thoughts known - I don't like the new system.

That said, I have three options: (1) adapt my work habits, (2) stay on 2.6. or (3) change the source.

There is a fourth option: the dev's revert to the old functionality. But, clearly, this is not going to happen.

And a fifth option: write a plug-in that does what you want Save to do, perhaps involving gimp-file-save, and bind it to Ctrl-S.

I don't like the new model either, but I'm going to work with it for a while and see if I continue to feel that way. If I decide I still don't like the change, writing a plug-in seems like it should be a straightforward fix.

...Akkana

On 05/04/2012 02:10 PM, Akkana Peck wrote:

And a fifth option: write a plug-in that does what you want Save to do, perhaps involving gimp-file-save, and bind it to Ctrl-S.

I don't like the new model either, but I'm going to work with it for a while and see if I continue to feel that way. If I decide I still don't like the change, writing a plug-in seems like it should be a straightforward fix.

Akkana saves the world, my crystal ball proves accurate once again (see my earlier message in this thread), and all is well with teh world.

:o)

Steve

Alexandre,

That change is there for a reason. And the reason is that we are trying to target a special group of users who have certain workflows and work on files in certain ways.

As I said in my previous email, I understand the reasons and fundamentally agree with the change, and I really don't think the reasons only apply to "a special group of users." There really is no such sharply defined group.

There is a continuum of uses and of users, and the focus of the GIMP's vision is somewhat towards the "high end" of the use continuum. The justification for the export change is strongest for the uses which are in focus for that vision. Just as there is no way to always separate what you see in your visual field into the two categories "entirely in focus" and "not at all in focus," there's a gradation in how much particular real users' uses of the GIMP are in focus as developers pursue their vision. You can't separate folks into the categories of "users who always use the software in an idealized entirely 'high-end' way" and "users who always use the software in a completely 'casual' way." So the benefits of the save/export change are a gradation rather than a binary variable too. Sure, some people may be so offended by having to change either their keystrokes or their save patterns that they'll go elsewhere. But I'm convinced that will have more to do with their temperaments than their use patterns.

Now, personally, that is, not on behalf of the team, I think that anyone who is trying to imply that we hate users, or ignore users, or try to force something on them simply needs to calm down, go outside, breath some fresh air and spend a great time with friends or family. Then go back and discuss this as a grown-up person.

I fully agree with this and with most of the rest of what you've said, and I understand your frustration with the "shouting" way people are reacting to the change. I just think folks need to be careful about giving the wrong impression in their reactions to this "shouting." You know there is no "us vs them", no "either you're an exact instantiation of this idealized user with this idealized workflow or you need to stop using the software," etc. But less-informed people could start to get that impression from the way some of the early posts in this conversation went.

-Dan

On Fri, 4 May 2012 09:52:32 +0400 Alexandre Prokoudine wrote:

We don't know exactly what you do ing GIMP during those unsafe workflows.

About 90% of the time I load PNGs or jpegs (100s of them), edit them, and save them back in the same format - I don't have any necessity for XCF in these cases.

We don't know if the sequence of actions you do can only be performed in GIMP.

I'm not sure what this question means. Would you prefer I use another program instead of Gimp? I only use Linux (have been for 15-odd years), and Gimp is the only mature (bitmap) graphics editor I know.

We don't know if your choice of GIMP as a tool is justified by logic, habit or accident.

Choice (see previous point).

We don't know if you need this unsafe workflow all the time or half the time.

I'm not sure what's unsafe. I like the actual (2.6) flow for most of my work (see first point).

Note that I haven't installed the new Gimp yet. From what I can understand in the discussion is that Open still opens all formats, but Save doesn't save anything but XCF. That's just not logical, practical or even aesthetic.

It certainly is not intuitive. The operation should be symmetrical: If I open a PNG, save should save a PNG (unless I applied changes which would disappear if saved as a PNG, in which case I'd like a warning).

Which is, in fact, the behaviour we have now in 2.6, isn't it?

John

On Fri, May 4, 2012 at 4:03 PM, Steve Kinney wrote:

On 05/04/2012 02:10 PM, Akkana Peck wrote:

And a fifth option: write a plug-in that does what you want Save to do, perhaps involving gimp-file-save, and bind it to Ctrl-S.

I don't like the new model either, but I'm going to work with it for a while and see if I continue to feel that way. If I decide I still don't like the change, writing a plug-in seems like it should be a straightforward fix.

Akkana saves the world, my crystal ball proves accurate once again (see my earlier message in this thread), and all is well with teh world.

:o)

Steve _______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

A similar plug-in has been available for a long time (save & export) and included in my "Useful Plugins" download.

Francois. Presently reading the Gimp saving vs export list. thank you for the humor. "Arcana?!" I had to look that one up! And I am very well read, believe me. What a nice word. Are you in charge of the gimpuser.com site, or admin or whatever? Well, one good thing, at least through this fray I found your site. Dan Smith
Houston

On 5/3/12, Francois wrote:

On Thu, May 3, 2012 at 7:14 AM, Kasim Ahmic wrote:

I was just thinking like a toggle in the Preferences saying something like "Use old save/export method". But by default it's set to the new method.

Kasim.

I encourage you to carefully read intro at http://gui.gimp.org/index.php/Save_%2B_export_specification. It really explains why this option wouldn't make a lot of sense.

Alexandre Prokoudine
http://libregraphicsworld.org

I had a look to that page, and it made me understand that this option had been chosen by stiff, dogmatic and narrow-minded people who consider us, the users, vile and mentally limited cattle who needs to be evangelized by you, the programmers, enjoying the holy light and full understanding of the world's arcana...

--
Francois (via gimpusers.com)
_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

It certainly is not intuitive. The operation should be symmetrical: If I open a PNG, save should save a PNG (unless I applied changes which would disappear if saved as a PNG, in which case I'd like a warning).

And that's the point, GETTING rid of the damn warnings! For me, every single time I edit/create a jpeg/png file, this just goes to slow things WAY down. One dialog for export/ignore/cancel + if this is the first save, an additional one to set the quality. The change fixes that by forcing me to be be explicit(ie, I want to export).

Also, one slip of the finger in 2.6(Ignore instead of export) on that damned dialog box and low an behold all of my layer work is GONE, PERMANENTLY, FOREVER!!!! Now my nice workflow where I do lots of non destructive editing is for naught because I hit the wrong damn button. The goal here is to be damn sure that this type of silliness does not happen anymore by making you be explicit in your workflow. I know dozens of people who have lost tens or even hundreds of layers in a second by a mis-key and this change will totally prevent them from loosing work at the cost of some people having to adapt to change and spend and extra 2-4 seconds per image.

Do you really think your few extra seconds are more important than possibly hours worth of work by people who use the features of GIMP that take it far beyond a simple photo editor? BTW, I am high functioning autism, so I do not adapt to change well myself, but IMHO, this is a good change mainly because I have been burned by this exact problem before.

So 2.8 saves the history as well? Just wondering. On a Mac and still
looking...Course'n, it's a ppc mac so it probably won't work even when they do offer... Thanks.
Dan

On 5/4/12, jfrazierjr@nc.rr.com wrote:

It certainly is not intuitive. The operation should be symmetrical: If I open a PNG, save should save a PNG (unless I applied changes which would disappear if saved as a PNG, in which case I'd like a warning).

And that's the point, GETTING rid of the damn warnings! For me, every single
time I edit/create a jpeg/png file, this just goes to slow things WAY down. One
dialog for export/ignore/cancel + if this is the first save, an additional one
to set the quality. The change fixes that by forcing me to be be explicit(ie, I want to export).

Also, one slip of the finger in 2.6(Ignore instead of export) on that damned

dialog box and low an behold all of my layer work is GONE, PERMANENTLY, FOREVER!!!! Now my nice workflow where I do lots of non destructive editing
is for naught because I hit the wrong damn button. The goal here is to be damn
sure that this type of silliness does not happen anymore by making you be explicit
in your workflow. I know dozens of people who have lost tens or even hundreds of layers in a second by a mis-key and this change will totally prevent
them from loosing work at the cost of some people having to adapt to change and
spend and extra 2-4 seconds per image.

Do you really think your few extra seconds are more important than possibly hours
worth of work by people who use the features of GIMP that take it far beyond

a simple photo editor? BTW, I am high functioning autism, so I do not adapt to
change well myself, but IMHO, this is a good change mainly because I have been
burned by this exact problem before. _______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

Can I just ask Alexander Prokoudinea question then, since he's obviously very tied to the project intimately? Can I ask if this decision to go to export vs. save, is it somewhat based around needs of people running gimp without the interface, as a server component?
Just wondering.
Dan
Houston

On Fri, May 4, 2012 at 7:40 PM, Daniel Smith wrote:

Can I ask if this decision to go to export vs. save, is it somewhat based around needs of people running gimp without the interface, as a server component?

No - it has to do with these two items, specifically:

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

For myself, export/overwrite still seems clumsy when working on simple, one-off edits. OTOH, I no longer have to worry about accidentally flattening my 10-layer composition when saving a PNG and then forgetting to resave as XCF. I'm thinking the long-term gain of not having to recreate hours of work is a big enough carrot that I can bear the stick of forced overwrite/export. I'm still getting used to it though, and who knows - maybe export/overwrite can be refined a bit.

Just my 0.02 to keep the flame war moving along nicely ;)

Chris

Nothing like a flame war. Though I must say that I love these "topics" cause it lets a lot of info out about how people have their different workflows, etc. I'm on a Mac and thus relegated to 2.6 but I've leanred an awful lot from reading all said posts. I really love this list and the helpful nature and devotion. If people weren't interested, they wouldn't write. I'd love to get a GEGL list started in such a way. Dan
Houston

On 5/4/12, Chris Mohler wrote:

On Fri, May 4, 2012 at 7:40 PM, Daniel Smith wrote:

Can I ask if this decision to go to export vs. save, is it somewhat based around needs of people running gimp without the interface, as a server component?

No - it has to do with these two items, specifically:

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

For myself, export/overwrite still seems clumsy when working on simple, one-off edits. OTOH, I no longer have to worry about accidentally flattening my 10-layer composition when saving a PNG and then forgetting to resave as XCF. I'm thinking the long-term gain of not having to recreate hours of work is a big enough carrot that I can bear the stick of forced overwrite/export. I'm still getting used to it though, and who knows - maybe export/overwrite can be refined a bit.

Just my 0.02 to keep the flame war moving along nicely ;)

Chris

Yeah; file this decision under if it ain't broke, fix it anyway category. lol

Maybe there is a method to the developer's madness, but I've yet seen the reason why. Doubt it will get changed back now though, so I've just accepted it, but I've still not gotten use to it yet, and I've been running RC1 for a few weeks now. :)

For myself, export/overwrite still seems clumsy when working on simple, one-off edits. OTOH, I no longer have to worry about accidentally flattening my 10-layer composition when saving a PNG and then forgetting to resave as XCF. I'm thinking the long-term gain of not having to recreate hours of work is a big enough carrot that I can bear the stick of forced overwrite/export. I'm still getting used to it though, and who knows - maybe export/overwrite can be refined a bit.

Chris

You should be saving your .xcf file first, THEN save the PNG copy of it. Priorities :)

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

On Sat, May 5, 2012 at 11:56 AM, Lyle wrote:

Yeah; file this decision under if it ain't broke, fix it anyway category. lol

Maybe there is a method to the developer's madness, but I've yet seen the reason why. Doubt it will get changed back now though, so I've just accepted it, but I've still not gotten use to it yet, and I've been running RC1 for a few weeks now. :)

The total lack of respect in this thread (madness? really?) is disappointing. Where do all these feelings of entitlement come from?

I've been using the betas for a while (single-window on a tiling WM, whee!!) and it took all of 2 sessions to get used to the change. Its just a different key for the same behaviour, after all, no functionality has been removed. But of course writing rants to the ML and insinuating negative motives to the devs is preferable to retraining finger memory....

I had it too, I discovered in the previous version 2.7 and I was very disappointed about it. I vote for a reverse to the old and more intuitive way. Thanks and bye.
Kekko

The classic case of YMMV.

Some do love the new GIMP, while others prefer the old layout. Changes can be pretty difficult for others but ... I would camp with Oon-Ee Ng when he wrote, "and it took all of 2 sessions to get used to the change.

Face it. There are the GIMP users, and there are those who need to start looking for an alternative.

But for the PEACE IN THE WORLD, have respect for the developers. You are already getting their hard work for free. At least, don't post your messages with an attitude.

In general, I agree with you Archie. This discussion should be more civil but many posts calling for civility have come from people who want to divide the user base into two groups where one group is somehow more entitled to use GIMP than the other because of the things they do with GIMP.

I find that as unsettling as those who forget all the hard work the developers have done to bring GIMP to us all as a very useful tool.

Those that seem to want to divide the user base into the "professionals" and those others always point to the use of .xcf files as the norm for those who are the "target" users.

Well, I wonder of all the people who use GIMP, what is the percentage of people who use .xcf files as the usual format in which to save their work? Simple question. How many people use .xcf files regularly and how many don't? And is the use of .xcf files really the way to bifurcate the user community into those who should be using GIMP and those who shouldn't? If a person -- like myself -- uses GIMP to touch up digital photographs, should I be excluded from using GIMP because I don't save my work as .xcf files?

Archie Arevalo wrote:

The classic case of YMMV.

Some do love the new GIMP, while others prefer the old layout. Changes can be pretty difficult for others but ... I would camp with Oon-Ee Ng when he wrote, "and it took all of 2 sessions to get used to the change.

Face it. There are the GIMP users, and there are those who need to start looking for an alternative.

But for the PEACE IN THE WORLD, have respect for the developers. You are already getting their hard work for free. At least, don't post your messages with an attitude.

------------------------------------------------------------------------

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

On Sat, May 5, 2012 at 1:17 AM, John Coppens wrote:

On Fri, 4 May 2012 09:52:32 +0400 Alexandre Prokoudine wrote:

We don't know exactly what you do ing GIMP during those unsafe workflows.

About 90% of the time I load PNGs or jpegs (100s of them), edit them, and save them back in the same format - I don't have any necessity for XCF in these cases.

Sorry but this is simply not verbose enough. How exactly do you edit them? What kind of chnages do you apply? Tools and filters you use?

We don't know if the sequence of actions you do can only be performed in GIMP.

I'm not sure what this question means.

The question should be understood literally :) Is GIMP the only tool to get your job done?

We don't know if you need this unsafe workflow all the time or half the time.

I'm not sure what's unsafe.

Losing multiple layers, masks, extra channels etc. is unsafe.

Note that I haven't installed the new Gimp yet.

*sigh*

It certainly is not intuitive.

*sigh*

I wish people used _experience_ for judging things.

Alas, the misconception of intuition isn't going away either.

Alexandre Prokoudine http://libregraphicsworld.org

Just to add one more link to this long thread, do you remember when the Toolbox menus disappeared? How many people whined or screamed because this change ruined their way to use GIMP? How many people spoke about MY workflow, MY habits, MY opinion about this stupid change, and threatened to stick to version 2.4, to fork to a more sensible version, to give up and use something else, to develop their own GNU image processing program? How many people explained that GIMP developer were stupid, ignorant, arrogant, scornful, etc. (I can't find my thesaurus to add more synonyms)?

And now, how many people remember the Toolbox menus?

Olivier Lecarme

On 05/05/2012 11:14 AM, Olivier wrote:

Just to add one more link to this long thread, do you remember when the Toolbox menus disappeared? How many people whined or screamed because this change ruined their way to use GIMP? How many people spoke about MY workflow, MY habits, MY opinion about this stupid change, and threatened to stick to version 2.4, to fork to a more sensible version, to give up and use something else, to develop their own GNU image processing program? How many people explained that GIMP developer were stupid, ignorant, arrogant, scornful, etc. (I can't find my thesaurus to add more synonyms)?

And now, how many people remember the Toolbox menus?

That's the bane of UI developers... everybody has an opinion, so for one person who does the work, fifty others feel entitled to criticize.

Contrast to how many people are likely to have a look at the Cage tool code(*) and make helpful suggestions

(*) only taken as a potential example, nothing implied, I didn't read the code :)

On 2012-05-04 at 17:29 I said:

with 2.7.4, the text-entry window is much smaller, with no apparent adjustment control, and any text entered does not

appear in

the white panel.
(But I did discover that one could cut-paste from one to the other, though the dynamic box seems more difficult to adjust.)

So the previously simple process has become a messy slog.

Have I misssed some setting/adjustment in the new Text

function?

What was the purpose of the 2.7.4 change to the Text function? In what sense is it an improvement? Who is supposed to benefit?

I am willing to adapt to the new way if there is a way of adjusting it to perform as conveniently as in 2.6...

Regards,

On Sat, May 5, 2012 at 12:21 PM, Ken Warner wrote:

but many posts calling for civility have come from people who want to divide the user base into two groups where one group is somehow more entitled to use GIMP than the other because of the things they do with GIMP.

You know, it's quite frustrating that after all the explanations people still seem to get this wrong. So let's try again.

We are not separating people into better of worse users, or the deserving and non-deserving, or entitled and not entitled. This would not be a constructive approach.

What we _are_ doing is _focusing_ on a group of users who are underloved by free software. We are building workflows around their needs. We are _targeting_ those users.

Maybe not everyone can see the difference, but it's right there. Hence attributing any kind of discrimination to us would be utterly wrong. I wish people really stopped doing that.

Alexandre Prokoudine http://libregraphicsworld.org

Is it really that complicated to change the menus and dialog boxes or the existence of them based around user preferences?
Is there a link anywhere to how it's written? I can guarantee you that when I worked in a big graphics house they'd find a way to alter them. Dan

Personally I like these new changes. Alexander is quite correct about that it is notfor not wanting "light users" but adding suport which was not there for those in real need for something more. This something more is that when you work with layers, lots of ioperations, you get all this in the autosave instead of overwriting this by mistake. This is quite an important feature - overwriting advanced edits by mistake has always been a pain in the neck - also in windows based MS programs or Adobe.

Thanks for the good work.

On Sat, 5 May 2012 18:30:02 +0400, Alexandre Prokoudine wrote:

On Sat, May 5, 2012 at 12:21 PM, Ken Warner wrote:

but many posts calling for civility have come from people who want to divide
the user base into two groups where one group is somehow more entitled to
use GIMP than the other because of the things they do with GIMP.

You know, it's quite frustrating that after all the explanations people still seem to get this wrong. So let's try again.

We are not separating people into better of worse users, or the deserving and non-deserving, or entitled and not entitled. This would not be a constructive approach.

What we _are_ doing is _focusing_ on a group of users who are underloved by free software. We are building workflows around their needs. We are _targeting_ those users.

Maybe not everyone can see the difference, but it's right there. Hence
attributing any kind of discrimination to us would be utterly wrong. I
wish people really stopped doing that.

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

On 05/05/2012 10:30 AM, Alexandre Prokoudine wrote:

On Sat, May 5, 2012 at 12:21 PM, Ken Warner wrote:

but many posts calling for civility have come from people who want to divide the user base into two groups where one group is somehow more entitled to use GIMP than the other because of the things they do with GIMP.

You know, it's quite frustrating that after all the explanations people still seem to get this wrong. So let's try again.

We are not separating people into better of worse users, or the deserving and non-deserving, or entitled and not entitled. This would not be a constructive approach.

What we _are_ doing is _focusing_ on a group of users who are underloved by free software. We are building workflows around their needs. We are _targeting_ those users.

Maybe not everyone can see the difference, but it's right there. Hence attributing any kind of discrimination to us would be utterly wrong. I wish people really stopped doing that.

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre,

Please allow me a few words...

a) The users whose workflow has been made more difficult are _understandably_ upset. They were using a program in a certain way that worked well for them. However, either unknown to them (maybe they should have been paying more attention?) the focus of the developers changed/evolved over time in a way that is not helpful to those users AND/OR those users simply did not realize (months and years ago) that they were using a program that was going to move away from the way in which they were using it.

Part of what seems to be missing here is humility and respect on the part of the developers ... would it be too hard to simply say "We are sorry ... even though we are the ones doing the work and we have chosen to go in a particular direction, WE ARE SORRY!" Sometimes those simple words can go a very long way. It is like saying "I am sorry for your loss"... there is not a darn thing that I can do about the fact that Uncle Harold has died, but I _am_ sorry that it has happened and that your life will change as a result.

On the other side, however, the upset users have not, IMHO, shown adequate understanding or appreciation for what the developers have GIVEN to them over the years. Maybe it is a case of a good thing that must come to an end for certain users.

b) The users could have paid more attention to the conversations the developers were having ... I am an "ordinary" user and *I* knew this was coming because I monitor the developer list.

c) The developers UTTERLY FAILED to manage public relations on this. It was completely obvious to me (from monitoring the discussions on the developer list) that this subject was going to touch of an enormous storm of anger among some users.

If the developers don't like the angry reaction they have received, perhaps the developers should examine how they could have done a better job of communication ON THE USER LISTS to warn people of what was coming. I am not saying "ask", I am saying "warn".

In what I have observed over the years as rather typical attitude by open-source developers, the developers did not seem to think about (and certainly did not execute) good ADVANCE public relations on this subject. The attitude of "we did it, like it or leave it" is just not well received in this day and age.

At the same time, users must understand that the developers are (despite what the developers might think), only human. They are fallible. They screw up. They make bad decisions. However, the developers are the ones doing the work!!!! Anybody that does not like the direction that an open-source program is going can branch off and do their own work. I know that 99.99% of users, like me, do not have the skills to do that, but that is the price we users pay for using free software.

Users of open-software have an extremely high loyalty and commitment to the particular software they use. They feel that it is "theirs". That they "own" it. That is all well and good until the software goes in a direction that is different from where the user wants it to go -- when that happens, there is great anger because there is great emotional loss. Developers have a responsibility to at least understand this concept and to attempt to mitigate users' feelings of loss and to prepare them in advance for inevitable changes.

If developers don't feel that they have such a "responsibility" -- which would be a reasonable opinion on a developer's part -- the developer must accept the anger that will come. It is inevitable; thinking otherwise is unsound.

d) As I said, I monitored, and participated a bit, in the developer discussion about save/export when implementation was being discussed. I described my workflow and how the proposed change would negatively affect me and users like me.

At that time export may have been part of the goals for the program, but it seemed that all aspects were still open for discussion.

In that process, despite a few people (it was a developer list, after all) saying "what about ordinary users", I had the sense that very little respect was given for the impact that this change was going to have on ordinary users.

I did not feel that, in those discussions, there was any serious consideration of possible ways that the needs of BOTH sides could be satisfied.

In summary... I completely understand the reasons behind the export behavior and I agree that it is critically important to many users. However, with so many thousands of users who do not use the "export workflow" that is needed by so many other users, there _must_ be a way that the "old" save method can be "turned on" -- that users can switch from one workflow method to the other.

I completely respect that the developers have a particular "target" user base in mind for the program -- and that must guide development. Just as this is not a word processor, this is not a "simple" image editor. However, take a hard look at the existing user base, and ask if it would really be so difficult to in some way make the "old" save method (efficiently) available for those users. In my opinion, doing so would not dumb-down or lessen the wonderfulness of the program.

Jay

On Sat, May 5, 2012 at 6:42 PM, Daniel Smith wrote:

Is it really that complicated to change the menus and dialog boxes or the existence of them based around user preferences?
Is there a link anywhere to how it's written? I can guarantee you that when I worked in a big graphics house they'd find a way to alter them.

Well, adding options that change behavior of an application always has some consequences.

1) The code gets messier, especially if you keep adding things on top. E.g. think of the proposed solution for native CMYK separation -- it is supposed to benefit from the new model where the internal data is 32bit float linear RGB, and everything else is exporting material that's being worked on in a separate projection.

2) Documentation and tutorials become confusing.

That's just off top of my head.

Alexandre Prokoudine http://libregraphicsworld.org

I didn't mean for Gimp proper to offer different versions or make it part of the program in preferences etc. I meant where are the files that determine what the dialog boxes and menus say, and where exporting and/or saving are accomplished to? It can't be that hard, you're just talking about meta files or something, right? Dan

On 5/5/12, Alexandre Prokoudine wrote:

On Sat, May 5, 2012 at 6:42 PM, Daniel Smith wrote:

Is it really that complicated to change the menus and dialog boxes or the existence of them based around user preferences?
Is there a link anywhere to how it's written? I can guarantee you that when I worked in a big graphics house they'd find a way to alter them.

Well, adding options that change behavior of an application always has some consequences.

1) The code gets messier, especially if you keep adding things on top. E.g. think of the proposed solution for native CMYK separation -- it is supposed to benefit from the new model where the internal data is 32bit float linear RGB, and everything else is exporting material that's being worked on in a separate projection.

2) Documentation and tutorials become confusing.

That's just off top of my head.

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

On Sat, May 5, 2012 at 7:04 PM, Jay Smith wrote:

c) The developers UTTERLY FAILED to manage public relations on this. It was completely obvious to me (from monitoring the discussions on the developer list) that this subject was going to touch of an enormous storm of anger among some users.

If the developers don't like the angry reaction they have received, perhaps the developers should examine how they could have done a better job of communication ON THE USER LISTS to warn people of what was coming. I am not saying "ask", I am saying "warn".

In what I have observed over the years as rather typical attitude by open-source developers, the developers did not seem to think about (and certainly did not execute) good ADVANCE public relations on this subject. The attitude of "we did it, like it or leave it" is just not well received in this day and age.

Jay,

What you wrote above is more or less the reason why I took the responsibility of handling public relations in the project last year. We haven't had a dedicated team member for that in years (ever since Dave Neary left in 2006 or so). Hence it's still going to take a while till I can safely say that we are on top of this.

However I stlll find it highly disturbing that so many people felt that the project wasn't doing dccent PR work, and yet noone else volunteered. If I'm run down by a truck tomorrow, what is the community going to do about the lack of a PR person again?

What is the community going to do about the ongoing situation with Mac builds when even the team has no idea (yet) what's going on there?

What is the community going to do about the lack of really good tutorials that sell GIMP instead of undermining its reputation?

Which member of the community is going to email Apress and tell them (s)he's capable of and willing to write the book on advanced techniques with GIMP that they still haven't found an author for?

Are we a givers or takers community? Are we makers or consumers?

Input appreciated :)

Alexandre Prokoudine http://libregraphicsworld.org

gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

On 05/05/2012 10:30 AM, Alexandre Prokoudine wrote:

We are not separating people into better of worse users, or the deserving and non-deserving, or entitled and not entitled. This would not be a constructive approach.

What we _are_ doing is _focusing_ on a group of users who are underloved by free software. We are building workflows around their needs. We are _targeting_ those users.

And this is the key to progress. Maximum quality, not maximum convenience, is the guiding principle in GIMP development. That's why I am still using it "after all this time." All users will not agree on all changes, but the users who best understand the GIMP, and who bump their heads on its limitations from time to time, are the ones whose input drives progress. That's the only way forward. Targeting a hypothetical "average" user is a downward spiral as each "generation" of new average users learns and does less and less.

New users will benefit from immediate exposure to the "professional paradigm" and start paying attention to file formats from day one. Long time users who often (or always) find no use for the XCF format, will have to relearn or remap a keyboard shortcut or two to keep the same speed & convenience they are used to. Long time users who routinely save their work in XCF won't notice a major difference.

And really... guise... If you don't need the new GIMP color model, you don't need the new version of GIMP. I am guessing that is approximately 100% of users who don't routinely save most files in XCF as "part one" of their usual workflow. It's not like you need to keep your GIMP version current for the sake of security patches or compatibility with external applications. Keeping the "old" GIMP also means that all your favorite plugins and scripts will keep right on doing exactly what you expect them to do.

:o)

Steve

On Fri, May 4, 2012 at 11:19 PM, Richard Gitschlag wrote:

You should be saving your .xcf file first, THEN save the PNG copy of it. Priorities :)

Indeed. I also try to "Save As" every hour or so and bump up the version of the XCF. Disk space is cheap ;)

But mistakes can happen, particularly when under a punishing deadline.

Chris

On Sat, May 5, 2012 at 10:04 AM, Jay Smith wrote:

c) The developers UTTERLY FAILED to manage public relations on this.  It was completely obvious to me (from monitoring the discussions on the developer list) that this subject was going to touch of an enormous storm of anger among some users.

I don't think this is accurate. I've seen quite a lot of PR and news items over the 2.6->2.8 time period, some of which did cover the new Save/Export functions, IIRC and not just on the dev list.

Having written some really basic in-house programs, my anecdotal evidence suggests that almost *any* change will cause at least some portion of the users to hate you ;)

Chris

Is it really that complicated to change the menus and dialog boxes or the existence of them based around user preferences?
[...]
Dan
_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

Hold that thought -- could the save/export distinction be made a User Preference? That would satisfy the parties on both ends. The default setting would be the new behavior (of course), but for those who prefer the old behavior they could enable that in their user preferences and there we go.

It's not like the message that tells you the Save command is only for the XCF format can't possibly redirect to the Export command....

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

On Sat, May 5, 2012 at 10:33 AM, Alexandre Prokoudine wrote:

However I stlll find it highly disturbing that so many people felt that the project wasn't doing dccent PR work, and yet noone else volunteered. If I'm run down by a truck tomorrow, what is the community going to do about the lack of a PR person again?

Please, please look both ways when crossing the street!

Seriously, I'm not at a place where I can volunteer much in the way of time or resources. I wish that I could though, and I'm grateful that you are doing so much these days.

Chris

Date: Sat, 5 May 2012 14:19:49 +0800 From: ngoonee.talk@gmail.com
To: forums@gimpusers.com
CC: team@gimpusers.com; gimp-user-list@gnome.org Subject: Re: [Gimp-user] HATE the new save vs. export behavior

... (single-window on a tiling WM, whee!!) ....

Speaking of which, the new single-window mode was one of the biggest reasons I decided to download 2.8.0 as an RC1 instead of waiting for the fully prepared 2.8.0 to come out. Every single time I opened ANY image (.xcf or otherwise) in GIMP 2.6 the absolutely first thing I had to do was move/size the image window in order to make sure that parts of it (menus or scrollbars, say) weren't getting buried underneath the toolboxes on the sides. And changing the window hints on the toolboxes or saving window positions did not resolve this matter any.

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

At the risk of committing a mailing list etiquette fopah... I'm reposting as I got no response and I am hoping one of the developers can actually shed light on this:

On 5/3/2012 8:15 AM, Jay Smith wrote:

Jonathan, I hope that you realized that when editing a JPG, repeatedly saving/exporting to JPG (your step 4) reduces the quality (actually compresses / deletes data).

GIMP doesn't reload the file after exporting, does it? If not, then the image in the GIMP's buffer should be the same high quality image it was prior to the export. Given that, as long as you don't exit the GIMP or reload the image from the exported file, multiple exports to a lossy format shouldn't cause loss of quality.

For example, if you do an export to jpeg and compress down to 15%, with the preview option set you can clearly see the loss of quality in the written image. However, when the export is complete, the image in the buffer reverts to the high quality it was prior to the export.

This implies multiple exports to a lossy format should *not* result in loss of image quality. However, *re-loading* an image previously saved to a lossy format and then exporting again will result in degradation.

Is there something I'm missing?

Gary

Hi,
strata_ranger@hotmail.com (2012-05-04 at 2119.16 -0700):

OTOH, I no longer have to worry about accidentally flattening my 10-layer composition when saving a PNG and then forgetting to resave as XCF.
Chris

You should be saving your .xcf file first, THEN save the PNG copy of it. Priorities :)

Exactly, I had not worried in a long time, as always saved to XCF, and used save a copy for the JPG or whatever when needed. Now it seems save a copy is becoming redundant, if I need yet another XCF, I can duplicate the image and save that.

So I am on the wall about how the new system will play for quick things (pretty common when tweaking a texture for a game or doing a raw "this what I mean" sketch) in the long run, as the issue that supposedly fixes, was a non issue already while mental load is increased with new commands and remembering if the complains about "not saved" matter or not.

GSR

i have modified the sources...

2012/5/5 GSR - FR

Hi,
strata_ranger@hotmail.com (2012-05-04 at 2119.16 -0700):

OTOH, I no longer have to worry about accidentally flattening my 10-layer composition when saving a PNG and then forgetting to resave as XCF.
Chris

You should be saving your .xcf file first, THEN save the PNG copy of it. Priorities :)

Exactly, I had not worried in a long time, as always saved to XCF, and used save a copy for the JPG or whatever when needed. Now it seems save a copy is becoming redundant, if I need yet another XCF, I can duplicate the image and save that.

So I am on the wall about how the new system will play for quick things (pretty common when tweaking a texture for a game or doing a raw "this what I mean" sketch) in the long run, as the issue that supposedly fixes, was a non issue already while mental load is increased with new commands and remembering if the complains about "not saved" matter or not.

GSR

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

i also have modified this code:

*gimp base folder/app/paint/gimppaintoptions.c*

*#define DEFAULT_BRUSH_SIZE 50.0*

#define DEFAULT_BRUSH_ASPECT_RATIO 0.0

#define DEFAULT_BRUSH_ANGLE 0.0

*gimppaintoptions-gui.c*

*scale = gimp_prop_spin_scale_new (config, "brush-size",*

*_("Size"), **1, 1.0, 2);*

* *

*
*

*
*

*
*

2012/5/6 Andrea Verdi

i have modified the sources...

2012/5/5 GSR - FR

Hi,
strata_ranger@hotmail.com (2012-05-04 at 2119.16 -0700):

OTOH, I no longer have to worry about accidentally flattening my 10-layer composition when saving a PNG and then forgetting to resave as XCF.
Chris

You should be saving your .xcf file first, THEN save the PNG copy of it. Priorities :)

Exactly, I had not worried in a long time, as always saved to XCF, and used save a copy for the JPG or whatever when needed. Now it seems save a copy is becoming redundant, if I need yet another XCF, I can duplicate the image and save that.

So I am on the wall about how the new system will play for quick things (pretty common when tweaking a texture for a game or doing a raw "this what I mean" sketch) in the long run, as the issue that supposedly fixes, was a non issue already while mental load is increased with new commands and remembering if the complains about "not saved" matter or not.

GSR

_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-user-list

During my trialling of Mageia-2 (Beta3) I find it provides Gimp 2.7.4, but the Text function doesn't work as in 2.6.

I would be most grateful if someone could confirm this (as it might be some setting I've missed):

With Gimp 2.7.4 (and presumably later), if you select 'Text' (the big 'A'), then click somewhere on an image, two things will appear:

(1) At the place where you clicked, a 'dynamic' window* will appear (2) Above it a text-entry window will appear.
When text is entered into (2), it does *not* appear in (1). Agreed? (Whereas with Gimp 2.6, it *does*.)
Can anyone see how to make the text also appear in the 'dynamic' window (apart from manual Copy/Paste)?

(* I don't know what the Gimp term for that window is.)

Many thanks!

Maurice writes:

I would be most grateful if someone could confirm this (as it might be some setting I've missed):

With Gimp 2.7.4 (and presumably later), if you select 'Text' (the big 'A'), then click somewhere on an image, two things will appear:

(1) At the place where you clicked, a 'dynamic' window* will appear (2) Above it a text-entry window will appear.
When text is entered into (2), it does *not* appear in (1). Agreed? (Whereas with Gimp 2.6, it *does*.)

With 2.8RC1:

(1) A window appears showing the current font settings (2) A 'dynamic window' appears where the text entered appears.

Did you abuse the Font field of the font settings window for text entry?

I must admit that I haven't yet figured out how to use the font settings 'window'.

-- Johan

On Sat, 5 May 2012 12:32:22 +0400 Alexandre Prokoudine wrote:

I'm not sure what this question means.

The question should be understood literally :) Is GIMP the only tool to get your job done?

I wrote a couple of macros in Guile which help me, so Gimp is my preferred tool, yes. Say 95% of bitmap editing is done in Gimp. For vector work, I use Inkscape (which, BTW, has a very convoluted file file flow).

We don't know if you need this unsafe workflow all the time or half the time.

I'm not sure what's unsafe.

Losing multiple layers, masks, extra channels etc. is unsafe.

Options for people who loose Y hours of work by slips of fingers:

-When starting to edit, why not immediately do a Save as xxx.xcf?

-Why not add (to Gimp) the possibility to maintain an autosave copy in (.XCF format) each N minutes? And not delete it for X days?

-Why not make the Undo buffer for the last N edited images persistent for X days? Disk space is generally not an issue.

John

On 05/06/2012 10:51 PM, John Coppens wrote:

-When starting to edit, why not immediately do a Save as xxx.xcf?

That's what I do and it has come in very handy.

-Why not add (to Gimp) the possibility to maintain an autosave copy in (.XCF format) each N minutes? And not delete it for X days?

I would not use that. For instance, just a couple of minutes ago I opened an XCF file, merged several layers for convenient export of some image elements to another XCF file, and closed the file without saving. If an autosave hit in the middle of that, it would "commit" this strictly temporary state to my source file, wiping out layers I need to keep if I closed the file - or somebody tripped over the power cord - before reverting the changes.

-Why not make the Undo buffer for the last N edited images persistent for X days? Disk space is generally not an issue.

That's an interesting idea. Over the years I have heard a lot people "wishing" out loud that they could undo changes in a saved image after closing out. Still though, there have been times when I had to repeatedly flush the undo buffer when using an older/slower machine to work on "big" files - a day's work could add up to gigabytes of saved buffer in some instances...

:o)

Steve

Hi,
admin@pilobilus.net (2012-05-06 at 2324.04 -0400):

-Why not add (to Gimp) the possibility to maintain an autosave copy in (.XCF format) each N minutes? And not delete it for X days?

I would not use that. For instance, just a couple of minutes ago I opened an XCF file, merged several layers for convenient export of some image elements to another XCF file, and closed the file without saving. If an autosave hit in the middle of that, it would "commit" this strictly temporary state to my source file, wiping out layers I need to keep if I closed the file - or somebody tripped over the power cord - before reverting the changes.

When people talk about autosaves, they normally mean saving to something like foo.xcf.auto, without touching the foo.xcf file at all. It is a pretty common feature of old text editors and many other apps, as in case of a program crash or a full system power off, your work is not completly lost, and you can decide if using whatever it managed to rescue is good or you prefer going back to the original file.

GSR

On Sun, 06 May 2012 23:24:04 -0400 Steve Kinney wrote:

On 05/06/2012 10:51 PM, John Coppens wrote:

-When starting to edit, why not immediately do a Save as xxx.xcf?

That's what I do and it has come in very handy.

-Why not add (to Gimp) the possibility to maintain an autosave copy in (.XCF format) each N minutes? And not delete it for X days?

I would not use that. For instance, just a couple of minutes ago I opened an XCF file, merged several layers for convenient export of some image elements to another XCF file, and closed the file without saving. If an autosave hit in the middle of that, it would "commit" this strictly temporary state to my source file, wiping out layers I need to keep if I closed the file - or somebody tripped over the power cord - before reverting the changes.

As 'GSR' also commented there are quite a few ways to avoid this problem. The autosave could save a copy with the same name in a temp directory, or add hashes (#yourfile.xcf#) or any other idea.

-Why not make the Undo buffer for the last N edited images persistent for X days? Disk space is generally not an issue.

That's an interesting idea. Over the years I have heard a lot people "wishing" out loud that they could undo changes in a saved image after closing out. Still though, there have been times when I had to repeatedly flush the undo buffer when using an older/slower machine to work on "big" files - a day's work could add up to gigabytes of saved buffer in some instances...

No doubt. Not unlike the cache of a browser... It's scary how much info gets saved in a machine, mostly never to be used again. But still, gigabytes are getting cheaper by the minute. Where's the time I my first harddisk was 20-odd MB ;-)

John

Count me on this. The previous behavior of Save/Save As was just fine. Save As did exactly what Export is doing now, without giving me grief over me format choice. Reason around it and praise the change as the holy frail if you want, it's still retarded and makes no sense. Save As doesn't overwrite the existing image, so there is no reason for the program to force this silly assed Export function on me or anyone else. Avoiding accidental overwrite using Save is avoided with a quick "are you sure?" dialog. Pushing this whole new system feels like training wheels to me. Assuming I'm not smart enough to not goof my own work.

Nevermind the preview function is apparently broken in the Export dialog. I went to save a small image as jpg in it, and it tells me the resulting file will be 1.3GB in size. In reality it ends up 193KB. 2.6 didn't have these issues. 2.6 worked in a fashion that made sense. Maybe I'll just go back to 2.6. :-/

Now you will get nasty-grams telling you that your workflow is "unsafe" or that you should be looking for an alternative to GIMP or that .xcf files are obviously the only choice for "professionals" and just about any other nonsense the developers use to justify what is obviously a self serving design change that they don't know how to back away from without losing face.

BTW: I agree with your sentiments 100%.

Red_Chaos1 wrote:

Count me on this. The previous behavior of Save/Save As was just fine. Save As did exactly what Export is doing now, without giving me grief over me format choice. Reason around it and praise the change as the holy frail if you want, it's still retarded and makes no sense. Save As doesn't overwrite the existing image, so there is no reason for the program to force this silly assed Export function on me or anyone else. Avoiding accidental overwrite using Save is avoided with a quick "are you sure?" dialog. Pushing this whole new system feels like training wheels to me. Assuming I'm not smart enough to not goof my own work.

Nevermind the preview function is apparently broken in the Export dialog. I went to save a small image as jpg in it, and it tells me the resulting file will be 1.3GB in size. In reality it ends up 193KB. 2.6 didn't have these issues. 2.6 worked in a fashion that made sense. Maybe I'll just go back to 2.6. :-/

Count me in too.

Here's my point of view: every sane app out there uses "Save", "Save as..." and "Export" for a conventional and now well assumed behaviour:

“Save” means “overwrite the original file”, period (it turns itself into "Save as..." when the file is new and has never been saved).

“Save as…” means “save to a new file with a different name and/or format”.

“Export” means “put the contents of the current document in a file of a nature this app isn’t intended to handle”. (At the same time “Import” means “bring data from an alien file and convert it into what this app is intended to handle”.) For instance, saving a spreadsheet to a text file or a word processing document to a non-editable file format (PDF or picture). In the Gimp, Export should be reserved for PDF, ASCII art or any other file type that isn’t a picture.

And these are the meanings every well designed app uses and for a good reason: the basis of the WIMP paradigm is that once you learn what basic UI idioms mean, you don’t have to relearn them for the next app.

The "overwrite" solution is a sorry workaround for a problem that didn't exist.

Telling users "this app is not for you" is beyond elitist. In the case of the Gimp, which is still vying for a place in the professional arena, it's plain ridiculous. Are you guys really trying to put away a big portion of your comparatively minuscule user base??? Really???

Finally, may I ask the devs who was asking them for this change? Can you guys point to bugs, forum or mailing lists posts asking to please change the old behavior? Can you just prove the need for this beyond your own personal preferences or agenda for pushing XCF?

For a long while, FLOSS applications have been accused of ignoring usability issues. Suddenly it seems developers are overreacting to that and so we saw the coming of Gnome Shell. Now the GIMP too???

Now you will get nasty-grams telling you that your workflow is "unsafe" or that you should be looking for an alternative to GIMP or that .xcf files are obviously the only choice for "professionals" and just about any other nonsense the developers use to justify what is obviously a self serving design change that they don't know how to back away from without losing face.

BTW: I agree with your sentiments 100%.

Red_Chaos1 wrote:

Count me on this. The previous behavior of Save/Save As was just fine. Save As did exactly what Export is doing now, without giving me grief over me format choice. Reason around it and praise the change as the holy frail if you want, it's still retarded and makes no sense. Save As doesn't overwrite the existing image, so there is no reason for the program to force this silly assed Export function on me or anyone else. Avoiding accidental overwrite using Save is avoided with a quick "are you sure?" dialog. Pushing this whole new system feels like training wheels to me. Assuming I'm not smart enough to not goof my own work.

Nevermind the preview function is apparently broken in the Export dialog. I went to save a small image as jpg in it, and it tells me the resulting file will be 1.3GB in size. In reality it ends up 193KB. 2.6 didn't have these issues. 2.6 worked in a fashion that made sense. Maybe I'll just go back to 2.6. :-/

On 05/16/2012 10:13 AM, Sicofante wrote:

“Save as…” means “save to a new file with a different name and/or format”.

“Export” means “put the contents of the current document in a file of a nature this app isn’t intended to handle”. (At the same time “Import” means “bring data from an alien file and convert it into what this app is intended to handle”.) For instance, saving a spreadsheet to a text file or a word processing document to a non-editable file format (PDF or picture). In the Gimp, Export should be reserved for PDF, ASCII art or any other file type that isn’t a picture.

A picture isn't always editable... You cannot really re-edit a GIF, for instance, because if you need new colors you are definitely not going to have the same result as if you had edited the original XCF and exported it to GIF again.

Sicofante writes:

“Save” means “overwrite the original file”, period

This is true for applications that simply on a specific file and can store/restore all relevant informatin the that file format. This is, indeed, the majority of applications.

However, several applications that deal with more complex data have exactly the behaviour GIMP now has. For example, Audacity opens MP3 or WAV but "Save" means: "Save as AUP (Audacity format)". To get MP3 or WAV, use "Export". Scribus also behaves similar. When you open an EPS with Inkscape, "Save" will save an SVG.

One thing I do, however, slightly agree with you. When for example working on a PNG, saving it (as XCF), and then export repeatedly as PNG I wonder whether it should ask *every* *time* if it's okay to overwrite the file.

-- Johan

Johan Vromans (jvromans@squirrel.nl) wrote:

One thing I do, however, slightly agree with you. When for example working on a PNG, saving it (as XCF), and then export repeatedly as PNG I wonder whether it should ask *every* *time* if it's okay to overwrite the file.

If you use CTRL-E for "Export to " (which is available after the first export after saving to xcf) it does not ask for permission to overwrite.

If you did not save to xcf there is a menupoint "Overwrite " which also doesn't ask for confirmation. It does not have a keyboard shortcut by default though.

Bye, Simon

Date: Wed, 16 May 2012 14:38:43 +0200 From: simon@budig.de
To: gimp-user-list@gnome.org
Subject: Re: [Gimp-user] HATE the new save vs. export behavior

If you use CTRL-E for "Export to " (which is available after the first export after saving to xcf) it does not ask for permission to overwrite.

If you did not save to xcf there is a menupoint "Overwrite " which also doesn't ask for confirmation. It does not have a keyboard shortcut by default though.

Which
is because they are not the even same command (file-export versus file-overwrite), and word from the GIMP bugtracker says that this was very intentional. This also means that once they fix the bug that both export/overwrite commands are accessible regardless of which one is visible on the menu (yes that is a bug), hitting Ctrl+E in the latter case will do absolutely nothing. Which while not technically a bug is DEFINITELY a regression for the end user.

You can still assign a shortcut for it yourself (look for file-overwrite in your Keyboard Shortcuts screen), maybe Ctrl+Alt+E.

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

I won't use the word hate; just dislike. I still remember when they changed the function by swapping what dilate and erode did. Also, when the redefined how Script-fus were to be formated; what a debacle. lol

GIMP's changed over time and getting better. I know the arguments for doing what they did but I still like the old way since I hate change. :)

Jonathan Kamens wrote:

I hate the new Save vs. Export behavior. It is completely non-intuitive to me, it makes my brain stumble every time I try to do just about any of the things that I do in GIMP on a regular basis, and it makes most of my workflows take more thought and more button clicks / key presses than they used to.

Thank you Jonathan for this post, you described well what I'm feeling too.

For png pictures, I often open 10 or 15 small png pictures for edition, I just want to change some colors or add a little thing, and now when I overwrite or "export" to png (it's technically not an export because my original picture was also in this format), then the picture's name is lost, it's irritating when we need to work further on the pictures, because we can't find it any longer thanks to the window's name.

- I don't understand why the original filename, including the original extension are not kept in the window's name after an overwrite or an export.

- I don't understand why we can't overwrite more than once (otherwise I would just remap the ctrl+s to overwrite) - I don't understand why the "overwrite" option is not active when we open an xcf file, it could just save the file in the same format as it was open, like for png, jpg or tiff.

I don't want to develop further, I just hope enough users will complain so developpers will go back to the old behavior, or at least make this "idiot-proof" save scheme an option which can be disabled for normal, aware, user. It takes 5 minutes to read an explanation on how raster images works (you can still redirect newcomers to https://en.wikipedia.org/wiki/JPEG#Effects_of_JPEG_compression ), it's a pity to affect the behavior of Gimp because of this.

Late to the discussion:

I can see the need for a more professional product, and heartily approve of most of the changes I have seen in 2.8. I even see the reasons behind the Save/Export changes, in terms of a professional workflow, of file/process safety, and in cleaning up terminology.

The problem with the "professional paradigm," though, isn't necessarily that it's not better/safer, etc., it's that no printer in an 80 mile radius uses the GIMP's XCF format, nor do any of the local graphic designers. All of them, however, can open TIFF, JPG, GIF, and BMP. All of the printers and all but one of the graphic designers can handle PSD (the last one uses PSP).

As a FLOSS evangelist, I have to say that familiarity and interoperability are two of our STRONGEST selling point to potential users, generally coming before cost-Free, in users needs. XCF already fails interoperability, not being used to any great degree. I am afraid that even the terminology change of -- "I'm sorry, but you can't 'Save As" a JPG (or similar filetype that CAN be saved to in any other commonly-used software), you have to 'Export To' "-- will appear to be a barrier to nervous new adopters.

I sell LibreOffice, by pointing out that not only can it OPEN almost everything, including DOCX and old Works files, It also allows the option of setting default SAVES defaults to DOC --which can be read by everyone-- though with a "you will lose formatting" warning (that can be disabled).

I sell the GIMP to (non-"professional") Photoshop users with GimpShop.

If one of the goals of the GIMP is to expand our user base, I believe we need to keep familiarity and interoperability in mind as we make changes and not push too strongly in directions which will frighten off new adopters, casual OR professional. While I will adopt the new Save/Export workflow in order to get the much-anticipated-and-improved new text functionality and the new colorspace, I would respectfully ask the devs to look at the following options, in the interest of balancing the needs of the professionals with the needs of evangelism:

1) An option (as has been suggested multiple times) to set Save/Export back to previous functionality. That way, those of us who can benefit from the improved workflow can use it, but new users can still have the comforting familiarity of the "tried and true."

2) An option to set a default save/export option, as in LibreOffice, possibly in conjunction with an XCF save (maybe either as a "Save/Export Multiple" in preferences, ie. CTRL-S saves an XCF file, a PSD file AND an 85% JPG file, all with the same filename) This would be a real timesaver for those of us who frequently nip off to the printer or save comparison samples.

3) A heirarchal file offering in the save/export menu: save to XCF always offered first, export to similar filetypes (PSD, PSP, PDN) second, but always available in the same menu, and the more limited filetypes last, as in the previous version's "search for other extensions," which would be hidden unless called for. Frequently used filetypes would remain visible as options. This would focus attention on the correct and preferred option, but allow the unfortunate necessary

4a) Timed autosaves in XCF format that are differentiated from the primary file, possibly multiple copies (up to a limit, set in preferences), in the interest of preserving history. This could be in combination with 1) or 2), above.

4b) Timed autosaves which preserve history (up to a limit, set in preferences), in XCF format, and differentiated from the primary file. This could be in combination with 1) or 2), above.

As many have said before, I have nothing but appreciation for the devs and the massive amount of work they do for those of us who can do nothing more than spread the Word of the GIMP, and I look forward, eagerly, to our future advances and inevitable domination.

Excelsior!

What we _are_ doing is _focusing_ on a group of users who are underloved by free software. We are building workflows around their needs. We are _targeting_ those users.

New users will benefit from immediate exposure to the "professional paradigm" and start paying attention to file formats from day one.

Long time users who often (or always) find no use for the XCF format, will have to relearn or remap a keyboard shortcut or two to keep the same speed & convenience they are used to. Long time users who routinely save their work in XCF won't notice a major difference.

And really... guise... If you don't need the new GIMP color model, you don't need the new version of GIMP. I am guessing that is approximately 100% of users who don't routinely save most files in XCF as "part one" of their usual workflow. It's not like you need to keep your GIMP version current for the sake of security patches or compatibility with external applications. Keeping the "old" GIMP also means that all your favorite plugins and scripts will keep right on doing exactly what you expect them to do.

On 5/30/2012 8:04 PM, darnkitten wrote:

Late to the discussion:

...this thread simply will not die. lol...

On 05/31/2012 04:04 AM, darnkitten wrote:

I sell LibreOffice, by pointing out that not only can it OPEN almost everything, including DOCX and old Works files, It also allows the option of setting default SAVES defaults to DOC --which can be read by everyone-- though with a "you will lose formatting" warning (that can be disabled).

Saving to JPEG from Gimp is more like exporting to PDF from OO (that, incidentally, OO calls "export").

The new save feature is not user friendly and it just kills productivity. I can see no other purpose of it other than a political game. Because of that, GIMP just lost me after 10+ years of heavy use. I've switched over to Pixelmator.
Please, let me know when you are back to something more operational to reconsider.

Regards CF

Yes the new save feature is fustrating and inconvinient, but quitting after 10+ years of heavy usage just over 1 minor change?

On Jun 21, 2012, at 12:10 AM, CoreForce wrote:

The new save feature is not user friendly and it just kills productivity. I can see no other purpose of it other than a political game. Because of that, GIMP just lost me after 10+ years of heavy use. I've switched over to Pixelmator.
Please, let me know when you are back to something more operational to reconsider.

Regards CF

--
CoreForce (via gimpusers.com)
_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

On Thu, Jun 21, 2012 at 12:10 PM, CoreForce wrote:

The new save feature is not user friendly and it just kills productivity. I can see no other purpose of it other than a political game. Because of that, GIMP just lost me after 10+ years of heavy use. I've switched over to Pixelmator.
Please, let me know when you are back to something more operational to reconsider.

UPS delivery or email?

Alexandre Prokoudine http://libregraphicsworld.org

On Thu, Jun 21, 2012 at 6:12 PM, Alexandre Prokoudine wrote:

On Thu, Jun 21, 2012 at 12:10 PM, CoreForce wrote:

The new save feature is not user friendly and it just kills productivity. I can see no other purpose of it other than a political game. Because of that, GIMP just lost me after 10+ years of heavy use. I've switched over to Pixelmator.
Please, let me know when you are back to something more operational to reconsider.

UPS delivery or email?

Please, don't be rude to such an esteemed and valuable former member of this community. A personal visit is the only satisfactory solution here, after all, where would open source software be if less people used it?

On Fri, Jun 22, 2012 at 3:28 AM, Oon-Ee Ng wrote:

UPS delivery or email?

Please, don't be rude to such an esteemed and valuable former member of this community. A personal visit is the only satisfactory solution here

Now I'm getting confused: which of us two is being ironic?

after all, where would open source software be if less people used it?

Consider this. Over a decade GIMP has been having millions of users and just a handful of developers. What's going to change if more people overreact, issue silly accusations and slam the door? Give me the worst scenario you can think of.

This is free software. People do it for fun. We respect your opinions, even when you disagree with us, and we are eager to adjust things to make users happier, but there's no way you can force us to do anything. We are not your hostages, and we don't work on your terms.

Alexandre

On Friday, June 22, 2012 04:10:27 Alexandre Prokoudine wrote:

On Fri, Jun 22, 2012 at 3:28 AM, Oon-Ee Ng wrote:

UPS delivery or email?

Please, don't be rude to such an esteemed and valuable former member of this community. A personal visit is the only satisfactory solution here

Now I'm getting confused: which of us two is being ironic?

after all, where would open source software be if less people used it?

Consider this. Over a decade GIMP has been having millions of users and just a handful of developers. What's going to change if more people overreact, issue silly accusations and slam the door? Give me the worst scenario you can think of.

This is free software. People do it for fun. We respect your opinions, even when you disagree with us, and we are eager to adjust things to make users happier, but there's no way you can force us to do anything. We are not your hostages, and we don't work on your terms.

Alexandre

+ 1 Alexandre

On Fri, Jun 22, 2012 at 8:10 AM, Alexandre Prokoudine wrote:

On Fri, Jun 22, 2012 at 3:28 AM, Oon-Ee Ng wrote:

UPS delivery or email?

Please, don't be rude to such an esteemed and valuable former member of this community. A personal visit is the only satisfactory solution here

Now I'm getting confused: which of us two is being ironic?

after all, where would open source software be if less people used it?

Consider this. Over a decade GIMP has been having millions of users and just a handful of developers. What's going to change if more people overreact, issue silly accusations and slam the door? Give me the worst scenario you can think of.

This is free software. People do it for fun. We respect your opinions, even when you disagree with us, and we are eager to adjust things to make users happier, but there's no way you can force us to do anything. We are not your hostages, and we don't work on your terms.

My point precisely =). Sorry, I think my email was taken the wrong way, since I wrote it in the same spirit as your initial reply (would have thought 'personal visit' would give it away).

I'm not for or against the new change to save/export (I use inkscape, and I'm used to that), but then again I've been using the new version for ages just to get the single-window mode (for which I and every other tiling WM user will be forever thankful).

You're doing a great job, don't let the trolls get you down.

On Fri, Jun 22, 2012 at 8:10 AM, Alexandre Prokoudine wrote:

On Fri, Jun 22, 2012 at 3:28 AM, Oon-Ee Ng wrote:

UPS delivery or email?

Please, don't be rude to such an esteemed and valuable former member
of this community. A personal visit is the only satisfactory solution
here

Now I'm getting confused: which of us two is being ironic?

after all, where would open source software be if less people used it?

Consider this. Over a decade GIMP has been having millions of users and just a handful of developers. What's going to change if more people overreact, issue silly accusations and slam the door? Give me the worst scenario you can think of.

This is free software. People do it for fun. We respect your opinions,
even when you disagree with us, and we are eager to adjust things to make users happier, but there's no way you can force us to do anything. We are not your hostages, and we don't work on your terms.

My point precisely =). Sorry, I think my email was taken the wrong way, since I wrote it in the same spirit as your initial reply (would have thought 'personal visit' would give it away).

I'm not for or against the new change to save/export (I use inkscape, and I'm used to that), but then again I've been using the new version for ages just to get the single-window mode (for which I and every other tiling WM user will be forever thankful).

You're doing a great job, don't let the trolls get you down.

Ditto,

Been using it for a couple of years just for the single window mode.

Put up a valiant resistance against the export function for a couple of hours, but then realized it was very smart move and has saved me from making unrecoverable overwrites.

So beers and cheers to the new export system, long may it reign.

On Fri, Jun 22, 2012 at 3:28 AM, Oon-Ee Ng wrote:

UPS delivery or email?

Please, don't be rude to such an esteemed and valuable former member of this community. A personal visit is the only satisfactory solution here

Now I'm getting confused: which of us two is being ironic?

after all, where would open source software be if less people used it?

Consider this. Over a decade GIMP has been having millions of users and just a handful of developers. What's going to change if more people overreact, issue silly accusations and slam the door? Give me the worst scenario you can think of.

This is free software. People do it for fun. We respect your opinions, even when you disagree with us, and we are eager to adjust things to make users happier, but there's no way you can force us to do anything. We are not your hostages, and we don't work on your terms.

Alexandre

I'm not going to read this whole thread. I read the one in the developer's list. Frankly, I think the whole thing is silly.

To you, the other contributors, and developers, thank you for your work.

I'm fine with the save/export change. I find it more logical and convenient. With previous versions, I found it slightly inconvenient/irritating when I just wanted to back my work up, Save As, name, choose format, when I just wanted xcf. I mean, first world problems, inconvenient/irritating nontheless. I see nothing wrong with adding caution while separating two different commands at the same time. I see the situation perfect for beginners and advanced users. Even the most experienced user can accidentally overwrite a file, if just once in their lives.

Isn't Gimp still open source? Hasn't one of the many great things about OSS always been that you can hack it, alter it to your preferences? If you don't know how, you could always search for it.

I'm not saying Gimp is perfect. There are areas I'd like to see improvement in but that's for another time. Gimp is free software that people volunteer to work on. I appreciate that and don't feel privileged enough to demand changes or threaten to take my toys and go home. Say what you will about my comments. I've said what I've wanted to say. I'm out.

Date: Fri, 22 Jun 2012 06:14:30 +0200 From: forums@gimpusers.com
To: gimp-user-list@gnome.org
CC: team@gimpusers.com
Subject: [Gimp-user] HATE the new save vs. export behavior

Isn't Gimp still open source? Hasn't one of the many great things about OSS always been that you can hack it, alter it to your preferences? If you don't know how, you could always search for it.

I wager the number of users who are able and willing to hack GIMP code to their preferences is still vastly outweighed by the number of users who use GIMP solely out-of-the-box, à la "free Photoshop". Especially Windows users, who are more accustomed to close-source products.

... which gives me a laugh every time I hear the argument that GIMP is not intended to be a Photoshop clone. Sure that may be true, but isn't it true that the line between GIMP and Photoshop gets narrower with every new release?

- Single-window mode? Got it. - Brushes organized by brush family? Yup. - Save/Export distinction? Check.
- Layer groups? Done.
- Nondestructive adjusment layers? Nope, not yet, but in the works.

I think the main reason I picked up GIMP in the first place was I needed something capable of scaling images with interpolation, and a previous app I used for that (called IPhoto Plus) was horribly outdated and hitting its limits.

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

On Fri, Jun 22, 2012 at 02:58:07PM -0700, Richard Gitschlag wrote: [...]

.. which gives me a laugh every time I hear the argument that GIMP is not intended to be a Photoshop clone. Sure that may be true, but isn't it true that the line between GIMP and Photoshop gets narrower with every new release?

- Single-window mode? Got it. - Brushes organized by brush family? Yup. - Save/Export distinction? Check.
- Layer groups? Done.
- Nondestructive adjusment layers? Nope, not yet, but in the works.

That is a conseguence of users being more demanding. They see some new command, they find it useful for getting theirs job done, so they comes here and ask for it in GIMP. That is true even in the other direction, see for instance the liquid rescale plugin that arrived to Photoshop _after_ GIMP. And the reason is that Photoshop is the only real photo retouching product that can be compared to GIMP, for functions and userbase.

So GIMP devs, hip hip hooray, go on the great job! You will never know how some users are grateful to you!

On Sat, Jun 23, 2012 at 1:47 PM, Marco Ciampa wrote:

So GIMP devs, hip hip hooray, go on the great job! You will never know how some users are grateful to you!

You've just given a pretty good idea :)

Alexandre Prokoudine http://libregraphicsworld.org

Dear GIMP developers, you have shittiet GIMP even more with your retarded ideas about how we should save our files.

And please, any "hurr designerrrs" don't counter me with GIMP saving dialog paradigm- what's going on is developers trying to frorce their shitty .xcf format on users. That's all there is. And that's ruining it for me, because when i need it i'll use it myself.

On Sat, Jun 30, 2012 at 7:15 PM, bobbo wrote:

Dear GIMP developers, you have shittiet GIMP even more with your retarded ideas about how we should save our files.

And please, any "hurr designerrrs" don't counter me with GIMP saving dialog paradigm- what's going on is developers trying to frorce their shitty .xcf format on users. That's all there is. And that's ruining it for me, because when i need it i'll use it myself.

You were offensive and insulting enough to just have triggered writing the code of conduct for our mailing lists. Thank you.

Alexandre Prokoudine http://libregraphicsworld.org

Seriously? I don't like the Save vs. Export thing any more than you or anyone else here but instead of discussing it normally you complain about it like a 12 year old. Call me crazy, but I'm pretty sure that's not the way to get your opinions noticed...

Sent from my iPod

On Jun 30, 2012, at 11:15 AM, bobbo wrote:

Dear GIMP developers, you have shittiet GIMP even more with your retarded ideas about how we should save our files.

And please, any "hurr designerrrs" don't counter me with GIMP saving dialog paradigm- what's going on is developers trying to frorce their shitty .xcf format on users. That's all there is. And that's ruining it for me, because when i need it i'll use it myself.

-- bobbo (via gimpusers.com)
_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

As someone who teaches 11 year old kids, I can safely say you're not being fair to the kids, they're generally more nature than that. On Jul 1, 2012 12:19 AM, "Kasim Ahmic" wrote:

Seriously? I don't like the Save vs. Export thing any more than you or anyone else here but instead of discussing it normally you complain about it like a 12 year old. Call me crazy, but I'm pretty sure that's not the way to get your opinions noticed...

Sent from my iPod

On Jun 30, 2012, at 11:15 AM, bobbo wrote:

Dear GIMP developers, you have shittiet GIMP even more with your

retarded ideas about how we should save our files.

And please, any "hurr designerrrs" don't counter me with GIMP saving

dialog paradigm- what's going on is developers trying to frorce their shitty .xcf format on users. That's all there is. And that's ruining it for me, because when i need it i'll use it myself.

--
bobbo (via gimpusers.com)
_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

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

Kasim did state "12-year-old" so let's just let that slide, shall we? BTW this also means that between the age of your students now and the way Kasim says bobbo is acting, I'd say you still have one good year. :)

Top posting is just so unnatural (at least for me). Think how that relates to the latest version of GIMP.

On Sunday, July 01, 2012 07:31:46 Oon-Ee Ng wrote:

As someone who teaches 11 year old kids, I can safely say you're not being fair to the kids, they're generally more nature than that.

On Jul 1, 2012 12:19 AM, "Kasim Ahmic" wrote:

Seriously? I don't like the Save vs. Export thing any more than you or anyone else here but instead of discussing it normally you complain about it like a 12 year old. Call me crazy, but I'm pretty sure that's not the way to get your opinions noticed...

Sent from my iPod

On Jun 30, 2012, at 11:15 AM, bobbo wrote:

Dear GIMP developers, you have shittiet GIMP even more with your

retarded ideas about how we should save our files.

And please, any "hurr designerrrs" don't counter me with GIMP saving

dialog paradigm- what's going on is developers trying to frorce their shitty .xcf format on users. That's all there is. And that's ruining it for
me, because when i need it i'll use it myself.

--
bobbo (via gimpusers.com)

On 05/31/2012 04:04 AM, darnkitten wrote:

I sell LibreOffice, by pointing out that not only can it OPEN almost everything, including DOCX and old Works files, It also allows the option of setting default SAVES defaults to DOC --which can be read by everyone-- though with a "you will lose formatting" warning (that can be disabled).

Saving to JPEG from Gimp is more like exporting to PDF from OO (that, incidentally, OO calls "export").

I would say it is more like saving to RTF, which is a "save" option, though a crappy one. (JPEG and RTF are both low-quality editable formats which lose data/formatting, compared to the native XCF and ODT formats). Exporting to PDF is converting from an editable format to an essentially non-editable container format, and IS an Export--Incidentally, one printer in my area prefers even image files to be exported to PDF...*sigh*...because Windows prints it directly instead of shoving it through that crappy photo printing wizard.

Date: Tue, 17 Jul 2012 21:27:59 +0200 From: forums@gimpusers.com
To: gimp-user-list@gnome.org
CC: team@gimpusers.com
Subject: [Gimp-user] HATE the new save vs. export behavior

(JPEG and RTF are both low-quality editable formats which lose data/formatting, compared to the native XCF and ODT formats)

Hey, RTF is NOT the JPEG of word processing. Maybe the PCX of word processing, but no JPEG. :)

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

I just want to add I'm also not happy with the new export vs save feature. I use GIMP for all my edit tasks; from complex foto editting to really simple screenshot taking and trimming it slightly. I used to love it for both, especially since it GIMP can do both small and complex tasks very easy. In 98% of the edits, I'm not using layers. I already almost always save everything in formats that do not lose information, often png, often for e.g. mailing. I don't want a xcf for screen shots or photographs...

I've seen the new "you have to use export" messagebox about 20 times now, very annoying ;-). Why is it not OK to allow saving to e.g. png (especially when not using layers!), but keep the export function ALSO as it is? That way, everyone will be happy I think?

2012/8/6 Anoko :

I just want to add I'm also not happy with the new export vs save feature. I use GIMP for all my edit tasks; from complex foto editting to really simple screenshot taking and trimming it slightly. I used to love it for both, especially since it GIMP can do both small and complex tasks very easy. In 98% of the edits, I'm not using layers. I already almost always save everything in formats that do not lose information, often png, often for e.g. mailing. I don't want a xcf for screen shots or photographs...

I've seen the new "you have to use export" messagebox about 20 times now, very annoying ;-). Why is it not OK to allow saving to e.g. png (especially when not using layers!), but keep the export function ALSO as it is? That way, everyone will be happy I think?

Is it soooooooooo difficult to change one's habits a little, and to learn simple shortcuts? Ctrl-E or Shift-Ctrl-E to export the image to any format you wish, Ctrl-W Alt-W to close the image without saving it. Seeing a warning message 20 times was clearly enough for teaching me that I should use Ctrl-E instead of Ctrl-S. -----
Olivier Lecarme

On Tue, Aug 7, 2012 at 2:30 PM, Olivier wrote:

2012/8/6 Anoko :

I just want to add I'm also not happy with the new export vs save feature. I use GIMP for all my edit tasks; from complex foto editting to really simple screenshot taking and trimming it slightly. I used to love it for both, especially since it GIMP can do both small and complex tasks very easy. In 98% of the edits, I'm not using layers. I already almost always save everything in formats that do not lose information, often png, often for e.g. mailing. I don't want a xcf for screen shots or photographs...

I've seen the new "you have to use export" messagebox about 20 times now, very annoying ;-). Why is it not OK to allow saving to e.g. png (especially when not using layers!), but keep the export function ALSO as it is? That way, everyone will be happy I think?

Is it soooooooooo difficult to change one's habits a little, and to learn simple shortcuts? Ctrl-E or Shift-Ctrl-E to export the image to any format you wish, Ctrl-W Alt-W to close the image without saving it. Seeing a warning message 20 times was clearly enough for teaching me that I should use Ctrl-E instead of Ctrl-S.

Old dog and new tricks?

2012/8/6 Anoko :

I've seen the new "you have to use export" messagebox about 20 times now, very annoying ;-). Why is it not OK to allow saving to e.g. png (especially when not using layers!), but keep the export function ALSO as it is? That way, everyone will be happy I think?

Is it soooooooooo difficult to change one's habits a little, and to learn simple shortcuts? Ctrl-E or Shift-Ctrl-E to export the image to any format you wish, Ctrl-W Alt-W to close the image without saving it. Seeing a warning message 20 times was clearly enough for teaching me that I should use Ctrl-E instead of Ctrl-S.

Well habbits or not, I still wonder why it is explicitly disallowed to save as something other than xcf. As I said, allowing that+keeping the export option makes all users happy. Now, a way that apparently some part of the users like and some don't is forced to all, while it is not necessary to force it.

GIMP is not the only program I use, so yeah I keep pressing CTRL+S thinking that should save whatever I'm editting to whatever file extension I gave it, just like in Inkscape, Libreoffice, KDevelop, etc. To me, "exporting" to a png does not feel like exporting at all. If the original image is something bitmappy without layers, there is no loss, and I use GIMP mostly for that. If it did have layers, GIMP would already warn. I don't use GIMP often enough to get used to learn the fact that it's the only program I have where CTRL+S does not save, but rather wants me to make a temporary projectfile.

On 07.08.12 at 11:23, Anoko wrote:

2012/8/6 Anoko :

I've seen the new "you have to use export" messagebox about 20 times now, very annoying ;-). Why is it not OK to allow saving to e.g. png (especially when not using layers!), but keep the export function ALSO as it is? That way, everyone will be happy I think?

Is it soooooooooo difficult to change one's habits a little, and to learn simple shortcuts? Ctrl-E or Shift-Ctrl-E to export the image to any format you wish, Ctrl-W Alt-W to close the image without saving it. Seeing a warning message 20 times was clearly enough for teaching me that I should use Ctrl-E instead of Ctrl-S.

Well habbits or not, I still wonder why it is explicitly disallowed to save as something other than xcf. As I said, allowing that+keeping the export option makes all users happy. Now, a way that apparently some part of the users like and some don't is forced to all, while it is not necessary to force it. ...

Hi Anoko,

this question has been widely discussed before and like many others I think, all that has to be said about it is already said. So don't be surprised if some answers sound annoyed. Usually advanced users have problems with the new behaviour, not experts and not beginners. If you can't live without Ctrl+S you can easily change the shortcuts via the Edit menu. If you like to know more about this change and why things have changed this way, you find some explanations at http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes. At least the last sentence in the 'Save and export' chapter is very important.
I hope this helps you.

Best regards,

grafxuser

On Tue, Aug 7, 2012 at 1:23 PM, Anoko wrote:

GIMP is not the only program I use, so yeah I keep pressing CTRL+S thinking that should save whatever I'm editting to whatever file extension I gave it, just like in Inkscape, Libreoffice, KDevelop, etc.

Inkscape does it wrong too, and the plan is to save only what it can open as a native file. It just hasn't been done yet. Which means that eventually Inkscape will work much like GIMP 2.8 in that respect.

Alexandre Prokoudine http://libregraphicsworld.org

* Anoko [08-07-12 05:25]:

2012/8/6 Anoko :

I've seen the new "you have to use export" messagebox about 20 times now, very annoying ;-). Why is it not OK to allow saving to e.g. png (especially when not using layers!), but keep the export function ALSO as it is? That way, everyone will be happy I think?

Is it soooooooooo difficult to change one's habits a little, and to learn simple shortcuts? Ctrl-E or Shift-Ctrl-E to export the image to any format you wish, Ctrl-W Alt-W to close the image without saving it. Seeing a warning message 20 times was clearly enough for teaching me that I should use Ctrl-E instead of Ctrl-S.

Well habbits or not, I still wonder why it is explicitly disallowed to save as something other than xcf. As I said, allowing that+keeping the export option makes all users happy. Now, a way that apparently some part of the users like and some don't is forced to all, while it is not necessary to force it.

You are "hung up* on a single word, "save" vs "export". Change your key bindings to match what *you* want.

Date: Tue, 7 Aug 2012 11:23:49 +0200 From: forums@gimpusers.com
To: gimp-user-list@gnome.org
CC: team@gimpusers.com
Subject: [Gimp-user] HATE the new save vs. export behavior

Well habbits or not, I still wonder why it is explicitly disallowed to save as something other than xcf. As I said, allowing that+keeping the

export option makes all users happy. Now, a way that apparently

some part of the users like and some don't is forced to all, while it is

not necessary to force it.

Translation: Why the existing message can/may not be converted into an "Export/Cancel" prompt, which would be a have-cake-eat-it-too solution. That the developers insist the cake being a lie is ... mystifying, to say the least.

... I don't use GIMP often enough to get used to learn the

fact that it's the only program I have where CTRL+S does not save,

but

rather wants me to make a temporary projectfile.

--
Anoko (via gimpusers.com)

In my experience, I only have a few such programs: GIMP 2.8, Visual Studio, and FontForge. Visual Studio, being a win32 program compiler, is pretty obvious: "Save" saves the project source code, and "Compile" writes the finished executable. FontForge's documentation makes clear that real font files are extremely optimized for small file sizes and don't include a lot of helpful metadata that is saved with your project (.sfd) file; the "Generate Fonts" command is what writes actual font files.

In my experience I've also personally written a program used to design mods for one specific game, where the "Save" command stored a project file and a separate "Compile..." command packaged it into the actual mod file. (Coincidentally, all three of these share another thing in common: Needing to perform a validation/error check before compiling the file.)

By contrast, GIMP is the only program I use where the majority of my work involves outputting to a standard file format, and I've only used XCF for situations where other formats simply cannot handle it (i.e. multilayer arrangements).

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

We have found that logic does not apply here. The only allowed interactions are those approved by the developers.

On 8/7/2012 2:23 AM, Anoko wrote:

2012/8/6 Anoko:

I've seen the new "you have to use export" messagebox about 20 times now, very annoying ;-). Why is it not OK to allow saving to e.g. png (especially when not using layers!), but keep the export function ALSO as it is? That way, everyone will be happy I think?

Is it soooooooooo difficult to change one's habits a little, and to learn simple shortcuts? Ctrl-E or Shift-Ctrl-E to export the image to any format you wish, Ctrl-W Alt-W to close the image without saving it. Seeing a warning message 20 times was clearly enough for teaching me that I should use Ctrl-E instead of Ctrl-S.

Well habbits or not, I still wonder why it is explicitly disallowed to save as something other than xcf. As I said, allowing that+keeping the export option makes all users happy. Now, a way that apparently some part of the users like and some don't is forced to all, while it is not necessary to force it.

GIMP is not the only program I use, so yeah I keep pressing CTRL+S thinking that should save whatever I'm editting to whatever file extension I gave it, just like in Inkscape, Libreoffice, KDevelop, etc. To me, "exporting" to a png does not feel like exporting at all. If the original image is something bitmappy without layers, there is no loss, and I use GIMP mostly for that. If it did have layers, GIMP would already warn. I don't use GIMP often enough to get used to learn the fact that it's the only program I have where CTRL+S does not save, but rather wants me to make a temporary projectfile.

You are "hung up* on a single word, "save" vs "export". Change

your key

bindings to match what *you* want.

Totally agreed. The
criticism to the new behaviour is quite bureaucratic.

You are "hung up* on a single word, "save" vs "export". Change

your key

bindings to match what *you* want.

Totally agreed. The
criticism to the new behaviour is quite bureaucratic.

I'm not sure how this remark helps the discussion (nor the other personal remarks about developers in other posts). I understand the discussion is heated, but please refrain from making inconstructive remarks (everyone). I just noticed this new GIMP behaviour, as Debian has only recently pushed 2.8 into testing. As will many other of the (probably less sofisticated) users.

Fact is that there are people who don't like the feature. Actually, I suppose this forum holds most of the people doing advanced stuff with GIMP, which in ratio will probably more often use the new feature compared to others. All people in my surroundings use GIMP for simpler tasks, and I suspect they will all dislike the new feature.

I read the explanation about the new feature. It basically tells me that GIMP users not liking the feature are not the intended audience of future GIMP versions. Personally, I doubt whether all intended users want to be enforced in a specific ("project for each image") way of working, but of course, the intended audience of GIMP are a choice of the developers, and there's not much to argue against it. However, I do not understand why no one discusses a compromise that does neither enforce nor burden exporting. Are the developers really willing to give up a "part" of their users for something which I think can be compromised in a way both sides are happy??

The explanation page says "In other words, GIMP used to assume that you don't mind accidental loss of unrecoverable project data and bothered you with confirmation dialogs. It was a convoluted logic, but people got used to it."

I do not see why this is solved. Someone who is not familair with GIMP, that wants to store something as a png file, clicks save, finds it needs to export, clicks export and has lost their layered data nevertheless, now basically without a warning saying layers got lost.

On Tue, Aug 7, 2012 at 8:49 PM, Anoko wrote:

I do not see why this is solved. Someone who is not familair with GIMP, that wants to store something as a png file, clicks save, finds it needs to export, clicks export and has lost their layered data nevertheless, now basically without a warning saying layers got lost.

GIMP knows that your project only has been exported not saved, it will thus ask you to save later when you try to quit GIMP - giving you a chance to preserve the layer structure (higher bit depth, and more) that was discarded in the export to PNG.

/

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
http://twitter.com/hodefoting

On Tue, Aug 7, 2012 at 8:49 PM, Anoko wrote:

I do not see why this is solved. Someone who is not familair with GIMP, that wants to store something as a png file, clicks save, finds it needs to export, clicks export and has lost their layered data nevertheless, now basically without a warning saying layers got lost.

GIMP knows that your project only has been exported not saved, it will thus ask you to save later when you try to quit GIMP - giving you a chance to preserve the layer structure (higher bit depth, and more) that was discarded in the export to PNG.

It does not help: The exit conformation does not say anything explicitly about layers. It will thus confuse people not understanding the difference between export, save, and what layers are about, and people that do know the difference, already knew they were saving to png and it does not help. If they exported to jpg and forgot about their transparancy layer, they are no longer warned.

On Tue, Aug 7, 2012 at 10:49 PM, Anoko wrote:

However, I do not understand why no one discusses a compromise that does neither enforce nor burden exporting.

The secondary workflow _is_ the compromise.

Are the developers really willing to give up a "part" of their users for something which I think can be compromised in a way both sides are happy??

Implementing behavior options _isn't_ a compromise, it's just another way of crippling user experience.

The explanation page says "In other words, GIMP used to assume that you don't mind accidental loss of unrecoverable project data and bothered you with confirmation dialogs. It was a convoluted logic, but people got used to it."

I do not see why this is solved.

Yes, you don't see it :)

Someone who is not familair with GIMP, that wants to store something as a png file, clicks save, finds it needs to export, clicks export and has lost their layered data nevertheless, now basically without a warning saying layers got lost.

Absolutely not. No one loses anything until confirming that by closing the project without saving as XCF.

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Aug 7, 2012 at 10:49 PM, Anoko wrote:

The explanation page says "In other words, GIMP used to assume that you don't mind accidental loss of unrecoverable project data and bothered you with confirmation dialogs. It was a convoluted logic, but people got used to it."

I do not see why this is solved.

Yes, you don't see it :)

I understand that you are bored of the discussion, but by suggesting that it is my problem alone of seeing it wrong, I think that's a bit insulting and really unnecessary. I was at least trying to be constructive. I suspect though that you have misunderstood my use case.

User: lets say he wants so save image with transparance as jpg, clicks save Gimp: you have to use export
User: Export to jpg
Gimp: ok! (no message that transparance got lost) User: click exit
Gimp: Sure? not saved!
User: uh, I just exported it, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree! Transparancy lost. This is something I already encountered once, so it is a realistic use case (whether it is a probable is something else, but whether the previous "problem" was much larger is to be seen as well).

Since in the "old" workflow, everyone who used to use "save" for exporting to png/jpg etc., will with some annoyance now use export, but no longer get "flatten layers?" messages, and he/she has to remember that indeed "unsaved changes" are unrelated to exporting.

Since such people will always get a "you have unsaved changes" message when exitting the GIMP, this message becomes useless for this workflow. Thus, the only way to use GIMP without major annoyance, is to follow the forced xcf route.

I suspect though that you have misunderstood my use case.

User: lets say he wants so save image with transparance as jpg, clicks save Gimp: you have to use export
User: Export to jpg
Gimp: ok! (no message that transparance got lost) User: click exit
Gimp: Sure? not saved!
User: uh, I just exported it, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree!

And this is where your use case is wrong! The whole point of separating save and export is that ONLY save is "safe". An export is NOT guaranteed to be either safe or lossless. It may be, depending on the source image. Your example exactly demonstrates the purpose of the new paradigm.

-Rob A >

On Wed, Aug 8, 2012 at 12:59 AM, Anoko wrote:

I understand that you are bored of the discussion, but by suggesting that it is my problem alone of seeing it wrong, I think that's a bit insulting and really unnecessary.

Well, what if it _is_ your problem alone? I could wrap that up in a cheerful marketing language. Should I?

I was at least trying to be constructive.

I did provide an explanation why nobody loses anything unless specifically willing to do that. If you want to have an argument about who was trying to be constructive, please don't count me in, otherwise we'll never hear the end of it.

I suspect though that you have misunderstood my use case.

User: lets say he wants so save image with transparance as jpg

Excuse me, but can you see the target group of users really trying that?

http://gui.gimp.org/index.php/Vision_briefing#GIMP_and_its_core_users

User: uh, I just exported it, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree!

Nope. Exporting is never safe. That's the whole point of exporting as opposed to saving.

You see, no matter how many times we repeat who this is done for, people keep trying to dumb the argumentation down to "but what if you take a complete newbie who knows nothing?". Now that is really boring. And quite possibly insulting.

You make your use case sound like something horrible happens when transparency is lost. But GIMP insists that you save the project data to XCF so that at any time later you could redo exporting the right way or whatever it is that you wish to adjust. That's the point of saving in GIMP, see?

Let me reinstate that: nothing is ever lost until you wish so.

Alexandre Prokoudine http://libregraphicsworld.org

On Wed, Aug 8, 2012 at 1:10 AM, Rob Antonishen wrote:

And this is where your use case is wrong! The whole point of separating save and export is that ONLY save is "safe". An export is NOT guaranteed to be either safe or lossless. It may be, depending on the source image. Your example exactly demonstrates the purpose of the new paradigm.

The main problem I see with the suggested use case is here: "Transparancy lost. This is something I already encountered once, so it is a realistic use case."

Excuse me, Anoko, but there's no way I'm going to believe that a mistake that is only ever done once is going to completely ruin everything. Especially since GIMP asks to save project data.

Alexandre Prokoudine http://libregraphicsworld.org

[..]

User: uh, I just exported it, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree!

And this is where your use case is wrong! The whole point of separating save and export is that ONLY save is "safe". An export is NOT guaranteed to be either safe or lossless. It may be, depending on the source image. Your example exactly demonstrates the purpose of the new paradigm.

Its wrong because users don't think that way? Not even a chance? :-/ I think they do.

An export is guaranteed to be safe in 98% cases for people not using intermediate xcfs, thus this paradigm is irrelevant and confusing for them. Then, yes, there's another lot of people for who the export is relevant. But both sides exist, I think this discussion is enough prove of that.

On Tue, Aug 07, 2012 at 10:59:47PM +0200, Anoko wrote:

On Tue, Aug 7, 2012 at 10:49 PM, Alexandre Prokoudine wrote:

On Tue, Aug 07, 2012 at 10:59:47PM +0200, Anoko wrote:

The explanation page says "In other words, GIMP used to assume that you don't mind accidental loss of unrecoverable project data and bothered you with confirmation dialogs. It was a convoluted logic, but people got used to it."

I do not see why this is solved.

Yes, you don't see it :)

I understand that you are bored of the discussion, but ....

No, the problem is really that you do not see it, sorry, no offense ...

User: lets say he wants so save image with transparance as jpg, clicks save Gimp: you have to use export
User: Export to jpg
Gimp: ok! (no message that transparance got lost)

And that is right! If you think that starting from an image format and saving into another brings so many ways to (possibly) loose data that this way, in that only save actually SAVE all the data, is the only logic way to do it.

User: click exit
Gimp: Sure? not saved!
User: uh, I just exported it,
oh yeah right exporting is not saving. But it's exported, oh yeah right exporting is not saving. But it's exported, oh yeah right exporting is not saving. But it's exported, oh yeah right exporting is not saving. But it's exported, oh yeah right exporting is not saving. But it's exported, oh yeah right exporting is not saving. But it's exported, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree!

Doh! http://thinkexist.com/quotation/alright-brain-you-don-t-like-me-and-i-don-t-like/538158.html

Transparancy lost.

or image lost due to lossy compression or path lost
or text layer lost
or color depth lost
or whatever

please SAVE!

This is something I already encountered once,

I am shure ... ;-)

so it is a realistic use case

Yes it is very realistic ;-)))))

(whether it is a probable is something else, but whether the previous "problem" was much larger is to be seen as well).

yes it is a big problem, a classic PEBKAC http://ars.userfriendly.org/cartoons/?id=19980506&mode=classic

;-)

Sorry I couldn't resist!

On Wed, Aug 8, 2012 at 1:42 AM, Anoko wrote:

Its wrong because users don't think that way?

What users? :)

The are no "users in general". There are all sorts of workflows and uses for applications. There are all kinds of users too.

The kind of users we are targeting, mostly understand and accept the distinction between saving and exporting.

The usability team spent quite a while writing all the reasoning down at gui.gimp.org. I don't really understand why we need yet another long thread to go through all these things yet again.

Alexandre Prokoudine http://libregraphicsworld.org

On 08/07/2012 04:59 PM, Anoko wrote:

On Tue, Aug 7, 2012 at 10:49 PM, Anoko wrote:

The explanation page says "In other words, GIMP used to assume that you don't mind accidental loss of unrecoverable project data and bothered you with confirmation dialogs. It was a convoluted logic, but people got used to it."

I do not see why this is solved.

Yes, you don't see it :)

I understand that you are bored of the discussion, but by suggesting that it is my problem alone of seeing it wrong, I think that's a bit insulting and really unnecessary. I was at least trying to be constructive. I suspect though that you have misunderstood my use case.

User: lets say he wants so save image with transparance as jpg, clicks save Gimp: you have to use export
User: Export to jpg
Gimp: ok! (no message that transparance got lost) User: click exit
Gimp: Sure? not saved!
User: uh, I just exported it, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree! Transparancy lost. This is something I already encountered once, so it is a realistic use case (whether it is a probable is something else, but whether the previous "problem" was much larger is to be seen as well).

Since in the "old" workflow, everyone who used to use "save" for exporting to png/jpg etc., will with some annoyance now use export, but no longer get "flatten layers?" messages, and he/she has to remember that indeed "unsaved changes" are unrelated to exporting.

Since such people will always get a "you have unsaved changes" message when exitting the GIMP, this message becomes useless for this workflow. Thus, the only way to use GIMP without major annoyance, is to follow the forced xcf route.

Hi Anoko,

I am just another user like you. I also don't like the new save/export model.

I wish that a mechanism could be found that solves these save/export issues for _both_ types of workflows. However, the answer to that from the developers seems to have been that it is too hard and causes too much potential confusion / logic branching in the code, thus making future coding more difficult. (So instead the users of one workflow type or the other have to do the work instead of the computer doing the work.)

However, IMHO the developers have _not_ misunderstood your use case and are _not_ overlooking the use case you describe.

Instead, IMHO they are not concerned about that use case.

It is all very strange to me. On one hand, they developers were trying to avoid accidental loss of data by making the change that they made.

However, the use case you describe (which I can see happening to many people) does not, IMHO, seem to concern the developers because they _may_ be thinking that "only an amateur" would make that mistake and thus that is not of concern for Gimp because Gimp is really not an appropriate tool for amateurs and amateurs are not in the target user group that the developers are making Gimp for.

So, on one hand, the developers make a change to prevent users from losing data as a result of their own lack of knowledge or bad procedures. On the other hand, the developers seem to ignore a situation (that you have described) which has the same result.

Either Gimp is for advanced users who won't have these problems (and don't need to be protected from themselves) or it is for a broader group of users that do need to have some protection from themselves. Pick one.

IMHO, the "loss of data" situation that the developers were trying to prevent with this change was not serious problem for the Gimp target user group (advanced users). I doubt those advanced users were having a problem before this change. I suspect that the people who were having the problem is the very group that are still going to have a problem in the use case you described.

When all the arguments about this got "loud", I expressed my opinion that protecting users from their own ignorance and bad procedures just enabled users to be ignorant and use bad procedures. My opinion was/is that learning is (along with many other factors) a result of making errors, paying the price.... and thus learning.

We evolve by learning. We learn as the result of experiences. Take away some of the bad experiences and you reduce the opportunities for learning.

The developers jumped on me like I had five horns growing out of my head. I got emails that called me bad names and suggested that I was a terrible person because I would allow somebody to suffer just so that they would learn something. (In response, I say that a person will suffer a whole lifetime if they don't learn some hard lessons -- the faster they do that learning, the sooner their life will get easier.)

In the end, however, I wish that a mechanism could be found that solves these save/export issues for _both_ types of workflows.

99% of my use is open TIFF, edit TIFF, save TIFF, close TIFF. 99% of the time, I have absolutely no need for retaining any data that cannot be saved in the TIFF. If I do need such data, I know how to save in the XCF file format.

I continue to try and use Gimp for my "simplistic" workflow because of some of the other very useful and valuable features Gimp has.

In any case, it has been said very clearly many times that this change to Gimp is permanent and that no amount of complaining and no amount of other use cases or other logic will change anything. I understand what the developers mean by saying that, but it makes it sound like they will not ever consider thinking about a mechanism that satisfies both groups. Blocking out the possibility of thinking about hard problems is sad.

All that said, and despite the insults I have received from a few developers, I have the greatest respect for what they have made and the ongoing work that they are doing. I think we underestimate how dedicated they have been and how much work they have done with very little reward.

People never complain about the quality or attributes of something that does not exist. If they had not made Gimp, we would have nothing to complain about.

Jay

Alexandre,

Just because you write something down doesn't make it right.

Mein Kampf comes to mind.....

On 8/7/2012 2:52 PM, Alexandre Prokoudine wrote:

On Wed, Aug 8, 2012 at 1:42 AM, Anoko wrote:

Its wrong because users don't think that way?

What users? :)

The are no "users in general". There are all sorts of workflows and uses for applications. There are all kinds of users too.

The kind of users we are targeting, mostly understand and accept the distinction between saving and exporting.

The usability team spent quite a while writing all the reasoning down at gui.gimp.org. I don't really understand why we need yet another long thread to go through all these things yet again.

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

On 08/07/2012 05:52 PM, Alexandre Prokoudine wrote:

The usability team spent quite a while writing all the reasoning down at gui.gimp.org. I don't really understand why we need yet another long thread to go through all these things yet again.

Alexandre Prokoudine

Alexandre,

IMHO the answers to your (probably rhetorical) statement (which I take as more of a question) are fairly obvious...

Either the "writing" process was not complete and/or the needs and preferences of some users/workflows were either not considered, were considered and ignored as unimportant, or viewed as outside the target group of users.

As many husbands have taken decades to learn (or else they are no longer married), sometimes "writing all the reasoning down" won't make the wife feel better. Right now, the developers are responding to an emotional situation by saying something like "but we did what was logical, we even wrote it down first". In the recorded history of human relations, I doubt that response has worked on a regular, consistent basis.

Users become very attached to the software they use. They start to think of it as "theirs". They have made a very real investment in time, energy, learning, etc. to use the software. Users also develop a "brand attachment" that is deeper than most product makers comprehend (users of products will often stick by a product that even they themselves complain about as being inferior -- sort of a Stockholm Syndrome in a different kind of way).

Software must evolve over time. If the users need the features in the new software versions, then the users must evolve with it. (Otherwise, the users have to set up Vmware and run old software on old operating systems -- I am still running one such program that I obtained in 1984 because I still have not been able to find anything better for the very specialized task I use it for.)

When software evolves in a direction different from that user/workflow, the user experiences *very personal* feelings of *loss*.

The strong feelings expressed in all these "yet another long threads" are users expressing their feelings of _loss_.

And it is not just their _feelings_. Some of them will decide that they will have to migrate to other software which does include them it its "target user group". That migration comes at a very real cost of time, effort, learning, and perhaps money.

Every product, probably especially including software, must over time re-evaluate who its "target user group" is. In doing so, if changes are made, then some previous _loyal_ users will be excluded. Those users have done nothing "wrong" -- they just woke up one morning and found that they now live outside the walls of the city and there is nothing they can do about it.

If the developers have made a mistake, it was possibly overlooking these "feelings issues" and not expecting such a strong reaction. That is not to say that the developers did not have to do what they did. However, they should not have been surprised by the reaction.

*If* I recall correctly, for a short period of time before you (Alexandre) took on your current role of attempting to soften and humanize the communication, there was some rather harsh communication from the developer side that just poured salt in users' wounds. Your involvement has made things better, though it seems that you are (understandably) getting tired. THANK YOU FOR WHAT YOU HAVE BEEN DOING!

I just wish the developers would be open to conversation of how both types of workflows could be accommodated efficiently (both efficient for users and in the code). Closing off that possibility of conversation is perhaps what hurts most of all. I wish I had enough knowledge to contribute ideas of how to accomplish this while meeting the needs of all.

Jay

On 08/07/2012 05:32 PM, Alexandre Prokoudine wrote:

On Wed, Aug 8, 2012 at 1:10 AM, Rob Antonishen wrote:

And this is where your use case is wrong! The whole point of separating save and export is that ONLY save is "safe". An export is NOT guaranteed to be either safe or lossless. It may be, depending on the source image. Your example exactly demonstrates the purpose of the new paradigm.

The main problem I see with the suggested use case is here: "Transparancy lost. This is something I already encountered once, so it is a realistic use case."

Excuse me, Anoko, but there's no way I'm going to believe that a mistake that is only ever done once is going to completely ruin everything. Especially since GIMP asks to save project data.

Alexandre Prokoudine

Splitting off to a different thread.

I have seen the term "project data" used in regard to XCF file format, as Alexandre has above.

However, to me, the XCF does not _currently_ really save what I consider to be the _project_ data.

Gimp does not save, to my knowledge (please excuse any errors), the following (and more, I am sure):

- window positions or sizes - visible dialogs
- viewing magnification magnification - active tool
- most recently applied filter
- most recently used settings in dialogs (such as Image Size settings such as inch vs mm etc.)
etc., etc.

Maybe these things are on the horizon, which would be great.

Still, when I think of a "project", I usually think of multiple images open at the same time, etc.

I don't know that "project" is a good word in this situation. I would prefer "workspace". But even if it is to be "project" it is more than just one image.

What I hope to see in the years to come is:

- Saving "image" includes saving the items listed above (and others) for a single image.

- Saving "workspace" (or "project") saves all "image" stuff mentioned above, for multiple images and whatever else is going on in Gimp at that moment. Opening "workspace [name]" would open multiple images and everything would look exactly like it did when the workspace was saved.

(Or maybe "project" and "workspace" are completely different things??)

Jay

On Wed, Aug 8, 2012 at 1:58 AM, Jay Smith wrote:

IMHO, the "loss of data" situation that the developers were trying to prevent with this change was not serious problem for the Gimp target user group (advanced users). I doubt those advanced users were having a problem before this change. I suspect that the people who were having the problem is the very group that are still going to have a problem in the use case you described.

Jay,

Since you are talking about IMHOs, I consider myself an advanced user. In a number of cases I already benefitted from the save/export separation, because it forced me to save XCF which I thought I probably didn't need and then ended up needing it to avoid redoing some layer compositions from scratch.

I also have compositions that I will probably never recover in a multilayered version, because I thought I knew better, and I was wrong.

The developers jumped on me like I had five horns growing out of my head.

Nobody really jumps on people round here. Besides, folks with five horns growing out of their heads have very few chances to be human, have they not? :)

In any case, it has been said very clearly many times that this change to Gimp is permanent and that no amount of complaining and no amount of other use cases or other logic will change anything. I understand what the developers mean by saying that, but it makes it sound like they will not ever consider thinking about a mechanism that satisfies both groups. Blocking out the possibility of thinking about hard problems is sad.

Jay, we are thinking about hard problems all the time. Whether you accept the results is an entirely different question.

Alexandre Prokoudine http://libregraphicsworld.org

[..]

User: uh, I just exported it, oh yeah right exporting is not saving. But it's exported, so my changes are safe. Agree!

And this is where your use case is wrong! The whole point of separating save and export is that ONLY save is "safe". An export is NOT guaranteed to be either safe or lossless. It may be, depending on the source image. Your example exactly demonstrates the purpose of the new paradigm.

Its wrong because users don't think that way? Not even a chance? :-/ I think they do.

An export is guaranteed to be safe in 98% cases for people not using intermediate xcfs, thus this paradigm is irrelevant and confusing for them.

I'd love to know where you got that number from as my experience tells me otherwise.

- Loading, modifying then saving a jpeg back is never "safe", just because of jpeg compression, with the possible exception of rotation and cropping, assuming the software does it correctly. - Under 2.6, saving in most non xcf file formats would loose many things such as saved selections and paths, - Under 2.6, saving as a psd would loose text layers rasterizing them instead as well as paths, without a warning,

On top of that, I have read countless posts on many forums that go along the lines of "I added the text 'I can has z cheezburger' to my funny picture and saved it. Now I want to change the text and I can't select it any more. Attached is the jpeg. Help!" or "I spent hours making a selection so I could make my car purple in this picture but really wanted it green. I How do I get that selection back. Attached is the jpeg."

Personally, I think that people will always use hammers to pound in screws, screwdrivers to pry things open, and pry-bars to hammer in nails, cause it is the tool they happen to have in hand. A part of using a tool is learning how to use that tool in the manner it is intended. I see the save/export distinction one small way to help educate users, and make them better users in the long run.

-Rob A>

On Wed, Aug 8, 2012 at 2:28 AM, Jay Smith wrote:

As many husbands have taken decades to learn (or else they are no longer married), sometimes "writing all the reasoning down" won't make the wife feel better. Right now, the developers are responding to an emotional situation by saying something like "but we did what was logical, we even wrote it down first". In the recorded history of human relations, I doubt that response has worked on a regular, consistent basis.

Jay,

Let's not try fooling each other. The only thing the former community is really going to accept is "Sorry, we screwed up, and you were right all the time. We are going to revert, sorry again".

The former community will probably also accept "OK, we are going to make this optional", except no two people so far agreed on how exactly this should be done, and noone so far seems to have understood how badly it would affect usability and code maintenance.

People just want the old stuff back at any cost. Not gonna happen.

Users become very attached to the software they use.

You make it sound like there are generations of people who passed the habit of Ctrl+S for saving to PNG from father to son, whereas personal digital image editing is barely 30 years old :)

When software evolves in a direction different from that user/workflow, the user experiences *very personal* feelings of *loss*.

The strong feelings expressed in all these "yet another long threads" are users expressing their feelings of _loss_.

And it is not just their _feelings_. Some of them will decide that they will have to migrate to other software which does include them it its "target user group". That migration comes at a very real cost of time, effort, learning, and perhaps money.

Excuse me, but what is wrong with that picture? Human civilization always needs time to adapt to new things. It was ever so.

Would you tell Wright brothers that they shouldn't have had come up with their Flyer, because, ye gods, a hundred years later people still got to spend some time to learn how to get the bloody thing take off? :)

If the developers have made a mistake, it was possibly overlooking these "feelings issues" and not expecting such a strong reaction. That is not to say that the developers did not have to do what they did. However, they should not have been surprised by the reaction.

We knew it was going to be crying and moaning all over the place. We had early warnings of that, too. And actually we made few adjustments to the new model to clarify things, e.g.

http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=f4ce57aa9709e492666c16259e81625a3e4a7796

http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=c3e904fab1b29224b7dd55bb5b4af49f34c3b335

Alexandre Prokoudine http://libregraphicsworld.org

On Wed, Aug 8, 2012 at 2:29 AM, Jay Smith wrote:

However, to me, the XCF does not _currently_ really save what I consider to be the _project_ data.

Gimp does not save, to my knowledge (please excuse any errors), the following (and more, I am sure):

- window positions or sizes - visible dialogs
- viewing magnification magnification - active tool
- most recently applied filter
- most recently used settings in dialogs (such as Image Size settings such as inch vs mm etc.)
etc., etc.

OK, fair point. I can see how a project could have several related images and certain workspace preferences preserved (i.e. "restore as I left it"). Maybe Peter would be interested to have a go at this in the future.

Of all the items listed above only the latter is kinda being addressed so far. Right now, in Git master, some of the former GIMP filters that have been ported to GEGL use the skeleton of the experimental GEGL tool and thus save recent settings automatically. I use it a lot for applying the unsharp mask filter (but I only scale down and clean-up stuff with this version, really -- it's not ready for prime time use).

(Or maybe "project" and "workspace" are completely different things??)

To me, they overlap. At least, a little bit.

Alexandre Prokoudine http://libregraphicsworld.org

On Wed, Aug 8, 2012 at 2:06 AM, Ken Warner wrote:

Alexandre,

Just because you write something down doesn't make it right.

Mein Kampf comes to mind.....

Ken,

Your unwillingness to try understanding the text you are commenting on is amusing, but doesn not really encourage a constructive discussion.

We never said we are right and everybody else is wrong. We never said things are right because we write them down. You just made it up, and if you were a fair person, you'd apologize, but I cannot possibly insist on that.

What we did say is that we make decisions that seem right to us, and we are responsible for making these decisions.

Surely you are intelligent enough to see the difference.

Alexandre Prokoudine http://libregraphicsworld.org

On 08/07/2012 06:53 PM, Alexandre Prokoudine wrote:

On Wed, Aug 8, 2012 at 2:28 AM, Jay Smith wrote:

As many husbands have taken decades to learn (or else they are no longer married), sometimes "writing all the reasoning down" won't make the wife feel better. Right now, the developers are responding to an emotional situation by saying something like "but we did what was logical, we even wrote it down first". In the recorded history of human relations, I doubt that response has worked on a regular, consistent basis.

Jay,

Let's not try fooling each other. The only thing the former community is really going to accept is "Sorry, we screwed up, and you were right all the time. We are going to revert, sorry again".

The former community will probably also accept "OK, we are going to make this optional", except no two people so far agreed on how exactly this should be done, and noone so far seems to have understood how badly it would affect usability and code maintenance.

People just want the old stuff back at any cost. Not gonna happen.

Users become very attached to the software they use.

You make it sound like there are generations of people who passed the habit of Ctrl+S for saving to PNG from father to son, whereas personal digital image editing is barely 30 years old :)

When software evolves in a direction different from that user/workflow, the user experiences *very personal* feelings of *loss*.

The strong feelings expressed in all these "yet another long threads" are users expressing their feelings of _loss_.

And it is not just their _feelings_. Some of them will decide that they will have to migrate to other software which does include them it its "target user group". That migration comes at a very real cost of time, effort, learning, and perhaps money.

Excuse me, but what is wrong with that picture? Human civilization always needs time to adapt to new things. It was ever so.

Would you tell Wright brothers that they shouldn't have had come up with their Flyer, because, ye gods, a hundred years later people still got to spend some time to learn how to get the bloody thing take off? :)

If the developers have made a mistake, it was possibly overlooking these "feelings issues" and not expecting such a strong reaction. That is not to say that the developers did not have to do what they did. However, they should not have been surprised by the reaction.

We knew it was going to be crying and moaning all over the place. We had early warnings of that, too. And actually we made few adjustments to the new model to clarify things, e.g.

http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=f4ce57aa9709e492666c16259e81625a3e4a7796

http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=c3e904fab1b29224b7dd55bb5b4af49f34c3b335

Alexandre Prokoudine

Alexandre,

You made a very specific statement:

"I don't really understand why we need yet another long thread to go through all these things yet again."

I attempted to explain my opinion of the situation, specifically in regard to what you claimed you did not understand.

In return, I got back a dismissive reply that IMHO completely ignored the intent of what I was trying to say. Your response has seriously tested my respect for you -- I tried very hard to show my respect for you.

I was not trying to say that users _should or should not_ do/think/feel this or that for whatever reason.

I was giving my opinion of the dynamics behind **WHY** they DO think/feel this or that.

Either you read my words too quickly without taking time to understand what I was getting at or you completely misunderstood what I was saying. Your response does not jive with the intent of what I was writing.

In fact, you just got out a "bigger hammer" to try and pound the problem down.

From this I am starting to get the idea that you don't actually _want_ to understand the problem; you just want the problem to go away. If that is the case, and as long as that is the case, the problem will not go away.

The users are writing from their feelings. Until you respond to those feelings, you will get nowhere.

In summary, IF nearly every one of the developers responses included some version of the following statement, nearly half of your "long threads" would vanish and life would be good:

"We understand _____ presents a difficult situation for some users and we regret the impact that this has had on you. Unfortunately, we had to make difficult choices in the subject of _______ and the result is that the program will no longer fit the workflow of some users. We feel that the changes we have made will be to the benefit of the majority of the user community and we are dedicated to continuing the improvement of Gimp for the target user community. We appreciate your loyalty to Gimp and hope that you will find a way to adjust your workflows so that Gimp's new behavior will work well for you. Thank you for expressing your concern. Please know that we have heard you, even if the changes we have had to make are not favorable for you, and that we will continue to work on improving the program to be the best that it can be for the target user community."

You may think that you have said this thousands of times, but I have not seen it. Bits and pieces of it had been said, but until you respond to the FEELINGS people are having, every time, you won't get any change in their behavior. Responding to the people with a repetition of the facts without expressing any empathy for what they are going through will get you nowhere.

I've got nothing more to contribute to this subject. Please don't feel the need to reply, especially not if it is like the last reply.

Jay

On 08/07/2012 07:11 PM, Alexandre Prokoudine wrote:

On Wed, Aug 8, 2012 at 2:29 AM, Jay Smith wrote:

However, to me, the XCF does not _currently_ really save what I consider to be the _project_ data.

Gimp does not save, to my knowledge (please excuse any errors), the following (and more, I am sure):

- window positions or sizes - visible dialogs
- viewing magnification magnification - active tool
- most recently applied filter
- most recently used settings in dialogs (such as Image Size settings such as inch vs mm etc.)
etc., etc.

OK, fair point. I can see how a project could have several related images and certain workspace preferences preserved (i.e. "restore as I left it"). Maybe Peter would be interested to have a go at this in the future.

Of all the items listed above only the latter is kinda being addressed so far. Right now, in Git master, some of the former GIMP filters that have been ported to GEGL use the skeleton of the experimental GEGL tool and thus save recent settings automatically. I use it a lot for applying the unsharp mask filter (but I only scale down and clean-up stuff with this version, really -- it's not ready for prime time use).

(Or maybe "project" and "workspace" are completely different things??)

To me, they overlap. At least, a little bit.

Alexandre Prokoudine

Alexandre,

Thank you for your very constructive and helpful reply.

See, I _feel_ heard. And I am a happy camper.

Clarification: I made the statement "Gimp does not save....". I should have said "Gimp does not save in the _image_ file when saving an image....". [The program 'workspace' does remember things like what dialogs were open when the program was closed.]

Jay

On Wed, Aug 8, 2012 at 3:23 AM, Jay Smith wrote:

In return, I got back a dismissive reply

You didn't :)

that IMHO completely ignored the
intent of what I was trying to say.

If I skip some bits, it doesn't mean that I don't read them or disagree. It also can mean that I agree and merely reply to the bits that I disagree or want to clarify (otherwise goddamn long threads get even longer :)). Which is exactly the case here.

In summary, IF nearly every one of the developers responses included some version of the following statement, nearly half of your "long threads" would vanish and life would be good:

"We understand _____ presents a difficult situation for some users and we regret the impact that this has had on you. Unfortunately, we had to make difficult choices in the subject of _______ and the result is that the program will no longer fit the workflow of some users. We feel that the changes we have made will be to the benefit of the majority of the user community and we are dedicated to continuing the improvement of Gimp for the target user community. We appreciate your loyalty to Gimp and hope that you will find a way to adjust your workflows so that Gimp's new behavior will work well for you. Thank you for expressing your concern. Please know that we have heard you, even if the changes we have had to make are not favorable for you, and that we will continue to work on improving the program to be the best that it can be for the target user community."

I can use that in the new FAQ with your permission. How about that?

Alexandre Prokoudine http://libregraphicsworld.org

On 8 Aug 2012 07:24, "Jay Smith" wrote:

In summary, IF nearly every one of the developers responses included some

version of the following statement, nearly half of your "long threads" would vanish and life would be good:

"We understand _____ presents a difficult situation for some users and we regret the impact that this has had on you. Unfortunately, we had to make difficult choices in the subject of _______ and the result is that the program will no longer fit the workflow of some users. We feel that the changes we have made will be to the benefit of the majority of the user community and we are dedicated to continuing the improvement of Gimp for the target user community. We appreciate your loyalty to Gimp and hope that you will find a way to adjust your workflows so that Gimp's new behavior will work well for you. Thank you for expressing your concern. Please know that we have heard you, even if the changes we have had to make are not favorable for you, and that we will continue to work on improving the program to be the best that it can be for the target user community."

You may think that you have said this thousands of times, but I have not

seen it. Bits and pieces of it had been said, but until you respond to the FEELINGS people are having, every time, you won't get any change in their behavior. Responding to the people with a repetition of the facts without expressing any empathy for what they are going through will get you nowhere.

I've got nothing more to contribute to this subject. Please don't feel

the need to reply, especially not if it is like the last reply.

Jay

Don't think that's going to help, everyone thinks they're representative of "the majority of the community". I'm not sure how being a user of open source software brings with it such a sense of entitlement. Gimp works like the kernel, like gnome, like KDE. Summary - the developers decide. Open source is very rarely a democracy like most of the detractors seem to think. None of the developers gain anything if you use their software, nor do they lose anything if you don't.

On Wed, Aug 8, 2012 at 4:47 AM, Oon-Ee Ng wrote:

None of the developers gain anything if you use their software, nor do they lose anything if you don't.

This is not entirely correct. We gain recognition from publicity when someone does great work available in public. Recognition of achievements is generally good for self-esteem. Unfortunately there is very little publicly available awesome work done with GIMP. So anyone trying to order the team around better impresses us first :)

There seems to be a widely adopted strange notion that we work for the good of the public and hence are subservient to it. I won't speak for the rest of the team, but personally I think it's bogus.

Alexandre Prokoudine http://libregraphicsworld.org

Date: Tue, 7 Aug 2012 18:28:56 -0400 From: jay@JaySmith.com
To: gimp-user-list@gnome.org
Subject: Re: [Gimp-user] HATE the new save vs. export behavior

I just wish the developers would be open to conversation of how both types of workflows could be accommodated efficiently (both efficient for users and in the code). Closing off that possibility of conversation is perhaps what hurts most of all. I wish I had enough knowledge to contribute ideas of how to accomplish this while meeting the needs of all.

I agree. IMHO the quickest way to solve this with MINIMUM total compromises is to turn the existing export-not-save message from a static message into a prompt with a choice of export/cancel buttons. That would require maybe less than a dozen lines of actual program code (basically just one logic branch) and rewriting one message string, total. The only developer response I've heard to that is a rather terse "go DIY".

...which, if I had the energy to set up a GIMP compiler one of these days and do exactly that on my own time, I probably would. :)

I understand that developers don't like how this issue keeps coming up over and over again: It hurts their feelings when, after all the time and effort that they spent working on program code (a right thankless blue-collar task in and of itself), the first thing they hear out of the mouths of their broad userbase is vocal complaints from the portion who doesn't like change X. Unfortunately, as Jay describes the hurt emotions are already 100% mutual: It's the users whose workflows relied on the old model who have their feelings hurt first.

Maybe it could have been avoided in advance with better communication routes. The save/export change was e.g. NEVER mentioned front and center on GIMP's homepage news, the only discussions were in dedicated venues that aren't easily found when not specifically looking for them.

Maybe the devs weren't expecting the change to be seen as so significant or so controversial? But either way you have a lot (not speaking proportionally) of GIMP users downloading the new version and feeling emotionally blindsided because they heard absolutely zero about GIMP 2.8 not letting them "Save" standard file formats like 2.6 did.

BTW, I remember browsing the MS Visual Studio forum archives at some point while migrating a program from Visual Basic 6 to VB.Net (what a hell that was). One of the VB topics that was highly controversial back in its day was how Visual Basic 6 had a convention of a "default form instance" but Visual Studio did not:

------------------

In C, you create a new form window just like any other object variable -- by instantiating its class definition:

instance = new class_name(...)

instance.method(...)

In Visual Basic 6.0 and earlier, if your application used only one instance of a given form class at a time you could simplify it by skipping instantiation altogether and just treating the class name itself like a live object variable (comparable to creating a singleton):

formclassname.method(...)

------------------

There were a few conceptual problems with this model in the VS environment (e.g. makes it difficult for the IDE to tell between static and instanced properties and methods), so when MS released VS2008, they dropped it in favor of traditional C-style instantiation.

A lot of old VB users were shocked (insert negative emotion here) because the latter method was the user-preferred way of doing this in old Visual Basic versions. (It was the primary way the program's very own documentation taught users about accessing form methods, with the traditional C-style instantiation held back as an "advanced usage") The former method may be better for several reasons but in the end old habits die hard, and a lot of VB users complained about the change.

With VS 2010, MS added (to the VB language bindings only) the notion of a "default form instance", where any reference to a non-static classname.method() will internally map to something like Application.Forms.getDefaultInstance(classname). The end result is similar to the old VB6 behavior: Convenient, singleton-like references to a form object if they need to have it.

Users become very attached to the software they use. They start to think of it as "theirs". They have made a very real investment in time, energy, learning, etc. to use the software. Users also develop a "brand attachment" that is deeper than most product makers comprehend (users of products will often stick by a product that even they themselves complain about as being inferior -- sort of a Stockholm Syndrome in a different kind of way).

A user's investment in learning how to USE a piece of software is indeed very real and absolutely no less than the developer's own investment in building it.

My mother regularly uses Microsoft Works 4.5 (originally designed for Windows 95) despite knowing that it has a known critical bug in its printing routines that prevents her from doing anything print-related (pagination, page margins, actual printing). She refuses to use the newer (and more stable/capable) versions of Works. Why? It is almost solely because Works 4.5 is an MDI application with one master window containing its own child windows inside it, so you only have one application window on the system taskbar (loosely comparable to Internet browser tabs and GIMP 2.8's single-window mode); the one particular thing you can do only with an MDI application is you can tell the MDI parent to tile its child window positions within its client area (analogous to telling your window manager to tile all open windows), this makes copy/pasting between them faster. It is literally the ONE feature of that version that's absolutely critical to her particular workflow (she does a lot of copy-paste and side-by-side comparisons between files), which also happens to be the same feature that MS deliberately scrapped when designing newer versions of Works (which use one application window per file, à la GIMP's default multi-window mode, Inkscape and so many other apps).

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

Wow. I decided to see if this was an issue for anyone else - I guess it is. I think I pretty well understand the arguments on both sides, and I have to say that I hope one of the many reasonable solutions proposed here is implemented. There really are legitimately different uses of the tool, and a 'one size fits all' approach seems needlessly restrictive.

I've been a Gimp user for a long time. Some of what I do is complex and takes advantage of all the goodness of XCF, but the vast majority is very simple:

1) Open a JPG file 2) Make some minor edits (usually cropping, rotation, and/or color level adjustment) 3) Save that same JPG

In my case I already have an automated workflow that saved the original as a write-only on a different disk, so I really don't care about any of the issues or benefits of XCF for these particular files - I can revert to the original at any time, and my changes are simple. I just need to make edits on a few hundred JPGs with the least possible effort. As well described WAY earlier, the change dramatically increases the complexity of this particular task.

The Gimp developer answer seems to be that I am not worthy of a tool so exalted as Gimp, and I should find and learn some lesser tool better suited to my plebeian needs. Really? I hope cooler heads prevail.

Sorry to pipe in here. I hope I am the only "list responder." I'm against the behavior, but I'm MORE against further discussion of it.

So please, if you would like to respond to this comment, let's not clutter the list any further. I hope the FAQ regarding this and other topics arrives soon so we can simply refer to it without have another long and ugly discussion.

(But I guess I never said I appreciate GiMP... I do. I teach it to others on a regular basis. So I hope no one has ever gotten the impression I don't love GiMP.)

On Thu, 2013-02-28 at 21:58 +0100, pbft wrote:

Wow. I decided to see if this was an issue for anyone else - I guess it is. I think I pretty well understand the arguments on both sides, and I have to say that I hope one of the many reasonable solutions proposed here is implemented. There really are legitimately different uses of the tool, and a 'one size fits all' approach seems needlessly restrictive.

I've been a Gimp user for a long time. Some of what I do is complex and takes advantage of all the goodness of XCF, but the vast majority is very simple:

1) Open a JPG file 2) Make some minor edits (usually cropping, rotation, and/or color level adjustment)
3) Save that same JPG

In my case I already have an automated workflow that saved the original as a write-only on a different disk, so I really don't care about any of the issues or benefits of XCF for these particular files - I can revert to the original at any time, and my changes are simple. I just need to make edits on a few hundred JPGs with the least possible effort. As well described WAY earlier, the change dramatically increases the complexity of this particular task.

The Gimp developer answer seems to be that I am not worthy of a tool so exalted as Gimp, and I should find and learn some lesser tool better suited to my plebeian needs. Really? I hope cooler heads prevail.

On Fri, Mar 1, 2013 at 12:58 AM, pbft wrote:

I just need to make edits on a few hundred JPGs with the least possible effort.

And an old-fashioned image editor is, of course, the best tool for this kind of job, isn't it?

What ever do all these nutheads invent lightrooms and darktables for? :)

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Mar 1, 2013 at 1:02 AM, Daniel wrote:

Sorry to pipe in here. I hope I am the only "list responder." I'm against the behavior, but I'm MORE against further discussion of it.

Ugh, sorry :)

(But I guess I never said I appreciate GiMP... I do. I teach it to others on a regular basis. So I hope no one has ever gotten the impression I don't love GiMP.)

Thank you, Daniel :)

Alexandre Prokoudine http://libregraphicsworld.org

On 02/28/2013 10:05 PM, Alexandre Prokoudine wrote:

On Fri, Mar 1, 2013 at 12:58 AM, pbft wrote:

I just need to make edits on a few hundred JPGs with the least possible effort.

And an old-fashioned image editor is, of course, the best tool for this kind of job, isn't it?

Translation :
Only the elite need gimp, others just need to pay for normal but commercial editor...
Greetings

Maderios
"Art is meant to disturb. Science reassures."
"L'art est fait pour troubler. La science rassure" (Georges Braque)

Am 2013-03-01 15:50, schrieb maderios:

Translation :
Only the elite need gimp, others just need to pay for normal but commercial editor...
Greetings

I do not understand it like that - did you actually check out darktable? It's a free program that seems to fit pbft's workflow. I have a similar workflow to his and since darktable was suggested to me, my usage of GIMP has decreased substantially - unrelated to the save/export behavior.

As for the save/export behavior, I also liked the old one better, but is it really so much more work to configure a shortcut for exporting while overwriting the original image (I used cmd-option-e here on OS X) and learn to ignore the prompt about unsaved changes? I don't think so, and if you think about the logic behind the change, it definitely makes sense.

On Fri, Mar 1, 2013 at 7:07 PM, darkweasel wrote:

Am 2013-03-01 15:50, schrieb maderios:

Translation :
Only the elite need gimp, others just need to pay for normal but commercial editor...
Greetings

I do not understand it like that - did you actually check out darktable?

Personally, I think that Daniel's suggestion to privately answer mails like that one was rather sensible ;-)

Alexandre Prokoudine http://libregraphicsworld.org

On 03/01/2013 04:09 PM, Alexandre Prokoudine wrote:

On Fri, Mar 1, 2013 at 7:07 PM, darkweasel wrote:

Am 2013-03-01 15:50, schrieb maderios:

Translation :
Only the elite need gimp, others just need to pay for normal but commercial editor...
Greetings

I do not understand it like that - did you actually check out darktable?

Personally, I think that Daniel's suggestion to privately answer mails like that one was rather sensible ;-)

You're true Alexandre... This list is reserved for the elite (end off trolling)
Regards

Maderios
"Art is meant to disturb. Science reassures."
"L'art est fait pour troubler. La science rassure" (Georges Braque)

I don't want to be very offensive, but yes, *sometimes* it smells of elitism in here.

On Fri, Mar 1, 2013 at 4:15 PM, maderios wrote:

On 03/01/2013 04:09 PM, Alexandre Prokoudine wrote:

On Fri, Mar 1, 2013 at 7:07 PM, darkweasel wrote:

Am 2013-03-01 15:50, schrieb maderios:

Translation :
Only the elite need gimp, others just need to pay for normal but commercial editor...
Greetings

I do not understand it like that - did you actually check out darktable?

Personally, I think that Daniel's suggestion to privately answer mails like that one was rather sensible ;-)

You're true Alexandre... This list is reserved for the elite (end off trolling)
Regards

--
Maderios
"Art is meant to disturb. Science reassures." "L'art est fait pour troubler. La science rassure" (Georges Braque)

______________________________**_________________ gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/**mailman/listinfo/gimp-user-**list

I'm sorry to hear about that, Psiweapon. Perhaps eventually you'll see it differently.

Alexandre

On Fri, Mar 1, 2013 at 7:35 PM, Psiweapon wrote:

I don't want to be very offensive, but yes, *sometimes* it smells of elitism in here.

On Fri, Mar 1, 2013 at 4:15 PM, maderios wrote:

On 03/01/2013 04:09 PM, Alexandre Prokoudine wrote:

On Fri, Mar 1, 2013 at 7:07 PM, darkweasel wrote:

Am 2013-03-01 15:50, schrieb maderios:

Translation :
Only the elite need gimp, others just need to pay for normal but commercial editor...
Greetings

I do not understand it like that - did you actually check out darktable?

Personally, I think that Daniel's suggestion to privately answer mails like that one was rather sensible ;-)

You're true Alexandre... This list is reserved for the elite (end off trolling)
Regards

--
Maderios
"Art is meant to disturb. Science reassures." "L'art est fait pour troubler. La science rassure" (Georges Braque)

I'm... actually confident that I will :)

On Fri, Mar 1, 2013 at 4:41 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

I'm sorry to hear about that, Psiweapon. Perhaps eventually you'll see it differently.

Alexandre

Pfffft didn't they sell any higher horses on the cattle fair?

On Fri, Mar 1, 2013 at 4:40 PM, Patrick Shanahan wrote:

* Psiweapon [03-01-13 10:35]:

I don't want to be very offensive, but yes, *sometimes* it smells of elitism in here.

don't look now, but your post:
You have top posted
You have fully quoted irrelevant materal You hve post html, email is *text* You are trolling

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

* Psiweapon [03-01-13 10:46]:

Pfffft didn't they sell any higher horses on the cattle fair?

On Fri, Mar 1, 2013 at 4:40 PM, Patrick Shanahan wrote:

* Psiweapon [03-01-13 10:35]:

I don't want to be very offensive, but yes, *sometimes* it smells of elitism in here.

don't look now, but your post:
You have top posted
You have fully quoted irrelevant materal You hve post html, email is *text* You are trolling

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

and you respond to private mail in an open forum!

# ------------------------------------------------------- :0:
* ^From:.psiweapon@gmail.com
/dev/null
# -------------------------------------------------------

(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

Date: Fri, 1 Mar 2013 16:07:36 +0100 From: darkweasel@euirc.eu
To: maderios@gmail.com; gimp-user-list@gnome.org Subject: Re: [Gimp-user] HATE the new save vs. export behavior

Am 2013-03-01 15:50, schrieb maderios:

Translation :
Only the elite need gimp, others just need to pay for normal but commercial editor...
Greetings

As for the save/export behavior, I also liked the old one better, but is it really so much more work to configure a shortcut for exporting while overwriting the original image (I used cmd-option-e here on OS X) and learn to ignore the prompt about unsaved changes? I don't think so, and if you think about the logic behind the change, it definitely makes sense. _______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list

It's not so much the practical task of getting used to it as it is that the change forces you to re-think what is what. In which case GIMP 2.8 isn't the first version to do something like that. For me, that honor goes all the way back to 2.4 -- now from a technical standpoint the old behavior was still present and accessible, the only change is it wasn't the default anymore. And (unlike key shortcuts for save/export) there was NO way to reconfigure the behavior at all. It was technically a simple change, but the way it forced you to re-think how you used GIMP was decidedly earth-shattering.

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

=

Was looking for an explanation on why devs changed the default behavior and found this thread. Spend couple of hours reading it (and other pages about the change).

Still, there are some unclear points that I, as a developer, do not understand; haven't seen the code and is too lazy to spend a day to try to analyze the source code, so maybe someone will be so kind to answer my questions?

In general, options complicate code and make it less manageable. Every option virtually increases amount of cases where application can fail. A snowball can soon become an avalanche.

Do you use automatic tests? How, exactly, it makes it less manageable? Why can't you use Strategy pattern for Save action?

Certain planned changes such as better native CMYK support presume that color separation is done a special mode for exporting. Maintaining a related behavior switch, when you have such a feature, would be hell.

Why can't you just call overwrite() when a user clicks on Save?

Behavior options make documentation convoluted and lacking consistence.

I can help you with that, just add the following to the docs: "This checkbox allows to use the old Save behavior, where open files are saved in the same format with loosing all layers/etc not supported by a target format".

I'm also curious how many hours have been spent in this thread, and how many hours could it actually take to implement that option. If you have tests and if you use proper design patterns, it should not take more than a couple of hours. I wish I could do it, but my primary language is not C.

On 11.05.2013 23:57, relgames wrote:

Was looking for an explanation on why devs changed the default behavior and found this thread.
Spend couple of hours reading it (and other pages about the change).

You didn't tell if you found
http://gui.gimp.org/index.php/Save_%2B_export_specification

The change isn't about anything in the source code, it is a conceptual change about how images are treated in GIMP.

Regards,
Michael