Read this with intrest (as a user) what is the intrinsic difference between save a copy and save as? I am assuming the working document changes in the save as case to the new saved as file. In the save a copy case I assume the working doment is unchanged.

One suggestion in the revert...would it be possible introduce an timed auto backup feature (I have implemented one using a scheme script I invoke with a hot key, currently) and have the revert offer up any of the automatic backups as well as the open state as a revert option?

-Rob A>

On 3/5/09, peter sikking wrote:

Hi all,

we have discussed this intensely before, the ambiguity of what you really
got in your document window after opening--or saving to--a non-GIMP-type image (e.g. jpeg, png).

The discussion returned on the irc this Monday, and I realised then that some remaining nagging use cases could be solved elegantly, and that rationalising the whole situation does not look to be a tour de force.

So here is a short spec:

all we need is some keyboard shortcuts...

ps: that was just a holiday from working on this:

--ps

founder + principal interaction architect man + machine interface works

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

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Thu, 5 Mar 2009 23:36:52 +0100 peter sikking wrote:

Hi all,

we have discussed this intensely before, the ambiguity of what you really
got in your document window after opening--or saving to--a non-GIMP-type image (e.g. jpeg, png).

The discussion returned on the irc this Monday, and I realised then that some remaining nagging use cases could be solved elegantly, and that rationalising the whole situation does not look to be a tour de force.

So here is a short spec:

As a user, I like it. I like the separation of saving native format and "exporting" to non-native formats. Am I right in thinking that "Save back" will only appear in the use case where a non-native file is opened?

Does this mean that the annoying pop-up asking If I want to export will go away if I choose export?
--Alexia

Hi,

On Fri, 2009-03-06 at 11:50 +0200, Alexia Death wrote:

Does this mean that the annoying pop-up asking If I want to export will go away if I choose export?

The dialog does not really ask you if you want to export. It informs you that the image can't be saved because the format you have chosen can not handle some aspects of the image (transparency, multiple layers, ...). It also offers you one or more ways to deal with this situation.

As far as I can see the new spec does not really change this. We should definitely try to straighten this dialog (as Peter already wrote). Part of that is probably that the dialog remembers the last made choice (per format or per image?) and perhaps it should even offer a choice to skip it entirely when exporting this image to this format again. I will have to think about how this fits into the current export functionality. As it is implemented on the plug-in side, it may turn out to be difficult to change it. But first it would be good for us to know how it should look and feel ideally.

Sven

The warning should survive in the case a user is trying to save the image with a layer mask being selected, i.e. the layer mask is up to be saved instead of the whole image. Of course, it can be the user's choice, but anyway he should be warned.

Sven Neumann wrote:

Hi,

On Fri, 2009-03-06 at 11:50 +0200, Alexia Death wrote:

Does this mean that the annoying pop-up asking If I want to export will go away if I choose export?

The dialog does not really ask you if you want to export. It informs you that the image can't be saved because the format you have chosen can not handle some aspects of the image (transparency, multiple layers, ...). It also offers you one or more ways to deal with this situation.

As far as I can see the new spec does not really change this. We should definitely try to straighten this dialog (as Peter already wrote). Part of that is probably that the dialog remembers the last made choice (per format or per image?) and perhaps it should even offer a choice to skip it entirely when exporting this image to this format again. I will have to think about how this fits into the current export functionality. As it is implemented on the plug-in side, it may turn out to be difficult to change it. But first it would be good for us to know how it should look and feel ideally.

Sven

Hi,

On Fri, 2009-03-06 at 14:21 +0200, Alexander Rabtchevich wrote:

The warning should survive in the case a user is trying to save the image with a layer mask being selected, i.e. the layer mask is up to be saved instead of the whole image. Of course, it can be the user's choice, but anyway he should be warned.

In my opinion GIMP should never save only the current drawable unless explicitely asked to do that. The user expects the whole image to be saved. So we probably need to add specific actions to save a layer, a channel or a layer mask.

Sven

Quoting peter sikking :

we have discussed this intensely before, the ambiguity of what you really
got in your document window after opening--or saving to--a non-GIMP-type image (e.g. jpeg, png).
:
:
So here is a short spec:

If you are accepting feedback on the spec, I should like to submit the following:

