Difference between revisions of "Image properties dialog enhancements"
| Line 10: | Line 10: | ||
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 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 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. | 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. | 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. | 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. | 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. | 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 | 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. | 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. | 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. | ||
| Line 55: | Line 55: | ||
[[File:relink-confirmation.png]] | [[File:relink-confirmation.png]] | ||
==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== | ==Linked vs. Embedded== | ||
| Line 69: | Line 74: | ||
These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links. | 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 a locations that may not be so obvious for the new users. | The image properties would be unified in a single window, adding features that are currently available only via extensions, in a locations that may not be so obvious for the new users. | ||
==Problems of the method== | |||
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. | |||
Revision as of 02:07, 21 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 propose 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.
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. This window could have an extra button for editing the image in an external application, but that's probably out of the scope of this proposal.
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 can 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 canceling it. This window would appear right after a single 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 a locations that may not be so obvious for the new users.
Problems of the method
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.