probably this will be my last reply on the matter, i do not like insist proposing something that someone else has to code, even if in this case would be just a trigger for not interactive call(s) I divided the objection in 2 groups, the first group focused on possible disadvantages and technical problem , ..the second in my opinion derived of some misunderstanding of what proposed, or how i proposed to implement In the first group >- so it is easy to set ( >but how to stop it for a file? it was in the Save >dialog, >but to get there again? Save as? >Suppose you do this. You edit something, and press >C-s. What would happen? Correct , i was too generic in proposing the change for "the save dialogs" let focus in the "Save as" dialog, in that case i can't image any similar problems (For who wish something as "save+export" a third party script may be a better option and the script already exist) ################################# Then there is the second group of objection: a lot complains about the risk to complicate the code or on the work needed to modify both the Save and Export function >so why not add it anyway, doesn't hurt no? yes it does: >- by associating 2 or more export files, "Export to foo.png" >(ctrl-E) has to be redesigned and never be as good as now. >- you have coupled saving to exporting of multiple files, hard. >in general these things do not happen at the same time, >saving work is a different thing then delivering. write >times go up by a factor of 1+N, where N is the number of >export formats. >- UI also needs to be not-error-inducing and give a clear model >to users to how things work. this proposal here is one of several >to get a liiiiitle bit of export back into the Save dialog. >each of these creates _a_ way to export, that users may figure >out as _the_ way to export, because they are migrating from >2.6 to 2.8. No, it does not help that we have clear Export on >the File menu. we simply cannot let these models of export develop. well i can't see nothing to redesign (except a detail in the Save as dialog) neither any need to re-associate files or redesign ctrl_E Because i do not propose any change for the save function, but basically only a modification to the GUI of "save AS" Sure any change in the GUI is connected to a change in the code But in this case not to a change in the Save as functions: that "export copy too as"would be there just because is most handy for users there, but will not interfere on how the Save function will work but just add not interactive call(s) after saving will be done So whatever user will chose Save as will work as usual with no any change, no interference, no complications just at the end "Export" will be called in not interactive way passing as arguments the filename, the directory used to save and the chosen file formats(my mock up show how chose the file format ) and for the rest the user deafault. Export function does not need any modification to support not interactive call (as far i know): If the user chose to Save as+ export a jpg ...a not interactive call will be done if user wish also also png , a second call would be done to "export as png" using for the rest the identical arguments (same filename and directory + user defaults chosen for that format) --- ----- ---- please allow me a metaphor Eat and Drink are 2 different concept ,no less then Save and Export Suppose you go in a Restaurant to eat, you order your food then you ask "do you have something to drink ?" And the waiter reply "sure we have!..but drinking is a different concept and we do not want create confusion in our clients. we have a separate room for who wish to drink, you will be welcome there Obviously eating there is not allowed, that is for drink...but you are free to change room anytime you feel thirsty and get back here when you wish to eat " The fact that 2 things are conceptually different do not exclude that may be much better achieve both simultaneously -- photocomix (via www.gimpusers.com) _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
