Re: Specification: Improved image properties dialog (0.48)

[Guillermo Espertino]

> From: Thorsten Wilms <t_w_@...>

> 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.

I strongly agree. Dependency tracking would be the perfect solution for
novice and advanced users.
I think that it should be the ultimate goal in image link management,
but meanwhile we should implement some minor improvements (like some of
the proposed in my blueprint) for making it nicer to work with images in
Inkscape.
The good thing is that these improvements are compatible with that ideal
solution, so it wouldn't be wasted time to fix some annoyances of the
image properties dialog now :-)


> From: Krzysztof Kosi?ski <tweenk.pl@...>

> I don't want just to flip the default, I want to change the behavior
> of the existing commands (import and paste) so that it follows
> intuition, and add new commands that explicitly expose the link
> behavior (see below).

> Note that the current behavior is wrong on many levels:
> - For pasting, we create a PNG file in the same directory as the
> edited file with a crazy name like
> inkscape_pasted_image_20091023_144102.png ?and link it.
> - For importing via drag-and-drop, we embed.
> - For importing via the dialog, we make a link.

> The defaults are inconsistent, and the paste case is completely bogus
> because 1. It attempts to write to the directory where the doc is
> located, which may not be permitted (the directory and the doc might
> be read-only); 2. It creates a crazy filename; 3. It breaks when the
> user relocates the document. More importantly we cannot create links
> to things that might not even be in a file (like pasting pixels from
> GIMP).

> Therefore we should default to embedding on paste and DnD, and have 2
> import commands: Import, which embeds, and Link Image, which creates a
> link. Note that this will make Import behavior consistent across all
> formats. When importing SVG or other vector formats, we never create a
> link.

> Serious artist know they want an image link, and most importantly know
> the difference between an embedded image and a link, so they will
> choose the correct option (insert image link). Newbie users do not
> know about this distinction. They just want to put images in the
> document, and expect them to stay there when they move the document to
> another folder or remove the original images.
>

Krzysztof:
Actually, every image is LINKED. There are no inconsistencies at all.
You say importing via drag and drop embeds, and that's wrong.
The naming and location of pasted files can be discussed, of course, but
you seem to be proposing to change the behavior of something that is
common in every program that works with external data (vectorial
illustration, page layout, even audio and video editors) because it
isn't "intuitive" for new users who didn't read the documentation?
It wouldn't be a problem if it is harmless, but changing it brings a lot
of problems, as JonCruz pointed out.
In my honest oppinion, a switch in the import dialog, a good method for
dependency tracking and solving and a better image properties dialog
would be the best solution.
Dumbing down the program because a part of its users are new to it and
didn't read the documentation is shooting to your own foot.

An SVG file, as it names stands for, stores VECTOR graphics. If it
allows to embed bitmap images, it is an option for cases when it's
needed. Links are the proper way to include images, and the most
convenient most of the times.

Also you're assuming that an SVG file is something that a regular user
will send to his friend via email, like a jpeg.
Inkscape is a vector illustration program. Its files are comparable to
CDR or AI files, that also work with links and embedded images.
So I guess it's safe to say that the target public for an application
like inkscape isn't a complete newbie that only used MS Paint.

By the way, GIMP started to change its focus since a clear target user
was defined, and this kind of discussions (if the program is or isn't
friendly for the unexperienced users) kinda stopped.
Does inkscape have a clear target user group defined?


> I don't understand. How do you imagine making an image external
> without saving it? :)

Re-linking it to the original bitmap file. If you imported it once, you
may still have the original file in your disk.
If you simply save it again, you'll end up with the original and the
"externalized" image in your disk.
That's confusing and breaks apart you project's organization.

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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jon Cruz]

On Oct 23, 2009, at 1:58 PM, Guillermo Espertino wrote:

> By the way, GIMP started to change its focus since a clear target user
> was defined, and this kind of discussions (if the program is or isn't
> friendly for the unexperienced users) kinda stopped.
> Does inkscape have a clear target user group defined?

We're trying to collect up info here:

http://wiki.inkscape.org/wiki/index.php/Marketing_Scratchpad

Please add to it as needed.

Thanks.

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

2009/10/23 Guillermo Espertino <gespertino@...>:
> I strongly agree. Dependency tracking would be the perfect solution for
> novice and advanced users.

But how would it work? How do we find a file, if we don't know its path?

> Krzysztof:
> Actually, every image is LINKED. There are no inconsistencies at all.
> You say importing via drag and drop embeds, and that's wrong.

