GIMP 2.8 usability discussion - Argument consolidation and referencing
This discussion is connected to the gimp-user-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.
GIMP 2.8 usability discussion - Argument consolidation and referencing
Having followed the discussions on the GIMP usability changes for some weeks now, what I am missing most is a direct comparison of arguments.
Therefore let's consolidate the consensus and the arguments pro and contra "Making the new open/save/export behavior of GIMP 2.8 optional" by giving argument abstracts and links to good arguments, i.e. giving references!
If there is a good argument, you don't have to fully repeat it, just give a short link and a short abstract (especially if the argument is too bloated or its core is hard to recognize).
This is the consensus so far (correct me if I am wrong):
### CONSENSUS:
There is no "the user". There are all kinds of folks with different habits, workflows.
On the one hand, there are "heavy-weight workflows". The main characteristic of this kind of workflow is the requirement of closing and re-opening one "high quality" working copy, and tasks like saving/exporting frequently as both JPEG and XCF, exporting JPEGs for comparisons, possibility to go back and alter steps throughout the whole workflow. The most important aspects of this kind of workflow is preserving image quality and preserving flexibility."
On the other hand, there are "lightweight workflows". The main
characteristic of this kind of workflow is that there is no need for
closing and re-opening the image. The most important aspect of this kind
of workflow is efficiency.
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00014.html
The following are the arguments I found so far. Everybody is invited to replace weak arguments by stronger ones or to add missing arguments --just don't forget to give references.
## PRO:
* Abstract: "The previous file open/save/export behavior met the needs
of all users."
http://mail.gnome.org/archives/gimp-user-list/2012-June/msg00228.html
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00056.html
* Abstract: "If the Save/Export separation would be the default setting and could be disabled, then every GIMP user could be happy. The "heavy-weight workflow" users just leave the default setting enabled, and the "lightweight workflow" users disable it at their own risk." http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00008.html http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00047.html http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00056.html
* Abstract: "There is no convincing argument so far to _not_ make this separation optional. It not even seems complicated to implement a switch for this behavior on the technical level." http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00025.html
* Abstract: "A GIMP fork because of such a little change that can be
made optional makes no sense."
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00064.html
## CONTRA:
* Abstract: "No." http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00009.html http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00057.html
* Abstract: "Users who don't like the new open/save/export behavior can
use another software than GIMP."
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00014.html
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00045.html
* Abstract: "Open-source software is a meritocracy, not a democracy.
Users who do not implement, should not complain. Stating and explaining
opinions is no merit."
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00063.html
* Abstract: "The PRO arguments only reflect the opinion of a few.
Therefore this is not important."
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00011.html
http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00063.html
* Abstract: "Everything convincing has been said elsewhere." http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00011.html http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00012.html http://mail.gnome.org/archives/gimp-user-list/2012-July/msg00026.html
* Abstract: "not the often touted ‘prosumer photo jpeg–to–jpeg’
workflow, because for complying with the GIMP product vision there is no
need for optimising this"
http://gui.gimp.org/index.php/Save_%2B_export_specification
Of course, the mere count of links doesn't say anything. Therefore the argument abstracts should be preferred.
If it appears too circumstantial even to give a link to a good argument, this is a direct contradiction to the "everything convincing has been said elsewhere" argument.
A good starting point for finding arguments is the GIMP mailing list
archive ("haystack"):
http://mail.gnome.org/archives/gimp-user-list/
http://mail.gnome.org/archives/gimp-developer-list/
- or Google ("needle finder") --try it with the "site:mail.gnome.org/archives/gimp-user-list/" or "site:mail.gnome.org/archives/gimp-developer-list/" options.
GIMP 2.8 usability discussion - Argument consolidation and referencing
On Sat, Jul 14, 2012 at 2:47 PM, Johannes wrote:
Having followed the discussions on the GIMP usability changes for some weeks now, what I am missing most is a direct comparison of arguments.
Therefore let's consolidate the consensus and the arguments pro and contra "Making the new open/save/export behavior of GIMP 2.8 optional" by giving argument abstracts and links to good arguments, i.e. giving references!
And what will it be good for?
Alexandre Prokoudine http://libregraphicsworld.org
GIMP 2.8 usability discussion - Argument consolidation and referencing
On Sat, Jul 14, 2012 at 5:47 AM, Johannes wrote:
This is the consensus so far (correct me if I am wrong):
### CORRECTED
There are a handful of people developing GIMP. They are following this: http://gui.gimp.org/index.php/Save_%2B_export_specification
Based on this: http://gui.gimp.org/index.php/GIMP_UI_Redesign
You can:
A: Bitch
B: Adapt
C: Fork
I suggest option B or C - they're likely to be the most productive.
HTH, Chris
(Note that I'm not a developer - just a user that's getting a bit tired of certain threads)
GIMP 2.8 usability discussion - Argument consolidation and referencing
Well, that is the question isn't it?
On 7/14/2012 7:34 AM, Alexandre Prokoudine wrote:
On Sat, Jul 14, 2012 at 2:47 PM, Johannes wrote:
Having followed the discussions on the GIMP usability changes for some weeks now, what I am missing most is a direct comparison of arguments.
Therefore let's consolidate the consensus and the arguments pro and contra "Making the new open/save/export behavior of GIMP 2.8 optional" by giving argument abstracts and links to good arguments, i.e. giving references!
And what will it be good for?
Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list
GIMP 2.8 usability discussion - Argument consolidation and referencing
Am 14.07.2012 16:45, schrieb Chris Mohler:
You can:
A: Bitch
B: Adapt
C: Fork
I suggest option B or C - they're likely to be the most productive.
In fact, I am preparing option B.
Precondition for this is a good understanding of what is to be adapted. I don't want my changes to be simply reverted, because I would be a newbie committer and others may like to play power games or something.
Don't get me wrong, I want to make things better, not cast perls before people without arguments.
GIMP 2.8 usability discussion - Argument consolidation and referencing
Am 14.07.2012 19:24, schrieb Johannes:
not cast perls before
people without arguments.
...and no pearls, too.
GIMP 2.8 usability discussion - Argument consolidation and referencing
On 14.07.2012 19:24, Johannes wrote:
Am 14.07.2012 16:45, schrieb Chris Mohler:
You can:
A: Bitch
B: Adapt
C: Fork
I suggest option B or C - they're likely to be the most productive.
In fact, I am preparing option B.
Precondition for this is a good understanding of what is to be adapted.
Your workflow, to the way GIMP 2.8 works now.
HTH, Michael
GIMP 2.8 usability discussion - Argument consolidation and referencing
On 7/14/2012 04:45, Chris Mohler wrote:
On Sat, Jul 14, 2012 at 5:47 AM, Johannes wrote:
This is the consensus so far (correct me if I am wrong):
### CORRECTED
There are a handful of people developing GIMP. They are following this: http://gui.gimp.org/index.php/Save_%2B_export_specification
Based on this: http://gui.gimp.org/index.php/GIMP_UI_Redesign
You can:
A: Bitch
B: Adapt
C: Fork
I suggest option B or C - they're likely to be the most productive.
Thanks for the refs. It makes for better understanding. In studying the specs something I don't understand is why there is an apparent distinction being made between file open behavior and file save. It seems to me that opening vice import has many of the same issues/ useability requirements that should be considered. In particular, a problem I encounter with workflow in GIMP is that GIMP doesn't really handle (AFAIK) meta-data embedded with image raster data in file formats (in my case, Tiff tags). Treating import in a manner analogous to export (ie, import and export may cause loss of data) seems reasonable (if only to me of course).
scott s. .
GIMP 2.8 usability discussion - Argument consolidation and referencing
On Sun, Jul 15, 2012 at 4:56 AM, scott s. wrote:
It seems to me that opening vice import has many of the same issues/ useability requirements that should be considered. In particular, a problem I encounter with workflow in GIMP is that GIMP doesn't really handle (AFAIK) meta-data embedded with image raster data in file formats (in my case, Tiff tags).
Reading metadata from TIFF has nothing to do with opening, importing, saving or exporting. GIMP currently relies on libtiff library which doesn't read or save embedded metadata. That's all :)
Alexandre Prokoudine http://libregraphicsworld.org
GIMP 2.8 usability discussion - Argument consolidation and referencing
Date: Sat, 14 Jul 2012 14:56:50 -1000 From: 75270.3703@earthlink.net
To: gimp-user-list@gnome.org
Subject: Re: [Gimp-user] GIMP 2.8 usability discussion - Argument consolidation and referencingIn particular, a problem I encounter with workflow in GIMP is that GIMP doesn't really handle (AFAIK) meta-data embedded with image raster data in file formats (in my case, Tiff tags). Treating import in a manner analogous to export (ie, import and export may cause loss of data) seems reasonable (if only to me of course).
scott s. .
Metadata is, almost by definition, non-essential to the layer and pixel composition of an image; so the fact GIMP ignores it during load only makes a difference if you need to write said composition back to a TIFF file with original metadata preserved. (Which is, of course, little consolation if your particular workflow relies on this.)
-- Stratadrake
strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.
GIMP 2.8 usability discussion - Argument consolidation and referencing
On 7/14/2012 16:23, Richard Gitschlag wrote:
Date: Sat, 14 Jul 2012 14:56:50 -1000
> From: 75270.3703@earthlink.net
> To: gimp-user-list@gnome.org
> Subject: Re: [Gimp-user] GIMP 2.8 usability discussion - Argument consolidation and referencing
>
> In particular, a problem I encounter with workflow in GIMP is that GIMP doesn't really
> handle (AFAIK) meta-data embedded with image raster data in file formats > (in my case, Tiff tags). Treating import in a manner analogous to > export (ie, import and export may cause loss of data) seems reasonable > (if only to me of course).
>
> scott s.
> .
>Metadata is, almost by definition, non-essential to the layer and pixel composition of an image; so the fact GIMP ignores it during load only makes a difference if you need to write said composition back to a TIFF file with original metadata preserved. (Which is, of course, little consolation if your particular workflow relies on this.)
Agreed, which is why my argument is that "file -> open" means to open a GIMP project file, i.e. xcf. Using other file formats would require a "file -> import" action, which implies that the file is being converted to GIMP's project format and of course may result in loss of data that GIMP doesn't import. This would be completely analogous to save/export. This is the behavior I am familiar with in various 3d design software: importers, exporters, and renderers for the native project format.
scott s. .
