Re: [Inkscape-devel] Specification: Improved image
On the issue of linking vs embedding images: can't we just have 2 commands? - Embed an image - Link an image
Those who don't understand what Link an image means probably expect the first behaviour anyway.
I'm among those who was surprised by the behaviour. I use Inkscape as an image editor first. Even if Inkscape is used to create svg files which were initially destined for webpage content, the difference is inconsistent treatment of similar objects (from casual user POV).
For html, there are: - Images (external objects, must be attached separately) - Text (part of the html file)
For svg, for the really clueless user, there are: - Graphics - More graphics (just with fewer editing options)
This is perhaps a simplistic view, but what do most users know about the subtleties of image objects? There's a whole segment of users out there for which Inkscape is "to create images, like Photoshop, except Inkscape uses vectors, which is like manipulating lines and moving around shapes instead of adding blobs of paint."
Valerie wrote:
On the issue of linking vs embedding images: can't we just have 2 commands?
- Embed an image
- Link an image
Certainly, but the problem is when the command is implicit in the action, such as Drag-and-Drop. Which should we choose?
With out thinking about users and workflows, I would like to see: 1) some on canvas indication of whether an image is linked or embeded. just something, perhaps a little icon. 2) a simple way of converting an image between the two states. I would like a context menu, but others might have better ideas. 3) a dialog listing all images, their properties and their linkedness or embededness. the dialog should also allow switching the location of the images.
I don't think these things solve the problem of choosing suitable defaults, but they might make the problem even more apparent and supply another way of dealing with it.
Aaron Spike
How about a pop-up menu upon release, with an additional link to the corresponding properties dialogue where you can set the default to avoid all the popping up?
Embed image Link image ---------- Set default
An icon appears in the corner when you click the image to indicate the status. As to whether it can be used to convert from one state to another though, there's the problem that embedding images may be one way. After embedding the file may have been passed around (which is the main purpose for embedding after all) so the link would no longer be there.
A toggle button in the upper bar should work too.
--- On Sun, 12/27/09, Aaron Spike <aaron@...749...> wrote:
From: Aaron Spike <aaron@...749...> Subject: Re: [Inkscape-devel] Specification: Improved image To: "Valerie" <valerie_vk@...36...> Cc: inkscape-devel@lists.sourceforge.net Date: Sunday, December 27, 2009, 10:08 PM Valerie wrote:
On the issue of linking vs embedding images: can't we
just have 2 commands?
- Embed an image
- Link an image
Certainly, but the problem is when the command is implicit in the action, such as Drag-and-Drop. Which should we choose?
With out thinking about users and workflows, I would like to see:
- some on canvas indication of whether an image is linked
or embeded. just something, perhaps a little icon. 2) a simple way of converting an image between the two states. I would like a context menu, but others might have better ideas. 3) a dialog listing all images, their properties and their linkedness or embededness. the dialog should also allow switching the location of the images.
I don't think these things solve the problem of choosing suitable defaults, but they might make the problem even more apparent and supply another way of dealing with it.
Aaron Spike
On Dec 27, 2009, at 6:44 AM, Valerie wrote:
How about a pop-up menu upon release, with an additional link to the corresponding properties dialogue where you can set the default to avoid all the popping up?
According to the standards (freedesktop, etc.) that should happen if the user holds down the modifier key to explicitly choose. So we still need to do the appropriate thing for that specific user without any popups in that situation.
On Dec 27, 2009, at 6:08 AM, Aaron Spike wrote:
Certainly, but the problem is when the command is implicit in the action, such as Drag-and-Drop. Which should we choose?
With out thinking about users and workflows, I would like to see:
- some on canvas indication of whether an image is linked or embeded.
just something, perhaps a little icon. 2) a simple way of converting an image between the two states. I would like a context menu, but others might have better ideas. 3) a dialog listing all images, their properties and their linkedness or embededness. the dialog should also allow switching the location of the images.
I don't think these things solve the problem of choosing suitable defaults, but they might make the problem even more apparent and supply another way of dealing with it.
Exactly (and what I want to get collected in the Wiki page on this).
Given your point #3 there, I think it starts to be clear that this does not only apply to linked images, but also to external CSS files, Palette files, included SVG bits, etc.
2009/12/27 Aaron Spike <aaron@...749...>:
Valerie wrote:
On the issue of linking vs embedding images: can't we just have 2 commands?
- Embed an image
- Link an image
Certainly, but the problem is when the command is implicit in the action, such as Drag-and-Drop. Which should we choose?
I would favor embedding in such a case. This would be consistent with e.g. OpenOffice and GIMP. When you drag or paste something into the document in those apps, you create a local copy of it, so users should be familiar with this concept. In fact we already use this approach when importing or DnDing SVG documents. The popup can be shown in response to middle dragging: in Nautilus it asks whether to paste files, move files or paste links.
A further important reason to prefer embedding is that it's simply not possible to accidentally "break" a document with embedded images. If there is ambiguity, embedding is the safe default.
The change required to embed on image paste is actually rather simple, and consists of copying code that starts at interface.cpp:1452 to ui/clipboard.cpp:866. For bonus points, the import snippets in interface.cpp could be refactored into public functions and moved to file.h, which would simplify the changes needed for import dialog.
With out thinking about users and workflows, I would like to see:
- some on canvas indication of whether an image is linked or embeded.
just something, perhaps a little icon.
Good idea. A small icon could appear in the corner of the selection cue when the image is selected. This requires a change to the _updateItemBboxes() method in selcue.cpp:61.
- a simple way of converting an image between the two states. I would
like a context menu, but others might have better ideas.
Currently there are extensions available for those tasks, but it's not obvious where to look for them. There should be 1 left-click menu item that would depend on the image's embed state: either "Embed", which would embed the image, or "Extract...", which would bring up a save dialog that allows the user to pick a location for the image; there should be an option to use a relative or absolute path, with the default being relative (most users will probably keep the linked images in the same directory or a subdir). The relevant place is context-menu.cpp:399.
Regards, Krzysztof
Aaron Spike wrote:
Valerie wrote:
On the issue of linking vs embedding images: can't we just have 2 commands?
- Embed an image
- Link an image
Certainly, but the problem is when the command is implicit in the action, such as Drag-and-Drop. Which should we choose?
With out thinking about users and workflows, I would like to see:
- some on canvas indication of whether an image is linked or embeded.
just something, perhaps a little icon. 2) a simple way of converting an image between the two states. I would like a context menu, but others might have better ideas. 3) a dialog listing all images, their properties and their linkedness or embededness. the dialog should also allow switching the location of the images.
I think this is indeed very important, and I would like to add that when dropping it might be useful to use an even more obvious indication of what is happening (using the same visual indication as in the icon).
Then we could also allow for a modifier that changes the behaviour while not having released the mouse (could be more convenient than changing it afterwards), obviously causing a change in the visual indication. And of course it should be mentioned in the status bar that it is possible to do this.
I don't think these things solve the problem of choosing suitable defaults, but they might make the problem even more apparent and supply another way of dealing with it.
To tackle the problem of defaults I think it is important to distinguish between pasting/dropping image content and an image file. When copy-pasting a selection from a bitmap editor for example we have little choice but to embed the image. However, when pasting/dropping a file from a file manager or something like that it could make sense to default to linking.
In summary: - Clear menu entries that distinguish between the two cases. - When dropping/pasting image content, embed it (no other choice). - When dropping/pasting a file, default to linking. - Provide a modifier to embed a file when dropping. - Provide very clear visual indications of what has happened, as well as what will happen.
BTW, I think the paste command might already be too overloaded to add another modifier, but perhaps it is possible to find something sensible that would be possible to use with both pasting and dropping.
2009/12/28 Jasper van de Gronde <th.v.d.gronde@...528...>:
- When dropping/pasting a file, default to linking. - Provide a modifier to embed a file when dropping. - Provide very clear visual indications of what has happened, as well as what will happen.
Check out the bugs I mentioned in the "mega-thread". https://bugs.launchpad.net/inkscape/+bug/171085 https://bugs.launchpad.net/inkscape/+bug/415374
I think the last of your points is problematic because some users do not know what an image link is. There's also the problem that for an user unaware of links, he might overwrite valuable images by using "edit externally" or using ImageMagick extensions.
The action of linking is inherently more "risky" than embedding - it is possible to break a link but not an embedded image. Actions like DnD and paste are ambiguous (some apps copy and some apps link), so I think we should default to embed, otherwise people will keep breaking their documents. When middle click dragging we can pop up a menu, and there can be pref settings for what should the behavior be, but the initial settings should be to embed. Import dialog should have two radio buttons "Embed" and "Link", which would be grayed out when selecting SVG documents (we always embed them).
Regards, Krzysztof
On Dec 28, 2009, at 4:53 AM, Jasper van de Gronde wrote:
- When dropping/pasting image content, embed it (no other choice).
Actually this is not really true.
One other choice we have is the current behavior where the program will create a new image file, save the image to it, then link to that image. (I believe there are a few bugs that are caused by it not detecting a non-writable target location, but those are easy to remedy)
On Dec 28, 2009, at 4:53 AM, Jasper van de Gronde wrote:
BTW, I think the paste command might already be too overloaded to add another modifier, but perhaps it is possible to find something sensible that would be possible to use with both pasting and dropping.
There are some conventions for this sort of things. Those include "Paste special..." and "Paste style" that I've seen in a few other programs.
participants (5)
-
Aaron Spike -
Jasper van de Gronde -
Jon Cruz -
Krzysztof Kosiński -
Valerie