Why? You can drag and drop something that is not a file on your disk,
like a bunch of objects from another application, or an image from the
web browser (in fact it's the preferred method of adding album art in
Rhythmbox). In those cases you have nothing to link to.

> The naming and location of pasted files can be discussed, of course, but
> you seem to be proposing to change the behavior of something that is
> common in every program that works with external data (vectorial
> illustration, page layout, even audio and video editors) because it
> isn't "intuitive" for new users who didn't read the documentation?

All vector and raster programs I know embed by default, but you can
create a link if you explicitly want it. You never get surprise links
from pasting or importing. More importantly, you never get a surprise
link to a bogus filename from pasting. Again, I am not against links.
I am against surprise links. Links are good and useful. Surprise links
are evil and turn users off Inkscape.

> Dumbing down the program because a part of its users are new to it and
> didn't read the documentation is shooting to your own foot.

Good defaults are not dumbing down. Making the program hard to use to
punish people who don't read documentation or don't know what they are
doing won't teach those people to read documentation. It will teach
them to use another program that does not create broken documents.
This whole remark is misguided because the proposed changes do not
remove any functionality - they only rename it to a more explicit
name.

> An SVG file, as it names stands for, stores VECTOR graphics. If it
> allows to embed bitmap images, it is an option for cases when it's
> needed. Links are the proper way to include images, and the most
> convenient most of the times.

Links are good if you don't move the document around, e.g. if it sits
on a web page, and you want to edit the linked documents without
touching the SVG. We cannot assume this about all user documents. You
seem to be arguing that we should always use links because it is "more
SVG-ish". This is not a practical consideration, but an ideological
one. I say: links break, embedded images don't. If we are not sure
what the user wants, we use the safe option of embedding. Embedding
makes the file larger, but still manageable, and we can compress it.

> Also you're assuming that an SVG file is something that a regular user
> will send to his friend via email, like a jpeg.

Yes, why would I assume otherwise? In fact it's the only suitable
format to send editable vector images to other people, because all
other widely supported vector formats are undocumented and/or
patented. (There's also PDF, but it's not intended to be editable.)

> Inkscape is a vector illustration program. Its files are comparable to
> CDR or AI files, that also work with links and embedded images.
> So I guess it's safe to say that the target public for an application
> like inkscape isn't a complete newbie that only used MS Paint.

I don't know about AI, but Corel Draw defaults to embedding images on
pasting, DnD and import in the way I described before, but has
explicit commands to create links. Audio and video projects are rarely
sent over email in editable form.

> By the way, GIMP started to change its focus since a clear target user
> was defined, and this kind of discussions (if the program is or isn't
> friendly for the unexperienced users) kinda stopped.
> Does inkscape have a clear target user group defined?

I know that it's not SVG / HTML purists.

> Re-linking it to the original bitmap file. If you imported it once, you
> may still have the original file in your disk.
> If you simply save it again, you'll end up with the original and the
> "externalized" image in your disk.
> That's confusing and breaks apart you project's organization.

OK, I understand. In that case, we can preserve the original image
location in the image tag, but embed the data. 'Convert to link'
creates a regular link; there is a warning if the image in the
original location was changed. 'Update' updates the embedded data from
the saved original location. This is an expansion of the hybrid link
concept I mentioned before with regards to editing embedded images.

Regards, Krzysztof

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Thorsten Wilms]

On Fri, 2009-10-23 at 23:50 +0200, Krzysztof Kosiński wrote:
> 2009/10/23 Guillermo Espertino <gespertino@...>:
> > I strongly agree. Dependency tracking would be the perfect solution for
> > novice and advanced users.
>
> But how would it work? How do we find a file, if we don't know its path?

Each file would have to have a system-wide unique ID, independent of
path and name.

Or you would have to keep track of where you have links to files to
trigger updates whenever a file is renamed/moved.

To have any chance to get there on platforms other than Linux, this
would have to happen on some intermediary layer.


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

2009/10/24 Thorsten Wilms <t_w_@...>:
>> But how would it work? How do we find a file, if we don't know its path?
>
> Each file would have to have a system-wide unique ID, independent of
> path and name.

Neither Linux nor Windows provide such functionality. I don't know how
to implement it in userspace in a way that would not hog down the
system.

> Or you would have to keep track of where you have links to files to
> trigger updates whenever a file is renamed/moved.

