RSS/Atom feed Twitter
Site is read-only, email is disabled

GIMP 2.8 Feature Request (2)

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

25 of 25 messages available
Toggle history

Please log in to manage your subscriptions.

GIMP 2.8 Feature Request (2) Josiah Jack 04 Jan 04:19
  GIMP 2.8 Feature Request (2) Martin Nordholts 04 Jan 05:22
   GIMP 2.8 Feature Request (2) Srihari Sriraman 04 Jan 05:27
   GIMP 2.8 Feature Request (2) Jay Smith 04 Jan 15:21
    GIMP 2.8 Feature Request (2) Alexia Death 04 Jan 15:50
     GIMP 2.8 Feature Request (2) Jay Smith 04 Jan 16:05
      GIMP 2.8 Feature Request (2) Rob Antonishen 04 Jan 16:26
      GIMP 2.8 Feature Request (2) gg@catking.net 04 Jan 16:45
      GIMP 2.8 Feature Request (2) Alexia Death 04 Jan 18:27
     GIMP 2.8 Feature Request (2) Martin Nordholts 05 Jan 06:14
      GIMP 2.8 Feature Request (2) Liam R E Quin 05 Jan 07:02
      GIMP 2.8 Feature Request (2) Liam R E Quin 05 Jan 07:03
       GIMP 2.8 Feature Request (2) Alexia Death 05 Jan 09:30
        GIMP 2.8 Feature Request (2) gg@catking.net 05 Jan 10:55
         GIMP 2.8 Feature Request (2) Liam R E Quin 07 Jan 00:47
    GIMP 2.8 Feature Request (2) Tobias Jakobs 04 Jan 15:54
    GIMP 2.8 Feature Request (2) Chris Mohler 04 Jan 18:31
    GIMP 2.8 Feature Request (2) Martin Nordholts 05 Jan 06:06
   GIMP 2.8 Feature Request (2) Miles Bader 26 Jan 06:45
    GIMP 2.8 Feature Request (2) Alexia Death 26 Jan 07:36
    GIMP 2.8 Feature Request (2) Martin Nordholts 26 Jan 07:57
  GIMP 2.8 Feature Request (2) Srihari Sriraman 04 Jan 05:22
  GIMP 2.8 Feature Request (2) Cristian Secară 06 Jan 20:33
   GIMP 2.8 Feature Request (2) Cristian Secară 06 Jan 20:57
   GIMP 2.8 Feature Request (2) Martin Nordholts 06 Jan 23:52
Josiah Jack
2012-01-04 04:19:07 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

Hello other gimpers!

Been trying out one of the latest GIMP releases in prep for the new 2.8 that I heard is coming out, and I've found a couple things that I dislike and hope will be changed/fixed.

1.) Please recombine the Save As, and Export dialogues. I keep going to Save As and it keeps telling me that it can only save as xcf, not jpg, tga, etc. This is incredibly annoying, especially since I only rarely use xcf file format! Also, if these are kept as separate save dialogues then it will probably be considered as below industry standards considering how almost all applications save and export(just another word for save) from a single save as dialogue.

2.) Clicking the close button to close the application doesn't close the application, it closes the currently open image (in Single Window Mode). I had to click it over 4 times because of all the images I had open. This is definitely a bug in my opinion. There should be a single dialogue that lists the currently open images and asks to save them, has individual save buttons, and, most importantly, has some sort of a "Close without Saving Any" button.

-Josiah Jack

Specs: GIMP 2.7.4
Windows Vista 32bit
AMD Athlon Dual Core 2.00Ghz
4GB RAM
Nvidia GeForce 9800 GT

Other Notes: Moved from: GIMP 2.4.6

Martin Nordholts
2012-01-04 05:22:20 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

2012/1/4 Josiah Jack :

Hello other gimpers!

Been trying out one of the latest GIMP releases in prep for the new 2.8 that I heard is coming out, and I've found a couple things that I dislike and hope will be changed/fixed.

1.)

Srihari Sriraman
2012-01-04 05:22:50 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

although I'm not sure about it being below industry standards, i second the combination of save-as and export options...

Closing single images works very well for me! :)

On Wed, Jan 4, 2012 at 9:49 AM, Josiah Jack wrote:

**
Hello other gimpers!

Been trying out one of the latest GIMP releases in prep for the new 2.8 that I heard is coming out, and I've found a couple things that I dislike and hope will be changed/fixed.

