Difference between revisions of "Image properties dialog enhancements"
| Line 29: | Line 29: | ||
One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one. | One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one. | ||
This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image. | |||
[[File:new-image-properties-dialog.png]] | [[File:new-image-properties-dialog.png]] | ||
The new window design should have an ID field to be able to easily identify what image we're working on, also offering the ability to change its ID without entering the XML editor, which can be daunting for the inexperienced user. | The new window design should have an ID field to be able to easily identify what image we're working on, also offering the ability to change its ID without entering the XML editor, which can be daunting for the inexperienced user. | ||
The URL field would be accompained by a browse button for easy image re-linking. | The URL field would be accompained by a browse button for easy image re-linking. | ||
The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct. | The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct. | ||
I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension. | I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension. | ||
The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock. | The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock. | ||
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead. | |||
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead. | |||
Initially I had the intention to add the "edit externally" button to this window, but I realized that moving that button there would add one extra step to reach that feature, which is already placed very conveniently in the context menu. | Initially I had the intention to add the "edit externally" button to this window, but I realized that moving that button there would add one extra step to reach that feature, which is already placed very conveniently in the context menu. | ||
Revision as of 03:15, 22 October 2009
Image properties dialog enhancements
Summary
Organizing linked bitmap images is quite a hassle at the moment. When a bitmap file is renamed or moved to a different location, the corresponding bitmap links need to be changed manually one by one in Inkscape, involving a tedious copy and paste process for the filenames. This can be improved. This is an alternative to the method proposed in [1].
Proposal
The proposal is to add some minor enhancements to the existing image properties dialog, in order to improve its usability and solve broken links in an easy and automated way.
The first thing that has to be solved is the inconsistency in absolute/relative linking. At the moment all the images are linked with absolute paths, and that con be very inconvenient when working on the same file over a network. The images in the same directory than the SVG file should be linked with relative paths, and so the images in children directories. This condition can be extended to folders contained by the same parent folder that contains the SVG.
That would solve common problems like broken links if the file was created or is retrieved from a remote machine over a samba mount in linux, for instance.
Another common situation where absolute links are useless is a project retrieved from a backup. Again, all files have to be re-linked. So in the first place, fixing the absolute/relative linking will solve a lot of broken links.
However, that wouldn't fix all the broken links, and there are several situations where moving or renaming a linked file will result in a broken link, so another strategy should be prepared for that.
As it would discussed in the mailing list and related bug reports, the lack of a browse button in the image properties dialog makes it too tedious to re-link missing images, so adding that button would make things easier.
But having dozens of broken links would be still a hassle even having that button, so a "smart re-linking" strategy would be handy.
Adding a modal warning about broken links would be excessive since we already have a pretty visible way to display that there are missing bitmaps, so the focus should be put on providing an automated way to resolve broken links using a single manual replacement. As it was expressed earlier, a proper management of absolute and relative links would help with this task.
Image Properties Dialog Re-design
One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one. This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image.
The new window design should have an ID field to be able to easily identify what image we're working on, also offering the ability to change its ID without entering the XML editor, which can be daunting for the inexperienced user.
The URL field would be accompained by a browse button for easy image re-linking. The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct.
I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension.
The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock.
The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead.
Initially I had the intention to add the "edit externally" button to this window, but I realized that moving that button there would add one extra step to reach that feature, which is already placed very conveniently in the context menu.
Steren Giannini suggested that a thumbnail would be useful in this window, so I added the "show image details" collapsable area with the thumbnail and some information of the original file (it would be collapesed by default). I still have doubts about this feature. If this dialog will be dockable like the fill and stroke, align or transform dialogs for instance, all that extra information will clutter the dialog and use valuable screen space. I leave this addition to further discussion.
Smart image re-linking
If there are several images with broken links and we choose the right path for one of those images (and they share the same location) Inkscape should compare the common location of the broken links and fix the remaining images with the new location automatically.
Example: there are 3 images with broken absolute links:
- /media/disk/inkscape-works/images/cat.png
- /media/disk/inkscape-works/images/dog.png
- /media/disk/inkscape-works/images/bird.png
when the user sets a relative link for the first image to images/cat.png the other images should be automatically relinked, since they had:
- broken links
- the same orignal path
- they exist in the new location.
This operation could be silent, but when there are several images the re-linking process can take some time, so a confirmation window would provide a clear warning about the operation is going to be performed, with the possibility of choosing "yes" to perform the re-link process with the images found, or skipping it choosing "no" This window would appear right after a single re-link.
The confirmation window can optionally show details about the images that are going to be re-linked, with the ability to untick the items that the user doesn't want to automatically re-link.
Manual selection of relative or absolute paths
Steren pointed me out that there are some situations where selecting manually if the image will be linked using an absolute or a relative path. In that case, the file selector window that opens with the "browse" button of the Image Properties dialog could have radio buttons for selecting absolute or relative. The default value would be proposed by inkscape according the guidelines discussed earlier, but the user would have the ability to force the path to be relative or absolute, according his needs. However, that feature imposes a potential problem: How the smart re-linking feature should act in that case? The automatically re-linked images would use the same path type than the manually selected?
Linked vs. Embedded
The new image properties dialog would have radio buttons for choosing if the image is linked or embedded.
The behavior of those buttons would be the following:
- If the image is linked (default for the imported bitmaps) the behavior would be the described earlier in this blueprint
- if the user chooses "embedded", the url input and its browse button will be grayed out, and the image will be embedded into the SVG document
- if the user chooses "linked" on an image that was previously embedded, a file dialog will be opened, prompting the user to enter a location and a file name (by default the id and the path of the SVG file will be used) to extract and save the image.
- if the link is broken, the "embedded" option will be grayed out until a valid path is set.
General Benefits of this change
These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links. The image properties would be unified in a single window, adding features that are currently available only via extensions, in locations that may not be so obvious for the new users.
Caveats
This method doesn't provide a direct way to manage blocked or hidden images, unless they can be fixed by the smart re-linking feature. Blocked or hidden images force the user to use the object properties dialog or the xml editor, in order to select the unaccessible images before using the image properties dialog. That particular problem isn't a limitation of the method, but the way that inkscape works with hidden and locked images. My guess is that some minor enhancements in the XML editor would make this problem obsolete (for instance: a filter to show only image tags in the xml tree, maybe thumbnails). This possibility is being discussed and any suggestion will be welcome.