[Kde-accessibility] Re: mmb pasting in Konqueror

Roland Seuhs roland.seuhs at hasos.com
Sun May 18 01:56:04 BST 2003


Am Samstag, 17. Mai 2003 15:48 schrieb Datschge:

> That isn't exactly true either. What the users can see is that the location
> bar contains the formerly pasted and now progressed selection buffer. This
> is exactly the point where it becomes brutally obvious how fatal it
> actually is that the mmb is no longer used solely for pasting the selection
> buffer: If mmb paste were the only thing users can do with the mmb the
> whole behavior would be perfectly consistent and the user wouldn't even get
> the idea to mix it up with another behavior at all.

First, it's not consistent at all.

The browser window is a read-only area, just like the mail-view in kmail, the desktop or the window of kghostview.

Let's compare the behaviour of those:

- When I middle-click the desktop, a menu appears, it doen't paste anything, it also doesn't want to create an icon with the clipboard contents as name.
- When I middle-cklick the mail-view in kmail, nothing happens, it doesn't try to send a reply with the clipboard contents.
- When I middle-click the kghostview-window, it jumps to the next page, it doens't try to find pdf documents about whatever happens to be in the clipboard on Google.

For read-only areas, IMO, it is possible and a good idea when the middle mouse buttion is used for a very common task.

Sending whatever happens to be in the clipboard to Google is not a common task and destroys whatever is currently shown. And it's not consistent with traditional Unix-style copy-paste at all. Even if it were consistent, it would still be nonsense. Consistency doesn't legitimate stupidity, if the consistent behaviour is stupid, it shouldn't be there, especially if it is destructive and especially if huge ressources (in this case a valuable mouse button and a whole browser window) are wasted.

> But instead mmb click
> on link to open it in a new window/tab has been taken over from mozilla
> breaking this consistency leading to the current mess where we even get
> requests to introduce a mmb "internet style autoscroll" feature instead.

So?
I'm no fan of autoscroll, but it can't get any worse than the current behaviour.

> So yes, in this regard I'm in favor of removing "mmb click on link to open
> it in a new window/tab" (which is also as non-obvious and even less
> consistent) or move it to another button/key combo so the consistency of
> mmb paste doesn't get watered down any further.

[Rant written, then deleted]

Please:

1) Trying to display the clipboard is not consistent at all, especially for a read-only area.
2) I'm all for consistency, but sometimes it does pay off to actually use your creative powers and use a button for an inconsistent function if the consistent function is not possible, rarely used or complete nonsense (like sending the clipboard to Google).
Example: In Gimp, the middle mouse button is used to scroll the drawing area. The "consistent" function would be to paste a text into the picture with the font settings last used - But this function would be rarely used so (gasp):

IN THAT CASE THE INCONSISTENT BEHAVIOUR IS BETTER THAN THE CONSISTENT BEHAVIOUR.

> Or remove all traces of mmb paste usage so all non-*nix converts will be
> happy

I'm a very happy Unix user and I used Unix-style copy-paste for many years and it's one of the things I love about Unix. (Actually it's the reason why I even preferred the pretty crappy FVWM over any Windows or MacOS alternative)

Roland

-- 
Always remember that you are unique.  Just like everyone else.





More information about the kfm-devel mailing list