1.) Please recombine the Save As, and Export dialogues. I keep going to Save As and it keeps telling me that it can only save as xcf, not jpg, tga, etc. This is incredibly annoying, especially since I only rarely use xcf file format! Also, if these are kept as separate save dialogues then it will probably be considered as below industry standards considering how almost all applications save and export(just another word for save) from a single save as dialogue.

2.) Clicking the close button to close the application doesn't close the application, it closes the currently open image (in Single Window Mode). I had to click it over 4 times because of all the images I had open. This is definitely a bug in my opinion. There should be a single dialogue that lists the currently open images and asks to save them, has individual save buttons, and, most importantly, has some sort of a "Close without Saving Any" button.

-Josiah Jack

Specs: GIMP 2.7.4
Windows Vista 32bit
AMD Athlon Dual Core 2.00Ghz
4GB RAM
Nvidia GeForce 9800 GT

Other Notes: Moved from: GIMP 2.4.6

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

Srihari Sriraman
2012-01-04 05:27:39 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

I now agree with Martin...
a composition should not be 'saved-as' jpeg or png... i take back my vote...

On Wed, Jan 4, 2012 at 10:52 AM, Martin Nordholts wrote:

2012/1/4 Josiah Jack :

Hello other gimpers!

Been trying out one of the latest GIMP releases in prep for the new 2.8

that

I heard is coming out, and I've found a couple things that I dislike and hope will be changed/fixed.

1.) Please recombine the Save As, and Export dialogues. I keep going to Save As and it keeps telling me that it can only save as xcf, not jpg,

tga,

etc. This is incredibly annoying, especially since I only rarely use xcf file format! Also, if these are kept as separate save dialogues then it will probably be considered as below industry standards considering how almost all applications save and export(just another word for save) from

a

single save as dialogue.

Hi!

If you rarely use the XCF format you are not part of the target user group. The separation of save and export is for users that do complex compositions in XCF and export every now and then. For those users, the way it works now makes sense. That an image previously was considered to be "saved" as PNG was misleading, inaccurate and confusing. No non-trivial composition has ever been "saved" in a PNG file. Not to mention the metric tonne of popup dialogs you had to wade through to "save" in PNG.

2.) Clicking the close button to close the application doesn't close the application, it closes the currently open image (in Single Window

Mode). I

had to click it over 4 times because of all the images I had open. This

is

definitely a bug in my opinion. There should be a single dialogue that lists the currently open images and asks to save them, has

individual save

buttons, and, most importantly, has some sort of a "Close without Saving Any" button.

We probably should, yes. But that has to wait until after we release 2.8. The last stable release was 4 (yes four!) years ago. That's an eternity and we need to learn how to make frequent releases. The first step is to actually release 2.8 first and we can only afford to be delayed by critical issues.

/ Martin

--

My GIMP Blog: http://www.chromecode.com/
"Single-window mode feature complete" _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Jay Smith
2012-01-04 15:21:48 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On 01/04/2012 12:22 AM, Martin Nordholts wrote:

If you rarely use the XCF format you are not part of the target user group. The separation of save and export is for users that do complex compositions in XCF and export every now and then. For those users, the way it works now makes sense. That an image previously was considered to be "saved" as PNG was misleading, inaccurate and confusing. No non-trivial composition has ever been "saved" in a PNG file. Not to mention the metric tonne of popup dialogs you had to wade through to "save" in PNG.

/ Martin

Oh my!

Please clarify so that I can understand if I am "supposed to" stop using Gimp and find something else going forward (because Gimp will be narrowly focused on one "target user group").

I am not in the "target user group". Where does Martin suggest I go? (Wait, don't answer that!)

I read Martin's statement as saying that Gimp is NOT intended for production workflows outside of a narrow definition, that being "users that do complex compositions in XCF and export every now and then."

Our workflow is: Using VueScan Professional (independent of Gimp) to scan a high volume of TIFF images. Open each image in Gimp to tweak color, sharpness, rotation, and crop to desired size. Save as TIFF and close. (Downline we use our own scripts and ImageMagick to batch create several sizes of JPEGs for web use; the TIFFs are also used for print output and are archived as TIFFs.)

It seems to me that I am being told that a workflow such as ours is perhaps "too pedestrian" and "not artistic enough" to be using Gimp. Yet, it is the only open source program that we have found that offers the quality and features we need to _productively_ do the tasks we do.

I comprehend the "stay in XCF" model and don't have a problem with it. I just feel that the swing in saving/exporting concepts was too extreme and did not take the opportunity to combine the operations in such a way that is logical, useful, and work-saving. I have not retained the list messages from the time that it was discussed and I am too lazy to go looking for them, but now (and at that time) I fail to understand what was thought to be "broken" and needed fixing.

Not having seen the new model (I am in production, not development; there is no time or capability to be examining and testing non-stable versions), it sounds like it is going to create a lot more work for us and create a LOT of trash files. We tend to "save" a lot during the editing process and if that is going to create XCF files (since we started by opening TIFF files), then I am going to have to run a nightly housekeeping script to delete all XCF files in the working directory structure.

My way of thinking about the appropriate save/export process is:

a) If an image has been created anew (and not opened), then the save should automatically to save as XCF unless the user specifies a different extent (such as .png or .tif or whatever). If a different extent has been specified, then see 'b'.

