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
(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
 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
   the file format ) and for the rest the user deafault.

   Export function does not need any modification to support not interactive
   (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
 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
  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
Gimp-developer mailing list

Reply via email to