Specification: Improved image properties dialog (0.48)
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've received valuable ideas from ~suv and Steren Giannini and the specification is starting to look very good, so I'd like to propose it as a feature for the next version of Inkscape.
The blueprint: https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enha...
I'd really love to know your oppinions about it, and get as many suggestions, critics, ideas or questions you might come up with to make it better.
Gez.
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.
Hi,
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.
In my work flow I usually have images linked and not embedded, because I often change them in some external program like Gimp. However, it's not that unusual that I have to change width/height ratio. Since (according to my knowledge) Inkscape defines the size of the images by means of pixels, new pictures, which have different w/h ratio are distorted and I have to correct that manually. Hence, a button, which would reset the image size would be most helpful.
Best regards, Rok
P.S.: The first time I sent the mail I sent it only to Gez.
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've received valuable ideas from ~suv and Steren Giannini and the specification is starting to look very good, so I'd like to propose it as a feature for the next version of Inkscape.
The blueprint:
https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enha...
I'd really love to know your oppinions about it, and get as many suggestions, critics, ideas or questions you might come up with to make it better.
Gez.
Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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 wrote:
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.
IMO, if you want to control size, you also need to choose interpolation method that suits best.
Alexandre
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 think that links are confusing for users not familiar with SVG
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.
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.
On Fri, Oct 23, 2009 at 12:51 AM, Alvin Penner <penner@...1856...> wrote:
I think that links are confusing for users not familiar with SVG
Indeed, I also share this opinion.
But for users comfortable with SVG and links, they should be able to use Link on import. I would propose to set a user preference : "Default behavior for image insertion" that would be "Embed" by default and could also be "Link"
Steren
On Oct 22, 2009, at 3:51 PM, Alvin Penner wrote:
I agree strongly. There are a significant number of bug reportsthat 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.
On Thu, 2009-10-22 at 22:50 -0700, Jon A. Cruz wrote:
On Oct 22, 2009, at 3:51 PM, Alvin Penner wrote:
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.
Indeed.
Having a switch in preferences would be bad, because the user has to be aware o what it is set to. Also means you have to first go there if you need to change it depending on project-specific needs.
An option in Import dialog would be better. Or even having 2 entirely separate actions.
Of course that wouldn't answer what to do in the drag-and-drop case :/
As this issue affects all kinds of graphic and sound applications, I have been thinking about a solution on another level. This would require linking to objects via IDs, so you can move stuff around without breaking links. Dependency tracking and automatic bundling once your stuff leaves your system.
participants (8)
-
Alexandre Prokoudine -
Alvin Penner -
Guillermo Espertino -
Jon A. Cruz -
Krzysztof Kosiński -
Rock Star -
Steren -
Thorsten Wilms