b) If an image has been opened, using a non-native extent (i.e. anything other than XCF) OR is being saved to a non-native extent (from 'a' above), then the save/export test that should be applied is whether or not the desired-save/export format results in data loss (due to the capabilities of the target format/extent). If it does result in data loss, then the operation automatically becomes a "Save As" (i.e. "Export") AND the currently open image remains open in XCF but has not been saved (this is a bit of a problem; not sure what to do about that unless it is ALSO saved silently alongside the other format). If the operation does not result in data loss, then the operation is allowed to proceed to automatically save to the desired format AND the currently open image remains open but it has now been saved.

If this process is going to be made a lot more complicated for workflows like ours, then I hope that there will eventually be an optional mechanism to override the save/export process based on input and output file formats.

Jay

Alexia Death
2012-01-04 15:50:37 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Wed, Jan 4, 2012 at 5:21 PM, Jay Smith wrote:

Our workflow is:

Tobias Jakobs
2012-01-04 15:54:33 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Wed, Jan 4, 2012 at 16:21, Jay Smith wrote:

On 01/04/2012 12:22 AM, Martin Nordholts wrote:

I read Martin's statement as saying that Gimp is NOT intended for production workflows outside of a narrow definition, that being "users that do complex compositions in XCF and export every now and then."

You should read it as "Gimp will not optimised for other workflows". You simply can't optimise for everyone.

Tobias

Jay Smith
2012-01-04 16:05:16 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On 01/04/2012 10:50 AM, Alexia Death wrote:

On Wed, Jan 4, 2012 at 5:21 PM, Jay Smith wrote:

Our workflow is: Using VueScan Professional (independent of Gimp) to scan a high volume of TIFF images. Open each image in Gimp to tweak color, sharpness, rotation, and crop to desired size. Save as TIFF and close. (Downline we use our own scripts and ImageMagick to batch create several sizes of JPEGs for web use; the TIFFs are also used for print output and are archived as TIFFs.)

Along broad lines this workflow is or should be just as supported with export as it is with save, just the command you invoke is slightly different. There's one nag I wish was fixed with export. It should default to input format for imported files. It's buggersome annoying that it defaults to png.

??? Why has this not been fixed? It is crazy to think that everybody wants to go to png.

This is completely nuts! I don't have the skills to contribute a fix for this, but surely somebody can (and should) before the next stable release.

If this process is going to be made a lot more complicated for workflows like ours, then I hope that there will eventually be an optional mechanism to override the save/export process based on input and output file formats.

A) it wont be. You can just map Ctrl-s to export, if you dont need to save XCF-s and nothing wil change for you. b) This mechanism already exists. If you save with same parameters all the time write/find a plugin that invokes the save with all the parameters already set. You can just prompt for filename and even manage folders automatically and save without any hassle. If you havent done any scripting but have done programming, it shoudnt take you more than 8 hours to churn out first version, less if you find a good starting sample from google first.

Gee, _only_ 8 hours to get a first version. It would be a _lot_ cheaper to buy Photoshop full version, except that we want to continue moving toward Linux.

The lack of semi-automated macro recording is, in my opinion, the key weakness of Gimp. Recording and testing a macro (say in Photoshop) would take less than 5 minutes.

Jay

Rob Antonishen
2012-01-04 16:26:44 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

b) This mechanism already exists. If you save with same parameters all

the time write/find a plugin that invokes the save with all the

parameters already set. You can just prompt for filename and even manage folders automatically and save without any hassle. If you havent done any scripting but have done programming, it shoudnt take you more than 8 hours to churn out first version, less if you find a good starting sample from google first.

Gee, _only_ 8 hours to get a first version. It would be a _lot_ cheaper to buy Photoshop full version, except that we want to continue moving toward Linux.

Or post a request on the gimp plugin registry, at gimptalk, gug, gimpchat, or even the gimp-user list and one of the many folks out there who do write scripts could make one for you in a 10th that time. I can think of a good half dozen folks (including myself) who regularly respond to such community requests.

Personally, I do support the save/export paradigm so I might be biased.

I've also written any number of export/batch conversion scripts to meet my needs and the needs of others, such as this one: http://photocomix-resources.deviantart.com/art/Gimp-SAVE-EXPORT-145826809?q=boost%3Apopular+save%2Bexport&qo=2

-Rob A>

gg@catking.net
2012-01-04 16:45:27 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On 01/04/12 17:05, Jay Smith wrote: >
>> Along broad lines this workflow is or should be just as supported with >> export as it is with save, just the command you invoke is slightly >> different. There's one nag I wish was fixed with export. It should >> default to input format for imported files. It's buggersome annoying >> that it defaults to png.
>
> ??? Why has this not been fixed? It is crazy to think that everybody > wants to go to png.
>
> This is completely nuts! I don't have the skills to contribute a fix > for this, but surely somebody can (and should) before the next stable > release.

Agreed , this should be fixed and would not be complicated to do.

The whole Export paradigm is only there to try to force users to do something someone else thinks they should be doing.

As long as there is an equally accessible and quick way to save just the way I opened a file that is not a major issue but personally I hate being lectured by software (in reality by developers who think they know better than I what I want/need to do).

/gg

Alexia Death
2012-01-04 18:27:05 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Wed, Jan 4, 2012 at 6:05 PM, Jay Smith wrote:

Gee, _only_ 8 hours to get a first version.

Chris Mohler
2012-01-04 18:31:06 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Wed, Jan 4, 2012 at 9:21 AM, Jay Smith wrote:

Not having seen the new model (I am in production, not development; there is no time or capability to be examining and testing non-stable versions), it sounds like it is going to create a lot more work for us and create a LOT of trash files.  We tend to "save" a lot during the editing process and if that is going to create XCF files (since we started by opening TIFF files), then I am going to have to run a nightly housekeeping script to delete all XCF files in the working directory structure.

A simple cron job - 'find' with date and filename tests - would do the trick, and might be quicker to write than a plug-in. Also, for a short time you'd be able to go back and re-edit the XCF if needed, and retain any extras - masks, layers, etc not present in the TIFF. It might even be a time *saver* if you think about it that way.

Or writing a simple plugin to save the current file as TIFF, overwriting the original, with a fixed set of options should not take 8 hours. I'd guess an hour, or maybe two at the outside.

But I don't have the free time myself - as a matter of fact, I should get back to work right now instead of reading mailing lists ;)

Chris

Martin Nordholts
2012-01-05 06:06:58 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

2012/1/4 Jay Smith :

Please clarify so that I can understand if I am "supposed to" stop using Gimp and find something else going forward (because Gimp will be narrowly focused on one "target user group").

I am not in the "target user group".

Martin Nordholts
2012-01-05 06:14:25 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

2012/1/4 Alexia Death :

There's one nag I wish was fixed with export. It should default to input format for imported files. It's buggersome annoying that it defaults to png.

guiguru intentionally left that out in the spec (http://gui.gimp.org/index.php?title=Save_%2B_export_specification) and I think it was to support this workflow:

"I am a user that always wants to export in .jpg. I use a lot of different source material, so the images I start out with can be of different formats. If I start with a .tiff, I still want GIMP to default to .jpg when I export the composition based on that file since.jpg was the format I exported to the last 10 times".

Note that if you export a single file to a non-PNG format, GIMP will default to that format on any export you do afterwards. In other words, you can easily change the default export format *

* Except that this is not remembered across restarts yet. That's not hard to fix though, it's just that we need to get 2.8 out first.......

/ Martin

Liam R E Quin
2012-01-05 07:02:52 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Thu, 2012-01-05 at 07:14 +0100, Martin Nordholts wrote: [...]

"I am a user that always wants to export in .jpg. I use a lot of different source material, so the images I start out with can be of different formats. If I start with a .tiff, I still want GIMP to default to .jpg when I export the composition based on that file since.jpg was the format I exported to the last 10 times".

I interpret this as "gimp should learn over time which format I prefer to use when exporting each particular image, and after 10 times should default to the requested format" but I think that's proably not what's really meant, as it'd be incredibly annoying.

Note also this is not a professional user, as she/he is preferring a lossy format, and hence is not in the gimp target user group :-)

I suggest a preference, default export format:
[same as imported file]
[same as last export]
[tiff]
[jpeg]
[png]
. . .

but that after you export a file once the same format you chose alst time should be offered as the default the next time you export that file, same as for non-png.

Not suggesting it be done before 2.8; there are some filename and export bugs in there to be fixed too after 2.8, with files reverting to Untitled after you export them. But I think not critical bugs.

Best,

Liam

Liam R E Quin
2012-01-05 07:03:17 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Thu, 2012-01-05 at 07:14 +0100, Martin Nordholts wrote: [...]

"I am a user that always wants to export in .jpg. I use a lot of different source material, so the images I start out with can be of different formats. If I start with a .tiff, I still want GIMP to default to .jpg when I export the composition based on that file since.jpg was the format I exported to the last 10 times".

I interpret this as "gimp should learn over time which format I prefer to use when exporting each particular image, and after 10 times should default to the requested format" but I think that's proably not what's really meant, as it'd be incredibly annoying.

Note also this is not a professional user, as she/he is preferring a lossy format, and hence is not in the gimp target user group :-)

I suggest a preference, default export format:
[same as imported file]
[same as last export]
[tiff]
[jpeg]
[png]
. . .

but that after you export a file once the same format you chose alst time should be offered as the default the next time you export that file, same as for non-png.

Not suggesting it be done before 2.8; there are some filename and export bugs in there to be fixed too after 2.8, with files reverting to Untitled after you export them. But I think not critical bugs.

Best,

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Alexia Death
2012-01-05 09:30:31 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Thu, Jan 5, 2012 at 9:03 AM, Liam R E Quin wrote:

I suggest a preference,
default export format:

gg@catking.net
2012-01-05 10:55:09 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On 01/05/12 10:30, Alexia Death wrote:

On Thu, Jan 5, 2012 at 9:03 AM, Liam R E Quin wrote:

I suggest a preference,
default export format:
[same as imported file]
[same as last export]
[tiff]
[jpeg]
[png]

Not sure jpeg should be explicitly in there since lossy. tiff is very clunky to put in as default. png first IMHO

The current spec states
1. Last export on this file
2. Last export on any file
3. png

That's so mindbogglingly annoying, but yeah found out last night that this is how it was specked and there have been rows over this before.

Odd that [same as imported file] is not in that list If find 2. rather odd, I'm not surprised there was disagreement on this spec.

I hacked up a quick patch to change that to:

1. Last export on this file 2. Last export on any file
3. Import type
4. png

its a tiny patch and man did that make my life nicer.

http://to.who.ee/0001-app-Add-import-type-as-third-preference-on-Export.patch

Cool, I'll build that in locally. I'll probably push it up to position 2.

Many thanks for posting.

/gg

Cristian Secară
2012-01-06 20:33:41 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

În data de Tue, 3 Jan 2012 22:19:07 -0600, Josiah Jack a scris:

1.) Please recombine the Save As, and Export dialogues. I keep going to Save As and it keeps telling me that it can only save as xcf, not jpg, tga, etc. This is incredibly annoying, especially since I only rarely use xcf file format!

At first I was a bit "angry" about the separate export option, but after I get used to it, it proved to solve another old confusion (and so now I like the new behavior).

The old problem was this: - open or create a losless image type - save as (say) .jpg
- after the image was saved in the new format, the title of the image in GIMP becomes something.jpg

My problem with previous style: I always asked myself if the remaining image in GIMP is now the compressed .jpg (thus with some loss already), or the old original with just the name changed. In other words it was never clear (for me :), after using the above scenario, if I will further save as .xcf (or .png, or .tiff, or whatever lossless), the image is saved as it originally was, or will be a result of a new loss-to-lossless transformed image.

Now things are much more clear: the working image is always in native GIMP format and export is the rest of the world.

There is only one thing I do not understand, that the shortcut Ctrl+E appears to do the same as Shift+Ctrl+E, and the shortcut in File menu is Shift +Ctrl +E. Why not just Ctrl+E ? (or what makes Ctrl+E ?)

Also, if these are kept as separate save dialogues then it will probably be considered as below industry standards considering how almost all applications save and export(just another word for save) from a single save as dialogue.

I think I can find a few programs I am using (on Windows) that follow the same logic as the new export in GIMP.