Under the section "exporting files", the command names "Export...", "Save back", and "Save as template" are confusing. For the latter two, using the word "save" runs counter to one of the main purposes of this exercise -- that is to say, we don't want the user to think that exported data is "safe" so why would we use the word "save" when exporting.

"Save back" in particular is confusing. Not only does employment of the term "save" lead to expectations of data safety and behavior consistent with the other Save commands, but "back" is ambiguous and generates more questions than it answers (what is being saved, a back?, or if back is a place, where?, how far back?).

Would it not be preferable to substitute "Export" for the spec's 'Save Back' command label, and to substitute "Export As..." for the spec's 'Export...' command. I don't see the reasoning behind the name juggling -- why deviate so dramatically from the logic underlying the naming of the "Save" and "Save As..." commands? Excepting for the name/status handling of the image, the correlation should be SaveExport and SaveAs...ExportAs...

I also think that it must be possible to "export" to GIMP file types. This is necessary so that more than one version of GIMP data files can be supported. (ie, GIMP 4.0 might still need to create GIMP 2.x compatible files). In fact, "Saving" should be limited to the latest preferred GIMP-native file format, while requiring that deprecated formats should be "Exported".

It may also be useful if this "export" capability permitted the saving of single-layers, layermasks, channels, or eventually groups/branches of layers (under GEGL) to native GIMP formats. Such may not be, or ever become, useful but nonetheless I see little benefit to prohibiting exportation to native GIMP formats.

Of course, exporting to GIMP-native should not alter the saved status or file name of the image. Not only does this maintain consistency with other export operations, but exporting to a deprecated GIMP format will likely mean a loss of image information.

There was much I liked about the specification, and feel it is especially important that GIMP users realize the potential of losing image data when using non-GIMP formats. This is a recurring problem for beginning users and while I don't think it is necessary to "dumb down" the GIMP interface for them, I do think that the terminology of the menu commands should be as consistent as possible.

Regards.

On Friday 06 March 2009, Sven Neumann wrote:

So we probably need to add specific actions to save a layer, a channel or a layer mask.

If that (plus to save all of a kind, e.g. all layers) could go into the generic save dialog, we would have another 10% questions less on irc :)

Daniel

Hi,

On Fri, 2009-03-06 at 07:33 -0500, saulgoode@flashingtwelve.brickfilms.com wrote:

I also think that it must be possible to "export" to GIMP file types. This is necessary so that more than one version of GIMP data files can be supported. (ie, GIMP 4.0 might still need to create GIMP 2.x compatible files).

Can we please discuss that when a new file format has been introduced? So far there is only XCF and we don't need to make this discussion more complex than needed by talking about imaginary file formats that might be added in the future.

Sven

Hi,

On Fri, 2009-03-06 at 14:17 +0100, peter sikking wrote:

right. one thing I have no overview of is how many ‘topics’ there are for which there are dialogs. Up to now I have seen layers, transparency, bit-depths.

Let's have a look at the capabilities that the save plug-ins announce:

typedef enum {
GIMP_EXPORT_CAN_HANDLE_RGB = 1 << 0, GIMP_EXPORT_CAN_HANDLE_GRAY = 1 << 1, GIMP_EXPORT_CAN_HANDLE_INDEXED = 1 << 2, GIMP_EXPORT_CAN_HANDLE_BITMAP = 1 << 3, GIMP_EXPORT_CAN_HANDLE_ALPHA = 1 << 4, GIMP_EXPORT_CAN_HANDLE_LAYERS = 1 << 5, GIMP_EXPORT_CAN_HANDLE_LAYERS_AS_ANIMATION = 1 << 6, GIMP_EXPORT_CAN_HANDLE_LAYER_MASKS = 1 << 7, GIMP_EXPORT_NEEDS_ALPHA = 1 << 8 } GimpExportCapabilities;

This results in a variety of possible dialogs:

