Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
(Sorry, resending this to list - the Gmail interface defaults to a private reply and I keep making the mistake)
2009/10/23 Jon A. Cruz <jon@...18...>:
A simplistic approach of a solution is to merely switch the default. However what generally happens in these cases (and specifically in this one) is that you are seeing bug reports from those who don't like the current behavior, but you see no feedback at all from those who are happy with the current behavior.
I don't want just to flip the default, I want to change the behavior of the existing commands (import and paste) so that it follows intuition, and add new commands that explicitly expose the link behavior (see below).
BTW, we have looked at this issue for some time, and there are severe consequences to making embed the default. We definitely need to remember to keep those in mind as we make changes.
What are those issues?
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).
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.
Regards, Krzysztof
On Oct 23, 2009, at 11:47 AM, Krzysztof Kosiński wrote:
I don't want just to flip the default, I want to change the behavior of the existing commands (import and paste) so that it follows intuition, and add new commands that explicitly expose the link behavior (see below).
But you are missing the most IMPORTANT point here.
You are thinking of *your* intuition. There is roughly half the user population who's intuition is the *opposite* of yours.
That is the tricky part. For some problems there is a common/unified solution, but for this one there is not.
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.
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".
This is a point I raised in my first post to this thread, I asked for feedback but didn't get any. I did a few days ago (before starting initial discussion with Gez) a blueprint for an Image Manager. (find it here http://wiki.inkscape.org/wiki/index.php/Image_links_manager note that it doesn't take into account all the remarks and things we've said since). This Image manager can be extended to "Media Manager".
My discussion with Gez made me question the utility of such a window. We need your opinions.
Steren
participants (3)
-
Jon A. Cruz -
Krzysztof Kosiński -
Steren