El jue, 16-04-2015 a las 09:29 -0400, Martin Owens escribió:
On Thu, 2015-04-16 at 09:11 -0300, Gez wrote:
Being able to overwrite a PDF you just open is more likely to case troubles than not. And that's another case for separating export and save, but I'll leave it for now :-D
In this case, I agree. PDF isn't a format we edit, it's something we import. Maybe something like an `Import New...` menu item would help with the separation there.
Why are you so against separating saving and export but you don't have problems about making a distinction between open and import? They are opposite ends of the same issue.
Inkscape already has an import command, but it inserts the contents of external files into an existing document. Adding an "import new" is probably confusing, "import as a new document" is probably better but a bit long. And in any case, it would be partially replacing the function that the open command already has, and adding an extra command to the file menu. That's exactly what people complain about regarding GIMP's save/export separation: "that destroys my workflow, I always use the x command to do y, why was it changed?"
The thing is that there are real and compelling reasons for having a proper distinction between the procedures of opening and importing, and the same reasons apply to saving and exporting. The program should make clear when it's doing one or the other. Failing to do that causes data loss and endless headaches.
Combining open/import and save/export has worked for some time, makes menus more compact and people got used to that combined function, but it also creates problems that have to be addressed. Maybe there's a way to fix that without separating those commands, but nobody seems to have found it without cluttering menus or adding several options to dialogs. All the existing attempts to fix it cause some annoyances, usually modified or slower workflows. People will complain. But preserving editability of project files and avoiding data corruption on existing assets should be sine quibus non.
Gez