The image has more than one layer but the plug-in can't handle layers. -> "Flatten Image" or "Merge Visible Layers" (for plug-ins that need alpha channel, the "Flatten Image" option is omitted)
(for plug-ins that can't handle an alpha channel, the "Merge" option is omitted)

The image has a single layer but that layer is of a different size than the image, it is offset and/or it has an opacity != 100. -> "Merge Visible Layers"

The image has more than one layer and the plug-in can only handle this if it treats those as frames of an animation. -> "Merge Visible Layers" or "Save as Animation" -> "Flatten Image" or "Save as Animation" (for plug-ins that don't support transparency)

The image has a layer with an alpha channel but the plug-in can't handle transparency.
-> "Flatten Image"

The image has layer masks which the plug-in can't handle. -> "Apply Layer Masks"

The image has a layer without an alpha channel, but the plug-in relies on one.
-> "Add Alpha Channel"

And of course there are the various image mode conflicts that are handled by offering to convert to the mode that the plug-in supports:

"Convert to RGB" "Convert to Grayscale"
"Convert to Indexed using default settings (Do it manually to tune the result)" "Convert to Indexed using bitmap default settings (Do it manually to tune the result)"

These can be combined as options if the destination format supports several modes.

The gory details can be looked up in libgimp/gimpexport.c in the function gimp_export_image().

Sven

On Fri, Mar 6, 2009 at 3:53 PM, Sven Neumann wrote:

This results in a variety of possible dialogs:

And? If I save to a format it can be assumed that I know its limitations. Being warned once about the information loss is good enough. Mind, gimp does not even do that right now. Loss of vector layers and text data goes unannounced. So how about doing it by letting the user per file type (once if user so chooses), its capabilities. Export makes information loss implicit anyway.

And of course there are the various image mode conflicts that are handled by offering to convert to the mode that the plug-in supports:

"Convert to RGB" "Convert to Grayscale"
"Convert to Indexed using default settings (Do it manually to tune the result)" "Convert to Indexed using bitmap default settings (Do it manually to tune the result)"

These can be combined as options if the destination format supports several modes.

Image mode conflicts are a separate problem IMHO.

great this gets tracked down.

One minor suggestion, a simple renaming: Export... => Export as...
Save back => Export

this way, 'Export' resembles 'Save' as a one-click-action and 'Export as...' parallels 'Save as'.

Additionally, the association between 'Save' and safe is kept consistent. (Otherwise a user touching up a JPG might wonder why he is served a nag-screen on closing the image - despite of having "saved back" before)

greetings, peter

Hi,

On Fri, 2009-03-06 at 17:37 +0200, Alexia Death wrote:

And? If I save to a format it can be assumed that I know its limitations. Being warned once about the information loss is good enough.

That is not what GIMP is doing. It tells you that it can't save to that format without modifying the image beforehand. And quite often it needs to ask you what to do because there are several possibilities.

If you knew about the limitations of the file format you are saving to, then you had converted the image beforehand and you wouldn't see the Export dialog at all.

Sven

oops, just recognized i'm replicating a previous post, sorry

yahvuu schrieb:

One minor suggestion, a simple renaming: Export... => Export as...
Save back => Export

yahvuu wrote:

One minor suggestion, a simple renaming: Export... => Export as...
Save back => Export

this way, 'Export' resembles 'Save' as a one-click-action and 'Export as...' parallels 'Save as'.

That sounds good to me. "Save back" would be something I've never seen in any other program to date. It doesn't give me any hints what it is doing other than it is supposedly some type of file(?) save operation.

On Fri, Mar 6, 2009 at 5:49 PM, Sven Neumann wrote:

Hi,

On Fri, 2009-03-06 at 17:37 +0200, Alexia Death wrote:

And? If I save to a format it can be assumed that I know its limitations. Being warned once about the information loss is good enough.

That is not what GIMP is doing. It tells you that it can't save to that format without modifying the image beforehand. And quite often it needs to ask you what to do because there are several possibilities.

But it does not modify the image I am working on, it converts the image into a save result that I never see in gimp. Neither will I expect it to alter my image If I initiate my action with export.

If you knew about the limitations of the file format you are saving to, then you had converted the image beforehand and you wouldn't see the Export dialog at all.

Why would I convert it beforehand? Why would a user need to do a bunch of actions that serve no purpose, are mostly 100% automatic and even hinder when I want to follow the export action up with a native save?

--Alexia

Hi,

On Fri, 2009-03-06 at 18:03 +0200, Alexia Death wrote:

Why would I convert it beforehand? Why would a user need to do a bunch of actions that serve no purpose, are mostly 100% automatic and even hinder when I want to follow the export action up with a native save?

Because they are not 100% automatic. There is user choice involved. If there wasn't, we wouldn't have that dialog. The dialog basically tells you that you forgot to do one or more important steps in your export workflow. And it helps you to do them. It does so in the hope that next time you will do them yourself.

I do almost always convert my image to the final state before saving it to a format such as JPEG or PNG. I can hardly remember how the Export dialog looks like because I never get to see it.

Sven

Hi,

On Fri, 2009-03-06 at 17:24 +0100, Jon Senior wrote:

Just to present the opposing case.

My workflow is: 1) Open raw image via the ufraw plugin. 2) Retouch as necessary, saving as xcf file. 3) Copy visible as new image
4) Resize new image for print or web + sharpen as neccessary. 5) Save result to jpeg file.

