mmb pasting in Konqueror

Luis Pedro Coelho luis_pedro at netcabo.pt
Sat May 17 13:49:12 BST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just voted for this in bugs.kde.org. I have seen it annoy people and it has 
annoyed me sometimes (read below).

> (1)
> > mmb click loading the URL in the clipboard or searching for a non-URL
> > string in the clipboard is non-obvious and unintuitive
>
> Wrong, it's fully consistent with the globally standardized "mmb click" ==
> "clipboard paste" behavior.

- From the bug discussion:
«
 mmb has two different functions in konqi: 
 1) pasting stuff 
 2) opening a link in a new tab/window 
 
 actually it has three quite different uses: 
 1 a) pasting a URL/search-string 
 1 b) pasting text in a form 
 2) opening a link 
»

I would go further: it has four different uses:
 1 a1) pasting a URL
 1 a2) pasting a search-string - which is any thing, actually
 1 b) pasting text in a form 
 2) opening a link 

For me, it is 1a2 which is utterly confusing. I often scroll the text by 
selecting it and going down (on a laptop this is actually the most 
confortable way for me). Then, if i mmb-click to open a link on a new tab and 
fail (again not that impossible in a laptop), I get a search in google for a 
whole paragraph. It took me a while to understand what was going on.

The others, I think are quite understandable. Even if 1a1 is mostly already 
provided by the "monitor your clipboard for URLs and popup a menu if you see 
them" klipper functionality. Still, I would say it make some sense to 
reproduce here as well.

> (3)
>
> > the content of the clipboard might be sensitive data: a password or a
> > credit card number.
>
> While any action by the user should be considered a conscious action I
> agree that at that point a dialog window should appear warning you that you
> are about to send possibly sensitive data into the internet, just like done
> with unencrypted data transfers. This would also be a chance firstly for
> the user to cancel that action and secondly for educating him about that
> particular behavior. (Btw: passwords cannot easily be copied anyway unless
> they're readable as clear text already which alone is already a security
> issue.)

Not, it is not alone already a security issue.
At least not as grave as sending it over the net to google. If I work on my 
computer in my house then this plaintext security issue is mostly mute - if 
you can come into my house and fire up my computer and search for the file 
where i have my credit card number in plain text, why didn't you just check 
my wallet?
While sending it over the net in plaintext can be easilly picked up.

> (5)
>
> > a user might try to mmb click on a link to open it in a new window/tab
> > and misclick invoking a mmb paste instead
>
> Again first and foremost we need to consider that by this the user actually
> might have done a conscious action, so this shouldn't be changed using some
> "intelligent" software behavior, nor will removing the mmb paste feature in
> this particular case change the fact that a misclick is a misclick.

There is a fine line between software which is broken because it is so error 
prone and software which is well-designed but misused. 
Here, I would say it is broken.

> (6)
>
> > when scrolling with the scroll wheel it's surprisingly easy on some
> > mouses to accidentally middle-click while scrolling
>
> This is, excuse me, a completely bs and preposterous reason to remove a
> feature. This is clearly a hardware problem if it's indeed the case. Since
> when is software used to work around hardware problems? And how do we
> detect whether a click was a conscious action or an accidental click,
> possibily due to a hardware error or hardware design fault? It's simply
> nonsense to try to fix broken hardware with software workarounds.

Most wheel-mouses I have seen work like this.

I don't normally use one, but at school we have those. The system (for all 
students) is linux based and I normally use konqueror as a browser. It is 
really difficult to use the wheel mouse without accidently clicking on 
something with the mmb - and I have healthy hands.
If you think that these wheel-mouses are broken, then almost all of them are 
because I have never seen one which doesn't work like this. Probably you can 
get around it by remapping buttons or something, but that's not an elegant 
solution either. They were designed with another model for the mmb (the 
Windows model) in mind, where it makes a lot of sense that wheel and 3rd 
mouse are connected. The fact that they are pervasive is something we must 
deal with, though.

> (8)
>
> > user wants to paste some text into a field box on a html page but misses
> > the edge of the box
>
> Again a case of misclick, just like (5). My suggestion: Optionally allow
> mmb url paste to be opened in a new tab/window (and make that the default).


I agreee that this would have advantages: easier to undo :) It wouldn't be 
destructive and it would be invokative of mmb-click = open in new window/tab.

> For me mmb paste is Konqueror's most outstanding feature and the case where
> mmb paste is used most times. Nothing rocks more than selecting a text-only
> URL and loading it using mmb as well as selecting terms and searching for
> them right away. Simply taking it away completely as default would be a
> huge disappointment for me (and surely others as well).

Then, make it configurable and let's talk about something else, like what the 
default should be ;)

I would say off in the principle of least surprise.

Regards,
- -- 
Luis Pedro Coelho

check out my game of hearts for the KDE at

http://hearts.sf.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+xi/lGpBAvyRwXdgRAp6xAKCsvVhkjJAGjx8Koe5bIqHwik/POQCaAx/c
Tr10ZwpLRGvUqCF6D5EYBfY=
=r9pk
-----END PGP SIGNATURE-----




More information about the kfm-devel mailing list