2009/12/27 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
FYI, linking was discussed in GIMP dev list and actually does make sense in many cases. From what I remember, it was decided to get back to that after moving to GEGL and new file format.
But was it discussed as a feature, or as the default for pasted and imported images? This is a critical piece of information, because this is a debate about defaults, not about features. As said before I don't want to remove the ability to link images, only label it more clearly and not use it by default when pasting, importing and DnDing.
Aha. So here we have another specific use case, and a more general rule that might be derived from it: "Users who only know bitmap editors might get confused"
Yes. The group that only knows raster editors is not trivially small. Photoshop is general knowledge and gets quipped about in Hollywood movies (e.g. Casino Royale), and Windows includes a simple raster editor. Corel DRAW and Adobe Illustrator are not general knowledge, and the only system that I know that comes with a vector program preinstalled is Ubuntu Studio. I expect more of the new users of Inkscape to be familiar with raster graphics than with either vector graphics or SVG.
However... one *KEY* point on Inkscape is that it *IS* supposed to be first and foremost an SVG editor, not a general purpose vector graphics program. That was some of the main reason to fork Inkscape in the first place, and has been explicitly stated.
Those goals are not conflicting, if we recognize that people who want SVG-specific features are more likely to be power users and explore the software for options. If we wanted to be a 100% pure SVG editor, then the XML editor should always be displayed under the canvas (like the messages box in IDEs), and all features that use sodipodi: or inkscape: namespaces should be removed. Embedding images is actually more "pure" SVG than editable spirals and live path effects.
For you using SVG as the output format is the goal, for me it's merely an advantage. The correct default depends on how we answer this question. This is where your survey data could help. How many users use Inkscape as a general purpose vector editor, compared to the number of people who use it as a web editor?
Not really. You've got a bit of a straw-man argument set up there, and phrasing a question in that manner won't really gain us useful information.
What straw-man? You say that Inkscape should be an SVG editor at the expense of average Joe usability. I say that Inkscape should be average-Joe-useful at the expense of rather abstract "SVG purity" (abstract, because embedded images are 100% SVG compliant). I don't see where's the misrepresentation. Do you claim that links are more intuitive for the casual user? The question was very simple. If you decline to answer it then I have reason to believe the answer is not favorable to you.
Here's a bug an actual end-user reported just the other day https://bugs.launchpad.net/inkscape/+bug/499252 It has a very good use case described, and also shows that the user is *expecting* image linking.
I cite from the reporter's description: "Make a copy of that bitmap as a bitmap (Alt+B) [I do this for editing images in order to keep the original image unchanged]". We can deduce two things from this report: 1. The default behavior is inconvenient in this case. The user wants to edit his local copy and leave the original unchanged. What he wants is actually an embedded image that can be edited externally through a tempfile. 2. This expectation comes from knowing Inkscape behavior. Even if a program does something completely unintuitive but predictable and documented, users will learn this over time. The fact that an established user can predict documented program behavior doesn't convey much useful information.
(Oh, and another somewhat recent one where the user not only expects the linking, but dislikes the details of where linked things are https://bugs.launchpad.net/inkscape/+bug/441179 )
This is about the initial path where the import dialog opens, not about linking vs embedding, see above as well. Sorry but not convinced in the slightest, try again.
Now my turn. These bugs are closely related to linking by default.
https://bugs.launchpad.net/inkscape/+bug/167026 (Images not transmitted over Inkboard, because they are links to files that don't exist on the other side; Inkboard doesn't work any more, but it's still related) https://bugs.launchpad.net/inkscape/+bug/171085 (User moved files around, did not expect breaking his SVG documents) https://bugs.launchpad.net/inkscape/+bug/169108 (Bitmap copy in an image that wasn't saved yet tries to create a file in Inkscape's install dir, causing a permissions issue when the directory is not writable) https://bugs.launchpad.net/inkscape/+bug/415374 (User uploaded an SVG with image links to a website, surprised by broken images. Read the first comment, because the reporter misuses the word "embedded". Apparently linking by default is sometimes confusing even in the Web context!)
IMPORTANT: The third bug highlights why your proposed / existing solution to pasting pixel data by storing a pasted image in the document's folder is completely wrong. If the document wasn't saved yet, there is no such folder! We end up saving to some arbitrary location, which is completely unexpected.
I acknowledge that bug reports only highlight problems with the existing implementation, and do not highlight problems with the proposed changes, so you are at a disadvantage.
No, it is neither bulletproof nor idiot-proof.
How? How in the world is it possible to break an embedded image? (Provide an example.)
We also need to consider the worst severity event for each solution. I cannot imagine a situation where temporarily not being able to edit an image externally (the embedded image can be extracted) is more serious than not having it at all, because somebody did not know to send it. The first situation happens when the user still has full access to all data, so fixing the "problem" is as simple as finding the link option. In the second situation the user is missing a piece of data and fixing the problem is impossible without contacting the sender of the broken document.
Embedding by default might not be completely problem-free, but at least it does not create problems that cannot be addressed within the application (missing data). I acknowledge that no solution is completely idiot-proof, just as there is no absolute safety or absolute security, but some solutions are more resistant to inexperience than others.
Have you tried?
Yes, I did it to examine how an embedded image's XML looks like. Maybe it wasn't lightning fast, but gedit handled it OK. That was on a 1.1GHz computer with 1GB of RAM, so not a powerhorse by any measure. Digression: the aforementioned average Joe who will use the default will never open the file in a text editor! Anyone who wants to hand edit his document will have no problem overriding the default and creating links.
Regards, Krzysztof