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
>- 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
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 +
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
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 www.gimpusers.com)
Gimp-developer mailing list