Simon Budig wrote:
> Liam R E Quin ( wrote:
>> [...]  Experienced users are
>> unlikely to want to overwrite the original jpeg, because they
>> know it loses data.
> Well, no. The "Export to <filename>" Menupoint is exactly for the
> usecase that someone opens a jpeg, does some quick adjustments and fully
> intentionally wants to overwrite the original file, because he does not
> care about the full blown XCF data.
> The point is, that with the semantic change of "Save" to "use XCF
> always" (which is IMHO a very good thing) you lose this kind of
> non-xcf-load-edit-save possibility for quick and dirty editing. Which is
> why the Export to <filename> thing got added to accomodate for this.
> The problem that arises with this is though, that the user suddenly
> mentally has to deal with two not-really-but-nearly independant
> filenames and to predict what a keyboard shortcut will do you have to
> read the window title.
> I think I'd prefer a tighter coupling between the XCF filename and the
> Export-to filename, i.e. changing the XCF filename also changes the
> basename of the Export-to-filename.

That makes a lot of sense. The coupling should include the full path too 
with none of the Untitled-1 sillyness. (Untitled should only apply to a 
newly created image that has not yet been saved.)

Importing /path/foo.png should create an unsaved /path/foo.xcf with that 
in the title bar.

Subsequent Save as png should automatically set the default file name to 
/path/foo.png .

If gimp is going to force the user to work in xcf end move into the 
import export business, this seems to be the way it can be made as 
transparent and painless as possible.

Such logic should be kept as simple and unconditional as possible. All 
attempts to do this or that (or something else again) depending on a 
number of criteria inevitably makes the programs behaviour inconsistent 
and unpredictable to anyone outside the team who wrote the code.

I have seen this fundemental design error in so much software. Trying to 
be over helpful and second guess what the user really wants to do in an 
array of different circumstances ultimately fails because the program 
does not know what the user wants to de because it's only linked to his 
mouse, not his brain. Equally but more importantly the user does not 
know what the program wants to do because he does not know the ins and 
outs the the double-guessing algo it uses.

Bottom line, trying to be too helpful ends up being unhelpful.

I think that needs to be considered here when prioritising three of four 
possible policies for where to save/export a file.


> Bye,
>         Simon

Gimp-developer mailing list

Reply via email to