Hi, I think a project aimed at improving image management in Inkscape would be great for students fromEcole Centrale Lyon. If you think it's a good idea, I could mentor a team of students that could work on this. (The same kind of work than we've done in the past : LPE for groups, stacking and envelope 2 years ago and Spray tool last year).

Concerning the smart broken link feature: Gez was worried about the time image path replacement would take. But in fact, once the system has found the new paths, it is only a replacement of XML attrributes. I think it doesn't cost computation time at all. Gez mentioned computation time needed when ungrouping a large group of objects, I think this is due to big XML manipulation. Here it's only an attribute replacement. But I may be mistaken, someone can help us ?

I still want to discuss about the ID field. I don't think it is a good idea to put it in "Image Properties". For me the user identify the image by either a thumbnail or the path. The ID field is already accessible in the "Object Properties" window. The user case Gez mentioned that uses ID is web design (we can consider that for artistic work, keeping all IDs meaningful is too much work). I think the "Object Properties" window is sufficent and may be more the window to open when doing web design. So I would vote to remove ID from the top of Image properties. We can remove it completely or move it to "show image details"

A last point to discuss is an Image manager. I described it in my initial blueprint: http://wiki.inkscape.org/wiki/index.php/Image_links_manager I think the enhancement of the image properties window is great. And I wonder if an other window that regroups all the images currently in the document can be useful. This is to discuss.

Steren.

On Thu, Oct 22, 2009 at 3:05 PM, Rock Star <rockstar1707@...400...> wrote:

I really like the blueprint, but there's one more thing i'd add to it. Some button for reseting the image size or width/heigh ratio.

Hi, Indeed, I also had this kind of issues (I was working with sponsors logos, and had to change them for other sponsors).

But to reset the image size would be too much, reset the ratio is better IMO. Here is an example : - The original image is 100x50 and is 200x100 in Inkscape. - You edit this image in gimp and make it 400x100. - What you want when you come back to Inkscape is an image that is 200x50 in Inkscape.

So this button should keep one Inkscape dimension (say Width, or the bigger or the smaller), and re-compute the other Inkscape dimension (say Height) considering the new image dimensions. What do you think ?

Steren

2009/10/22 Guillermo Espertino <gespertino@...400...>:

Hi: I created a blueprint based on some ideas discussed in https://bugs.launchpad.net/inkscape/+bug/172162

It's a specification of an improved image properties dialog that (hopefully) would tackle some annoying aspects of image links management in inkscape.

I think that links are confusing for users not familiar with SVG, and should be only created with explicit commands for image linking. By default all images should be embedded. This is what users expect. For example, import, drag and drop, opening or pasting an image should embed it. A link should only be created if the user selects a command named 'Insert Image Link'.

Of course, that doesn't mean we should make image links easier to use, just that we should not default to creating them.

Regards, Krzysztof

I assume you probably meant : Of course, that doesn't mean we should make image links less easy to use, just that we should not default to creating them.

Exactly :)

Regards, Krzysztof

On Oct 22, 2009, at 3:51 PM, Alvin Penner wrote:

 I agree strongly. There are a significant number of bug reports  

that have been complicated a great deal by the fact that users did not realize that they were using links, they assumed the objects were embedded.

...

Of course, that doesn't mean we should make image links easier to use,

just that we should not default to creating them.

What it comes down to is that you will confuse half the users, depending on which way you default. That is, if you default to only linking images you will confuse/annoy those who expect embedded. However, if on the other hand you default to always embedding images, you will confuse/annoy those who expect linked.

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. People really only speak up when something bothers them. So you will make the second half of the users happy at the expense of the first half.

Taking a step back to the higher level, this issue is really one of confusion on what is happening. The program's behavior is not clear, and thus people get confused. The real solution is to change the UI and workflow to make it very clear to users what is going on. *Part* of that solution is to allow a user to set the default behavior as needed for that specific user. But a *prior* step is to clearly communicate to the user what is actually happening, what those choices are, etc.

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.