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.

Hi Anoko,

I am just another user like you. I also don't like the new save/export model.

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 work.)

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 learning.

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 little reward.

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 complain about.

gimp-user-list mailing list

Reply via email to