Simon Budig wrote: > Liam R E Quin (liam@xxxxxxxxxxx) 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. regards. > > Bye, > Simon > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
