On Oct 23, 2009, at 11:47 AM, Krzysztof Kosiński wrote:
Note that the current behavior is wrong on many levels:
- For pasting, we create a PNG file in the same directory as the
edited file with a crazy name like inkscape_pasted_image_20091023_144102.png and link it.
- For importing via drag-and-drop, we embed.
- For importing via the dialog, we make a link.
The defaults are inconsistent, and the paste case is completely bogus because 1. It attempts to write to the directory where the doc is located, which may not be permitted (the directory and the doc might be read-only); 2. It creates a crazy filename; 3. It breaks when the user relocates the document. More importantly we cannot create links to things that might not even be in a file (like pasting pixels from GIMP).
I agree, especially for pasting. Someone reworked the code in an "interesting" way that breaks down under many scenarios. This is just one of them.
Therefore we should default to embedding on paste and DnD, and have 2 import commands: Import, which embeds, and Link Image, which creates a link. Note that this will make Import behavior consistent across all formats. When importing SVG or other vector formats, we never create a link.
However... I don't think the "Therefore" actually quite matches. Among other issues, a drag-n-drop is actually a complex paste operation (and thus shares paste code). So I think the code is doing a few things you don't expect.
Also for the import case, embedding will break things for many, many users. We've looked at that a few times.
The good solution is to create a "media manager" that handles things like images, linked css files, ICC profile files, etc. Things can then be worked out with the UI and perhaps a "Publish" menu/command that does things a bit more explicitly than "save as" or "export".
You're on the right track about things. I think we just need to get a solution that is comprehensive and throughout the entire program and not just fix smaller bugs one at a time.