Re: [Evolution] Strange behaviour of Ctrl-V

[Nick Jenkins <nickpj gmail com>]

> In the normal text area, I maintain that it should
> paste the URL, especially when the composer is in plain-text mode

I think we agree 100% on the desired outcome in this case. I absolutely
want it to paste the URL in this use-case too, and I consider the
current behaviour to be a bug, no question whatsoever about that. But
crucially, it is a bug in Chromium, not in Evo. If I have a file copied
via a file manager, I (and also I believe other users) think it should
paste the file as an attachment. In order to do this, Evolution must
look at the available types for pasted data, and do something based on
that. The problem is that Chromium is setting the wrong data type, as
demonstrated by the exact same problem occurring in Open Office.
Therefore Chromium should set the right data type, thus fixing the root
cause, and the problem will be fixed.

> Someone in the thread did make a reference to Outlook's behaviour as
> the expected one (or perhaps it was on the long BZ exchange, I
> forget).

That was probably me, I migrated from Outlook to Evo in September 2008,
but I think it's the right behaviour based on fundamental reasons
(outlined below). I.e. the causation chain is: Fundamental beliefs about
usability of desktop apps -> Observe Evo's previous behaviour ->
disagree with it because of violation of usability beliefs -> File bug
-> include Outlook as real-world example of email app with
attachment-pasting behaviour.

The causation chain is not: Observe what Outlook does -> Observe what
Evo does -> File bug against Evo. Where's the motivation in that? If I
felt that way, I literally would not be able to summon the motivation to
log a bug, because I just wouldn't care.

> However the
> "Microsoft Way" is viewed by many people as the "Right Way" simply by
> default and without rational argument. That's what I want to resist.

I agree, and if I felt that it was the "Right Way" then clearly I would
still be using Windows & Outlook. I'm not, ergo, I don't feel that way.

Equally though, it's a fact that there are things that Outlook (and
Thunderbird, and Kmail, and gmail, and so forth) do right, and it's also
a fact that there are things that they do wrong. Let's learn what we can
from both categories, from the widest pool of relevant apps, and then
use that information to help make the best app, succumbing to neither
the "that's how Outlook does it" nor the "Not Invented Here" syndrome.

> > Ah. But the thing is, if you go to a file browser (like nautilus),
> > select a file, and press Ctrl-C, then go to a compose window and
> > press Ctrl-V, what behavior would you expect?
>
> I would expect the URI of the file (which is what I get when I paste
> it in a Shell command line for example).

I respectfully disagree. I think the app should do the best thing that
it can with the data it gets. In the case of a terminal window, the
_only_ thing it can do is paste the URI, so that's what it does. But
Evo, OpenOffice, and other apps, will _frequently_ have a choice of what
they can do with pasted data, and they should each do the best thing
that they can, and that's what they now try to do.

Most likely you are a highly advanced user, who has adapted to &
internalised the previous less-than-optimal URI pasting behaviour.
That's fully understandable, but it does not follow from that that the
previous less-than-optimal behaviour was better.

Surely this should be the canonical test if you're making software that
adheres to the principle of least surprise: If you take a person off the
street, an average person, if it helps maybe imagine a parent or a
neighbour, who has no personal interest in software (which immediately
excludes pretty much everyone on this list), and to that person, you
show them copying a file, and pasting it into Evo, and then before you
show them the results, you ask them what they you expect is going to
happen, do you think they will say:
a) It might add the file in some way to the email?
b) It might paste some text that says something like: "file://smb:\
\redux/home/nickj/bin/iview/gavinandstacey_10_02_03.mp4"?

I mean, seriously? Is this even really a question?

Additionally, we do not live in a world where everything can be
expressed as text. Here are some further questions that I would like to
pose for plain text emails:
* If a user copies an image's content in GIMP (i.e. the image data, NOT
the file), and pastes it into Evo, what do you expect to happen? An
image attachment for the copied section, or some ASCII art
representation of the copied data?
* If a user copies a section of audio data from an audio editor, and
pastes it into Evo, what do you expect to happen?

That's for plain text. But we've barely even gotten started yet! Now
let's make it more complicated. Now we have an HTML email, so we now
have 3 choices of what to do with pasted data: paste as text, add as
attachment, or paste as HTML.

* A user copies some spreadsheet cells, and pastes into Evo. This data
can be represented as text (either text version of the cells, or perhaps
text version of the file's path, assuming it has been saved), it can be
an attachment (as an image of the cells, or perhaps as a file if the
spreadsheet has been saved), or it can be pasted as HTML. What should
happen?

This is absolutely a non-trivial topic. There is essentially a matrix of
possible pasted data types, versus possible actions, and those actions
are slightly different for HTML and plain text modes.

My personal guiding belief is that for a desktop app, the app should do
the best thing it can with pasted data (based on the data types
specified by the data source), and that the test of best is the least
surprising thing, as defined by what an average person might reasonably
expect. That is the reason why I think Chromium's URL text should paste
as a text URL but that Chromium needs to set the right data type to make
this happen, that is the reason why I think pasted files should be
attachments, and that is the reason why I think pasted spreadsheet cells
should be pasted as HTML when in HTML mode or as text when in plain text
mode. Do the best you can with what you've got.

Anyway, that's my 2 cents :-)

-- All the best,
Nick.