Even on Linux, inotify does not provide information where a file is
moved, only that it is moved somewhere. Detecting where a file is
moved would require watching every directory on the entire filesystem
(see http://www.linuxjournal.com/article/8478). This is usually
impossible, because there is a limit on the number of watches you can
set (usually 8192), and you have to set one watch per directory
(inotify watches are not recursive). Even if we didn't hit the limit,
it would work only when Inkscape is running, and would not prevent
breaking documents when sending them to someone else.

Regards, Krzysztof

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Rock Star]

A short comment about tracking files...

I assume Songbird has some similar functionality.

For example, I have some songs in some folder and I import/add them into Songbird. Later on I find out that I don't like the naming of the files or a folder where the songs are, so I simply use some file manager to change their names. This "external" renaming of files (or folder where the file is located) doesn't seam to cause problems to Songbird. It always plays the right song that I choose from the database. So it's obviously tracking that file somehow.

I have no idea how does it do that or if this is exactly the same as what the conversation is about, but I thought that it might be useful to know.

Rok

2009/10/24 Krzysztof Kosiński <[e-mail]>

2009/10/24 Thorsten Wilms <t_w_@...>:

>> But how would it work? How do we find a file, if we don't know its path?
>
> Each file would have to have a system-wide unique ID, independent of
> path and name.

Neither Linux nor Windows provide such functionality. I don't know how
to implement it in userspace in a way that would not hog down the
system.

> Or you would have to keep track of where you have links to files to
> trigger updates whenever a file is renamed/moved.

Even on Linux, inotify does not provide information where a file is
moved, only that it is moved somewhere. Detecting where a file is
moved would require watching every directory on the entire filesystem
(see http://www.linuxjournal.com/article/8478). This is usually
impossible, because there is a limit on the number of watches you can
set (usually 8192), and you have to set one watch per directory
(inotify watches are not recursive). Even if we didn't hit the limit,
it would work only when Inkscape is running, and would not prevent
breaking documents when sending them to someone else.

Regards, Krzysztof

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Steren Giannini-2]

That is because Songbird consider the metadata of your files, not the name of the file.
Moreover, Songbird is "watching" a particular folder. If you move this folder completely ouside of the watched folder, there will be a problem.

But please, can we be a little less ambitious and refocus on a solution that wouldn't require a change in all major filesystems ?

2009/10/24 Rock Star <rockstar1707@...>

A short comment about tracking files...

I assume Songbird has some similar functionality.

For example, I have some songs in some folder and I import/add them into Songbird. Later on I find out that I don't like the naming of the files or a folder where the songs are, so I simply use some file manager to change their names. This "external" renaming of files (or folder where the file is located) doesn't seam to cause problems to Songbird. It always plays the right song that I choose from the database. So it's obviously tracking that file somehow.

I have no idea how does it do that or if this is exactly the same as what the conversation is about, but I thought that it might be useful to know.

Rok

2009/10/24 Krzysztof Kosiński <[e-mail]>

2009/10/24 Thorsten Wilms <t_w_@...>:

>> But how would it work? How do we find a file, if we don't know its path?
>
> Each file would have to have a system-wide unique ID, independent of
> path and name.

Neither Linux nor Windows provide such functionality. I don't know how
to implement it in userspace in a way that would not hog down the
system.

> Or you would have to keep track of where you have links to files to
> trigger updates whenever a file is renamed/moved.

Even on Linux, inotify does not provide information where a file is
moved, only that it is moved somewhere. Detecting where a file is
moved would require watching every directory on the entire filesystem
(see http://www.linuxjournal.com/article/8478). This is usually
impossible, because there is a limit on the number of watches you can
set (usually 8192), and you have to set one watch per directory
(inotify watches are not recursive). Even if we didn't hit the limit,
it would work only when Inkscape is running, and would not prevent
breaking documents when sending them to someone else.

Regards, Krzysztof

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alexandre Prokoudine]

On 10/24/09, Steren wrote:
> That is because Songbird consider the metadata of your files, not the name
> of the file.
> Moreover, Songbird is "watching" a particular folder. If you move this
> folder completely ouside of the watched folder, there will be a problem.
>
> But please, can we be a little less ambitious and refocus on a solution that
> wouldn't require a change in all major filesystems ?

...and start with user scenarios like most everybody else? :)

Like, for example, how exactly users edit an embedded bitmap file in
GIMP/Krita/mtPaint/etc.

Alexandre

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel