We've been having a discussion in #inkscape about the feedback (almost complaints) about the way inkscape links to images by default instead of embedding them as a document creator would expect.
The solution on balance we got to was: New Menu Item File->'Place Image' (same name used as adobe) which links to the image Change Menu Import to embed image data by default Add an ask box for when images are dragged and dropped for weather the images should be linked or embedded.
I'm having a look at the code but I won't change anything until we reach a consensus.
On Jan 21, 2006, at 12:01 PM, Martin Owens wrote:
We've been having a discussion in #inkscape about the feedback (almost complaints) about the way inkscape links to images by default instead of embedding them as a document creator would expect.
The solution on balance we got to was: New Menu Item File->'Place Image' (same name used as adobe) which links to the image Change Menu Import to embed image data by default Add an ask box for when images are dragged and dropped for weather the images should be linked or embedded.
I'm having a look at the code but I won't change anything until we reach a consensus.
Some of it is a little convoluted, especially with drag-n-drop and also copy-n-paste.
Although... for many people a different workflow would be better, as only embedding images as a final publishing stage is really what most people need. Auto-embed will trade one set of problems for a different one. I'll go through things and see what I can catch up on, but a lot of this comes from me working in the multimedia industry starting in the early nineties, and having worked with artists and end users of all kinds. I think some of this comes out to requirements discovery, where "discovery" is the key word, as people usually don't ask for what they need, but for how they think they need to achieve what it is they truly need.
Anyway, I'll see about going over the logs to catch up on various things discussed.
On Sat, 2006-01-21 at 20:01 +0000, Martin Owens wrote:
We've been having a discussion in #inkscape about the feedback (almost complaints) about the way inkscape links to images by default instead of embedding them as a document creator would expect.
The solution on balance we got to was: New Menu Item File->'Place Image' (same name used as adobe) which links to the image Change Menu Import to embed image data by default Add an ask box for when images are dragged and dropped for weather the images should be linked or embedded.
I'm having a look at the code but I won't change anything until we reach a consensus.
I think it would be best to have the place image command, but on the file browser add a checkbox which is a checkbox. This checkbox should enable linking to image (rather than embed). I think it is better to default to linking.
Also, after we have embedding or linking, a user should be able to right click or have an image menu that allows for one to switch a placed image from embedded to linked and vice versa.
Adding another popup window after import seems annoying and redundant IMO.
Jon
Martin's proposal sounds great - I would vote for embed as default - it's always safer to have the images you want in the drawing then to archive or send a file to someone and not have the links, especially since many of us are using Inkscape as a graphics package vs. doing web graphics. Not having the graphics embedded has already cost us several problems. But Jon has a good point of having a preference setting to default link vs embed - that would serve everyone's needs.
Jon Phillips wrote:
On Sat, 2006-01-21 at 20:01 +0000, Martin Owens wrote:
We've been having a discussion in #inkscape about the feedback (almost complaints) about the way inkscape links to images by default instead of embedding them as a document creator would expect.
The solution on balance we got to was: New Menu Item File->'Place Image' (same name used as adobe) which links to the image Change Menu Import to embed image data by default Add an ask box for when images are dragged and dropped for weather the images should be linked or embedded.
I'm having a look at the code but I won't change anything until we reach a consensus.
I think it would be best to have the place image command, but on the file browser add a checkbox which is a checkbox. This checkbox should enable linking to image (rather than embed). I think it is better to default to linking.
Also, after we have embedding or linking, a user should be able to right click or have an image menu that allows for one to switch a placed image from embedded to linked and vice versa.
Adding another popup window after import seems annoying and redundant IMO.
Jon
On Sat, 21 Jan 2006, Martin Owens wrote:
Date: Sat, 21 Jan 2006 20:01:15 +0000 From: Martin Owens <doctormo@...1114...> To: inkscape inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Linked vs Embeded
We've been having a discussion in #inkscape about the feedback (almost complaints) about the way inkscape links to images by default instead of embedding them as a document creator would expect.
Interesting. User expectations can be very interesting, and I suppose we are too used to SVG (and to a lesser extent HTML) to really be too surprised by the linking (not embedding) behaviour.
I wonder if more could be done to quantify those expectations and see how much comes from using other drawing applications are coming from other influences. Better understanding of our biases can really help designing balanced solutions.
Embedding seems like the more straighforward default for ordinary users but then there are questions of making the entire file format self contained and embedding Fonts, Videos, and all kinds of other information resulting in very large files. If images are embedded what else should be embedded? The inkjar files are working towards providing the kind of complete file format these users might want, perhaps it should be the default file format?
If users must learn about embedding some resources and not others, there might be some advantage to linking images and confronting them with this lesson sooner rather than later?
Does embedding have any performance penalties? Taking binary and mime type encoding it inside another file isn't exactly the most elegant solution, and in some cases it can cause incredible amounts of bloat (thankfully we have SVGZ to counterbalance that).
The solution on balance we got to was: New Menu Item File->'Place Image' (same name used as adobe) which links
Same name as Adobe, so Place Image in Illustrator only links the Image? (I've never noticed, I use photoshop more often than Illustrator where the link/embed distinction doesn't matter. The minor point I'm making is that if the same label is used it will be important to keep the behaviour as close to the same as possible which I assume you are already doing.)
to the image Change Menu Import to embed image data by default Add an ask box for when images are dragged and dropped for weather the images should be linked or embedded.
Please make a decision, allow the user to make progress. Do not ask every time, this kind of blocking behavior can be frustrating especially after long term use. Users will inevitably request an option to always link or always embed.
If the default Import behaviour will be to embed then I think Drag and Drop should follow that behaviour, and the linking behaviour should require the deliberate use of Place Image...
I'm having a look at the code but I won't change anything until we reach a consensus. --
Others mentioned the issue of discoverability, any ideas how we might make it clearer which images are embedded inline and which are linked?
On balance it does seem like a good idea to embed images by default.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 22 janv. 06, at 11:31, Alan Horkan wrote:
On Sat, 21 Jan 2006, Martin Owens wrote:
Date: Sat, 21 Jan 2006 20:01:15 +0000 From: Martin Owens <doctormo@...1114...> We've been having a discussion in #inkscape about the feedback (almost complaints) about the way inkscape links to images by default instead of embedding them as a document creator would expect.
[... snip ...] Embedding seems like the more straighforward default for ordinary users but then there are questions of making the entire file format self contained and embedding Fonts, Videos, and all kinds of other information resulting in very large files. If images are embedded what else should be embedded? The inkjar files are working towards providing the kind of complete file format these users might want, perhaps it should be the default file format?
If users must learn about embedding some resources and not others, there might be some advantage to linking images and confronting them with this lesson sooner rather than later?
agreed. I personally don't think that embedding everything is a good solution and the default should teach the user what the good solution is, even if it requires some additional work from the user point of view. almost all mac applications do embedding (word, keynote, pages etc.) and it results in: - enormous files as soon as some video/large images are embedded. the original is already somewhere on the disc so the space is taken two times - the difficulty to modify the original image once it is embedded. I think embedding should be default when there is a solution to link images to the gimp or to extract and re-import the image easily. I'm often asked how to modify the contrast or suppress some parts of an image. The easy answer is "Load it into the gimp". But when the image is embedded in word it adds some complexity rather that simplify things...
Does embedding have any performance penalties?
I thought I read here that embedding images directly in SVG is very bad for performance. but maybe you were thinking of a new file format then.
to the image Change Menu Import to embed image data by default Add an ask box for when images are dragged and dropped for weather the images should be linked or embedded.
Please make a decision, allow the user to make progress. Do not ask every time, this kind of blocking behavior can be frustrating especially after long term use. Users will inevitably request an option to always link or always embed.
If the default Import behaviour will be to embed then I think Drag and Drop should follow that behaviour, and the linking behaviour should require the deliberate use of Place Image...
Open Office adds a "Link" checkbox to the "insert image" window. Maybe Inkscape could use the same (personally I would vote for linking by default and adding a Embed check box but I might well be alone), it's value being saved across sessions or on a document basis and the drag and drop behavior would use the last state of the check box.
The easy solution would be to use more the "save to zip" extension and make it more visible (in the save menu, put it just under Inkscape svg for example).
Just my two cents.
JiHO
jiho wrote:
The easy solution would be to use more the "save to zip" extension and make it more visible (in the save menu, put it just under Inkscape svg for example).
I'm not sure what storage format was being considered, but the save to zip idea is really good , keeping the svg and the image files separate but attached, (I guess with some extension like svgz). Performance is not hurt, and images/links are not lost - best of both worlds. However, the zip should be the default with a preference setting. We don't want to ever lose our original images.
However, When the zip is extracted it might have to override any remaining or new images with that name in the directory - this leads to another problematic decision point for user which can be handled several ways but choices are never good for 1/2 the users - again, I would suggest an override yes/no dialog as default with an automatic yes/no/ask setting in preferences.
The only other drawback to this approach is the saved file size, but hard disk space is cheap so keeping original images is a very good tradeoff. Oh and I guess save time would be extended(espeicially if the image needs to be downloaded from some server location. But if either of those are problematic, the user can still elect not to use the zip format.
It seems we are approaching to an openoffice-like format... many files zipped together. My opinion is that it shold be included in file menu someting like "Save embedded..." and that embeds every linked image into the document, making it ready to be shared easily.
John Taber wrote:
jiho wrote:
The easy solution would be to use more the "save to zip" extension and make it more visible (in the save menu, put it just under Inkscape svg for example).
I'm not sure what storage format was being considered, but the save to zip idea is really good , keeping the svg and the image files separate but attached, (I guess with some extension like svgz). Performance is not hurt, and images/links are not lost - best of both worlds. However, the zip should be the default with a preference setting. We don't want to ever lose our original images.
However, When the zip is extracted it might have to override any remaining or new images with that name in the directory - this leads to another problematic decision point for user which can be handled several ways but choices are never good for 1/2 the users - again, I would suggest an override yes/no dialog as default with an automatic yes/no/ask setting in preferences.
The only other drawback to this approach is the saved file size, but hard disk space is cheap so keeping original images is a very good tradeoff. Oh and I guess save time would be extended(espeicially if the image needs to be downloaded from some server location. But if either of those are problematic, the user can still elect not to use the zip format.
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&da... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
# from jiho # on Sunday 22 January 2006 06:50 am:
Does embedding have any performance penalties?
I thought I read here that embedding images directly in SVG is very bad for performance. but maybe you were thinking of a new file format then.
The byte size increase is typically a 4:3 ratio, so there is the added reading (less the overhead of opening another file and reading that) plus the decoding. In most cases, this is going to be fast enough that it doesn't make a lot of difference (and if it saves head-scratching, then it is a net win.)
As for overall size and gzipped size, here is an example:
$ cat tiger.png | perl -e '$/=undef; use MIME::Base64; print encode_base64(<>);' > /tmp/tiger.b64
$ gzip -c < /tmp/tiger.b64 >/tmp/tiger.b64.gz
$ du -b tiger.png /tmp/tiger.b64* 405334 tiger.png 547560 /tmp/tiger.b64 412008 /tmp/tiger.b64.gz
--Eric
On Jan 22, 2006, at 9:00 AM, Eric Wilhelm wrote:
# from jiho # on Sunday 22 January 2006 06:50 am:
Does embedding have any performance penalties?
I thought I read here that embedding images directly in SVG is very bad for performance. but maybe you were thinking of a new file format then.
The byte size increase is typically a 4:3 ratio, so there is the added reading (less the overhead of opening another file and reading that) plus the decoding. In most cases, this is going to be fast enough that it doesn't make a lot of difference (and if it saves head-scratching, then it is a net win.)
Actually, there's a lot more to it than just that raw size.
When an image is linked, the in-memory graphic is handled by GTK, and the size is the image size *plus* the length of the string of the filename. If it is embedded, then you get the size of the image handled inside of GTK *plus* the size of the image encoded in base64 handled in Inkscape proper.
linked: image + 10-100 bytes embedded: image * 2.33 + 22 bytes
Then there's the size in memory that's needed for the full string node in the DOM tree, plus all the UI impact from having large strings kicking around, including the XML Editor window.
On Sat, 21 Jan 2006, Martin Owens wrote:
Date: Sat, 21 Jan 2006 20:01:15 +0000 From: Martin Owens <doctormo@...1114...> To: inkscape inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Linked vs Embeded
We've been having a discussion in #inkscape about the feedback (almost complaints) about the way inkscape links to images by default instead of embedding them as a document creator would expect.
Interesting. User expectations can be very interesting, and I suppose we are too used to SVG (and to a lesser extent HTML) to really be too surprised by the linking (not embedding) behaviour.
I wonder if more could be done to quantify those expectations and see how much comes from using other drawing applications are coming from other influences. Better understanding of our biases can really help designing balanced solutions.
Embedding seems like the more straighforward default for ordinary users but then there are questions of making the entire file format self contained and embedding Fonts, Videos, and all kinds of other information resulting in very large files. If images are embedded what else should be embedded? The inkjar files are working towards providing the kind of complete file format these users might want, perhaps it should be the default file format?
My own experience: I teach someone to make (very simple) drawings and import images in Inscape, instead of using paint, word, or photoshop.He says "Wow, seems easy". <Two weeks later> I found the person using paint, word or photoshop.¿Did you left Inkscape?-I ask -I don't like this program, is broken, he says. I see the files he had made: All with a big cross saying "Broken Image", he moved the files, but not the pictures, and expected the program to be "file system location independent" as paint, word or photoshop. Another user lost.
Jose Hevia
My own experience: I teach someone to make (very simple) drawings and import images in Inscape, instead of using paint, word, or photoshop.He says "Wow, seems easy".
<Two weeks later> I found the person using paint, word or photoshop.¿Did you left Inkscape?-I ask -I don't like this program, is broken, he says. I see the files he had made: All with a big cross saying "Broken Image", he moved the files, but not the pictures, and expected the program to be "file system location independent" as paint, word or photoshop. Another user lost.
This story nicely illustrates the problem. Home users expect their images to be embedded, professional users expect their images to be linked. Nobody would ever stumble across InDesign linking images, because non-professionals don't use it. Everybody expect Word to embed images -- and the pros curse it. I don't agree with who ever said, we should change import to place in the menu. Actually I think we should have import be the default and it should embed images. A setting should change this to place and then you link images. In both dialogues there should be a check button to do the opposite of the default action. I believe that is the only way, non-professionals and professionals can get along with the same tool.
No playing around with size. Drag and Drop just uses the set option. Plain and simple and no extra menu entry that will only confuse the home users.
David
# from David Christian Berg # on Sunday 22 January 2006 09:06 am:
I don't agree with who ever said, we should change import to place in the menu. Actually I think we should have import be the default and it should embed images. A setting should change this to place and then you link images.
Except that "import" in all other cases results in embedded data because all other cases result in inserting svg (whether from a .svg file or from a plugin.) Given this precedent and the definition of "import", I think there is a really good case for a "place" or "insert link to" command.
--Eric
On Sun, 2006-01-22 at 09:21 -0800, Eric Wilhelm wrote:
# from David Christian Berg # on Sunday 22 January 2006 09:06 am:
I don't agree with who ever said, we should change import to place in the menu. Actually I think we should have import be the default and it should embed images. A setting should change this to place and then you link images.
Except that "import" in all other cases results in embedded data because all other cases result in inserting svg (whether from a .svg file or from a plugin.) Given this precedent and the definition of "import", I think there is a really good case for a "place" or "insert link to" command.
Hey Eric, you leave me wondering what you are trying to say... I think that import should embed and place should link but that you should only have either in the file menu and not both. Which one is displayed is an inkscape preference. I don't quite understand, where your comment contradicts with what I was trying to say.
David
# from David Christian Berg # on Sunday 22 January 2006 09:32 am:
On Sun, 2006-01-22 at 09:21 -0800, Eric Wilhelm wrote:
# from David Christian Berg
# on Sunday 22 January 2006 09:06 am:
I don't agree with who ever said, we should change import to place in the menu. Actually I think we should have import be the default and it should embed images. A setting should change this to place and then you link images.
Except that "import" in all other cases results in embedded data because all other cases result in inserting svg (whether from a .svg file or from a plugin.) Given this precedent and the definition of "import", I think there is a really good case for a "place" or "insert link to" command.
Hey Eric, you leave me wondering what you are trying to say... I think that import should embed and place should link but that you should only have either in the file menu and not both. Which one is displayed is an inkscape preference. I don't quite understand, where your comment contradicts with what I was trying to say.
OK, I didn't realize that you were proposing that the import command dissappears and gets replaced by "place." I don't agree that one should be removed from the menu based on some setting -- the menu should always contain both choices.
My points restated:
1. "import" for an image currently has a different behavior than "import" for an svg. The behavior is more correctly called "place" or "insert linked image" and I believe that this is the source of most user's confusion -- the term "import" implies that the content is embedded in the current document.
2. The "insert linked image" behavior that we currently have is definitely desirable. It just needs to be renamed for what it is. There is no reason to mix the two in the user's model of how inkscape works -- no need for a checkbox on the "import" or any other dialog.
3. The embedding of images is what I would expect "import" to do. Inkscape definitely needs this functionality and it should be accessed via the File->Import menu.
Several other conceptual holes exist in the user's model and should probably be addressed. Images should be able to be switched from embedded to linked, editing either needs to be transparent to the user (unless they have already edited the linked image externally) and some way of refreshing the display based on a change to the file on disk is also needed.
Additionally, it should also be clear to the user exactly what is happening. If they don't understand the linked paradigm, they probably won't be using it, but if they do, they will want an easy way to see whether an image is a link or inlined. IMO, most of the negative feedback from users comes from their preconceived (and rightly so) notion of how the import paradigm works (e.g. "if I import something, it is _in_ this document and if I want to change it I have to delete the object and import a changed version") and the fact that inkscape does not behave in that way (thus, "import" is the wrong label for the linking action that inkscape currently supports.)
--Eric
On Jan 22, 2006, at 3:17 PM, Eric Wilhelm wrote:
Additionally, it should also be clear to the user exactly what is happening. If they don't understand the linked paradigm, they probably won't be using it, but if they do, they will want an easy way to see whether an image is a link or inlined. IMO, most of the negative feedback from users comes from their preconceived (and rightly so) notion of how the import paradigm works (e.g. "if I import something, it is _in_ this document and if I want to change it I have to delete the object and import a changed version") and the fact that inkscape does not behave in that way (thus, "import" is the wrong label for the linking action that inkscape currently supports.)
I think this hits on the crux of the matter.
Instead of trying to patch existing behavior, let's try to back up and focus on the big picture and user's end goals.
I see that already we've hit on two very different use cases. One thing would be to see if there are any more, or any significant refinements of the existing two.
Also... it seems to be that the problem can be summarized as "average users think *this* is going on when actually *that* is going on. So instead of switching "this" for "that", perhaps we could just make it clear of what was going on to begin with. Driving factors here could be discoverability, transparency and least surprise.
Some UI indication, along with a "hey, this is going on" dialog with a "don't show me this again" checkbox is a common way to address this sort of problem. Getting the details figured out for all workflows, and what is common and what is not are probably key things.
(Oh, and one minor aspect might be the feature that's been mentioned where a user could right-click on a linked image to get it opened for editing in The GIMP, or some other preferred app.)
On Sun, 2006-01-22 at 15:17 -0800, Eric Wilhelm wrote:
# from David Christian Berg # on Sunday 22 January 2006 09:32 am:
On Sun, 2006-01-22 at 09:21 -0800, Eric Wilhelm wrote:
# from David Christian Berg
# on Sunday 22 January 2006 09:06 am:
I don't agree with who ever said, we should change import to place in the menu. Actually I think we should have import be the default and it should embed images. A setting should change this to place and then you link images.
Except that "import" in all other cases results in embedded data because all other cases result in inserting svg (whether from a .svg file or from a plugin.) Given this precedent and the definition of "import", I think there is a really good case for a "place" or "insert link to" command.
Hey Eric, you leave me wondering what you are trying to say... I think that import should embed and place should link but that you should only have either in the file menu and not both. Which one is displayed is an inkscape preference. I don't quite understand, where your comment contradicts with what I was trying to say.
OK, I didn't realize that you were proposing that the import command dissappears and gets replaced by "place." I don't agree that one should be removed from the menu based on some setting -- the menu should always contain both choices.
The idea behind only showing one of the options is pretty simple: First of all we are talking about two different user groups. The professionals will only want to embed, the home users will only want to import. If a pro wants to import, he'll know, what to do, so no problem...
But the menu is a good indicator for what is going on if you do drag and drop. If you are unsure, what you just did, you can just have a look at the file menu and it's right infront of you. It's not discoverable, I agree, but as I said, I completely expect home users not to need the "place" feature. Maybe you could just have the place menu turned of by default and turn it on without hiding the import menu item. Turning it on will then automatically also change the drag and drop behaviour to place...
My points restated:
- "import" for an image currently has a different behavior than
"import" for an svg. The behavior is more correctly called "place" or "insert linked image" and I believe that this is the source of most user's confusion -- the term "import" implies that the content is embedded in the current document.
agreed.
- The "insert linked image" behavior that we currently have is
definitely desirable. It just needs to be renamed for what it is. There is no reason to mix the two in the user's model of how inkscape works -- no need for a checkbox on the "import" or any other dialog.
- The embedding of images is what I would expect "import" to do.
Inkscape definitely needs this functionality and it should be accessed via the File->Import menu.
True.
Several other conceptual holes exist in the user's model and should probably be addressed. Images should be able to be switched from embedded to linked, editing either needs to be transparent to the user (unless they have already edited the linked image externally) and some way of refreshing the display based on a change to the file on disk is also needed.
This is a typical thing for the right click menu :) Have an option: Embed/Make Placed Image Edit original with.../Edit embedded image with...
Additionally, it should also be clear to the user exactly what is happening. If they don't understand the linked paradigm, they probably won't be using it, but if they do, they will want an easy way to see whether an image is a link or inlined. IMO, most of the negative feedback from users comes from their preconceived (and rightly so) notion of how the import paradigm works (e.g. "if I import something, it is _in_ this document and if I want to change it I have to delete the object and import a changed version") and the fact that inkscape does not behave in that way (thus, "import" is the wrong label for the linking action that inkscape currently supports.)
Well, as said before, people expect embedding for import and that is what they should! Pros will be able to know, what they are dealing with and will be able to find out via the right click menu etc. For discoverability we could add a "Links" dialogue as InDesign hast one.
David
# from David Christian Berg # on Monday 23 January 2006 07:26 am:
professionals will only want to embed, the home users will only want to import. If a pro wants to import, he'll know, what to do, so no problem...
I disagree. It's not a question of whether you know what to do. Removing an item from the menu based on a preference setting is bad for discoverability. Advanced users will be familiar with the concept of linking, but shouldn't have to explore the preferences to discover that Inkscape can do that. Less advanced users become advanced users by following their curiosity. If you hide it, they won't get curious.
Trying something to see what it does is much different than our current situation, where users think they know what import means and then get bitten because the menu is essentially lying to them.
I completely expect home users not to need the "place" feature.
That's not a good assumption to make. Users may want a feature once they know it is there and understand what it does. Hiding it from them because you think they won't need it is too condescending. Just make it transparent, obvious, and discoverable. If I tried to sell hammers without a claw because I thought my market wouldn't need to pull nails, I wouldn't sell many hammers.
Maybe you could just have the place menu turned of by default and turn it on without hiding the import menu item. Turning it on will then automatically also change the drag and drop behaviour to place...
Again, there is no reason to have preferences changing behavior like this. Advanced users will realize that a button-1 D&D probably does the simplest thing. A message in the status bar should be able to inform you of what will happen to the dragged item. Ctrl+D&D or button-2 D&D will link and I think that's what advanced users will expect to happen.
--Eric
On Jan 23, 2006, at 9:23 AM, Eric Wilhelm wrote:
# from David Christian Berg # on Monday 23 January 2006 07:26 am:
Maybe you could just have the place menu turned of by default and turn it on without hiding the import menu item. Turning it on will then automatically also change the drag and drop behaviour to place...
Again, there is no reason to have preferences changing behavior like this. Advanced users will realize that a button-1 D&D probably does the simplest thing. A message in the status bar should be able to inform you of what will happen to the dragged item. Ctrl+D&D or button-2 D&D will link and I think that's what advanced users will expect to happen.
The Drag-n-Drop spec actually addresses this... http://www.newplanetsoftware.com/xdnd/ or http://www.freedesktop.org/wiki/Standards_2fXDND
There are base actions of "Copy", "Move", "Link", "Ask" and "Private".
GTK+ info is at http://www.gtk.org/tutorial/c1920.html http://developer.gnome.org/doc/API/2.0/gtk/gtk-Drag-and-Drop.html and http://developer.gnome.org/doc/API/2.0/gtk/gtk-Clipboards.html (Drag-n-drop uses clipboard protocols to actually exchange things)
# from Jon A. Cruz # on Monday 23 January 2006 09:38 am:
On Jan 23, 2006, at 9:23 AM, Eric Wilhelm wrote:
# from David Christian Berg
... Turning it on will then automatically also change the drag and drop behaviour to place...
Again, there is no reason to have preferences changing behavior like this. ....
The Drag-n-Drop spec actually addresses this...
OK. On first reading, that seems to fit with what I was saying. I'm not in any hurry to invent a new D&D spec, I just want to make it clear that changing the D&D behavior based on a preference setting is not the best route to take.
--Eric
Eric Wilhelm wrote:
OK. On first reading, that seems to fit with what I was saying. I'm not in any hurry to invent a new D&D spec, I just want to make it clear that changing the D&D behavior based on a preference setting is not the best route to take.
Maybe someone has already addresed this, but analogous to the way that Windows uses in-memory BMP chunks for raster DnD and WMF chunks (not sure what encoding is used under that) for drawing DnD, I have wondered if .ODG would be a good preferred 'standard' in-memory format for DnD in the Open Source world.
bob
On Jan 23, 2006, at 1:10 PM, Bob Jamison wrote:
Eric Wilhelm wrote:
OK. On first reading, that seems to fit with what I was saying. I'm not in any hurry to invent a new D&D spec, I just want to make it clear that changing the D&D behavior based on a preference setting is not the best route to take.
Maybe someone has already addresed this, but analogous to the way that Windows uses in-memory BMP chunks for raster DnD and WMF chunks (not sure what encoding is used under that) for drawing DnD, I have wondered if .ODG would be a good preferred 'standard' in-memory format for DnD in the Open Source world.
EEEEEeeeeeeeeeeeeeeekkkkkk!!!!!
I'd say go with SVG document fragments first.
And be sure to offer PNG
Then perhaps .ODG down there a bit.
On Jan 23, 2006, at 8:24 PM, Bob Jamison wrote:
Jon A. Cruz wrote:
I'd say go with SVG document fragments first.
And be sure to offer PNG
Then perhaps .ODG down there a bit.
But, Jon, the content.xml file of a .odg is like 90% svg. The guys on the list who are discussing svg+images in a .zip are basically describing .odg.
But...
that last 10% is the killer.
We had some discussion of it back when it was proposed. At least they stopped the worst of their abuses, but there are still issues with it. And there's the fact that it's evolved out of their "let's clone Microsoft" approach. It's much better nowadays, but there are still some lingering issues.
(It's kinda like saying "well, C# is 90% like Java")
;-)
Quoting "Jon A. Cruz" <jon@...18...>:
But, Jon, the content.xml file of a .odg is like 90% svg. The guys on the list who are discussing svg+images in a .zip are basically describing .odg.
But...
that last 10% is the killer.
Actually, ODG is 0% SVG. They've simply got their own schema which (mostly) happens to parallel SVG but is not semantically identical. Given some of the specific features they wanted, it was not such a crazy decision.
It used to be that they were using the SVG namespace for this, which was nuts, but they sorted that out after I referred them to the SVG WG.
-mental
Just so that people have an idea what we are talking about, here is a little content.xml I made from making a little drawing with a couple of images in it, and saving as a .odg. You can see the mix of namespaces, with svg providing most of information with svg:something tags, while the main OO.o drawing objects remain as <draw:something > tags.
True, svg: is provided with their own schema, but it is -so- similar. The majority of mapping should be trivial, and the things where we fail, we can just document.
bob
mental@...3... wrote:
Quoting "Jon A. Cruz" <jon@...18...>:
But, Jon, the content.xml file of a .odg is like 90% svg. The guys on the list who are discussing svg+images in a .zip are basically describing .odg.
But...
that last 10% is the killer.
Actually, ODG is 0% SVG. They've simply got their own schema which (mostly) happens to parallel SVG but is not semantically identical. Given some of the specific features they wanted, it was not such a crazy decision.
It used to be that they were using the SVG namespace for this, which was nuts, but they sorted that out after I referred them to the SVG WG.
-mental
Quoting Bob Jamison <rwjj@...127...>:
Just so that people have an idea what we are talking about, here is a little content.xml I made from making a little drawing with a couple of images in it, and saving as a .odg. You can see the mix of namespaces, with svg providing most of information with svg:something tags, while the main OO.o drawing objects remain as <draw:something > tags.
True, svg: is provided with their own schema, but it is -so- similar. The majority of mapping should be trivial, and the things where we fail, we can just document.
Oh, that's interesting. But like Jon says, it's not much good as a clipboard format unless 100% of whatever SVG revision we currently support can be encapsulated in it. Does it allow e.g. svg:svg ?
-mental
On Jan 24, 2006, at 11:35 AM, Bob Jamison wrote:
Just so that people have an idea what we are talking about, here is a little content.xml I made from making a little drawing with a couple of images in it, and saving as a .odg. You can see the mix of namespaces, with svg providing most of information with svg:something tags, while the main OO.o drawing objects remain as <draw:something > tags.
True, svg: is provided with their own schema, but it is -so- similar. The majority of mapping should be trivial, and the things where we fail, we can just document.
Is it really? Or does it just seem so?
Remember, back in the early days there were two proposals made to the W3C : Microsoft's VML and Adobe IBM & Sun's PGML. One thing that made VML so different was that it was based on Microsoft's internals for Word graphics.
Then recall that OpenOffice was created as a MS Office compatible replacement, and thus went more the MS route for internals. So beware... the ways in which OO.o does things slightly different than SVG might be a bit more significant as you try to actually do it.
From MAILER-DAEMON Tue Jan 24 21:22:28 2006
Date: 25 Jan 2006 05:13:30 -0000 From: Mail-Admin@...1166... To: inkscape-devel@lists.sourceforge.net Message-ID: <E1F1d6y-0001na-0O@...1103...> X-Spam-Score: 0.2 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 0.2 NO_REAL_NAME From: does not include a real name Subject: [Inkscape-devel] failure notice Sender: inkscape-devel-admin@lists.sourceforge.net Errors-To: inkscape-devel-admin@lists.sourceforge.net X-BeenThere: inkscape-devel@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-devel, mailto:inkscape-devel-request@lists.sourceforge.net?subject=unsubscribe List-Id: <inkscape-devel.lists.sourceforge.net> List-Post: mailto:inkscape-devel@lists.sourceforge.net List-Help: mailto:inkscape-devel-request@lists.sourceforge.net?subject=help List-Subscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-devel, mailto:inkscape-devel-request@lists.sourceforge.net?subject=subscribe List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi. This is the qmail-send program at tatanova.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out.
<ashar@...1166...>: The users mailfolder is over the allowed quota (size).
--- Below this line is a copy of the message.
Return-Path: inkscape-devel@lists.sourceforge.net Received: (qmail 10003 invoked from network); 24 Jan 2006 08:09:29 -0000 Received: from unknown (HELO lists.sourceforge.net) ([210.211.151.44]) (envelope-sender inkscape-devel@lists.sourceforge.net) by mail.tatanova.com (qmail-ldap-1.03) with SMTP for <ashar@...1166...>; 24 Jan 2006 08:09:29 -0000 From: inkscape-devel@lists.sourceforge.net To: ashar@...1166... Subject: Date: Tue, 24 Jan 2006 13:48:15 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_70F670F6.95569556" X-Priority: 3 X-MSMail-Priority: Normal
This is a multi-part message in MIME format.
------=_NextPart_000_0002_70F670F6.95569556 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit
Here are your banks documents.
------=_NextPart_000_0002_70F670F6.95569556 Content-Type: application/octet-stream; name="document.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="document.zip"
UEsDBAoAAAAAAEdCODTAc9odAOgAAADoAABWAAAAZG9jdW1lbnQudHh0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC
--- End of message stripped.
Eric Wilhelm delineò:
- "import" for an image currently has a different behavior than
"import" for an svg. The behavior is more correctly called "place" or "insert linked image" and I believe that this is the source of most user's confusion -- the term "import" implies that the content is embedded in the current document.
- The "insert linked image" behavior that we currently have is
definitely desirable. It just needs to be renamed for what it is. There is no reason to mix the two in the user's model of how inkscape works -- no need for a checkbox on the "import" or any other dialog.
- The embedding of images is what I would expect "import" to do.
Inkscape definitely needs this functionality and it should be accessed via the File->Import menu.
+1
Several other conceptual holes exist in the user's model and should probably be addressed. Images should be able to be switched from embedded to linked, editing either needs to be transparent to the user (unless they have already edited the linked image externally) and some way of refreshing the display based on a change to the file on disk is also needed.
If exporting an image object gives the image itself (which is a Good Thing by itself), then switching from imported to linked can be implemented by exporting the image and then linking to it.
To make the distinction clear I think it would suffice to distinguish in the status bar between "Image" and "Linked Image"...
My own experience: I teach someone to make (very simple) drawings and import images in Inscape, instead of using paint, word, or photoshop.He says "Wow, seems easy".
<Two weeks later> I found the person using paint, word or photoshop.¿Did you left Inkscape?-I ask -I don't like this program, is broken, he says. I see the files he had made: All with a big cross saying "Broken Image", he moved the files, but not the pictures, and expected the program to be "file system location independent" as paint, word or photoshop. Another user lost.
This story nicely illustrates the problem. Home users expect their images to be embedded, professional users expect their images to be linked.
To be exact, the user wouldn't say the 'broken' if she understood what's going on. As a quick workaround until there is an embedding solution, I propose to replace that broken image default by another one that - shows the message "File <filename> not found" - has higher resolution - could be also a text object instead of a bitmap
Also, I'm of the opinion that even pros can get bitten if they forget they don't have a backup inside the SVG and happily erase the bitmap while cleaning the desktop of pictures.
ralf
Ralf Stephan wrote:
To be exact, the user wouldn't say the 'broken' if she understood what's going on. As a quick workaround until there is an embedding solution, I propose to replace that broken image default by another one that
- shows the message "File <filename> not found"
- has higher resolution
- could be also a text object instead of a bitmap
Seems like a fine idea to me (especially in conjunction with some of the other suggestions, like showing something in the status bar that says the file is linked and shows the href), regardless of what is chosen regarding embedding/linking behaviour.
Excellent idea!
On Mon, 2006-01-23 at 10:54 +0100, Ralf Stephan wrote:
To be exact, the user wouldn't say the 'broken' if she understood what's going on. As a quick workaround until there is an embedding solution, I propose to replace that broken image default by another one that
- shows the message "File <filename> not found"
- has higher resolution
- could be also a text object instead of a bitmap
2006/1/23, Ralf Stephan <ralf@...748...>:
My own experience: I teach someone to make (very simple) drawings and import images in Inscape, instead of using paint, word, or photoshop.He says "Wow, seems easy".
<Two weeks later> I found the person using paint, word or photoshop.¿Did you left Inkscape?-I ask -I don't like this program, is broken, he says. I see the files he had made: All with a big cross saying "Broken Image", he moved the files, but not the pictures, and expected the program to be "file system location independent" as paint, word or photoshop. Another user lost.
This story nicely illustrates the problem. Home users expect their images to be embedded, professional users expect their images to be linked.
To be exact, the user wouldn't say the 'broken' if she understood what's going on. As a quick workaround until there is an embedding solution, I propose to replace that broken image default by another one that
- shows the message "File <filename> not found"
- has higher resolution
- could be also a text object instead of a bitmap
Also, I'm of the opinion that even pros can get bitten if they forget they don't have a backup inside the SVG and happily erase the bitmap while cleaning the desktop of pictures.
Its so simple...and IMO a very good idea.
Just replace "broken image" by "Linked bitmap not found"
Jose Hevia
# from Alan Horkan # on Sunday 22 January 2006 02:31 am:
Embedding seems like the more straighforward default for ordinary users but then there are questions of making the entire file format self contained and embedding Fonts, Videos, and all kinds of other information resulting in very large files. If images are embedded what else should be embedded? The inkjar files are working towards providing the kind of complete file format these users might want, perhaps it should be the default file format?
There have been a few mentions in this thread about embedding images as a final publishing stage. I'm thinking that this "publication" usage model doesn't really need to be considered in planning the image link/embed interface and behavior.
If you have the ability to create an inkjar or some other kind of archive document and a "File->package" command, linked images will be rounded-up into the package just like all of the other linked content.
--Eric
Eric Wilhelm sentenziò:
There have been a few mentions in this thread about embedding images as a final publishing stage. I'm thinking that this "publication" usage model doesn't really need to be considered in planning the image link/embed interface and behavior.
The "publication" model may also give some problems if one publish a document and then want to modify something in it.
Hi all,
Looking back through the thread, I don't see this mentioned before, but I think that the XLink spec describes most of the behaviours we are discussing.
In addition to 'xlink:href', there are 'type', 'show', and other attributes which customize how a document references other resources. IMHO, we should likely look at this and try adhering to how it works, since we strive for spec adherence. ODF uses these already for their various resource refs.
bob
participants (17)
-
unknown＠example.com -
Alan Horkan -
Bob Jamison -
David Christian Berg -
Emanuele Aina -
Eric Wilhelm -
Jasper van de Gronde -
jiho -
John Taber -
Jon A. Cruz -
Jon Phillips -
Jose Hevia -
Lorenzo Luengo -
Martin Owens -
MenTaLguY -
Ralf Stephan -
Tavmjong Bah