Clipboard for the dummies

Lubos Lunak l.lunak at suse.cz
Fri Nov 1 18:13:05 GMT 2002


On Friday 01 November 2002 17:57, Havoc Pennington wrote:
> Lubos Lunak <l.lunak at suse.cz> writes:
[snip]
>
> > - only text selected by the mouse becomes the selection (i.e. not text
> > selected by keyboard, or autoselected lineedits)
>
> Special-casing mouse selection seems questionable to me. Especially in
> light of accessibility concerns, when you remember that some users
> will only use the keyboard, or will use the keyboard primarily.

 Well, if I don't use the mouse, I can hardly MMB the selection.

> > - when there's no selected text, selection is still remembered (the last
> > valid selection) - this is why Qt lineedits unselect on focus out, while
> > Gtk ones don't
>
> This is fine I think.
>
> > - explicit actions like 'copy link location' set selection, even if
> > there's no text selected (I couldn't find any such action in any Gtk2 app
> > to test, Havoc?)
>
> Maybe Galeon2 has it, I don't know. As I said earlier, one idea here
> is to actually *draw* the highlight for the URL, i.e. it would become
> selected in a user-visible way when you choose this menu item.

 Strictly speaking, this wouldn't be consistent with the pure-X11 style, as 
the highlighted text wouldn't be the thing  pasted. The URL text may say 
'here' while the link may be 'http://here.org'.

>
> > Remember, it would be nice if we did it the same way like others do, so
> > we'd have to make at least Qt and Gtk work the same, in case we don't go
> > with the X11-pure style (Havoc: any chance?).
>
> There's certainly some chance. I would expect Owen to be fairly hard
> to convince that we should break the current X11 specs in a
> backward-incompatible way, but then you may well get supporting
> opinions from say the GNOME UI team. Also, GTK should certainly work
> like Windows when running on Windows, and I'm not sure it does right
> now, so it would make sense to have GTK at least optionally able to
> work like Windows.
>
> The important thing I think is to avoid making a unilateral decision
> here, since while either the current X11 specs or a new more
> Windows-like setup work fine if applied consistently, they are both
> pretty broken if half the apps do one and half the other. ;-)
> Users just complained *so much* about the situation in the past that I
> hate to recreate it.

 I don't think it's so consistent now (ok, this may be because I use mainly 
KDE apps, while GTK app are at least consistent with each other). E.g. the 
paper at freedesktop.org doesn't say a thing about how the selection should 
work from the user's point of view.

 I wonder if we could handle having an option selecting one of the two styles.

> If we go to a Windows-like setup, it seems to me that we basically
> have to break the MMB paste. You can imagine the flames this will
> inspire. While we can say "the last selection you made gets pasted by
> MMB" my feeling is that if you can typically see several highlighted
> selections on the screen, MMB becomes pretty hard to use.

 I don't think so, the most common usage of MMB is 'select something with 
mouse, with a small delay MMB elsewhere'. This would stay the same. And I 
find the rest of the changes reasonable and in fact improving the general 
situation. On the other hand I use Ctrl+C/V style more often than MMB, and my 
point of view may suffer from KDE's present and history of clipboard handling 
- and we also need to define _some_ consistent style, while Gtk already has 
it.

 I think it would be interesting to know the opinion of the GNOME usability 
team or whatever you call it. Could you please forward them the first mail in 
this thread, perhaps with short explanation, and see what they say? I first 
thought about asking on xdg@, but as I expect most people there being 
die-hard X11 users, I don't think they'd bother to evaluate it from the 
broader point of view. Maybe we should make a poll at dot.kde.org asking 
which of the four points should be true and which not >;).

> On the implementation side what Windows-style means is that we would
> probably have an X selection for each toplevel window. Maybe it could
> be called PRIMARY_<WindowID>. Considering the possibility of
> out-of-process components (and XEMBED), it should really be done via
> an externally-visible X selection rather than all in-toolkit
> in-process.
>

 No, no, no, even though it might be interesting to see having so many X atoms 
>;). The underlying system would remain completely the same. It's just about 
how it would work for the user. All the four diferencies from the pure-X11 
style I listed require only toolkit/app changes, no change in the system 
itself.

>
> The summary decision to be made I think:
>
>  - if we continue to conform to current X11 specs, that's certainly
>    easier. Most toolkits/apps are already close to conforming,
>    and people that have researched the issue already understand how
>    it's supposed to work. However, we get the funny global selection.
>
>  - if we go Windows-style, we get per-window selection, but most apps
>    are currently broken: Motif apps, Windows, GTK, XEmacs, almost
>    everything.  We would have to make a backward-incompatible spec
>    change and then convince the world that it was a good idea (after
>    we've already been trying to convince them for a while to do it the
>    traditional X11 way). Also, MMB paste becomes near-useless.
>
> Essentially, is moving to Windows-style selection important enough to
> endure a few years of transition period and quite a few flamewars?
> That's the question in my mind.

 Well, yes. I even wouldn't mind having it the pure-X11 style way. It's just 
that I find the other way slighly better, and now it's about if it would be 
worth it, or if it's worth having the option and having to code it for both 
styles.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/




More information about the kde-core-devel mailing list