Export instead save directly
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.
Export instead save directly
Hello,
I have a little problem with the 2.8.16 version of Gimp. I'm not really
so clear that other file formats can not be saved directly. I save my
photos like in PNG and it must for this version export to PNG. What is
this with the export? I find extremely impractical. Therefore, I will
probably still to work with the 2.6.11 version on.
For this reason I will Gimp 2.8.16 uninstalled.
Export instead save directly
* Alexandra Sachsenweger [02-28-16 11:27]:
Hello,
I have a little problem with the 2.8.16 version of Gimp. I'm not really so clear that other file formats can not be saved directly. I save my photos like in PNG and it must for this version export to PNG. What is this with the export? I find extremely impractical. Therefore, I will probably still to work with the 2.6.11 version on.
Because the image withing gimp is not png. Export equals save to a different format. Export it is.
For this reason I will Gimp 2.8.16 uninstalled.
You are welcome to your choice.
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net
Export instead save directly
> Therefore, I will
> probably still to work with the 2.6.11 version on.
> For this reason I will Gimp 2.8.16 uninstalled.
I suppose that many users returned back to 2.6 for this reason.
There should be a clear warning that saving is still possible, only it
was renamed to "overwrite".
IMO, the intention of the authors was to educate the users and remind
them that at the opening of a file, the data are internally converted to
the working format, and at the saving they are converted back to
original format. But this intention missed its goal, because the user is
not informed what and why was changed, and when he sees that the
application behaves in a weird and user-unfriendly way, then the
simplest solution is to downgrade back to the last sane version.
Export instead save directly
I think the real intention was to prevent the user from accidentally writing to a file format that throws away any layers which have been created and other useful image information. It was a little strange at first for me, but I've gotten quite used to the hotkeys for exporting. It's a shame to revert to 2.6 just for this reason. You miss out on a LOT of new functionality, and all you've really done is save yourself the minor trouble of learning a different save hotkey combo. Ctrl-E = Export or Alt + F + W = overwrite. I use it as a celebration of each successful image edit (Alt [F]or the [W]in!) ;)
There, now you may remember it. :) Hope you reconsider!
My 2p.
-C
On Sun, Feb 28, 2016 at 9:38 PM, A. da Mek wrote:
Therefore, I will
probably still to work with the 2.6.11 version on. For this reason I will Gimp 2.8.16 uninstalled.I suppose that many users returned back to 2.6 for this reason. There should be a clear warning that saving is still possible, only it was renamed to "overwrite".
IMO, the intention of the authors was to educate the users and remind them that at the opening of a file, the data are internally converted to the working format, and at the saving they are converted back to original format. But this intention missed its goal, because the user is not informed what and why was changed, and when he sees that the application behaves in a weird and user-unfriendly way, then the simplest solution is to downgrade back to the last sane version._______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
01234567890123456789012345678901234567890123456789
>> I suppose that many users returned back to 2.6 for this reason.
>> There should be a clear warning that saving is still possible, only
it was renamed to "overwrite".
>> IMO, the intention of the authors was to educate the users and
remind them that at the opening of a file, the data are internally
converted to the working format, and at the saving they are converted
back to original format. But this intention missed its goal, because the
user is not informed what and why was changed, and when he sees that the
application behaves in a weird and user-unfriendly way, then the
simplest solution is to downgrade back to the last sane version.
>
> I think the real intention was to prevent the user from accidentally
writing to a file format that throws away any layers which have been
created and other useful image information.
Which is in other words the same what I wrote, or at least what I wanted to express.
> It's a shame to revert to 2.6 just for this reason. You miss out on a LOT of new functionality
For an average user, GIMP already has everything what we need. But it does be a shame that many of us were forced by this unfortunate change to revert to 2.6.
> and all you've really done is save yourself the minor trouble of learning a different save hotkey combo.
Of course, once I know that saving is still possible, it is only a minor
nuisance to use it under another name. (This could be repaired without
changing the code, only by a different localization.)
But the serious harm is that when we upgrade to 2.8 and see that "save"
does not behave in the expected, logical and traditional way (as it ever
behaved in previous versions and as still behaves in other applications
(for example Inkscape)), that is to save to the file which was opened,
then we consider this version broken and cannot guess that this function
was only hidden on another place and under a different name.
My first reaction was exactly the same as of the user who started this
thread: to downgrade to 2.6, and so I suppose that we two are not the
only ones who did so.
The only reason why I did not give up and continued to search for
further information about this change (and why I joined this mail-list)
is that for me, the GIMP was always a flag-ship of open-source
applications and one of proofs that they are better that the commercial
ones, because they are written by the users who know what they need. So
I was very disappointed when I found this change of functionality and
was wondering what happened and why. IMO, the usual approach of
open-source programmers is "I need a feature, so I am adding it";
whereas the intention for this change was "I want to prevent other users
to do something; I know better than they what is good for them."
When I "save as" (now "export as") into a format other than xcf, or
"save" (now "overwrite") after opening a file of a format other than
xcf, and then "close view", the warning dialog appears which informs me
that some editions can be lost; so I see no reason why to have separate
menu items for "save" versus "overwrite" and "save as" versus "export
as". But as I already said, this would be not much important if the
users were properly informed about this contra-intuitive change.
Export instead save directly
From: gimp-developer-list on behalf of A. da Mek Sent: 29 February 2016 08:35 To: gimp-developer Subject: Re: [Gimp-developer] Export instead save directly ...But as I already said, this would be not much important if the users were properly informed about this contra-intuitive change. _______________________________________________ To which I can only refer you to the informative article that Alexandre wrote 4 years ago: http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes
Export instead save directly
29 февр. 2016 г. 11:35 пользователь "A. da Mek" написал:
For an average user, GIMP already has everything what we need. But it does be a shame that many of us were forced by this unfortunate change to revert to 2.6.
Many of who? There is no indication whatsoever that the group of people who reverted to 2.6 is any large.
But the serious harm is that when we upgrade to 2.8 and see that "save" does not behave in the expected, logical and traditional way (as it ever behaved in previous versions and as still behaves in other applications (for example Inkscape)),
Inkscape developers are considering the very same change: save only to SVG.
then we consider this version broken
If I may just ask, could you please drop "we" and start talking in singular noun please?
But as I already said, this would be not much important if the users were
properly informed about this contra-intuitive change.
They were.
Alex
Export instead save directly
But it does be a shame that many of us were forced by this unfortunate change to revert to 2.6.
Many of who? There is no indication whatsoever that the group of people who reverted to 2.6 is any large.
How can we know how many of them there is, if they simply downgrade to 2.6 and do not bother to discuss it somewhere?
then we consider this version broken
If I may just ask, could you please drop "we" and start talking in singular noun please?
We are at least two: I and the user who started this thread.
I did not opened this matter for myself and only lurked here to see if I
am the only one who sees it as a serious problem. Once I learned how to
save with the new user interface, I have no personal interest in this
cause.
But now when someone else came with with this topic, I fear that there
may be much more of such users who were discouraged from using the new
version, which would be a pity, because the GIMP is an excellent
application.
Export instead save directly
On Mon, Feb 29, 2016 at 12:34 PM, A. da Mek wrote:
Many of who? There is no indication whatsoever that the group of people who
reverted to 2.6 is any large.How can we know how many of them there is, if they simply downgrade to 2.6 and do not bother to discuss it somewhere?
One of the first things I learned when I was in the marketing and PR business is that unhappy customers do complain. A lot. Whereas people who are fine with changes rarely talk, let alone be vocal. So when you seriously mess up, you get no end of complaints from a lot of people and very little support.
What we do have here, however, is a small group of users who are unhappy with this change and who are very vocal. That's telling.
Also, if you think that changes of this sort should be officially talked about in any other way than they already have been, I'm listening.
Alex
Export instead save directly
How can we know how many of them there is, if they simply downgrade to 2.6 and do not bother to discuss it somewhere?
One of the first things I learned when I was in the marketing and PR business is that unhappy customers do complain. A lot.
A producer of a commercial product gets the complaints from the customers who paid for that product and are nor satisfied with it. He does not know if there are any customers who were aware of the flaws of his product already before they bought it, and so they simply decided to buy another product.
Also, if you think that changes of this sort should be officially talked about in any other way than they already have been, I'm listening.
A warning on the download page.
A tip of the day (if possible the first one).
Export instead save directly
On Mon, Feb 29, 2016 at 3:20 PM, A. da Mek wrote:
How can we know how many of them there is, if they simply downgrade to 2.6
and do not bother to discuss it somewhere?One of the first things I learned when I was in the marketing and PR business is that unhappy customers do complain. A lot.
A producer of a commercial product gets the complaints from the customers who paid for that product and are nor satisfied with it. He does not know if there are any customers who were aware of the flaws of his product already before they bought it, and so they simply decided to buy another product.
This is simply not how it really works.
Alex
Export instead save directly
Also, the old way of forcing a user to bypass a warning message every time he/she wants to save to the loaded format is (workflow-wise) much worse than just learning the "Export" hotkey imho. Also, it's clearly not a "flaw"; it's not broken, it's working as intended. If there were a vote, I'd vote to keep it the new way (and I process a very very high volume of product photos with GIMP). I reckon people are more likely to complain about a change in UI conventions than praise it... so here's one praising it. How many theoretical user votes is that worth? ;)
My 2p. -C
On Mon, Feb 29, 2016 at 12:27 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:
On Mon, Feb 29, 2016 at 3:20 PM, A. da Mek wrote:
How can we know how many of them there is, if they simply downgrade to 2.6
and do not bother to discuss it somewhere?One of the first things I learned when I was in the marketing and PR business is that unhappy customers do complain. A lot.
A producer of a commercial product gets the complaints from the customers who paid for that product and are nor satisfied with it. He does not
know if
there are any customers who were aware of the flaws of his product
already
before they bought it, and so they simply decided to buy another product.
This is simply not how it really works.
Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
Hello,
On Mon, 29 Feb 2016 13:15:49 +0000 C R wrote:
Also, the old way of forcing a user to bypass a warning message every time he/she wants to save to the loaded format is (workflow-wise) much worse than just learning the "Export" hotkey imho. Also, it's clearly not a "flaw"; it's not broken, it's working as intended. If there were a vote, I'd vote to keep it the new way (and I process a very very high volume of product photos with GIMP). I reckon people are more likely to complain about a change in UI conventions than praise it... so here's one praising it. How many theoretical user votes is that worth? ;)
That's it! I'm a long-time user of Gimp (this is not an excuse for being right when arguing :-P), and even if I got hurt twice or thrice with the Save as vs Export change, I quickly decided to think about the good reasons for this change, accepted them (and changed the hotkey to export with Ctrl S - hah, I quite never save as .xcf when I process photos, I only use the .xcf storing when I work on graphical constructions).
To bring my 2 cents WRT the exchange between Alexandre and A. da Mek, I think that it's very different/difficult to get feedback from users when you don't sell a product more or less directly and distribute it a passive way (downloads on a website for instance). Alexandre is right (and I well know this, being part of commercial and open source projects for more than 15 years), generally the only guys you hear are the ones who make more noise than the silent ones; and the noisy guys are most of the time the angry ones, specifically the ones with a expansive character and an egocentric/narrow way of thinking. A pain in the *ss to deal w/ user support sometimes, a bigger pain when users come from Windows userland (or other kind of dumb users).
I saw the Save as vs Export thing discussed in many places but it has been well explained and every time it made sense to people who were asking why, it's just difficult for some guys to understand that the file format in GIMP is xcf and that jpg/tif/etc. are exports, exactly like in *office, where odt is the file format and PDF an export for printing/exanging.
The other very important (to my eyes) point when dealing w/ usability is something that may shut the mouth of angry birds: "people" (including me) were complaining about the multiple-window GUI scheme in Gimp 2.6, and for years. Gimp developers finally added a single-window GUI scheme. Isn't that quite a compromise and acceptation from them to (optionally) comply with "standards" and user requests when they make sense?
Regards,
On Mon, Feb 29, 2016 at 12:27 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:
On Mon, Feb 29, 2016 at 3:20 PM, A. da Mek wrote:
How can we know how many of them there is, if they simply downgrade to 2.6
and do not bother to discuss it somewhere?One of the first things I learned when I was in the marketing and PR business is that unhappy customers do complain. A lot.
A producer of a commercial product gets the complaints from the customers who paid for that product and are nor satisfied with it. He does not
know if
there are any customers who were aware of the flaws of his product
already
before they bought it, and so they simply decided to buy another product.
This is simply not how it really works.
Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
wwp
Export instead save directly
On Mon, Feb 29, 2016 at 5:16 PM, wwp wrote:
A pain in
the *ss to deal w/ user support sometimes, a bigger pain when users come from Windows userland (or other kind of dumb users).
I don't think this kind of generalization is really appropriate.
The other very important (to my eyes) point when dealing w/ usability is something that may shut the mouth of angry birds:
Even though some discussions are annoying (mostly because of repetitive statements), this is not about shutting any mouths. This is about creating software that does the job.
Alex
Export instead save directly
If there were a vote, I'd vote to keep it the new way (and I process a very very high volume of product photos with GIMP).
But those are two different questions:
1) Whether to use the "new" interface or the "old" one. This was already
decided long ago.
2) If the users, accustomed to the "old" interface, are properly
informed. I would recommend some short explanation like this:
When you want to "save" a non-xcf file, use "overwrite" instead.
And when you want to "save as" to a non-xcf file, use "export as" instead.
Export instead save directly
Alexandre Prokoudine writes:
Also, if you think that changes of this sort should be officially talked about in any other way than they already have been, I'm listening.
A. da Mek writes:
A warning on the download page.
A tip of the day (if possible the first one).
The Save-Export split is described in the Release Notes for 2.8,
linked from the downloads page:
http://www.gimp.org/release-notes/gimp-2.8.html
It's always a good idea to read the release notes when upgrading
software if you want to be warned about user interface changes.
(Do I always remember to do that myself? No. But if I forget to look, I don't complain afterward about not having been informed.)
The change was also discussed on the gimp-user list starting in early May 2012. (It was discussed on IRC and the developer list much earlier than that, of course, but users aren't expected to see that.) And it has been discussed a lot since then -- my mail folder tracking this topic is up to 1722 messages now, and that doesn't count forums.
I don't like the Save-Export split either (and said so in 2012), but it's baffling to see people complaining about not being notified in 2016 about a change that was clearly documented and discussed back in 2012.
As for sticking with 2.6 and refusing to upgrade: really? Well, it's your choice, of course, but there's no way I'd stick with an older version just because of something that's so easily worked around in a program as configurable as GIMP. You can learn to use export, you can customize your key bindings, you can use a plug-in that does what you want (that's what I did: google for "gimp saver"). GIMP 2.8 has some great new features and 2.10 will have even more. You're free not to upgrade, but you're shortchanging yourself.
...Akkana
Export instead save directly
* A. da Mek [02-29-16 10:20]:
If there were a vote, I'd vote to keep it the new way (and I process a very very high volume of product photos with GIMP).
But those are two different questions: 1) Whether to use the "new" interface or the "old" one. This was already decided long ago.
2) If the users, accustomed to the "old" interface, are properly informed. I would recommend some short explanation like this: When you want to "save" a non-xcf file, use "overwrite" instead. And when you want to "save as" to a non-xcf file, use "export as" instead.
And that msg has been explained *here* ad nauseam. Please take a moment to view the list archives.
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net
Export instead save directly
Hi all,
On Mon, 29 Feb 2016 13:15:49 +0000 C R wrote:
Also, the old way of forcing a user to bypass a warning message every time he/she wants to save to the loaded format is (workflow-wise) much worse than just learning the "Export" hotkey imho. Also, it's clearly not a "flaw"; it's not broken, it's working as intended. If there were a vote, I'd vote to keep it the new way (and I process a very very high volume of product photos with GIMP). I reckon people are more likely to complain about a change in UI conventions than praise it... so here's one praising it. How many theoretical user votes is that worth? ;)
just to note that I, too, am perfectly fine with the new save/export behaviour, and accept it and understand the motivation behind it.
Regards,
Shlomi Fish
--------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Understand what Open Source is - http://shlom.in/oss-fs The conversation about how someone shouldn’t do something in an IRC channel is always at least twice as long as the text the accused person created in the first place — Chris62vw’s Rule Please reply to list if it's a mailing list post - http://shlom.in/reply .
Export instead save directly
And that msg has been explained *here* ad nauseam. Please take a moment to view the list archives.
How many of common users do you suppose to be subscribed to the developer list? To say nothing of reading archives four years back. Imagine a common user who is not an expert on bitmap editing, and the GIMP is for him only one of a dozen of applications used now and then.
Export instead save directly
On Mon, Feb 29, 2016 at 8:29 PM, A. da Mek wrote:
How many of common users do you suppose to be subscribed to the developer list?
Well, how many of them do you expect to read release notes?
P.S. On of the ideas we had for future point releases (3.0, 3.2 etc.) is a dialog that runs the first time the new version is launched and guides users through major changes.
Alex
Export instead save directly
On 02/29/2016 12:37 PM, Alexandre Prokoudine wrote:
Well, how many of them do you expect to read release notes?
P.S. On of the ideas we had for future point releases (3.0, 3.2 etc.) is a dialog that runs the first time the new version is launched and guides users through major changes.
That sounds really nice!
Elle
Export instead save directly
As for sticking with 2.6 and refusing to upgrade: really? Well, it's your choice, of course, but there's no way I'd stick with an older version just because of something that's so easily worked around
But what I am trying to explain is that they do not know that it is
easily worked around. They see that it is forbidden to save non-xcf
files, and so they (wrongly) suppose that they will have to use "export
as" and select the filename every time when they want to save the opened
file (which of course would be very bothering). They overlook the item
"overwrite", which is not much intuitive (and moreover is seen only when
a non-xcf file is opened), and do not realize that this is their old
"save" in disguise. So they think that the new version is aimed only for
the experts who are working primarily with xcf files, not for simple
editing jpg and png files.
And when they read:
"We want GIMP to be a tool used by professionals who work on complex
projects.
This is our target audience, and it has certain workflows.
We want to change GIMP to honor those workflows,"
then they take it as the confirmation of their impression. And the release notes say:
"Saving an image can only be done in the XCF format which is GIMPs
native file format, able to save all kinds of information necessary for
works in progress.
To export into other formats File->Export needs to be used."
Although the release notes then say also:
"There are some optimizations for alternative workflows such as opening a jpg, polishing it, and quickly exporting back to the original file."
this still uses the word "export", so it may be misleading to user not accustomed with this new terminology.
Before these long explanations, I suppose that it would be much more understandable to write simply:
"Save" was renamed to "overwrite" (in the context of editing non-xcf files).
Export instead save directly
On Mon, 2016-02-29 at 18:22 +0000, A. da Mek wrote:
But what I am trying to explain is that they do not know that it is easily worked around.
A possibility might be to have a link on the save dialogue, "export to non-GIMP-native formats" that gets rid of the save dialogue and brings up export *in the same folder*, rather like "edit these settings as curves" in levels.
I still think that there should be a file->import as it's really hard to tell people JPEG and PNG are not native to GIMP when it opens them just fine.
Liam
Liam R. E. Quin
Export instead save directly
> I still think that there should be a file->import as it's really hard to tell people JPEG and PNG are not native to GIMP when it opens them just fine.
Yes, I had the same thought; the current system is asymmetric. If it is insisted that non-xcf files cannot be saved and are exported instead, so they shall be also only imported instead of opened. But when I can open a file, then I expect that I am able also to save it. OTOH, as the application can detect which format is being opened, and choose automatically between opening of the native format and importing of other formats, so maybe the best solution could be simply change the label from "open" to "open or import".
Export instead save directly
Hello,
On Mon, 29 Feb 2016 19:31:00 +0000 "A. da Mek" wrote:
I still think that there should be a file->import as it's really hard to tell people JPEG and PNG are not native to GIMP when it opens them just fine.
Yes, I had the same thought; the current system is asymmetric. If it is insisted that non-xcf files cannot be saved and are exported instead, so they shall be also only imported instead of opened. But when I can open a file, then I expect that I am able also to save it.
That's probably the real point.
OTOH, as the application can detect which format is being opened, and choose automatically between opening of the native format and importing of other formats, so maybe the best solution could be simply change the label from "open" to "open or import".
"open" is generic enough. "import" (if it exists besides "open") usually implies that you convert from a format that is not the format used internally or not the intended format for the application. "export" has the same meaning (but other direction). "save" is generic too. You can also think about other generic terms, like "load" and "store".
Regards,
wwp
Export instead save directly
Hello,
OK, once the discussion is here again, I will also add my 2 cents. There are definitively more than 2 people disapointed by this change. I am the third one. I've got somehow used the new concept, so I don't complain and don't want to get back the former UI, but let me explain two important points:
1. import and export terms are usually used for actions which are not natural for the given application. And most often they don't need to be in pairs, which means, we can import some data, but we cannot store them, and we can export some data, but we cannot load them. This is definitively not the case of Gimp for most of the graphical formats.
2. Do you know some photo/image viewer which can display xcf files? I am not aware of any. Maybe there is some, but it is not important at the moment. The important message is, that poeple (I appologise to Alex for speaking on behalf of other peaple than I am) usually don't want to store they images as xcf. I bet most often they want to load their JPEG from their camera, make some edits, color enhancemnts, etc. and SAVE it back as JPEG. That's all.
Pavel
On 29.02.2016 20:40, wwp wrote:
Hello,
On Mon, 29 Feb 2016 19:31:00 +0000 "A. da Mek" wrote:
I still think that there should be a file->import as it's really
hard to tell people JPEG and PNG are not native to GIMP when it opens them just fine.
Yes, I had the same thought; the current system is asymmetric. If it is insisted that non-xcf files cannot be saved and are exported instead, so they shall be also only imported instead of opened. But when I can open a file, then I expect that I am able also to save it.
That's probably the real point.
OTOH, as the application can detect which format is being opened, and choose automatically between opening of the native format and importing of other formats, so maybe the best solution could be simply change the label from "open" to "open or import".
"open" is generic enough. "import" (if it exists besides "open") usually implies that you convert from a format that is not the format used internally or not the intended format for the application. "export" has the same meaning (but other direction). "save" is generic too. You can also think about other generic terms, like "load" and "store".
Regards,
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
It would probably be okay to use "Save" in a case where there is not much data to be lost by doing so. Like if you flatten the layered image first. If you've done that without exporting anything, it's pretty safe to assume you wouldn't lose anything you were worried about by saving to the imported format.
So for the sake of disinterested people who are just making minor single layer adjustments, Save could default to the imported/opened format IFF there is not more than one layer.
To sum up:
Multiple layers = Save = .xcf
Single layer = Save = .jpg/.png/ imported file format
Maybe this is a way to put a much fought over issue to bed? :)
Just a thought.
-C
Hello,
OK, once the discussion is here again, I will also add my 2 cents. There are definitively more than 2 people disapointed by this change. I am the third one. I've got somehow used the new concept, so I don't complain and don't want to get back the former UI, but let me explain two important points:
1. import and export terms are usually used for actions which are not natural for the given application. And most often they don't need to be in pairs, which means, we can import some data, but we cannot store them, and we can export some data, but we cannot load them. This is definitively not the case of Gimp for most of the graphical formats.
2. Do you know some photo/image viewer which can display xcf files? I am not aware of any. Maybe there is some, but it is not important at the moment. The important message is, that poeple (I appologise to Alex for speaking on behalf of other peaple than I am) usually don't want to store they images as xcf. I bet most often they want to load their JPEG from their camera, make some edits, color enhancemnts, etc. and SAVE it back as JPEG. That's all.
Pavel
On 29.02.2016 20:40, wwp wrote:
Hello,
On Mon, 29 Feb 2016 19:31:00 +0000 "A. da Mek" wrote:
> I still think that there should be a file->import as it's really hard
to tell people JPEG and PNG are not native to GIMP when it opens them just fine.
Yes, I had the same thought; the current system is asymmetric. If it is insisted that non-xcf files cannot be saved and are exported instead, so they shall be also only imported instead of opened. But when I can open a file, then I expect that I am able also to save it.
That's probably the real point.
OTOH, as the application can detect which format is being opened, and
choose automatically between opening of the native format and importing of other formats, so maybe the best solution could be simply change the label from "open" to "open or import".
"open" is generic enough. "import" (if it exists besides "open") usually implies that you convert from a format that is not the format used internally or not the intended format for the application. "export" has the same meaning (but other direction). "save" is generic too. You can also think about other generic terms, like "load" and "store".
Regards,
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
Am Montag, 29. Februar 2016, 22:21:49 schrieb pavel@pamsoft.cz:
Hello,
Hi.
[...]
2. Do you know some photo/image viewer which can display xcf files? I am not aware of any. Maybe there is some, but it is not important at the moment. The important message is, that poeple (I appologise to Alex for speaking on behalf of other peaple than I am) usually don't want to store they images as xcf.
How is that relevant? When you are done with editing you can still export a final flat copy to JPEG for easy viewing while still keeping your working XCF for backup, later tweaking of your work and even to help you proof that an image is actually yours. For cases where that is not needed just using export is fine.
I bet most often they want to load their JPEG from their camera, make some edits, color enhancemnts, etc. and SAVE it back as JPEG. That's all.
While there are certainly people who want to do that it's definitely not the target GIMP tries to cater for. As being said already in this thread, GIMP tries to support professional users in a workflow typical for them. And that certainly neither includes roundtrips through a lossy format like JPEG nor writing to original files.
So yes, users might have to learn that there are export and overwrite now, but as users of a professional tool it shouldn't be asked too much to invest those few seconds to understand these concepts and remember them. This is not a single click tool but a serious application that you need to invest some of your time in to learn it. I fear there is no easy way out.
Pavel
Tobias, not being part of the GIMP team and therefore telling his personal opinion
[...]
Export instead save directly
On 03/01/2016 12:07 AM, C R wrote:
To sum up:
Multiple layers = Save = .xcf
Single layer = Save = .jpg/.png/ imported file format
This would overload the Save action again - something we explicitly got rid of by separating Save and Export.
Save = XCF Export = Everything else
Simple as that.
Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
Export instead save directly
Am Montag, 29. Februar 2016, 23:07:57 schrieb C R:
It would probably be okay to use "Save" in a case where there is not much data to be lost by doing so. Like if you flatten the layered image first. If you've done that without exporting anything, it's pretty safe to assume you wouldn't lose anything you were worried about by saving to the imported format.
So for the sake of disinterested people who are just making minor single layer adjustments, Save could default to the imported/opened format IFF there is not more than one layer.
To sum up: Multiple layers = Save = .xcf
Single layer = Save = .jpg/.png/ imported file formatMaybe this is a way to put a much fought over issue to bed? :)
Just a thought.
That would be terrible. Users not understanding the concept would suddenly be facing images where they can just save to JPEG while others can't, but PNG is still enabled (because they somehow added an alpha channel), and even other images support XCF only (maybe because the layer is bigger than the image). So they would have three images that might look the same and seem to use the same features but GIMP seems to treat them different for no apparent reason. Internal state isn't that obvious after all. I assume that would be even more confusing.
-C
Tobias
[...]
Export instead save directly
That would be terrible. Users not understanding the concept would suddenly be
facing images where they can just save to JPEG while others can't, but PNG is
still enabled (because they somehow added an alpha channel), and even other images support XCF only (maybe because the layer is bigger than the image).
No, that's not what I'm suggesting. If you import a jpeg for example, do your editing, and end up with an alpha channel somehow, the save could still default to the .jpg (the jpeg save dialogue could display a warning that transparency will be lost). That does not prevent the user from requesting a .png (by specifying that extension). It also does not prevent the user saving as an xcf either for that matter.
When closing the file, if the file is not saved as an xcf, and there is extra data to be lost, well, the warning about it is there anyway.
I'm also okay with saying GIMP is for professionals, and just keeping it the way it is, which is the way I use it, and like it just fine. That does not mean I can't be open to making a few small changes for people who want to use GIMP for basic edits without the technical stuff that I need "in the way". Adding the above feature would not cripple my workflow, and I can see the benefit to simpler needs of less advanced users.
My 2p. -C
So
they would have three images that might look the same and seem to use the same
features but GIMP seems to treat them different for no apparent reason. Internal state isn't that obvious after all. I assume that would be even more
confusing.-C
Tobias
[...]
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
Hello Pavel,
On Mon, 29 Feb 2016 22:21:49 +0100 pavel@pamsoft.cz wrote:
2. Do you know some photo/image viewer which can display xcf files? I am not aware of any. Maybe there is some, but it is not important at the moment. The important message is, that poeple (I appologise to Alex for speaking on behalf of other peaple than I am) usually don't want to store they images as xcf. I bet most often they want to load their JPEG from their camera, make some edits, color enhancemnts, etc. and SAVE it back as JPEG. That's all.
[snip]
XnView (MP version at least) does show xcf :-).
Regards,
wwp
Export instead save directly
Am Montag, 29. Februar 2016, 23:57:10 schrieb C R:
That would be terrible. Users not understanding the concept would suddenly be
facing images where they can just save to JPEG while others can't, but PNG is
still enabled (because they somehow added an alpha channel), and even other
images support XCF only (maybe because the layer is bigger than the image).
(I used "just" in the sense of "without any further actions" and not "only".)
No, that's not what I'm suggesting. If you import a jpeg for example, do your editing, and end up with an alpha channel somehow, the save could still default to the .jpg (the jpeg save dialogue could display a warning that transparency will be lost). That does not prevent the user from requesting a .png (by specifying that extension). It also does not prevent the user saving as an xcf either for that matter.
When closing the file, if the file is not saved as an xcf, and there is extra data to be lost, well, the warning about it is there anyway.
But that would mean to just go back to the status quo ante, i.e., revert the save/export dichotomy and bring back saving to arbitrary formats.
[...]
My 2p.
-C
Tobias
[...]
Export instead save directly
If Save intelligently determines the file format that is most likely to be used to save, Export should not be necessary. Just "Save" and "Save As" would suffice.
We could use the "multi layer" & "layer outside layer boundaries" convention to suggest that the user save to xcf, as normal to preserve what they are seeing in the editor. The workflow would just involve flattening the image (which also gets rid of alpha) first before saving to make the Save default to the imported file format as a save suggestion. This has the advantage of being intuitive and changeable merely by typing the required file extension. For my various workflows, 99 times out of 100, it would not be necessary to change anything.
I'd be lying if I said the current export convention didn't trip me up occasionally. It's been 6 years since I switched completely from Photoshop, so in my case, it's not really blamable on convention anylonger. :)
My 2p.
-C
On 1 Mar 2016 8:43 am, "Tobias Ellinghaus" wrote:
Am Montag, 29. Februar 2016, 23:57:10 schrieb C R:
That would be terrible. Users not understanding the concept would
suddenly
be
facing images where they can just save to JPEG while others can't, butPNG
is
still enabled (because they somehow added an alpha channel), and even other
images support XCF only (maybe because the layer is bigger than the image).(I used "just" in the sense of "without any further actions" and not "only".)
No, that's not what I'm suggesting. If you import a jpeg for example, do your editing, and end up with an alpha channel somehow, the save could still default to the .jpg (the jpeg save dialogue could display a warning that transparency will be lost). That does not prevent the user from requesting a .png (by specifying that extension). It also does not
prevent
the user saving as an xcf either for that matter.
When closing the file, if the file is not saved as an xcf, and there is extra data to be lost, well, the warning about it is there anyway.
But that would mean to just go back to the status quo ante, i.e., revert the
save/export dichotomy and bring back saving to arbitrary formats.[...]
My 2p.
-CTobias
[...]
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
Am 01.03.2016 um 15:05 schrieb C R :
If Save intelligently determines the file format that is most likely to be used to save, Export should not be necessary. Just "Save" and "Save As" would suffice.
That's nearly exactly what I did with my patched version on http://gimp.lisanet.de I even made this a configurable option in the Preferences dialog. So, if one is interested, have a look at my patches.
We could use the "multi layer" & "layer outside layer boundaries"
I'm currently testing only for 'multiple layers' but it's quite easy to add other tests.
convention to suggest that the user save to xcf, as normal to preserve what they are seeing in the editor. The workflow would just involve flattening the image (which also gets rid of alpha) first before saving to make the Save default to the imported file format as a save suggestion. This has the advantage of being intuitive and changeable merely by typing the required file extension. For my various workflows, 99 times out of 100, it would not be necessary to change anything.
That was the reason why I did it. And I got a lot of positive feedback from users of my package.
I'd be lying if I said the current export convention didn't trip me up occasionally. It's been 6 years since I switched completely from Photoshop, so in my case, it's not really blamable on convention anylonger. :)
My 2p.
-C
On 1 Mar 2016 8:43 am, "Tobias Ellinghaus" wrote:
Am Montag, 29. Februar 2016, 23:57:10 schrieb C R:
That would be terrible. Users not understanding the concept would
suddenly
be
facing images where they can just save to JPEG while others can't, butPNG
is
still enabled (because they somehow added an alpha channel), and even other
images support XCF only (maybe because the layer is bigger than the image).(I used "just" in the sense of "without any further actions" and not "only".)
No, that's not what I'm suggesting. If you import a jpeg for example, do your editing, and end up with an alpha channel somehow, the save could still default to the .jpg (the jpeg save dialogue could display a warning that transparency will be lost). That does not prevent the user from requesting a .png (by specifying that extension). It also does not
prevent
the user saving as an xcf either for that matter.
When closing the file, if the file is not saved as an xcf, and there is extra data to be lost, well, the warning about it is there anyway.
But that would mean to just go back to the status quo ante, i.e., revert the
save/export dichotomy and bring back saving to arbitrary formats.[...]
My 2p.
-CTobias
[...]
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
Sounds good to me. I'm more than capable of choosing the correct file extension(s) and settings for myself. I think it's beneficial to have those settings already intelligently defaulted to when saving. I believe it will save some clicking in most workflows. Also good that it can be turned on and off in settings. I'd keep the warning about not having saved an .xcf file of the current doc when closing if there is indeed data to be lost. That will have the same effect as the current [Sorry, you can't Save to a jpeg, please use export instead] warning screen. When I type a file extension, GIMP knows what I want to happen. It should do it dutifully, then warn me at a later time that I should save my project construction file before closing it.
+1 from me.
-C
On Tue, Mar 1, 2016 at 2:52 PM, Simone Karin Lehmann wrote:
Am 01.03.2016 um 15:05 schrieb C R :
If Save intelligently determines the file format that is most likely to
be
used to save, Export should not be necessary. Just "Save" and "Save As" would suffice.
That's nearly exactly what I did with my patched version on http://gimp.lisanet.de
I even made this a configurable option in the Preferences dialog. So, if one is interested, have a look at my patches.We could use the "multi layer" & "layer outside layer boundaries"
I'm currently testing only for 'multiple layers' but it's quite easy to add other tests.
convention to suggest that the user save to xcf, as normal to preserve
what
they are seeing in the editor. The workflow would just involve flattening the image (which also gets rid of alpha) first before saving to make the Save default to the imported file format as a save suggestion. This has
the
advantage of being intuitive and changeable merely by typing the required file extension. For my various workflows, 99 times out of 100, it would
not
be necessary to change anything.
That was the reason why I did it. And I got a lot of positive feedback from users of my package.
I'd be lying if I said the current export convention didn't trip me up occasionally. It's been 6 years since I switched completely from
Photoshop,
so in my case, it's not really blamable on convention anylonger. :)
My 2p.
-C
On 1 Mar 2016 8:43 am, "Tobias Ellinghaus" wrote:
Am Montag, 29. Februar 2016, 23:57:10 schrieb C R:
That would be terrible. Users not understanding the concept would
suddenly
be
facing images where they can just save to JPEG while others can't, butPNG
is
still enabled (because they somehow added an alpha channel), and even other
images support XCF only (maybe because the layer is bigger than the image).(I used "just" in the sense of "without any further actions" and not "only".)
No, that's not what I'm suggesting. If you import a jpeg for example,
do
your editing, and end up with an alpha channel somehow, the save could still default to the .jpg (the jpeg save dialogue could display a
warning
that transparency will be lost). That does not prevent the user from requesting a .png (by specifying that extension). It also does not
prevent
the user saving as an xcf either for that matter.
When closing the file, if the file is not saved as an xcf, and there is extra data to be lost, well, the warning about it is there anyway.
But that would mean to just go back to the status quo ante, i.e., revert the
save/export dichotomy and bring back saving to arbitrary formats.[...]
My 2p.
-CTobias
[...]
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
As long as people are putting their hands up, I never save in xcf and would prefer a workflow that was open, edit, save in same format.
However, rather than try to change the core code to appease those with
a similar thought, I would like to know if it is possible to change
this behaviour with a plugin.
This way both sides are happy.
Is it possible to write a plugin that re-maps core shortcuts and changes default menu layouts etc?
On 1 March 2016 at 11:00, C R wrote:
Sounds good to me. I'm more than capable of choosing the correct file extension(s) and settings for myself. I think it's beneficial to have those settings already intelligently defaulted to when saving. I believe it will save some clicking in most workflows. Also good that it can be turned on and off in settings. I'd keep the warning about not having saved an .xcf file of the current doc when closing if there is indeed data to be lost. That will have the same effect as the current [Sorry, you can't Save to a jpeg, please use export instead] warning screen. When I type a file extension, GIMP knows what I want to happen. It should do it dutifully, then warn me at a later time that I should save my project construction file before closing it.
+1 from me.
-C
On Tue, Mar 1, 2016 at 2:52 PM, Simone Karin Lehmann wrote:
Am 01.03.2016 um 15:05 schrieb C R :
If Save intelligently determines the file format that is most likely to
be
used to save, Export should not be necessary. Just "Save" and "Save As" would suffice.
That's nearly exactly what I did with my patched version on http://gimp.lisanet.de
I even made this a configurable option in the Preferences dialog. So, if one is interested, have a look at my patches.We could use the "multi layer" & "layer outside layer boundaries"
I'm currently testing only for 'multiple layers' but it's quite easy to add other tests.
convention to suggest that the user save to xcf, as normal to preserve
what
they are seeing in the editor. The workflow would just involve flattening the image (which also gets rid of alpha) first before saving to make the Save default to the imported file format as a save suggestion. This has
the
advantage of being intuitive and changeable merely by typing the required file extension. For my various workflows, 99 times out of 100, it would
not
be necessary to change anything.
That was the reason why I did it. And I got a lot of positive feedback from users of my package.
I'd be lying if I said the current export convention didn't trip me up occasionally. It's been 6 years since I switched completely from
Photoshop,
so in my case, it's not really blamable on convention anylonger. :)
My 2p.
-C
On 1 Mar 2016 8:43 am, "Tobias Ellinghaus" wrote:
Am Montag, 29. Februar 2016, 23:57:10 schrieb C R:
That would be terrible. Users not understanding the concept would
suddenly
be
facing images where they can just save to JPEG while others can't, butPNG
is
still enabled (because they somehow added an alpha channel), and even other
images support XCF only (maybe because the layer is bigger than the image).(I used "just" in the sense of "without any further actions" and not "only".)
No, that's not what I'm suggesting. If you import a jpeg for example,
do
your editing, and end up with an alpha channel somehow, the save could still default to the .jpg (the jpeg save dialogue could display a
warning
that transparency will be lost). That does not prevent the user from requesting a .png (by specifying that extension). It also does not
prevent
the user saving as an xcf either for that matter.
When closing the file, if the file is not saved as an xcf, and there is extra data to be lost, well, the warning about it is there anyway.
But that would mean to just go back to the status quo ante, i.e., revert the
save/export dichotomy and bring back saving to arbitrary formats.[...]
My 2p.
-CTobias
[...]
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Export instead save directly
On Mon, Mar 14, 2016 at 6:06 AM, john smith wrote:
As long as people are putting their hands up
There is no vote on this, and there won't be one.
Is it possible to write a plugin that re-maps core shortcuts
Edit -> Keyboard Shortcuts
and changes default menu layouts etc?
The can't be such a plugin.
Alex