2.) Clicking the close button to close the application doesn't close the application, it closes the currently open image (in Single Window Mode).

Look at the end of File menu. Ctrl+Q closes the application and all opened images at once.

Cristi

Cristian Secară
2012-01-06 20:57:14 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

În data de Fri, 6 Jan 2012 22:33:41 +0200, Cristian Secară a scris:

2.) Clicking the close button to close the application doesn't close the application, it closes the currently open image (in Single Window Mode).

Look at the end of File menu. Ctrl+Q closes the application and all opened images at once.

(... but I agree that a global approach would be probably better, something like individual close button on each tab, or a context menu over tab which includes a close option and THE program close to do just program close)

Cristi

Martin Nordholts
2012-01-06 23:52:20 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

2012/1/6 Cristian Secară :

There is only one thing I do not understand, that the shortcut Ctrl+E appears to do the same as Shift+Ctrl+E, and the shortcut in File menu is Shift +Ctrl +E. Why not just Ctrl+E ? (or what makes Ctrl+E ?)

Ctrl+E acts like Ctrl+S but for export. If you never exported and press Ctrl+E, "Export..." will be invoked. Just like if you never saved, Ctrl+S will invoke "Save as...". If you have already exported the image, Ctrl+E will re-export the image whereas Ctrl+Shift+E will always "Export...". Just like if you have already saved the image, Ctrl+S will re-save the image whereas Ctrl+Shift+S will always "Save as...".

/ Martin

Liam R E Quin
2012-01-07 00:47:06 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Thu, 2012-01-05 at 11:55 +0100, gg@catking.net wrote:

On 01/05/12 10:30, Alexia Death wrote:

On Thu, Jan 5, 2012 at 9:03 AM, Liam R E Quin wrote:

I suggest a preference,
default export format:
[same as imported file]
[same as last export]
[tiff]
[jpeg]
[png]

Not sure jpeg should be explicitly in there since lossy. tiff is very clunky to put in as default. png first IMHO

I meant the list as an example, sorry for not making that clear.

Liam

Miles Bader
2012-01-26 06:45:36 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

Martin Nordholts writes:

If you rarely use the XCF format you are not part of the target user group. The separation of save and export is for users that do complex compositions in XCF and export every now and then.

This seems like a completely bizarre statement.

Who exactly is git being "targetted" at?!

'cause the above doesn't seem to include much of its current user-base -- the Gimp is the default image editor for many, many, systems, and I wouldn't be surprised if 95% of Gimp users don't even know what XCF is, much less actually use it...

-Miles

Alexia Death
2012-01-26 07:36:56 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

On Thu, Jan 26, 2012 at 8:45 AM, Miles Bader wrote:

'cause the above doesn't seem to include much of its current user-base -- the Gimp is the default image editor for many, many, systems, and I wouldn't be surprised if 95% of Gimp users don't even know what XCF is, much less actually use it...

And this is the actual problem we are trying to cure. Take a simple task, add text to image. I cant believe how many people show up asking us how they can change text on a jpg image they made with gimp. They have no idea they could have actually saved the composition as an XCF. Save/Export separation WILL cure this ignorance and save a lot of work for many people.

Martin Nordholts
2012-01-26 07:57:11 UTC (about 12 years ago)

GIMP 2.8 Feature Request (2)

2012/1/26 Miles Bader :

Martin Nordholts writes:

If you rarely use the XCF format you are not part of the target user group. The separation of save and export is for users that do complex compositions in XCF and export every now and then.

This seems like a completely bizarre statement.

Who exactly is git being "targetted" at?!

'cause the above doesn't seem to include much of its current user-base -- the Gimp is the default image editor for many, many, systems, and I wouldn't be surprised if 95% of Gimp users don't even know what XCF is, much less actually use it...

GIMP should not be the default image editor (which Ubuntu realized long ago [1]), because GIMP does not aim to be a JPEG touch-up application, but a high-end photo manipulation application. If GIMP tries to be both an easy to use JPEG touch-up application and a high-end photo manipulation application at the same time, it will never become a great application, just as a car can never be a great car if it tries to be both a Ferrari and a Jeep at the same time.

We could have chosen to direct GIMP towards becoming a great JPEG touch-up application, but there are several good ones in existence already, and to be honest it is quite a boring app to develop, so we went for focusing on creating a high-end photo manipulation application instead.

/ Martin

[1] http://arstechnica.com/open-source/news/2009/11/giving-up-the-gimp-is-a-sign-of-ubuntus-mainstream-maturity.ars