Re: [Inkscape-devel] Fwd: sorting out PS/EPS/PDF export mess
jiho wrote:
part of the point in having it into the export dialog is that: 1/ it can be invoked with a keyboard shortcut already (and if the export button can be focused by default it would make it possible to create a backup by Shift-Control-E + Return) 2/ the dialog can stay open at all time, so you can be just one click away from a backup. Now it just needs to be gtkmmified and thinned a little to fit with the docked ones.
I'm going to argue for the shortcut, in part because the one for "Save a copy" is already there, and in part because the incremental copy one will save a lot of trouble (clicking or entering, switching focus - adds up if you do it a lot).
And besides, the point of these was also to have preset options inputted to the export dialog so that they work painlessly, instead of changing all kinds of stuff for each type of copy-save or export you want to do.
JF
On 2008-March-18 , at 23:59 , Joshua Facemyer / Impressus Art wrote:
jiho wrote:
part of the point in having it into the export dialog is that: 1/ it can be invoked with a keyboard shortcut already (and if the export button can be focused by default it would make it possible to create a backup by Shift-Control-E + Return) 2/ the dialog can stay open at all time, so you can be just one click away from a backup. Now it just needs to be gtkmmified and thinned a little to fit with the docked ones.
I'm going to argue for the shortcut, in part because the one for "Save a copy" is already there, and in part because the incremental copy one will save a lot of trouble (clicking or entering, switching focus - adds up if you do it a lot).
And besides, the point of these was also to have preset options inputted to the export dialog so that they work painlessly, instead of changing all kinds of stuff for each type of copy-save or export you want to do.
No problem with me at all. that all makes sense. I'm just trying to get a feeling of the different possibilities through this discussion. Please add it to the blueprint so that it stays on record? If it could be called "Save a backup" and not "Save a copy" in the end it would make me happy ;) Oh and by the way, does GTK have dynamic menus, in the sense that the menu shows something in its default state and shows something different when a modifier is pressed. This would allow to show [Save as CTRL+SHIFT+S] in the default state, and when ALT is pressed, show: [Save a backup CTRL+SHIFT+ALT+S] This makes more functionality fit in less menu space and hides some complexity from the first sight. I am not sure it would be the best option for this particular one but this was an opportunity to ask.
JiHO --- http://jo.irisson.free.fr/
jiho kirjutas:
If it could be called "Save a backup" and not "Save a copy" in the end it would make me happy ;)
I think "Save a copy" is more clear and more general, as any copy may be backup, but not necessarily need to. (I never used this for backups, but not to open new page every time when I am finished with a little drawing I save a copy of it as original and delete all to start working on next one.)
Oh and by the way, does GTK have dynamic menus, in the sense that the menu shows something in its default state and shows something different when a modifier is pressed. This would allow to show [Save as CTRL+SHIFT+S] in the default state, and when ALT is pressed, show: [Save a backup CTRL+SHIFT+ALT+S] This makes more functionality fit in less menu space and hides some complexity from the first sight. I am not sure it would be the best option for this particular one but this was an opportunity to ask.
Alt operator in menus is used to execute a item like _Edit -> Prefe_rences with keystroke Alt+E+R (you may release E before pressing R). So using ALT is impossible, but idea itself sounds interesting, Ctrl and Shift keys are unused in menus.
To explain my idea of the feature: No extra menu items, all names remain the same. At the bottom of any save page there would be checkboxes named "Append autoincremental digit" and "Append date" followed by a text box [YMDhm] determining format of savedate. When clicking on appropriate checkbox the filename could change from "Untitled.svg" to "Untitled%n.svg" or "Untitled%Y%M%D%h%m.svg". It also needs checking on every filename change (made by user), if the right appending string is still present and uncheck the checkbox if not. The save dialog may have a extra checkbox "Always save to original with no appendings". Let's assume the Filename textbox reads "Project%n.svg". It tries to save to file Project.svg, if such a file exists, it renames it to Project01.svg and saves to Project.svg, when the appending is some sort of date, the Last modified of file to be renamed would be used (which leads to problems when the filesystem is mounted using no_utime or similar performance gain options, so with zero date the moment should be used).
It can become a great mess, if the "Always save to original" is used with this "filename generation string" "Project%Y%D%M%n.svg", if coded wrong. Also the syntax should be rethought again, as in filenames % is permitted character and when saving from web filenames like hello%20world are not rare at all. Maybe generating string ought to be encapsulated by '[' and ']' marks or something similar, would be more clear also ("Untitled [%n].svg").
Mattias
JiHO
I propose:
Save/Save As...: Saves the current file as Inkscape SVG or SVGZ. No other options are given because all other options would be lossy.
Save a Copy...: Saves the current file under another name without changing the name of the current document. Again only SVG or SVGZ.
Export...: User may choose from a number of lossy formats, vector and bitmap, with all of the various options for selecting areas etc.
From the discussions I've heard in the last few years on this topic these three options would offer the functionality that users see in other apps and request of Inkscape with minimal confusion as to what sort of editor Inkscape actually is.
Aaron Spike
On Tue, Mar 18, 2008 at 9:37 PM, Aaron Spike <aaron@...749...> wrote:
I propose:
Save/Save As...: Saves the current file as Inkscape SVG or SVGZ. No other options are given because all other options would be lossy.
Save a Copy...: Saves the current file under another name without changing the name of the current document. Again only SVG or SVGZ.
Export...: User may choose from a number of lossy formats, vector and bitmap, with all of the various options for selecting areas etc.
From the discussions I've heard in the last few years on this topic these three options would offer the functionality that users see in other apps and request of Inkscape with minimal confusion as to what sort of editor Inkscape actually is.
Aaron Spike
Sounds like a sensible, clear structure. At the end of the day anything non svg is a lossy format for us in terms of functionality, so we should only ever be exporting to them, we should never end up with a doc where hitting save stores a document to disc that looses info.
Aaron Spike wrote:
I propose:
Save/Save As...: Saves the current file as Inkscape SVG or SVGZ. No other options are given because all other options would be lossy.
Agreed - didn't think about plain SVG being lossy, but it is for Inkscape.
Save a Copy...: Saves the current file under another name without changing the name of the current document. Again only SVG or SVGZ.
Agreed - however, I think this can easily be worked into the export dialog as I explained previously - just open the dialog preset with the current file type options. But the menu title and key command should remain as they are, since they already exist and are expected as such.
Export...: User may choose from a number of lossy formats, vector and bitmap, with all of the various options for selecting areas etc.
Agreed. I would still like to see a "Save incremental copy" option, even if not in the menu at least as a key command, which would do the same as the "Save a copy" option - except that it doesn't open the dialog and saves a copy according the the incremental copy rules in the export or doc prefs dialog, wherever makes most sense.
JF
On 2008-March-19 , at 06:08 , Joshua Facemyer / Impressus Art wrote:
Aaron Spike wrote:
I propose:
Save/Save As...: Saves the current file as Inkscape SVG or SVGZ. No other options are given because all other options would be lossy.
Agreed - didn't think about plain SVG being lossy, but it is for Inkscape.
Save a Copy...: Saves the current file under another name without changing the name of the current document. Again only SVG or SVGZ.
Agreed - however, I think this can easily be worked into the export dialog as I explained previously - just open the dialog preset with the current file type options. But the menu title and key command should remain as they are, since they already exist and are expected as such.
Again, if SVG/SVGZ is present in the export dialog (which it should), this would just duplicate functionality with no added bonus don't you think?
Export...: User may choose from a number of lossy formats, vector and bitmap, with all of the various options for selecting areas etc.
Agreed. I would still like to see a "Save incremental copy" option, even if not in the menu at least as a key command, which would do the same as the "Save a copy" option - except that it doesn't open the dialog and saves a copy according the the incremental copy rules in the export or doc prefs dialog, wherever makes most sense.
I think this should ultimately replace "Save a copy" and show a standard save dialog except for some buttons which insert placeholder syntax. However I don't see is how it is possible, usability wise, to have a command that does not open a dialog (while I agree with Joshua that this would be very nice). Indeed, if the prefs for the name format are in Inkscape general preferences and that the menu command just saves the file according to those, with no user interaction, the user cannot figure out how it actually works the first time he uses it: Bad. If the prefs are in the save dialog, together with a checkbox [Do not show this dialog in the future] it will make it impossible to change them easily afterwards: Bad. So we'll need to make a clumsy workaround like something in the general prefs which says: [Show the incremental save dialog again]: Bad too. The only possibility I see, which is very suboptimal though, it to have the prefs for the name in Inscape general prefs (or on a per document basis even) and to artificially show a small progress bar when saving, with a message and a button pointing to where the prefs are. This means slowing down artificially an otherwise quick process which, again, is probably suboptimal (to say the least). Anyone with ideas? (On the other hand, having that in the export dialog make it possible to keep it open at all time and just click [Export] to save a new copy :-P Yes, I am kind of single-minded --if that's the right expression and if it is not too pejorative in English)
JiHO --- http://jo.irisson.free.fr/
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of jiho Sent: woensdag 19 maart 2008 8:39 To: Joshua Facemyer / Impressus Art; Inkscape List Devel Subject: Re: [Inkscape-devel] Fwd: sorting out PS/EPS/PDF export mess
Export...: User may choose from a number of lossy formats, vector and bitmap, with all of the various options for selecting areas etc.
Agreed. I would still like to see a "Save incremental
copy" option,
even if not in the menu at least as a key command, which
would do the
same as the "Save a copy" option - except that it doesn't open the dialog and saves a copy according the the incremental copy rules in the export or doc prefs dialog, wherever makes most sense.
I think this should ultimately replace "Save a copy" and show a standard save dialog except for some buttons which insert placeholder syntax.
Although it might duplicate functionality, "Save a copy" seems to me like a very clear description of exactly what it does, plus it is recognizable from other apps. "Export" to me implies saving to some different file format to export it from Inkscape to some other program. ('save a copy' was my first patch, I'm protecting my child!) Moreover, Save a copy would, like Aaron proposed, always save to InkscapeSVG; export can save to other formats and it would be nice if Inkscape remembered the last format that was saved to and opened the dialog with that. Removing save a copy removes this possibility.
However I don't see is how it is possible, usability wise, to have a command that does not open a dialog (while I agree with Joshua that this would be very nice). Indeed, if the prefs for the name format are in Inkscape general preferences and that the menu command just saves the file according to those, with no user interaction, the user cannot figure out how it actually works the first time he uses it: Bad. If the prefs are in the save dialog, together with a checkbox [Do not show this dialog in the future] it will make it impossible to change them easily afterwards: Bad. So we'll need to make a clumsy workaround like something in the general prefs which says: [Show the incremental save dialog again]: Bad too. The only possibility I see, which is very suboptimal though, it to have the prefs for the name in Inscape general prefs (or on a per document basis even) and to artificially show a small progress bar when saving, with a message and a button pointing to where the prefs are. This means slowing down artificially an otherwise quick process which, again, is probably suboptimal (to say the least). Anyone with ideas?
Why not have it as a document preference. First time user hits "save increm" Inkscape can't find the doc pref and opens a dialog where to save the incremental files (the path to which depends on which file being edited and therefore it should not be a global preference). Then the second time user presses it, Inkscape sees the doc pref and does not ask. Changing things is possible from document preferences dialog.
(On the other hand, having that in the export dialog make it possible to keep it open at all time and just click [Export] to save a new copy :-P Yes, I am kind of single-minded --if that's the right expression and if it is not too pejorative in English)
I'm not too sure how many dialogs I'd like to keep open at the same time! :)
-johan
On Mar 18, 2008, at 4:13 PM, jiho wrote:
Oh and by the way, does GTK have dynamic menus, in the sense that the menu shows something in its default state and shows something different when a modifier is pressed. This would allow to show [Save as CTRL+SHIFT+S] in the default state, and when ALT is pressed, show: [Save a backup CTRL+SHIFT+ALT+S] This makes more functionality fit in less menu space and hides some complexity from the first sight. I am not sure it would be the best option for this particular one but this was an opportunity to ask.
You've just hit on something that drives usability and documentation guys I know nuts. Dynamic menus...
They might save a few pixels on screen, but confuse people looking for things. "I know it was here, but I can't see it..." and "*Where* was that menu item?", etc.
It can actually increase complexity to have something autoflip like that.
participants (7)
-
unknown＠example.com -
Aaron Spike -
jiho -
john cliff -
Jon A. Cruz -
Joshua Facemyer / Impressus Art -
Mattias