[bitmap import] modal dialog destroys workflow
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Invalid
|
Medium
|
Jon A. Cruz |
Bug Description
I very much appreciate the effort to address the long standing issue to bitmap embedding/linking. That said, the popup modal dialog asking for a decision each time a bitmap is imported is the most obtrusive UI solution that really creates barriers to a pleasant experience. This is especially true when importing a series of images. Another not such a good solution is to define an Inkscape preference for the default behavior.
What strikes me as the best approach here is to simply decide on the default behavior, which I'm sure will cause a lengthy argument, but good design is not about avoiding decisions. Either choice we pick, the alternative should be allowed by the following two ways:
a) file dialog -- when importing bitmaps through the menu/toolbar item, the file dialog should be extended with a checkbox listing that alternative option ("[ ] embed image").
b) when dropping a target using DnD, when a modifier key is pressed (Alt on Linux and Windows), a menu should be shown listing all the actions possible to apply to the dragged items. This behavior is similar to how the Nautilus file manager deals with drag and drop for example.
As for the default discussion I vote for embedding even if it poses a performance and file size cost. There is an insanely high number of mockups in circulation which have the 'missing bitmap' icon instead of actual artwork and based on my use paterns the need to embed large bitmaps or needing the images to be linked have been rather low. That said, I strongly suggest to use relative paths by default.
description: | updated |
Changed in inkscape: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → Jon A. Cruz (jon-joncruz) |
status: | Confirmed → In Progress |
tags: | added: bitmap ui |
Changed in inkscape: | |
status: | In Progress → Triaged |
Yes, there was much discussion on this already, with the need to address both the users who would need embedding vs. the users who would need linking explicitly covered. There was a student project underway that would address this, that we had decided to wait for. Then some changes were unexpectedly added that did not quite cover all the use cases.
I've been getting a cleanup of that in. This includes proper link vs. embed on DnD via modifier key, including following the standard keys and to also follow the standard to allow the user choice menu.
Not using relative paths is a separate bug. This had been fixed a few times in the course of 0.47 development, but kept being unfixed by other changes. This is currently covered by bug #170225.