That is the crux of the matter. You're missing out on these "big picture" issues.
(Oh, and another somewhat recent one where the user not only expects the linking, but dislikes the details of where linked things are https://bugs.launchpad.net/inkscape/+bug/441179 )
This is about the initial path where the import dialog opens, not
about linking vs embedding, see above as well. Sorry but not convinced
in the slightest, try again.
Now my turn. These bugs are closely related to linking by default.
https://bugs.launchpad.net/inkscape/+bug/167026 (Images not
transmitted over Inkboard, because they are links to files that don't
exist on the other side; Inkboard doesn't work any more, but it's
still related)
Nope. Not a blocker. In fact, that is easily addressed by correcting behavior and *keeping*linking. In fact, it will make things easier since you won't have as much bloat being sent over the wire at runtime.
Yes, this is a very good use case (did you make sure it's covered in the wiki). But no, it does not prove embedding is the only solution. This only proves that this use case needs to be explicitly addressed.
In fact, if you have some users with Inkboard and several common images, it creates a *far* more usable experience if Inkscape does not exchange any bytes for those shared images. As I look over this, it actually strengthens my opinion that we need to support "linking *plus* media management".
Guess what? This one actually cries out *explicitly* for proper linked media management. As the user requests in that report:
"... simple right click on a "broken image" and then be able to update the path for all the images
that are in selection?"
I believe that is exactly what I pointed out would solve use cases you added initially. This appears to be the "Sara" use case, and would be solved by the "Sara" solution.
https://bugs.launchpad.net/inkscape/+bug/415374 (User uploaded an SVG
with image links to a website, surprised by broken images. Read the
first comment, because the reporter misuses the word "embedded".
Apparently linking by default is sometimes confusing even in the Web
context!)
Nope. Not a blocker either.
*IF* you had done a scan of bugs with the "big picture" in mind, you would see that related issues come up with an *unsaved* document not having a fixed location. We need to address that issue overall and then guess what? This bug can get fixed by a different bug getting fixed. Kill two birds with one stone.
IMPORTANT: The third bug highlights why your proposed / existing
solution to pasting pixel data by storing a pasted image in the
document's folder is completely wrong. If the document wasn't saved
yet, there is no such folder! We end up saving to some arbitrary
location, which is completely unexpected.
But... we are doing that somewhat already. I have looked into the scenario a lot, and there are many things we can do to improve user experience.
The *KEY* here is that we have several interacting issues, and we want to solve the overall experience. We don't want to break one thing here to fix another thing over there.
I acknowledge that bug reports only highlight problems with the
existing implementation, and do not highlight problems with the
proposed changes, so you are at a disadvantage.
No, it is neither bulletproof nor idiot-proof.
How? How in the world is it possible to break an embedded image?
(Provide an example.)
I have. Since you don't care to actually address that, it is clear you really are more interested in arguing rather than in fixing.
***PLEASE***
** Update the wiki with use cases and personas
** Come into the chat room like the other developers
Both of these can significantly improve communication and help solve problems.
We also need to consider the worst severity event for each solution. I
cannot imagine a situation where temporarily not being able to edit an
image externally (the embedded image can be extracted) is more serious
than not having it at all, because somebody did not know to send it.
Very good points. Did you include them on the Wiki yet???
The first situation happens when the user still has full access to all
data, so fixing the "problem" is as simple as finding the link option.
In the second situation the user is missing a piece of data and fixing
the problem is impossible without contacting the sender of the broken
document.
Again, I distill a key point for the requirements here. "Must solve the problem will full access to data is available"
Please make sure that is covered in the wiki.
Embedding by default might not be completely problem-free, but at
least it does not create problems that cannot be addressed within the
application (missing data). I acknowledge that no solution is
completely idiot-proof, just as there is no absolute safety or
absolute security, but some solutions are more resistant to
inexperience than others.
A simple fix that addresses this includes what others have proposed. The first time a potentially confusing situation is encountered we just notify the user so that it won't be a surprise. Simple users can choose their most helpful setting, but non-simple users can get the more beneficial one. Also we should include the "don't show me this again" option that is so common in many programs.
Did you ensure this has made it's way onto the wiki?
Have you tried?
Yes, I did it to examine how an embedded image's XML looks like. Maybe
it wasn't lightning fast, but gedit handled it OK. That was on a
1.1GHz computer with 1GB of RAM, so not a powerhorse by any measure.
Digression: the aforementioned average Joe who will use the default
will never open the file in a text editor! Anyone who wants to hand
edit his document will have no problem overriding the default and
creating links.
Ah, but then we have the problem you've already pointed out. User A create artwork and hands it off to user B. User B then suffers the pain.
That is a "meta problem" describing several you've seen and pointed out already, but it applies equally well in this case.
Personally I've had problems trying to edit files with embedded data using emacs and others. Some have gotten so bad as to make emacs unusable on them. (That's quite a feat BTW)
Also, you mention the system you tried to edit on, but what about the size and number of embedded images? We will need to collect up info on ranges so that we can set proper cutoffs or warnings, much like we had to do with our preview dialog. And just like with the preview dialog, if we don't have good details on how certain values are chosen, we will see problems as we go and things change.