I don't mind being warned that step 5 will result in a loss of data (although it'd be nice to be able to do the export silently). But I don't want to have to think about the processes required to export my image to a jpeg for publishing. I just want to do it and get back to editing my xcf file with its nice layers.

Sure, we all just want the computer do do what we want, without being asked. But unfortunately mind-reading devices are not yet available. So the only thing we can do is to ask you if you want to flatten the image because you can't save it as a JPEG file as JPEG does not support transparency.

I am all for improving this situation. But so far no one has come up with a good idea how this could be done. We can't just guess what the user might want to do. If saving a multi-layered image as GIF, is she trying to save an animation or has she forgotten to merge the layers? If saving an image with transparency as a JPEG file, is that really the correct background color so that automatically flattening the image will give the desired result? IF saving an RGB image as GIF, does the user just don't care about the conversion to Indexed Colors or has she forgotten to do it?

Sven

PS: In your particular workflow, basically you are already doing the export conversion yourself. What's breaking your workflow is the fact that "Copy visible as new image" introduces an alpha channel. To improve your workflow we should have a look at that and try to figure out a way to avoid that.

Apologies. I think I hit reply, not reply-all.

On Fri, 06 Mar 2009 17:40:36 +0100 Sven Neumann wrote:

Sure, we all just want the computer do do what we want, without being asked. But unfortunately mind-reading devices are not yet available. So the only thing we can do is to ask you if you want to flatten the image because you can't save it as a JPEG file as JPEG does not support transparency.

Granted. What I was trying to show was that I would prefer to have export manage everything (and simple tell me that I will lose data), than to be expected to modify the workflow in order to prepare images for export.

An example might be when gimp is ultimately capable of 16-bit editing. I will edit my photo in 16-bit to reduce the damage caused by applying curves etc, but I will still want to export to 8-bit jpgs. I might not want to resize so I just hit "export". You were saying that you view the warning when exporting as a reminder that you should have already done that work yourself. I view it as a reminder that the exported file format is a compromise. At the minute, this makes no difference to the end result, but it is a differing mindset which could come into conflict depending on the reworking of the menu items so I felt it worth mentioning.

I am all for improving this situation. But so far no one has come up with a good idea how this could be done. We can't just guess what the user might want to do. If saving a multi-layered image as GIF, is she trying to save an animation or has she forgotten to merge the layers? If saving an image with transparency as a JPEG file, is that really the correct background color so that automatically flattening the image will give the desired result? IF saving an RGB image as GIF, does the user just don't care about the conversion to Indexed Colors or has she forgotten to do it?

I agree that it can't be 100% automatic and I wasn't suggesting that it should be. The point I was trying to make is better expressed above.

PS: In your particular workflow, basically you are already doing the export conversion yourself. What's breaking your workflow is the fact that "Copy visible as new image" introduces an alpha channel. To improve your workflow we should have a look at that and try to figure out a way to avoid that.

Interesting. I gave that as the extreme example. Sometimes I just use "Save a copy" direct from the xcf image. It all depends on what I need the exported file for.

Hi,

just a reminder that there are some bug reports about this topic that might be worth looking at:

Bug 75328 – Add "skip this question" to export dialog boxes. Bug 75459 – Add persistent defaults for the Export dialog Bug 119545 – Merge Export features into the Save dialog Bug 164709 – Export dialog should not allow to ignore mandatory export actions

And there's workflow analysis that Jimmac has done quite some time ago:

http://primates.ximian.com/~glesage/wiki/doku.php?id=gimp:png_export

