2009/12/27 Alexandre Prokoudine <alexandre.prokoudine@...>:
> 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
> 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
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
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
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
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
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