image links management

Agreed. The Image Properties dialog could probably use some other improvements as well...

This is a really needed feature.
Another useful improvement would be some "smart" path replacement strategy.
For instance, 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) the program should compare the common location of the broken links and fix the remaining images with the new location automatically.

An 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:
a) broken links
b) the same orignal path
c) they exist in the new location.

another related blueprint that IMHO is closer to the reporters original proposal:
Linked Bitmap Manager : Blueprints : Inkscape:
<https://blueprints.launchpad.net/inkscape/+spec/linked-bitmap-manager>

~suv: The blueprint indeed is closer to the original proposal, but It doesn't seem to be very effective. In fact, it looks like a straight copy of the Adobe's dialog, which is not very good.
I think I found an easier and more transparent solution for the same problem, re-using most of the things that are already there in the UI. I filed a new blueprint and specification with a simplified method that includes ideas for the Image Properties dialog UI, re-linking strategies and linked/embedded selection.
https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enhancements

I didn't add it, but an option for editing the images externally could be added easily to the same dialog, unifying everything and making it very easy to use.
Ideas, corrections and suggestions are welcome.

@Gez - thank you for the detailed new blueprint. Have you seen the newest proposal by Steren? Maybe you can merge your ideas…

Image links manager - Inkscape Wiki:
<http://wiki.inkscape.org/wiki/index.php/Image_links_manager>

~suv: that's exactly a copy from Adobe's dialog. I don't think it's that good and I don't even think we need it.
As I proposed in my blueprint, there's a more transparent way to do it, using the structure we already have and without the need of adding a new tool (a new window, a new slot in the context window and the menus, etc).
The proposed "image links manager" certainly covers the problems and provides solutions, but it also adds complexity that can be avoided.
I can't see the benefit of having a list of images. The images are already in the document, the broken links have a distinctive "missing image" bitmap that is hard to miss, and a semi-automated replacement method would be enough to repair the links easily.
My proposal covers the same problematic situations that Steren's, but improving an existing tool, not adding a new one (and even moving some features into the same dialog, to reduce the clutter)