Sven

Hi,

peter sikking schrieb:

I must also point out that this save + export change is also a change in attitude for GIMP. it clearly supports that our high-end users work in no-loss xcf all the time (if they want to store results) and that also means avoiding doing things like merging, flattening, applying masks, reducing colours. that is all part of the export scenario.

what about using the same mechanism for export as it is planned for managing the GEGL tree? I'm referring to http://gui.gimp.org/index.php/GEGL_analysed, especially your quote "ah, GEGL will solve that".

That means for the user, all export functionality could be represented by a tiny GEGL tree/list which provides operations for flattening, color reduction, background creation, writing files and so on. This tree gets executed anytime the user exports her image.

The first time the user exports something, he has to choose between - automatic conversion, which follows the principle of least surprise and creates a default GEGL tree
- manual conversion, thereby building the list step by step. If the user forgets something, a dialog offers to create the missing steps, very similar to the current behaviour.

The cool thing is, all the complexity of image conversion is represented in a fashion the user is already accustomed to. And the user can easily customize the export process. I'm thinking here of a photo workflow, where multiple versions of an image with different amounts of resizing and sharpening have to be exported. Just add these steps to your 'export tree/list'.

The items in the list should have a checkbox 'ask me every time' (for adjusting jpeg compression etc.)

greetings, peter

PS: Not shure if the export tree should be presented separately or wether it can be merged with the main tree

On Fri, 2009-03-06 at 17:40 +0100, Sven Neumann wrote: [...]

I am all for improving this situation. But so far no one has come up with a good idea how this could be done. We can't just guess what the user might want to do.

We could do better than today. E.g. export to tiff should be probably able to handle layers.

My own workflow for www.fromoldbooks.org tends to be, 1. scan image with xsane plugin
2. crop if needed
3. save as "306-svens-ankles-raw.png 4. either quit after doing several of these, or continue with one... 5. use levels, curves, rotate, flatten, and save as e.g. 306-svens-ankles-cleaned.png 6. spend up to an hour cleaning up the scanned image, under the same name
7. make jpeg versions at various sizes, by 7.1 save as 306-svens-ankles-1.jpg resize image smaller (e.g. to 75%) sharpen, curves etc if needed
7.2 save as 306-svens-ankles-2.jpg undo the resize, sharpen, curves etc 7.3 resize image smaller (e.g. to 56.25%) sharpen, curves, etc. if needed, and save again... and so on, sometimes as many as 10 different sizes.

So I don't want to have to re-enter the filename 10 times.

Why do I not work in .xcf? Because it's not a published standard, and most other programs can't handle it, e.g. to show me a thumbnail, and even GIMP might one day not be able to open the old xcf files. I do sometimes save as xcf in step 5, to save time, as saving in PNG often takes several minutes.

It's important to me that I can see when I saved something in terms of undo history / workflow. I rely on the "*" a lot, from when I last saved as PNG. But, it would be even better if Save and Export events appeared in the undo history (even though obviously "undo" would have to skip over them, you can't undo a save with most file systems!). So, I want Export to make the star go away, if Save As will no longer save as PNG. Otherwise, GIMP sits there for several minutes and I go off and do something else, and when I come back, how do I know it did anything? I'll forget whether I saved the file or not.

For anyone wondering -- I use gimp to rescale and make multiple versions of engravings, and imagemagick in a script for photos, because scanned engravings are so much harder to rescale and often need some touchup.

Liam

I know this thread is already getting long, but I'd prefer to see Export behave similar to:

1. Create a new, multilayer XCF 2. File->Export
3. Name it something.png, click Next 4. Set options, click Save

At no point do I want to be nagged about layers, masks, or anything else. If there were a small warning icon (with maybe a turn-down triangle to display the actual warnings) on the bottom of the option dialog in step 4, that would be nice - but not necessary. I know PNG does not support layers - I do not need the reminder every time.

5. Close the XCF file

At this point I should be prompted to save the XCF "master" file, since I've only done an export and never saved the original.

I based this on PNG, but I'd like to see this workflow on all non-natives. GIF for instance should have the choice to save as animation displayed on the GIF option dialog - not in the warning dialog. IMO, the warning dialog should die ;)

Just $0.02

Chris

Hi,

