On 08/07/2012 04:59 PM, Anoko wrote:
On Tue, Aug 7, 2012 at 10:49 PM, Anoko wrote:
The explanation page says "In other words, GIMP used to assume
that you don't mind accidental loss of unrecoverable project data and
bothered you with confirmation dialogs. It was a convoluted logic,
but people got used to it."
I do not see why this is solved.
Yes, you don't see it :)
I understand that you are bored of the discussion, but by suggesting that it is
my problem alone of seeing it wrong, I think that's a bit insulting and really
unnecessary. I was at least trying to be constructive. I suspect though that
you have misunderstood my use case.
User: lets say he wants so save image with transparance as jpg, clicks save
Gimp: you have to use export
User: Export to jpg
Gimp: ok! (no message that transparance got lost)
User: click exit
Gimp: Sure? not saved!
User: uh, I just exported it, oh yeah right exporting is not saving. But it's
exported, so my changes are safe. Agree!
Transparancy lost. This is something I already encountered once, so it is a realistic use
case (whether it is a probable is something else, but whether the previous
"problem" was much larger is to be seen as well).
Since in the "old" workflow, everyone who used to use "save" for exporting to png/jpg etc., will
with some annoyance now use export, but no longer get "flatten layers?" messages, and he/she has to remember
that indeed "unsaved changes" are unrelated to exporting.
Since such people will always get a "you have unsaved changes" message when
exitting the GIMP, this message becomes useless for this workflow. Thus, the only way to
use GIMP without major annoyance, is to follow the forced xcf route.
I am just another user like you. I also don't like the new save/export
I wish that a mechanism could be found that solves these save/export
issues for _both_ types of workflows. However, the answer to that from
the developers seems to have been that it is too hard and causes too
much potential confusion / logic branching in the code, thus making
future coding more difficult. (So instead the users of one workflow
type or the other have to do the work instead of the computer doing the
However, IMHO the developers have _not_ misunderstood your use case and
are _not_ overlooking the use case you describe.
Instead, IMHO they are not concerned about that use case.
It is all very strange to me. On one hand, they developers were trying
to avoid accidental loss of data by making the change that they made.
However, the use case you describe (which I can see happening to many
people) does not, IMHO, seem to concern the developers because they
_may_ be thinking that "only an amateur" would make that mistake and
thus that is not of concern for Gimp because Gimp is really not an
appropriate tool for amateurs and amateurs are not in the target user
group that the developers are making Gimp for.
So, on one hand, the developers make a change to prevent users from
losing data as a result of their own lack of knowledge or bad
procedures. On the other hand, the developers seem to ignore a
situation (that you have described) which has the same result.
Either Gimp is for advanced users who won't have these problems (and
don't need to be protected from themselves) or it is for a broader group
of users that do need to have some protection from themselves. Pick one.
IMHO, the "loss of data" situation that the developers were trying to
prevent with this change was not serious problem for the Gimp target
user group (advanced users). I doubt those advanced users were having a
problem before this change. I suspect that the people who were having
the problem is the very group that are still going to have a problem in
the use case you described.
When all the arguments about this got "loud", I expressed my opinion
that protecting users from their own ignorance and bad procedures just
enabled users to be ignorant and use bad procedures. My opinion was/is
that learning is (along with many other factors) a result of making
errors, paying the price.... and thus learning.
We evolve by learning. We learn as the result of experiences. Take
away some of the bad experiences and you reduce the opportunities for
The developers jumped on me like I had five horns growing out of my
head. I got emails that called me bad names and suggested that I was a
terrible person because I would allow somebody to suffer just so that
they would learn something. (In response, I say that a person will
suffer a whole lifetime if they don't learn some hard lessons -- the
faster they do that learning, the sooner their life will get easier.)
In the end, however, I wish that a mechanism could be found that solves
these save/export issues for _both_ types of workflows.
99% of my use is open TIFF, edit TIFF, save TIFF, close TIFF. 99% of
the time, I have absolutely no need for retaining any data that cannot
be saved in the TIFF. If I do need such data, I know how to save in the
XCF file format.
I continue to try and use Gimp for my "simplistic" workflow because of
some of the other very useful and valuable features Gimp has.
In any case, it has been said very clearly many times that this change
to Gimp is permanent and that no amount of complaining and no amount of
other use cases or other logic will change anything. I understand what
the developers mean by saying that, but it makes it sound like they will
not ever consider thinking about a mechanism that satisfies both groups.
Blocking out the possibility of thinking about hard problems is sad.
All that said, and despite the insults I have received from a few
developers, I have the greatest respect for what they have made and the
ongoing work that they are doing. I think we underestimate how
dedicated they have been and how much work they have done with very
People never complain about the quality or attributes of something that
does not exist. If they had not made Gimp, we would have nothing to
gimp-user-list mailing list