> 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. _______________________________________________ evolution-list mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-list