On Sat, 2009-03-07 at 18:27 +0100, peter sikking wrote:

first, "Copy visible as new image" could easily turn out too smart, but since the bottom Background layer prefers to be one without alpha, I can see something like: when ‘visible’ has effectively universal full opacity, then omit alpha in the new image.

also the export step can wise up a bit and complain less when there is universal full opacity.

We just don't have a good way to figure this out currently. Copy Visible makes a copy from the projection and the projection always has an alpha channel. Perhaps we can make use of the tile-row-hints here. I'll investigate a little if this is a possibility...

Sven

Hi,

On Sat, 2009-03-07 at 16:03 +0100, peter sikking wrote:

no, squeezing these export options in the save dialog is not possible.

I think there is a misunderstanding here. What people suggested is not to put the export options into the Save file-chooser but into the dialog that the save plug-in shows. Not all save plug-ins do this, but for those that do it seems to make a lot of choice to integrate the export questions there. The Save as GIF dialog for example would have a toggle to decide if the image should be merged or if an animation should be saved. That would also make the dialog somewhat simpler as we could make all the animation-specific choices insensitive if the user decides to save the merged image.

that Ignore button has to go. what has to be supported is turning layers/channels/masks into documents, that then can be saved/exported.

OK

I am still tending against a "never show this again" checkbox. even with a reset in the preferences.

OK. That makes it also a lot easier to implement.

Sven

Hi,

On Sun, 2009-03-08 at 11:15 +0100, Sven Neumann wrote:

Not all save plug-ins do this, but for those that do it seems to make a lot of choice to integrate the export questions there.

That was supposed to read "... it seems to make a lot of sense ...".

Sven

On Sat, 2009-03-07 at 18:27 +0100, peter sikking wrote:

first, "Copy visible as new image" could easily turn out too smart,
but since the bottom Background layer prefers to be one without alpha,

The first basic assumption is wrong...so maybe what build on that need reconsideration

A Alpha channel in the background layer do not create problems or disadvantages of sort

A example if you open a png you get exactly that : a image with a background layer that has a alpha channel ,that do not create any complication ,not when editing, not when saving

Problems come only in the contrary case.

Gimp now allow other layers to be without alpha channel, before that was possible only for the BG layer(not because BG layer is better without alpha,but because for the BG a a alpha layer is not strictly needed)

So now is easy have , without noticing , a layer on top without alpha channel

and that will react in a weird way to most layer mode,(when were implemented layer modes , layer(s) to merge were supposed to have alpha)

And obviously then also tools as eraser will also give unwanted results if the alpha is missed

I hope i didn't went too OT, my point is a alpha channel in the BG do not create problem ,neither slow the workflow.

but a NOT-BG layer without alpha that may well create problems ,will be better if layer with no alpha were more clearly "marked " then now

___

peter sikking wrote:

Liam wrote:

I had a careful look at this:

My own workflow for www.fromoldbooks.org tends to be, 1. scan image with xsane plugin
2. crop if needed
3. save as "306-svens-ankles-raw.png 4. either quit after doing several of these, or continue with one... 5. use levels, curves, rotate, flatten, and save as e.g. 306-svens-ankles-cleaned.png
6. spend up to an hour cleaning up the scanned image, under the same name

I guess you realised by now that with the new attitude GIMP prefers that you do all this in xcf, so we can fully support you. Then you can Export to something you consider archival/future proof.

Hi,

there is a problem with this new attitude. Why does GIMP try to impose this " you will work with xcf or die" dictate?

Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not "import") a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working.

Here I want to do some simple editing and save. I do not want to "export" to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc.

All I require is open: edit: save , in original format with original options.

currently I have to jump through hoops and probably delete an extranious xcf that got created along the way because of a temporary save I did to preserve an edit.

This is uncomfortably close the MS approach of "we know best so you'd better fall into line."

Can't this be made less intrusive?

regards.

7. make jpeg versions at various sizes, by 7.1 save as 306-svens-ankles-1.jpg resize image smaller (e.g. to 75%) sharpen, curves etc if needed
7.2 save as 306-svens-ankles-2.jpg undo the resize, sharpen, curves etc 7.3 resize image smaller (e.g. to 56.25%) sharpen, curves, etc. if needed, and save again... and so on, sometimes as many as 10 different sizes.

