On Fri, May 18, 2012 at 12:39 AM, Markus Heiler wrote:

So my question actually is:

- What other image-editor can I use on Linux?

Pinta, Krita.

Please, I would like the gimp overlords to recommend to all average joes out there what we shall use from now on.

The humour is strong with this Jedi.

Alexandre Prokoudine http://libregraphicsworld.org

What a trip.

On Thu, May 17, 2012 at 3:39 PM, Markus Heiler wrote:

I can see that my Gimp Overlords have also decided to gnomify Gimp.

I think that was a good move. We need to treat all users as potential idiots.

This is getting old. All they gotta do is go use some other FREE graphics application. Most of these complaints could be addressed by simply changing their keyboard shortcuts to use the "overwrite" command instead. I always change about 60% of the Gimp shortcuts anyway. (need to keep my sanity going back and forth between Photoshop and Gimp) Not a big deal.

I am a professional graphic designer and I am thrilled that I no longer have to confirm 3 different dialog windows every time I go to export a flat or compressed rendition of the very complex, multi-layer images that I regularly construct in Gimp. Thank you.

On 05/17/12 23:04, Alexandre Prokoudine wrote:

On Fri, May 18, 2012 at 12:39 AM, Markus Heiler wrote:

So my question actually is:

- What other image-editor can I use on Linux?

Pinta, Krita.

Please, I would like the gimp overlords to recommend to all average joes out there what we shall use from now on.

The humour is strong with this Jedi.

Indeed, but he does have a point. I also find this export jive to be contrived. If I "open" a file and then save it I expect it to be the same file not something else.

Logically then, I am not "opening" the original file, I am "importing" it. So why don't we have File | Open , that only handles xcf ; and File | Import for all the other file formats that people actually use?

Probably because it would be meaningless repetition of function, as is the case for "export".

In addition, having saved my png as a png I have to deal with yet another dialog when I close the already save image which wants to know if I want to close the file without saving. Grrr!

It seems someone thought that xcf was not getting enough air time and that everyone "should" be using it.

The comparison to GNOME is interesting. That project has a long time reputation of being feature Nazis. They know best and anyone who does not agree is just wrong.

File | Export feels a bit that way. I think that's the point he's making.

/gg

On 12-05-17 06:10 PM, Jason Simanek wrote:

This is getting old.

I'm sure it will get even older. :-)

Most of these complaints could be addressed by simply changing their keyboard shortcuts to use the "overwrite" command instead.

So you are saying that in order to "work around" the change we have to use keyboard shortcuts? What about the users that don't often use keyboard shortcuts? Is knowing them going to be "required" or would be just another indicator of whether a user is in the target audience for the program?

On Thu, May 17, 2012 at 6:18 PM, gg wrote:

On 05/17/12 23:04, Alexandre Prokoudine wrote:

On Fri, May 18, 2012 at 12:39 AM, Markus Heiler wrote:

Please, I would like the gimp overlords to recommend to all average

joes out there what we shall use from now on.

The humour is strong with this Jedi.

It seems someone thought that xcf was not getting enough air time and that everyone "should" be using it.

Thank you oh wizened denizen of the timecube, the truth is revealed! GIMP is not an image editor, it is an XCF editor!

Thus must it be renamed - behold: GXCFMP !

On Fri, May 18, 2012 at 2:18 AM, gg wrote:

It seems someone thought that xcf was not getting enough air time and that everyone "should" be using it.

If this is a funny conspiracy theories contest, I'm game! :)

The comparison to GNOME is interesting. That project has a long time reputation of being feature Nazis. They know best and anyone who does not agree is just wrong.

Godwin's law in action. How very predictable.

File | Export feels a bit that way. I think that's the point he's making.

People are not forced to use software at knifepoint. I wish they remembered that well before making accusations.

Alexandre Prokoudine http://libregraphicsworld.org

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

On Thu, May 17, 2012 at 6:12 PM, Kevin Cozens wrote:

On 12-05-17 06:10 PM, Jason Simanek wrote:

Most of these complaints could be addressed by simply changing their keyboard shortcuts to use the "overwrite" command instead.

So you are saying that in order to "work around" the change we have to use keyboard shortcuts? What about the users that don't often use keyboard shortcuts? Is knowing them going to be "required" or would be just another indicator of whether a user is in the target audience for the program?

Well from my perspective if folks are using the Menu > File > then there is only the small hurdle of understanding which command does what they expect it to. So it's "Overwrite" instead of "Save", it's just a matter of learning some terminology.

Most of the whiny complaints that I have read seem to come from somewhat-advanced users that feel entitled to be offended that their way of doing things is no longer the primary use-case of the Gimp project. Indeed, I have read many complaints about how "unintuitive" Ctrl+E is to do what was formerly executed with Ctrl+S. My comment regarding the simplicity of changing keyboard shortcuts is in reference to those complaints.

