Hi inkscapers,
I was looking at a few bugs (#168504 and #168958) and thinking about some of my own personal grievances with the whole business of exporting and saving as.
Currently in inkscape 0.46 (Ubuntu 8.10) there are a whole boat full of exporting, saving, loading menus in the File menu. Most of which seem to follow this logic:
1) File New/Load/Save * New > * Open ... * Open Recent > * Revert * Save * Save As ... * Save a copy ... 2) Import/Export * Import ... * Export Bitmap ... * Import from Open Clipart ... 3) Print ... 4) Vacuum Defs 5) Preferences * Document Properties ... * Document Meta Data ... * Inkscape Preferences ... * Input Devices ... 6) Application * Close * Quit
This seems a bit of a mess, although I don't know if you've changed much for 0.47 so apologies if this has already been put through for refinement.
My suggestions would be as follows:
* Move Revert to Edit and have it as a function of the undo system. And/Or rename it to 'Reload from File' * Remove Save a Copy and replace with 'Publish ...' which would have a dialog specifically designed to export to pdf, plain svg or png and with options that make sense such as v1.1 svg, clean defs and no personal data (such as paths). * The document properties and meta data seem out of place, since they're more to do with the document object than the file object. Maybe a top level document menu? One that includes some of the edit menu items specific for the document? * Vacuum Defs seems like a plugin or something that could be a part of publish, or the doc menu. * Import and Export make sense, but perhaps having plugins that allow imports and exports to various places and removing the specific link for open clipart.
Thoughts? Flames?
Regards, Martin Owens
On Tue, Feb 24, 2009 at 9:56 AM, Martin Owens <doctormo@...400...> wrote:
* Move Revert to Edit and have it as a function of the undo system. And/Or rename it to 'Reload from File'
It's not function of undo - it _erases_ undo! It's a very file-level operation so it should be in File.
* Remove Save a Copy and replace with 'Publish ...' which would have a dialog specifically designed to export to pdf, plain svg or png and with options that make sense such as v1.1 svg, clean defs and no personal data (such as paths).
Recently, PDF started to support almost as many options as PNG export - limiting it to areas, objects, etc, so it would indeed make sense to combine them. But for a lot of other formats that we support on export, most of these options would not be supported. Do we want to use "Publish" for dxf or fig? If yes, it will be rather clumsy. If not, how do I know what formats to search under Publish and what under Save? As it is now, the division at least makes sense: bitmaps are one dialog, eveything else is another.
* The document properties and meta data seem out of place, since they're more to do with the document object than the file object. Maybe a top level document menu? One that includes some of the edit menu items specific for the document?
For a user, file is pretty much synonymous to document, and I see no reasons to separate them.
* Vacuum Defs seems like a plugin or something that could be a part of publish, or the doc menu.
It was more or less planned to eventually go into the Resources dialog where you manage document's resources.
* Import and Export make sense, but perhaps having plugins that allow imports and exports to various places and removing the specific link for open clipart.
What other places provide public domain SVG clipart over rss? I don't know of any :)
On Tue, Feb 24, 2009 at 8:51 PM, bulia byak wrote:
* Remove Save a Copy and replace with 'Publish ...' which would have a dialog specifically designed to export to pdf, plain svg or png and with options that make sense such as v1.1 svg, clean defs and no personal data (such as paths).
Recently, PDF started to support almost as many options as PNG export
- limiting it to areas, objects, etc, so it would indeed make sense to
combine them. But for a lot of other formats that we support on export, most of these options would not be supported. Do we want to use "Publish" for dxf or fig? If yes, it will be rather clumsy. If not, how do I know what formats to search under Publish and what under Save? As it is now, the division at least makes sense: bitmaps are one dialog, eveything else is another.
Well, "Bitmap export" is not optimal as it is now. We have a fair amount of requests to add more file formats there, including SVG, PDF... :)
Alexandre
DoctorMO wrote:
- Remove Save a Copy and replace with 'Publish ...' which would have a
dialog specifically designed to export to pdf, plain svg or png and with options that make sense such as v1.1 svg, clean defs and no personal data (such as paths).
What does "Publish" mean? I know this is a term from Corel Draw and other such applications but it simply doesn't make any sense if you didn't see those programs before. You don't "publish" anything from Inkscape, you just save a file. On the other hand, "Export to OCAL" could be renamed to "Publish in OCAL", because that's more suggestive of what it does. I definitely oppose putting the word "publish" anywhere in the menu. It was confusing enough when I used Corel: you save to all formats in Save, but for PDF you have an odd separate item...
The document properties and meta data seem out of place, since they're more to do with the document object than the file object. Maybe a top level document menu? One that includes some of the edit menu items specific for the document?
1. What is the difference between a file and a document? A file contains a document but they map 1:1, so in a sense they are equivalent. 2. File menu contains several non-global actions now (like Save). If I wanted to set the metadata I would go there first, even if that's not rigorously logical.
Vacuum Defs seems like a plugin or something that could be a part of publish, or the doc menu.
It isn't a plugin. It is a maintenance operation that is very important, because otherwise your file can swell to a grandiose size. I agree that it doesn't make much sense to a beginner. Maybe I would put it in the edit menu, but you typically do it just before saving, so it's reasonable to put it in the same menu as the saving options. I would consider changing its name to "Clean Up Document" or something like that. Moreover, I already said that "publish" makes zero sense for something that doesn't cause anything to be published but rather saves / changes a file.
Import and Export make sense, but perhaps having plugins that allow imports and exports to various places and removing the specific link for open clipart.
I think Export should have all the formats that are now in Save, and Save should only have Inkscape SVG and maybe plain SVG, e.g. formats that preserve editing capabilities. The Save a Copy format should be removed then, because it would be the same as Export. However, this could be slightly confusing.
Regards, Krzysztof Kosiński
Krzysztof Kosiński wrote:
Import and Export make sense, but perhaps having plugins that allow imports and exports to various places and removing the specific link for open clipart.
I think Export should have all the formats that are now in Save, and Save should only have Inkscape SVG and maybe plain SVG, e.g. formats that preserve editing capabilities. The Save a Copy format should be removed then, because it would be the same as Export. However, this could be slightly confusing.
+1, this is a great way to make it easier to people (like me) who come from Adobeland. Defining export as saving a file in a format that won't preserve editability is definitely the best compromise with regards to the 'publish' issue -- which by the way, you made totally clear why it doesn't make sense in Inkscape or even Corel.
also, i remember reading an opinion against mixing bitmap and vector formats in one menu breaking the 'export bitmap' separation. IMHO this wouldn't be confusing at all if we go the 'save means editable, export means finished' route.
I think Export should have all the formats that are now in Save, and Save should only have Inkscape SVG and maybe plain SVG, e.g. formats that preserve editing capabilities. The Save a Copy format should be removed then, because it would be the same as Export. However, this could be slightly confusing.
+1
+1 also, I'm not too concerned about the specific wording. I just want something definitive that has a different context. I want to fix that damn bug that asks me to save my document as svg again after I've saved it as pdf, even though nothing has changed and the pdf isn't considered an editable target (or the 'source' image)
If it's all an Export, then that's fine. We can work out which features are available. I'd add SVG Plain with an option to limit to 1.1 spec, objectify text and import raster linked images. All these things need doing to do a good export to OCAL for instance or stuff you want to work in Firefox or other svg viewers.
- What is the difference between a file and a document? A file
contains a
document but they map 1:1, so in a sense they are equivalent.
A file is the outside and a document is the inside, they are conceptually different. Like the outside of a box and the inside of the same box. The first a thing to be placed, the second a place to put other things.
It may be that I was thinking along the lines of: The File menu contains system/application stuff, opening, importing, saving, closing, app prefs. All of these things are linked to the outside os. All the doc stuff is internal. But I'm happy to agree it's not the only way of looking at it.
It's not function of undo - it _erases_ undo! It's a very file-level operation so it should be in File.
So it's a a clarity thing, 'Revert to File' or 'Reload from File', something that gives it context above 'Revert', since you'd have to have a static memory that Revert means File, not Undo.
What other places provide public domain SVG clipart over rss? I don't know of any :)
Even if there wasn't any others, having the adjunct flexibility in place allows others to come up with the targets. Export to my work's private bzr repository plugin, Export to email plugin, Export to that wordpress svg comic strip, that I wrote when I was drunk because I thought it was cool, plugin.
Well I'm glad to have spured a discussion, I'm not that interested in being right. My solutions were off the top of my head. I just know that I have problems with the way it currently is as a user.
Best Regards, Martin Owens
On Tue, Feb 24, 2009 at 11:23 PM, Martin Owens <doctormo@...400...> wrote:
So it's a a clarity thing, 'Revert to File' or 'Reload from File', something that gives it context above 'Revert', since you'd have to have a static memory that Revert means File, not Undo.
Probably, but I think it's just convention. Lots of apps have "revert" commands and they all mean the same.
On Tue, 2009-02-24 at 23:29 -0400, bulia byak wrote:
On Tue, Feb 24, 2009 at 11:23 PM, Martin Owens <doctormo@...400...> wrote:
So it's a a clarity thing, 'Revert to File' or 'Reload from File', something that gives it context above 'Revert', since you'd have to have a static memory that Revert means File, not Undo.
Probably, but I think it's just convention. Lots of apps have "revert" commands and they all mean the same.
If you can say that the suggestions degrade that convention to a greater degree for old users who understand it than they would add to the intuitiveness for new users. Then perhaps there is no need to change. But I persist in my reckoning that the intuitiveness of 'Revert' alone is low enough to merit clarification along the lines of the suggestions.
Regards, Martin
On Wed, Feb 25, 2009 at 7:17 AM, Martin Owens wrote:
So it's a a clarity thing, 'Revert to File' or 'Reload from File', something that gives it context above 'Revert', since you'd have to have a static memory that Revert means File, not Undo.
Probably, but I think it's just convention. Lots of apps have "revert" commands and they all mean the same.
If you can say that the suggestions degrade that convention to a greater degree for old users who understand it than they would add to the intuitiveness for new users. Then perhaps there is no need to change. But I persist in my reckoning that the intuitiveness of 'Revert' alone is low enough to merit clarification along the lines of the suggestions.
Do you possibly refer to users who refuse to read tooltips? :-)
Alexandre
participants (6)
-
Alexandre Prokoudine -
bulia byak -
Joshua Facemyer -
Krzysztof Kosiński -
Martin Owens -
ricardo lafuente