(Note: I don't favour one proposal over the other - I haven't spent enough time yet to think about the issue in depth. In general I'd vote for the "leanest" solution.)

one quick comment though:

> I can't see the benefit of having a list of images.
Images might be hidden, locked or otherwise not accessible (referenced in the <defs> section? what happens with clones?) , especially if you deal with documents you didn't create yourself (the case where image links are most likely to break) and therefor don't know it's internal structure.

Hi,
I'm only finding this conversation now, sorry for that. I can guarantee you that everything I wrote in this blueprint is not copied from a software from Adobe. In fact I spent my afternoon thinking about it.

I will have more time tomorrow to have a look to you proposals and to discuss this with you.

Just to mention also that I may be a mentor of a group of student who could work on it if the specifications are clear.

Steren: I'm sorry if I sounded like I was accusing you of copying it. But it is so similar that I honestly thought that you picked it up from there.

~suv: You have good points there. But I wonder how common are those situations to justify the creation of such a feature.
People who use to work with locked and hidden images probably won't be afraid of using the XML editor, and in that case wouldn't be a problem to select the hidden or locked image from the XML tree and use the image properties dialog (which in my proposal becomes a single dialog for the currently selected image, instead of a dialog for each image).
I mean, the only way to hide an object right now is via the Object Properties dialog, and it has some serious usability issues. For instance, If you hide any object, you'll only be able to take it back using the XML editor.
If you have locked objects is almost the same. You have to unlock them to touch them, so you have to be familiar with the object properties dialog and probably with the XML editor too.
So I still can't see the benefit. The users who are able to work with locked and hidden objects won't have much troubles. People who isn't will, and in that case the Steren's solution doesn't provide size adjustments so if the image is locked or hidden and the new link has different dimensions that dialog wouldn't help much.
For that particular cases I think a filter in the XML editor would be more helpful. You could simple filter image tags and use the image properties dialog for links management.

Gez:
- I must admit I inspired myself from the "Edit>Links" window of OpenOffice.org I use to keep control of embedded images in .odf. I also remember that Adobe Premiere, when I tried it five years ago, had a smart recovery tool. These may have influenced me.

- I had a first look to your proposal, I think enhancing the property window is a good idea. It's better than my "Right-Click" paragraph. So I'm 100% with you on this point.

- I still think an Image manager window is needed. To have in one place the information of all my images. In fact when I look the canvas, I may see all my images (almost as ~suv said), but I can't know if they are embedded or linked relatively or absolutely. With the manager, I keep an eye on everything and can moreover decide to do operations on a large number of images very easily : the thumbnail tells me which image it is, and I don't have to strive to select it, contrary to the canvas, where it can sometime be very hard to select one particular image (if your layers are locked, or if your image is very transparent).
But we may wonder : why do we need to do such operations on multiple images ? Personally, it was when I had to :
* reorganize my folders (I want to be sure everything is relative)
* share my work (I want to be sure everything is embedded, or I want to be sure everything is relative)

- I also think that a better XML editor would be awesome. I can imagine filters, thumbnails could be nice too.

I'm looking forward to work with you on this specification

Steren:
My point is that the user shouldn't worry about the images being relative or absolute. As I specified in my blueprint, Inkscape should make images in the same directory (or children) relative automatically, and probably the same for folders that share the same parent than the one that contains the svg. The rest should be marked as absolute.
Of course, you can't fight a messy user who has all his files scattered all around, but maybe you should think if we need extra features for people who can't get their project organized.

In response to your example cases:
- Folder reorganization: If you move your images manually to a new folder, you'll likely use a children folder, the same folder or a folder that shares the same parent of your svg file. Relinking one single image using the image properties dialog would trigger the smart re-linking, so with a single operation you'd get your links fixed automatically.
- Share your work: The save as dialog offers a zipped svg file with collected images. It grabs every image you have linked in your SVG and puts them in a zip file, along the SVG document. It can be improved, the images should be put in a children folder labelled "images" and then compressed, but it covers the need of sharing work without loosing your image links.

I'm not saying that your links manager wouldn't be a useful feature at all, but it's a completely new tool (with its own window, thumbnails, and all) and I think we can have a similar solution more immediately revamping the existing image properties dialog.
I still think that an impreved XML editor (with filters and thumbnails, as you say) would be more useful, and it would help to select images without the need of unlocking or unhiding them.

Thanks for the feedback. I'm looking forward to work together on this project too.
Maybe we should follow this discussion in the mailing list and move the conclusions to the blueprint.

> ~suv: You have good points there. But I wonder how common are those situations to justify the creation of such a feature.

I used to work at at t-shirt/graphics design company where I eventually got them using Inkscape almost exclusively. Even though there were only four of us this was a common annoyance.

I was really the only one who was comfortable using the xml editor, often having to help out the others in the office. So, even though we were only four users I can assure you that an image management feautre would've been very useful in our situation.

Scribus's new (as of 1.3.5) image management feature was really helpful when creating a document, as was the Collect for Output feature (it collects all of the images, fonts and other resources and puts them in one folder). Perhaps it may be a good idea to look at theirs.

Ant

Antonio: Please take a look on my proposal. I think it covers the most common situations. The suggestion to use the xml editor was only for images that are locked or hidden (but that's not exclusive for images, in the current state any hidden object forces the user to take a look on the XML editor).

<off-topic>
> in the current state any hidden object forces the user to
> take a look on the XML editor

what about:
a) The preferences for 'Selecting' allows hidden / locked objects to be part of a 'Crtl+A' selection set (and when using 'Tab' or 'Shift +Tab').
b) You can access hidden / locked objects with the 'Edit > Find…' dialog. Once they are part of a selection set you can move them, change attributes, copy them etc. You just have no access to them with the mouse. You can search and select hidden images, move them to a separate layer and unhide them with 'Unhide All' ;-)
c) And finally - you can unhide / unlock all hidden or locked objects in the current layer with 'Object > Unhide All' and 'Object > Unlock All'.

But there are separate RFEs about an improved GUI for locked/hidden objects. ;-)
</off-topic>

What seems missing is a menu entry like 'Objects > Image properties': you can't get to that dialog even if you manage to select a hidden or locked image because it is only available in the context menu. You first have to use 'Object > Object properties…' to unlock/unhide the image and then 'context menu > Image properties'.

Gez : As I said, I like your Image properties window. I have some questions:

- Why display the ID in the image properties ? I think users recognize the image by looking at a thumbnail or by looking at the file path. Currently, the ID brings no information. I would suggest to display a thumbnail instead of the ID, thus the user would be sure to edit the right image.

