On Dec 23, 2009, at 1:47 PM, Krzysztof Kosiński wrote:
W dniu 23 grudnia 2009 22:14 użytkownik Jon Cruz <jon@...18...> napisał:
One of the newly created problem there would be "Hey! I keep editing this in GIMP, but my changes never show up".
Pasting an image into Inkscape does not allow you to edit it and have the changes show up in the document - it is not the original image that is linked, it is the copy in the document's folder. The feature you don't want to break does not actually exist. Moreover people have no such problems with apps like OpenOffice.org which embed by default.
Another one is "I have a common image placed for background, and now my directory jumped from 100MB to 20GB and can't fit on my thumb drive any more".
20GB uncompressed SVG file would have to contain 5GB of images.
When phrased that way, we see your preferred solution turns into "Make Inkscape never support external media"
The links made through pasting are useless. They point to images with bogus filenames. If this is the only way to create a link to an image, then we do not actually support links.
Also once the big-picture is seen in that phrasing, we can see that we need to support CSS files, ICC files, Palette files, *other* SVG files and many others, and not just have a solution for images and only images.
Those other files are not directly related to this problem because you do not paste them into documents. We can address link management separately.
Now here is the elephant you are not seeing. This is *all* link management. For example you say the links that are pasted don't work:
Solution A: Since pasted links are broken, don't link images. Solution B: Since pasted links are broken, fix the pasting of links.
(which solution sounds like proper software engineering?)
In this case I think we're seeing a side effect of the ad-hoc way image pasting was changed. For clipboard operations, many data "flavors" are offered. Someone changed the code to take all image types that could be found, in the order they happen to be in the system. (It is drawing from those supported by GdkPixbuf and from our import extensions). The refinement needs to be to order things to look for preferred data flavors first. And a few of those data flavors are proper links that can be used.
And I personally never see an image in the documents folder linked. Thus your experience does not apply to my use cases. However I will *not* say that since I never see a problem it would mean that you are never seeing one.
So, as we refine this and get more of the details on the problems you personally are seeing, it sound more and more like you are being adversely affected by misbehaving pasting/linking. If we fix that, then most of those use cases will be solved... with no need to resort to embedding.
And then other use cases will clearly need to have different solutions applied. For example, the one you have for "Sara" would be solved by Inkscape noticing that those files are missing and popping up a search dialog to locate one of them (the rest will most often be found by using the base path of the first one manually located).
So, thanks. I think we have just discovered that you have at least one system that is exposing major bugs in our clipboard implementation. Before anything else it is probably quite important to fix those.