On Thu, Mar 7, 2013 at 3:43 PM, LucaDC wrote:
Just my 2c.
Just a few clarifications then :)
(And yes, that was me who said he wasn't going to email any further here.)
Given this assumption, I think that 'export' should be for what has passed through 'import', to enforce the fact that the file has been converted to Inkscape format, edited and then reconverted back to the original one (or another). If I 'open' a file, I also expect to 'save' it in the original format, not to 'export' also if there is some sort of loss.
It both makes sense and doesn't make sense.
From the native/non-native file format point of view, "Import" for
opening non-native data makes sense.
However right now importing is mostly for adding any kind of files to the currently opened document, and hence that would be messing up two use different cases.
Second c. These features are not so young: many programmers have already implemented them in a lot of programs out there. I'd say that there is a "standard" for them or at least some behaviour that all more-than-the-last-year users already know or have got used to.
Nope. Apps that mix various content and have concepts like layers or tracks don't really follow this "standard" all that much. Examples: Adobe InDesign, Scribus, Apple Logic, Cubase, Ardour, Lightworks, Kdenlive, Final Cut Pro, Adobe AfterEffects, Nuke, Ramen, Blender. All of them are project-based (just like Inkscape, really), and hence none of them saves back to original files. They export or render.
Even though we tend to forget, Inkscape is an _SVG_ editor. That's its definition.
Alexandre Prokoudine http://libregraphicsworld.org