- I'm not sure you noticed that "Edit Externally" is currently working and is in the context menu (Right-Click). You said it is out of the scope of the proposal, but it's already here. I like the way it is today : Right-Click > Edit Externally. I prefer this to Right-Click > Images Properties > Edit Externally .

- Concerning the smart re-linking: If the system detects that other images can be automatically relinked, it has already done all the computation work. So there won't be any computation time after the user choose "yes" to the automatic relinking, so no need for a "Cancel" action. I would also suggest to add the list of the name of images that are going to be relinked in this dialog box.

Steren:
- IDs are very important. An ID Is an unique name for each element in your SVG document. Inkscape names these IDs automatically, but keeping a good naming scheme for the elements is always a good practice for creating organized documents, making it easier to modify or re-use elements in the future. Also IDs are used for export, interactivity, etc. I think Inkscape in general has this important tag pretty hidden and would be nicer if it is more visible to the user.
I also thought about a thumbnail. Of course it would be nice, but probably packing so many features in the specification at the beginning makes it look too complicated to be started, so I planned to start with something that can be implemented re-using the existing structure. Of course we can add the thumbnail as an optional enhancement in the specification. I agree.

- Yes, I'm aware of the edit externally command. I wrote that because it is already implemented and it works, and it isn't crucial to move it into the image properties dialog.
I mean, it's there, it's functional. We can move it to that dialog later, but it's not urgent.

- It depends. The user might want to skip the smart re-linking so the replacement of the links on the actual document should be performed after the user confirms that he want it. The re-linking process would have two stages: detection of possible re-link targets, and commit those changes after user's confirmation.
About the list of images that are going to be re-linked... what for? It would be merely informative.
In your proposal it makes more sense, but in this case I think it only clutters the window. I'd rather use the verbose output of the command line for that information.

Gez:
1. IDs are important for organization. But in Inkscape, I don't think people are using them. Maybe because meaningfull IDs require too much work. The ID can be found in the object property, the same way it is found for any other object, I don't see why to add it in the image properties window.
Concerning the thumbnail, this is a blueprint, it should not consider the difficulty of the task, I would insist to add it in your mock-up.

3. As you said :
- First : detection of possible re-link targets
- Second : user's confirmation or user's "no thanks"
- Third : commit those changes if confirmed
The first stage is the one that require some computation (and "some" may be exagerated). With the results of the first, the third is instantaneous. That's why I still don't see when to display the "Cancel operation button"

And I would rather say YES to a dialog that says "image2.png and image3.png are going to be changed " than to a dialog that says "Some images are going to be changed". That's why I propose a list of images that are going to be changed.

Steren: Ok, let's add those features in the blueprint.

1) I think people don't use IDs because they aren't integrated very well to the UI and look like something hidden, something that you'd never need to use. Making them more accessible maybe would invite people to be more organized with their projects.
Anyway, IDs may look unnecessary for an illustrator or a graphic artist, but are very important in svg projects for the web. I think it wouldn't harm to put that field in that dialog.
We can add the thumbnail and the "edit externally" button and see how they work in the mockup.

2) Oh, wait. Now I understand! There is no cancel button. I was talking about the yes/no buttons (the "no" button would cancel the relinking). I'll change that part of the text to make it more clear.
And about the "some computation" part... I wouldn't be so sure. Did you notice how much time does it take to ungroup several grouped objects? This might be similar, so that's why I thought about that confirmation window.
But it's the only confirmation that will be asked.

3) I'm concerned about the list of results. It wouldn't be a problem with a couple of images, but imagine that list when the replacement were fifty or more. Do you have any idea about how to display that amount of information in an elegant way?

I'll follow this discussion in the mailing list. I think that it's more appropriate and will give us different points of view.

~suv: I totally missed the unlock all and show all commands! were they always there?
I must admit that I don't use to lock or hide objects, I use layers instead. But anyway, this seems to support my point: if it isn't difficult to select locked or hidden images, the listing of all the images in the document isn't crucial.
And good point about the need of adding the image properties dialog in the object menu. I'm adding it to the specification.

a feature that enables to manage externally stored images including the format .svg is at least for me as "web-developer" very essential

i see no progress on this and wonder if it ever will become a part of inkscape capabilities

in case it is question of gui - i have plenty experience and can help out. though i am not a programmer i may yet be helpful in that aspect as i also used to be the programmers workaround guy in my previous life

thank you all for a great work. since i today only confess to open source, my dependency of inkscape render quite obvious - and without you, each human like me would be in a much less possible situation

/jean