I am tempted to make similar whining complaints about the many UI decisions made by the folks that make the Gnome desktop, the Unity desktop and the KDE desktop. The reality is that if I am not able to contribute code or make the time to get consistently involved with discussions and thoughtful critiques of UI and UX, then any complaints from me are basically worthless, a waste of my own energy and a massive drag on the attitudes of the people that ARE donating their time and effort to make something that may or may not be useful to other people.

Jason Simanek

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

The comparison to GNOME is interesting. That project has a long time reputation of being feature Nazis. They know best and anyone who does not agree is just wrong.

The job of a user interaction architect does not involve pleasing every living creature out there. What it does involve is listening to people, understanding what their real needs are and then designing interactions and UI.

For years GIMP had been criticized as a project that was lacking focus. It was trying to be everything and failed at that. Now that we have a focus and we've changed UI to match the product vision, do you know what's happening?

I've been monitoring teh interwebz closely regading v2.8 and the save/export change, and what I see is a consistently positive reaction from folks we are targeting: professional web designers, 3D artists etc. They don't even need the explanation why this change is useful: they already know it, it's how they expect things to work, and they welcome this change. So within our product vision apparently we are doing it right.

Yes, someone somewhere will always disagree. And you know what? They have a choice, be it Cinnamon instead of GNOME, or Krita instead of GIMP. This is why we like other projects so much: when some people disagree with what we do, we can tell them -- hey, here is a nice app you might like trying instead of GIMP.

Whether you see this choice is entirely up to you.

Alexandre Prokoudine http://libregraphicsworld.org

A long time ago, I suggested "save workspace" (to XCF) VS "save image" (into a "standard" image format, like png, ideally chosen with some awareness of past actions or the format of the main ingredients of the current image).

gg wrote:

Indeed, but he does have a point. I also find this export jive to be contrived. If I "open" a file and then save it I expect it to be the same file not something else.

It's completely contrived, to work around the technical limitation that Gimp doesn't track what features are used in its internal storage format, so it can't tell if it will loose information when saved back to the original file format. If it did track this, it would be possible to open, edit and then save to jpeg, just like (ahem..) that other image editing program does.