So I don't want to have to re-enter the filename 10 times.

we are helping you by keeping the same filename filled in as default in the export. you remind me here that we can even help you for the first export by filling in the filename of the xcf. you also remind me that it is not specified what the default file type should be for export (it cannot be xcf...) it is easy to define it as ‘same as last time’ but what will be the very first default? some truly open format?

It's important to me that I can see when I saved something in terms of undo history / workflow. I rely on the "*" a lot, from when I last saved as PNG. But, it would be even better if Save and Export events appeared in the undo history (even though obviously "undo" would have to skip over them, you can't undo a save with most file systems!).

the "*" can only help you when saving, that is to xcf.

although Save and Export cannot be real undo list items (they are not targets or undoable), I can be convinced to annotate the undo history with the Save and Export moments.

--ps

founder + principal interaction architect man + machine interface works

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

Hello,
On Mon, Mar 9, 2009 at 10:09 AM, gg wrote:

there is a problem with this new attitude. Why does GIMP try to impose this " you will work with xcf or die" dictate?

Because it has always been an XCF editor, not an anything else editor. Being able to modify images loaded from PNG, JPEG etc is just because people have created loaders which effectively translate PNG -> in-memory XCF. Everything else, including PSD, is too underspecified/basic to handle GIMP images accurately.

Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not "import") a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working.

That's because you cannot simply open a png, only import. And this has always been the case; what you object to is merely: making an idea that has been implicit in GIMP so far, explicit.

Here I want to do some simple editing and save. I do not want to "export" to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc.

I believe you are protesting your sudden realization of the inaccurate way you were thinking of things, here.

All I require is open: edit: save , in original format with original options.

Open, edit, export as XXX (where XXX is original file -- one of the actions described in the spec.), export settings could be taken from the info in the original file.
I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF.

David

David Gowers wrote:

Hello,
On Mon, Mar 9, 2009 at 10:09 AM, gg wrote:

there is a problem with this new attitude. Why does GIMP try to impose this " you will work with xcf or die" dictate?

Because it has always been an XCF editor, not an anything else editor. Being able to modify images loaded from PNG, JPEG etc is just because people have created loaders which effectively translate PNG -> in-memory XCF. Everything else, including PSD, is too underspecified/basic to handle GIMP images accurately.

Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not "import") a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working.

That's because you cannot simply open a png, only import. And this has always been the case; what you object to is merely: making an idea that has been implicit in GIMP so far, explicit.

IIRC, before (circa 2.2 ?) I could open a png/jpeg ... and save it, with the caveat of the flatten layers nag/warnings.

Yes, it seems that in making it explicit it is becoming more cumbersome. Implicit had some merits. I get the feeling that all this import/export business is in danger of making heavy weather of it.

Here I want to do some simple editing and save. I do not want to "export" to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc.

I believe you are protesting your sudden realization of the inaccurate way you were thinking of things, here.

All I require is open: edit: save , in original format with original options.

Open, edit, export as XXX (where XXX is original file -- one of the actions described in the spec.), export settings could be taken from the info in the original file.

Sounds good. If exporting to original name with original options is readily accessible from a top level menu without having to retype the name that would be pretty good.

I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF.

maybe if the xcf was never saved as such and the work was saved to it's original name, the in memory xcf data could be regarded as an expendable buffer rather than a document that needs to be saved.

Thanks for your reply.

David

gg (gg@catking.net) wrote (in part) (on 2009-03-08 at 20:55):

Sounds good. If exporting to original name with original options is readily accessible from a top level menu without having to retype the name that would be pretty good.

> > I am concerned about whether this would require you to 'confirm close'
> > since the image would not be saved as XCF.

maybe if the xcf was never saved as such and the work was saved to it's
original name, the in memory xcf data could be regarded as an expendable
buffer rather than a document that needs to be saved.

Maybe a check-mark on the "beefed up" dialog being discussed: [x] Close in-memory image after export? and remember this setting for next/subsequent exports of other images until turned off?
(implicit in this would be a automatic [Yes] answer to the "Don't save" popup that would otherwise be shown for dirty images.

Perceived advantage is that it makes clear the primacy of the XCF in memory image vs whatever it was when originally imported.

No reason not to also support this if original import (or XCF opened image) is now being exported to a different format.