[And no, the compression ratio "problem" for jpeg is a red herring. It's not that hard to extract the quantisation tables on open, and then carry them through to be used by default on save. ]

Graeme Gill.

On Fri, May 18, 2012 at 6:21 AM, Graeme Gill wrote:

gg wrote:

Indeed, but he does have a point. I also find this export jive to be contrived. If I "open" a file and then save it I expect it to be the same file not something else.

It's completely contrived, to work around the technical limitation that Gimp doesn't track what features are used in its internal storage format, so it can't tell if it will loose information when saved back to the original file format. If it did track this, it would be possible to open, edit and then save to jpeg, just like (ahem..) that other image editing program does.

I suggest you actually try GIMP 2.6 or even 2.4. Personally I don't see a constructive discussion arising from assumptions that have nothing to do with actual state of affairs. GIMP had been understanding this stuff and warning about flattening of layers since dawn of times. With 2.8 we simply removed those annoying dialogs.

[And no, the compression ratio "problem" for jpeg is a red herring. It's not that hard to extract the quantisation tables on open, and then carry them through to be used by default on save. ]

The code to read quantization tables dates back at the very least to 2007. It's in plug-ins/jpeg/jpegqual.c.

Is it really important to discuss imaginary technical deficiences? Why?

Alexandre Prokoudine http://libregraphicsworld.org

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

I agree that Import/Save/Export is likely to make complete sense to the target user of GIMP 2.10.
I also have the impression that it may be quite effective at informing soon-to-be-former-users that they are not members of the target club.

On Fri, May 18, 2012 at 6:49 AM, Nicolas Robidoux wrote:

I also have the impression that it may be quite effective at informing soon-to-be-former-users that they are not members of the target club.

Well, calling it a club would certainly give people the wrong idea. Targeting doesn't really equal to elitism :)

I agree that the change should have been explained earlier, and hopefully we shall manage to avoid this kind of communication flops in the future.

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine wrote:

I suggest you actually try GIMP 2.6 or even 2.4. Personally I don't see a constructive discussion arising from assumptions that have nothing to do with actual state of affairs. GIMP had been

I'm not making assumptions, I'm stating the admitted (by the Gimp developers themselves) state of affairs.

See and

Graeme Gill.

2012/5/17 Markus Heiler :

It now, hmm, forces me to store in a super awesome cool format... called xfccxghgf

The reason is that

1. Open file 2. Make changes
3. Save and close file
4. Open the saved file again

should be a non-destructive operation. In GIMP 2.6, this was not the case, so we had to warn the user about loss of information when "saving" as PNG for example. Now that exporting is a separate command, we don't need to issue any warnings, and the process of creating PNGs is smoother (once you learn the new way of working). And in an image editor like GIMP, creating PNGs etc needs to be smooth ...

[...] I now realize that I can't save my image like I used to be able to.

You can actually, just do

File -> Overwrite

instead of

File -> Save.

Best regards, Martin

On Thu, 2012-05-17 at 22:49 -0400, Nicolas Robidoux wrote:

I agree that Import/Save/Export is likely to make complete sense to the target user of GIMP 2.10.
I also have the impression that it may be quite effective at informing soon-to-be-former-users that they are not members of the target club.

That is such utter FUD it makes me puke.

Really, --mitch

One thing that can be useful for who does not read release notes is a tip that appear when an image opened from a format different by xfc is saved. The tip can be: "Gimp now save images as xfc internal format. If you want to save in different format use Export. If you want save in the original format use Overwrite" . The tip has a checkbox where you can chose to don't show next time.

PS: Excuse for my English if I'm not very clear Il giorno 18/mag/2012 08:15, "Michael Natterer" ha scritto:

On Thu, 2012-05-17 at 22:49 -0400, Nicolas Robidoux wrote:

I agree that Import/Save/Export is likely to make complete sense to the target user of GIMP 2.10.
I also have the impression that it may be quite effective at informing soon-to-be-former-users that they are not members of the target club.

That is such utter FUD it makes me puke.

Really, --mitch

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

Jason Simanek gmail.com> writes:

This is getting old. All they gotta do is go use some other FREE graphics application. Most of these complaints could be addressed by simply changing their keyboard shortcuts to use the "overwrite" command instead. I always change about 60% of the Gimp shortcuts anyway. (need to keep my sanity going back and forth between Photoshop and Gimp) Not a big deal.

Here's the problem - overwrite only works once. Then it becomes export. And you can't assign the same keyboard shortcut to both. You'll have to assign two shortcuts, and remember to use one shortcut the first time, and the other shortcut the second, third etc. That is indeed a strange behavior - a command that only works once per file.

Say what you will about save vs. export but this has to be fixed.

Markus Heiler gmail.com> writes:

- What other image-editor can I use on Linux?

pixlr. It's a web app, not a standalone app. But it's pretty awesome. It may not have ALL the features Gimp has, but it also has some it doesn't, such as layer styles or some basic shape drawing options. You can work with masks, layers, color corrections, all the things you'd expect.

www.pixlr.com

Hi!

My 2c on the issue - This change is GOOD not only for the target audience but to the novice too! You would not belive how may times people new to graphics have come to varoius gimp channels asking how i can change text on this here image I saved from gimp yesterday as jpg or png and I have to tell them that they cant! and they are not even aware of the xcf as a format that would allow them to change the composition at any time. In the worst case, they have managed to destroy the original by overwriting it too!

The noobs are safe from destructive mistakes and the pro-s are happy because it now works the way that is the defacto industry standard. Only people that complain are the intermediate users that have habbits they have to change now... Very human. And slightly tedious.

On 18/05/12 02:23, Nicolas Robidoux wrote:

A long time ago, I suggested "save workspace" (to XCF) VS "save image" (into a "standard" image format, like png, ideally chosen with some awareness of past actions or the format of the main ingredients of the current image).

Hi Nicolas,

Now that is the best idea I've seen on this subject. xcf is not an image format since just about nothing else can read it. It is Gimp's internal format. Describing it as saving the gimp workspace is a lot closer to describing its real function and would instantly make sense.

In any other context opening a file and then saving it, the user will *expect to be saving the file* . Why try to redefine what the world already does.

Calling it save workspace makes it instantly clear that it will not writing back to the source image and that any layers etc and work in progress will be safe.

Thus the user would realise what xcf is about and would not be confused by the interface insisting he saves as xcf when he wants to save his png.

Despite the rest of the save/export argument this seems like damn good idea all round.

In fact if this had been thought of years ago, messing with File | Save would probably not have been needed to force people to use xcf.

Chapeau, Nicolas.

Michael Grosberg wrote:

Here's the problem - overwrite only works once. Then it becomes export.

that is a bug.

Overwrite stays Overwrite for as long as users work backwards to the imported file.

only when users start working forward (via Export... defining a new export target + type) does it all change to Export to foo.xyz.

(I checked my spec to see if there was confusion about it: no there is not)

--ps

founder + principal interaction architect man + machine interface works

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

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

On 05/18/2012 10:24 AM, gg wrote:

Calling it save workspace makes it instantly clear that it will not writing back to the source image and that any layers etc and work in progress will be safe.

I would expect "Save Workspace" to save the arrangement of windows and panels. Maybe also the selection of opened files, but not any of the files themselves.

Thinking about how the term "workspace" is used elsewhere, I'm confident a significant percentage of users would have similar expectations.

This is how things work in NIP2. (I am not holding NIP2 as a paragon of beginner friendliness by no means. Just brainstorming, and adapting things a bit to what I understand of GIMP.)

Open/Save have to to with loading/saving from/into the file system (the "hard disk").

Two kinds of objects can be opened/saved: workspaces (which include "everything", windows and all) and individual images. (In GIMP, there may need to be a third type: XCF.)

If the focus is within the "frame" of an individual image, NIP2 understand that "Save" has to do with the image itself, and will ask whether you want png, jpg, ... with a reasonable default.

"Elsewhere", it would make a lot of sense that "Save" default to saving the workspace. (I've not checked because I normally use the menu instead of keyboard shortcuts.)

-----

Import/Export have to do with conversion using an ICC profile. By default, NIP2 does not do this automatically, and makes reasonable but minimal assumptions. But it does not involve the hard drive (unless the profile needs to be taken from there).

Colourspace conversion is separate from both Open/Save and Import/Export.

-----

Again, this is just to give an example of a system which I find logical, and which IMHO accommodates fairly naturally both "naive users" and "power users".

However, it does not address the fact that in GIMP there is a exposed construct that sits between "resulting JPEG" and "the whole workspace with windows, image loaded, some tools at the foregroung...": The XCF file.

Once GEGL becomes the operative system, XCF can be understood as the "tree" that leads to a specific image.

"Save tree"?

On 05/18/2012 02:18 PM, Nicolas Robidoux wrote:

Once GEGL becomes the operative system, XCF can be understood as the "tree" that leads to a specific image.

"Save tree"?

"project" would have my vote.

Whimsically, save workspace/XCF/image could be save forest/tree/leaf.

On Fri, May 18, 2012 at 4:18 PM, Nicolas Robidoux wrote:

Once GEGL becomes the operative system, XCF can be understood as the "tree" that leads to a specific image.

"Save tree"?

"Save the trees
Save the bees
Save the wales
Save those snails"

(c) http://www.youtube.com/watch?v=eScDfYzMEEw

Alexandre Prokoudine http://libregraphicsworld.org

Alexia Death gmail.com> writes:

Hi!

My 2c on the issue - This change is GOOD not only for the target audience but to the novice too!

Those are good reasons to do something, but I believe the problem is with the selected solution and not with the idea of attempting to solve the problem. Photoshop Has a similar "protect user from destructive saving" system, annoying in its own way, which only lets you save to the original as long as no new layers have been added. Once you add layers, choosing "Save" opens a dialog letting you asve as PSD and you have to manually select JPG/PNG in order to save. There is also a warning inside the dialog that data will be lost.

I can see that certain usage patterns will be easier using the new system but perhaps allowances could be made in some cases. For example, if the image is kept as a single layer, it should allow saving to all full-color, non-lossy formats. If an image is saved to a lossy format, it could be decided that the first time you attempt to do this, an alert will explain to you that repeated saving to JPG corrupts the image. A checkbox in the dialog will enable you to prevent it from showing again.

On Fri, May 18, 2012 at 5:13 PM, Michael Grosberg wrote:

If an image is saved to a lossy format, it could be decided that the first time you attempt to do this, an alert will explain to you that repeated saving to JPG corrupts the image. A checkbox in the dialog will enable you to prevent it from showing again.

I have a gut feeling that in terms of usability it is considered to be a mortal sin :)

Alexandre Prokoudine http://libregraphicsworld.org

Hello list

I can't really understand what all this fuss is about. All grafical programms I know of work this way. You only save in the programs own format and export to a diffent like png, jpg or pdf... It is only a kind of "getting used to it" in GIMP, when you have been working with it for some time.

I hate little windows popping up asking me if I'm really, really sure to proceed with the decision I made, so they don't really alert me anymore. I guess a lot of user feel that way, espacially on windows-systems where you get even more alert-windows.
I think it's a really good solution to stick with the normal way to handle saving-procedures.

just my 2c

Anke

Am 18.05.2012 15:32, schrieb Alexandre Prokoudine:

On Fri, May 18, 2012 at 5:13 PM, Michael Grosberg wrote:

If an image is saved to a lossy format, it could be decided that the first time you attempt to do this, an alert will explain to you that repeated saving to JPG corrupts the image. A checkbox in the dialog will enable you to prevent it from showing again.

I have a gut feeling that in terms of usability it is considered to be a mortal sin :)

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

Anke Lange
An der Landwehr 25
49076 Osnabrck
Telefon 0541 6004299
gimp-werkstatt@gmx.de

www.kreativ-workshops.net
www.gimp-werkstatt.de
www.kompozer-web.de

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

Metaphor: A tree (.xcf) will grow away from the forest (project/workspace), but a leaf (.jpg or .png) cut away from the tree won't.

(And yes, I am perfectly aware that in a graph theory sense what I'm proposing to call a "leaf" is actually a "root". The point here is to communicate the key information to non-technical users in a form that they will understand and remember.)

On Fri, May 18, 2012 at 4:24 AM, gg wrote: ...

In any other context opening a file and then saving it, the user will *expect to be saving the file* . Why try to redefine what the world already does.

...

Here is a trivial change that would immediately take care of the confusion that lead to the top post of this thread:

Exchange the ACTIONS of open import and save export.

That is:

import/export is for XCF.

save/open is for JPEG, PNG, GIF, TIFF, ...

If you think about it for a minute, this is not as ad hoc as it first seems, and I suspect that it would preemptively kill a lot of complaints.

Sure, some users will shoot themselves in the foot and open/save and ask "how can I undo"? My guess is that generally they make this mistake once.

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

On Fri, May 18, 2012 at 6:25 PM, Nicolas Robidoux wrote:

Here is a trivial change that would immediately take care of the confusion that lead to the top post of this thread:

Exchange the ACTIONS of open import and save export.

That is:

import/export is for XCF.

save/open is for JPEG, PNG, GIF, TIFF, ...

How does it align to the workflows of professionals?

Alexandre Prokoudine http://libregraphicsworld.org

How does it align to the workflows of professionals?

They still do exactly the same thing. They just use exchanged buttons/keyboard shortcuts.

I'm suggesting "command remapping" so that open/save does what most beginners expect, and import/export does what professionals want (instead of the other way around).

Yet another completely different (and rather radical) idea: If the user saves as JPEG (say), GIMP automatically and silently saves the XCF alongside it or in a special folder. Then Open/Save does everything you want, and when the beginner user reopens the JPEG, he can be asked if he/she wants to actually get back the XCF.

Terminology ideas:

.xcf: composition (composition suggests "result of compositing as well as its process", which is a fitting description, I think) or project

"Everything" (tools, frames, input and output images...): session, workspace or project.

.jpg or .png or .tif or ...: image

Am 18.05.2012 16:49, schrieb Nicolas Robidoux:

Yet another completely different (and rather radical) idea: If the user saves as JPEG (say), GIMP automatically and silently saves the XCF alongside it or in a special folder.

this idea was considered and rejected two years ago. However, for a fully geglized GIMP, it seams feasible to write a journal of all user activities -- for crash recovery and re-edit capability across sessions.

To give an upper bound of required journal bandwidth, let's say the pointing device input comes in as 2*16bit coordinates at 50Hz rate. That's 200B/s or roughly 7MB for a 10-hour workday of non-stop drawing.

I guess with compression and real-world data, it's much less, by factor 10-1000.

best regards, yahvuu

Going to split this because it really NEEDS some wider discussion. There's no nice way of phrasing it - in the current GIMP this distinction is a total snafu.

To: gimp-developer-list@gnome.org From: grosberg.michael@gmail.com
Date: Fri, 18 May 2012 06:45:22 +0000 Subject: Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm

Here's the problem - overwrite only works once. Then it becomes export. And you can't assign the same keyboard shortcut to both. You'll have to assign two shortcuts, and remember to use one shortcut the first time, and the other shortcut the second, third etc. That is indeed a strange behavior - a command that only works once per file.

Say what you will about save vs. export but this has to be fixed.

When I filed bug #675385 about the export/overwrite distinction the overall response was "notabug", but Michael Natterer did also comment that:

Michael Natterer

[GIMP developer]

2012-05-05 17:05:25 UTC

There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu entry is hidden. I fixed that in git, it will be in 2.8.1.

Unfortunately this will only exacerbate the problem -- when all you need to do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this means that your Ctrl+E will either work only once per image session (if assigned to "file-overwrite") or not at all (if assigned to "file-export"). In order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned to the third command.

But why should a third shortcut even be necessary in the first place? This whole distinction between "overwrite" and "export" was fundamentally flawed from the start; there is no reason GIMP should need three functions to perform what are essentially only two commands:

- "Export..." - Analogous to the "Save As" command, but for non-XCF formats. Intended for first-time exports and other situations where you want to export an image to a different filename. You are prompted for a filename and format options before it actually writes to file. - "Overwrite" - Analogous to the "Save" command, but for non-XCF formats. Intended for exporting back to the original (non-XCF) file; whether or not there was a previous export within the current session is simply irrelevant. If the file was neither imported nor exported, then it will trade off to the "Export..." command (also analogous to the Save / Save As distinction).

Remember, at any time GIMP only displays two export options in its menu: The first may be called "Export to [filename]" or "Overwrite [filename]" but regardless of whichever one is currently shown, it performs ultimately the same function: Exporting back to the same non-XCF file with no questions asked. Why does there even need to be two different internal functions (file-export and file-overwrite) to handle this ONE behavior?

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

On 18.05.2012 15:53, Anke Lange wrote:

Hello list

I can't really understand what all this fuss is about. All grafical programms I know of work this way.

+1

Regards

Stefan Peter

On 18/05/2012, Richard Gitschlag wrote:

Going to split this because it really NEEDS some wider discussion. There's no nice way of phrasing it - in the current GIMP this distinction is a total snafu.

To: gimp-developer-list@gnome.org From: grosberg.michael@gmail.com
Date: Fri, 18 May 2012 06:45:22 +0000 Subject: Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm

Here's the problem - overwrite only works once. Then it becomes export. And you can't assign the same keyboard shortcut to both.

Michael Natterer 2012-05-05 17:05:25 UTC There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu entry is hidden. I fixed that in git, it will be in 2.8.1.

Unfortunately this will only exacerbate the problem -- when all you need to do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this means that your Ctrl+E will either work only once per image session (if assigned to "file-overwrite") or not at all (if assigned to "file-export"). In order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned to the third command.

I didn't read the huge paragraph I snipped, but I think you completely misunderstood the reply to the bug. The bug is that ctrl-e doesn't work in 2.8.0 when you import a file until you do 'export'. This is fixed in 2.8.1, you can now always press ctrl-e to export a file. If it is imported, it will prompt for a new name, if you already picked an export name it will silently export to the same name again.

On 05/18/12 19:47, Richard Gitschlag wrote:

When I filed bug #675385 about the export/overwrite distinction the overall response was "notabug", but Michael Natterer did also comment that:

> Michael Natterer

[GIMP developer] 2012-05-05 17:05:25 UTC > There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu > entry is hidden. I fixed that in git, it will be in 2.8.1.

Unfortunately this will only exacerbate the problem -- when all you need to do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this means that your Ctrl+E will either work only once per image session (if assigned to "file-overwrite") or not at all (if assigned to "file-export"). In order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned to the third command.

But why should a third shortcut even be necessary in the first place? This whole distinction between "overwrite" and "export" was fundamentally flawed from the start; there is no reason GIMP should need three functions to perform what are essentially only two commands:

- "Export..." - Analogous to the "Save As" command, but for non-XCF formats. Intended for first-time exports and other situations where you want to export an image to a different filename. You are prompted for a filename and format options before it actually writes to file. - "Overwrite" - Analogous to the "Save" command, but for non-XCF formats. Intended for exporting back to the original (non-XCF) file; whether or not there was a previous export within the current session is simply irrelevant. If the file was neither imported nor exported, then it will trade off to the "Export..." command (also analogous to the Save / Save As distinction).

Remember, at any time GIMP only displays two export options in its menu: The first may be called "Export to [filename]" or "Overwrite [filename]" but regardless of whichever one is currently shown, it performs ultimately the same function: Exporting back to the same non-XCF file with no questions asked. Why does there even need to be two different internal functions (file-export and file-overwrite) to handle this ONE behavior?

That about sums it up for me.

/gg

Another terminology suggestion:

Save image: jpeg, png, tiff, gif, whatever, with default chosen either reasonably (match what the user fed to GIMP, or the last one used) or somewhat safely (not JPEG unless specified).

Save work: xcf

Save project (or, possibly, workspace): multiple xcfs if there is more than one, window configuration, exposed tools with settings, the whole enchilada. Like putting GIMP to sleep. Also, GIMP probably should do this automatically in the background, to help project recovery.

There is no need for separate terminology when opening something, because GIMP can automatically figure out what kind of object it is and act accordingly. So, it's "Open this".

P.S. Thank you gg.

P.S. I know I'm not a UX expert by any means. NNTR

I've been using devel versions for a long while now and have to say I I'm quite unhappy when the new save system. Before the change collegues were impressed by the ability to just add the extension to the filename to save in the desired format, it was a real feature.

Some background on my usage:

I work in an architects office and do a lot of viz as well as the ususal preparation of photographs and other images for publications and presentations. This means doing both heavy (50 layers or more) images for sizes up to A1 and simple tweaks to photographs and other images. The performance of Gimp is unfortunately not good enough for very complex and large format work and there I have to use PS.

In my spare time i do a fair bit of web design, mainly for personal and free software projects, but I have previously worked as a web designer. I'm also an amateur photographer, whose pictures have been published in magazines and books. At home all my computers run Debian and has done for years.

At work we are obviously a windows shop and have the full Adobe suite installed. I'm quite fond of Gimp for some tasks and switch between Gimp and PS. A few years ago the main reason for using gimp was the startup time and the ease of saving to various formats. Perfect for small tweaks to images. Then some of the tools developed and the perspective correction and the Free Select Tools surpassed PS. Both very commonly used by me so that was great and made me push the use of gimp into more complex task at work.

So the tasks I do is:

1. Large complex, multilayered collage type images aiming for close to photorealism. Often painting shadows etc. 2. Adjustments to photographs, curves, sharpness, size perspective corr. 3. Lo res images and graphics for websites. 4. Preparation of images for use as textures, bumpmaps etc for 3d visualisation software. I mainly use Blender and Luxrender.

The thing is that of all those tasks only no 1 could potentially benefit from the safety feature of xcf only save. But even there it actually gets in the way. I've never accidentally lost work due to saving in the wrong format. And I'm in my mid 30's having done graphics for ever ;)

Task no 1 is often based on images prepared using 2,3,4 beforehand. This means that a *vast* majority of saves and opens fall into categories where xcf seriously slows you down.

2,3 and 4 were the tasks gimp used to be perfect for but it has now lost that advantage and due to the save, export, overwrite design it's now more complicated than PS and very confusing.

As mentioned I really like Gimp and I'm grateful for your hard work. I understand that the vision is for Gimp to become great at complex tasks as no 1. I'd just like to emphasize that in my case, and I believe it will be the same for others, way more saves (and opens) will be to jpg,png etc than to xcf.

Regards

On 05/20/2012 08:02 PM, twfb wrote:

I've been using devel versions for a long while now and have to say I I'm quite unhappy when the new save system. Before the change collegues were impressed by the ability to just add the extension to the filename to save in the desired format, it was a real feature.

Some background on my usage:

I work in an architects office and do a lot of viz as well as the ususal preparation of photographs and other images for publications and presentations. This means doing both heavy (50 layers or more) images for sizes up to A1 and simple tweaks to photographs and other images. The performance of Gimp is unfortunately not good enough for very complex and large format work and there I have to use PS.

In my spare time i do a fair bit of web design, mainly for personal and free software projects, but I have previously worked as a web designer. I'm also an amateur photographer, whose pictures have been published in magazines and books. At home all my computers run Debian and has done for years.

At work we are obviously a windows shop and have the full Adobe suite installed. I'm quite fond of Gimp for some tasks and switch between Gimp and PS. A few years ago the main reason for using gimp was the startup time and the ease of saving to various formats. Perfect for small tweaks to images. Then some of the tools developed and the perspective correction and the Free Select Tools surpassed PS. Both very commonly used by me so that was great and made me push the use of gimp into more complex task at work.

So the tasks I do is:

1. Large complex, multilayered collage type images aiming for close to photorealism. Often painting shadows etc. 2. Adjustments to photographs, curves, sharpness, size perspective corr. 3. Lo res images and graphics for websites. 4. Preparation of images for use as textures, bumpmaps etc for 3d visualisation software. I mainly use Blender and Luxrender.

The thing is that of all those tasks only no 1 could potentially benefit from the safety feature of xcf only save. But even there it actually gets in the way. I've never accidentally lost work due to saving in the wrong format. And I'm in my mid 30's having done graphics for ever ;)

Task no 1 is often based on images prepared using 2,3,4 beforehand. This means that a *vast* majority of saves and opens fall into categories where xcf seriously slows you down.

2,3 and 4 were the tasks gimp used to be perfect for but it has now lost that advantage and due to the save, export, overwrite design it's now more complicated than PS and very confusing.

As mentioned I really like Gimp and I'm grateful for your hard work. I understand that the vision is for Gimp to become great at complex tasks as no 1. I'd just like to emphasize that in my case, and I believe it will be the same for others, way more saves (and opens) will be to jpg,png etc than to xcf.

I seriously don't get all the fuzz. Just change S key to E key on keyboard and everything works exactly the same way it always did.

Regards, Vlada

Regards

On 12-05-18 10:49 AM, Nicolas Robidoux wrote:

Yet another completely different (and rather radical) idea: If the user saves as JPEG (say), GIMP automatically and silently saves the XCF alongside it or in a special folder.

Interesting idea but how/when will someone be able to toss away the XCF files they no longer need for projects they worked on ages ago. For a certain group of users this would just fill up their hard drive with XCF files they may not even realize are being saved so they wouldn't be aware of the need to removed XCF files for old projects.

On 12-05-18 10:03 AM, Nicolas Robidoux wrote:

(And yes, I am perfectly aware that in a graph theory sense what I'm proposing to call a "leaf" is actually a "root". The point here is to communicate the key information to non-technical users in a form that they will understand and remember.)

It will depend on ones background. If say "root", to me, that refers to the top level (overall) part of a project (or set of schematics in the case of its use in a schematic capture program I use). It might lead to thinking its the same as saving the whole set of layers or just the first (root) layer.

On 12-05-18 07:07 AM, Thorsten Wilms wrote:

I would expect "Save Workspace" to save the arrangement of windows and panels. Maybe also the selection of opened files, but not any of the files themselves.

That would be my interpretation of "workspace" based on how I can save/load the workspace in a CAD/CAM program I use. It allows changing the layout of menus, icons, and work area but has nothing to do with any model being worked on.

On 12-05-18 08:27 AM, Ofnuts wrote:

"project" would have my vote.

+1

I like this. It is in keeping with several other programs I use (and have seen) where what you are working on has multiple pieces that all need to be saved so you can continue your work at a later day by reloading the project file and not have lost anything.

On Sun, May 20, 2012 at 11:19:08PM +0200, Vladimir Savic wrote:

I seriously don't get all the fuzz. Just change S key to E key on keyboard and everything works exactly the same way it always did.

Me too. And I'm not a pro nor a dev.

...
Just change S key to E key on keyboard ...

It's about first impressions. By the time one is remapping keys, it's too late.

On Mon, May 21, 2012 at 10:51 AM, Kevin Cozens wrote:

...
Interesting idea but how/when will someone be able to toss away the XCF files they no longer need for projects they worked on ages ago. For a certain group of users this would just fill up their hard drive with XCF files they may not even realize are being saved so they wouldn't be aware of the need to removed XCF files for old projects.

NIP2-like solution: When the XCFs start filling up a certain size/percentage of the storage, inform the user at start up and offer to clean up through a GUI.

On Mon, 2012-05-21 at 12:11 -0400, Nicolas Robidoux wrote:

On Mon, May 21, 2012 at 10:51 AM, Kevin Cozens wrote:

[...]

NIP2-like solution: When the XCFs start filling up a certain size/percentage of the storage, inform the user at start up and offer to clean up through a GUI.

Probably it'd need to be slightly more visible - e.g. a checkbox in export, on by default, saying, "save a copy in gimp-native format".

For one thing I often scale down an image after editing, and export for the Web, and would *not* want the xcf file overwritten with the scaled down version.

On the other hand, if I've scanned a largish picture and got a gigabyte image, I don't really want to wait while gimp saves it an extra time.

What *would* be useful here is journalling and the ability to recover state after a crash (or even after an accidental close?).

As GIMP matures in this area I think the answer might be the idea of a "project" which has its own folder for default import/export and resources (e.g. fonts, brushes could come from there too) and also maybe its own window layout with docks etc., so you could have two "single image windows" active at the same time. Then a per-project file could contain history.

I'm not totally against the idea of a "project", but I wonder if it's really necessary to create a project folder with assets considering that XCF is intended to store all that stuff in a single file. I'm fine if the idea is to create a sidecar folder with all the temp stuff generated to speed up preview (caches, proxies, temp pre-comps, etc.) instead of putting them inside the file, but that information should be optional and users should be able to delete it without worrying about the "native editable file". Project folders are fine when you're working on your own machine, but a single native file with editable features is better when you have to pass that file to others.

I'd rather like to see two kind of XCF files when a non-destructive workflow is possibel, a fully editable one (where every asset keeps its original features) and other "baked" where you still have a multilayer comp, but transforms, filters and comples nodetrees are baked into pixels (useful for exchange with other applications that support multiple layers but don't have full XCF/GEGL support).

I also think we are shifting the focus. Even if "Save" is changed to "Save Project" people will still complain about the keystroke, although "Save Project" would make the difference between saving and exporting more evident.

Gez.

On Mon, May 21, 2012 at 5:31 PM, Guillermo Espertino (Gez) wrote:

I'm not totally against the idea of a "project", but I wonder if it's really necessary to create a project folder with assets considering that XCF is intended to store all that stuff in a single file.

The reason is that a GIMP project may contain more than one "finished product"; XCF only collects data relevant to *one* image. For example, I may want to produce various sized versions of a logo.

In addition, XCF does not contain information about how GIMP windows and tools were organized around the related collection of output images. A "project" would, in my mind, collect everything: related images and GIMP configuration.

On 05/22/2012 08:05 AM, Nicolas Robidoux wrote:

On Mon, May 21, 2012 at 5:31 PM, Guillermo Espertino (Gez) wrote:

I'm not totally against the idea of a "project", but I wonder if it's really necessary to create a project folder with assets considering that XCF is intended to store all that stuff in a single file.

The reason is that a GIMP project may contain more than one "finished product"; XCF only collects data relevant to *one* image. For example, I may want to produce various sized versions of a logo.

Seems to me a "project" is a superstructure whose character is broadly independent of the nature of the tasks it contains. A "project" incorporates tasks, resources, status, sometimes even schedules -:-) - and when opened presents the entirety of the project scope. Kinda "eclipse"-like.

-- Burnie