LWN: Comments on "Gräßlin: Next Generation Klipper"

Gräßlin: Next Generation Klipper

ssokolow — Thu, 17 Jul 2014 16:47:14 +0000

Still, why not just gather a bunch of people from various desktops together and and cook up some FreeDesktop.org D-Bus standard along the lines of MPRIS?

Gräßlin: Next Generation Klipper

roblucid — Thu, 10 Jul 2014 18:24:11 +0000

Hmmm, interesting idea .. but ... Klipper promises the user to keep last N items. A solution keeping history which is just garbage collected periodically doesn't necessarily forget the things when expected. Nor would Klipper have a way to reconstruct the information it IS meant to hold, unless it did the ghastly file storage thing, which likely increases memory use through buffer copying.

The article is nice, I didn't discover the search keyword feature by typing into context menu, yet now I know I have it already :)

So may be, volatile ranges could be applicable for a searchable "archive", say "current" items and "wastebin". I just have a hard time convincing myself, I'd use the feature enough to make it worth loading it's code into memory, or implementing.

Are there volatile range implementations yet, for user space system caches, or front end caches to indexed data/value files? Things like nscd(8), gdbm?

They might be a hard sell to the typical application as handling async signals correctly can be messy, especially if you have multi-threaded code.

Gräßlin: Next Generation Klipper

JGR — Thu, 10 Jul 2014 10:58:45 +0000

Hopefully, the functionality to handle these hypothetical files would be encapsulated in a library/small number of libraries.
It should not be necessary to have to update the applications themselves, only the library that they're linked against, which scales better than every application rolling their own parser/etc.

Gräßlin: Next Generation Klipper

roblucid — Thu, 10 Jul 2014 08:45:05 +0000

Why would you want to communicate via files, which each application needs to understand, rather than use an IPC based solution which the Desktop frameworks define and provide in their library?

What if you later, needed to change your file design for some reason. Modifying every application ever written that uses the buffer scheme, doesn't scale.

Gräßlin: Next Generation Klipper

roblucid — Thu, 10 Jul 2014 08:40:42 +0000

Yes, and I actually use it that way where I can, but I find clipboard still useful. Storing the username (often complicated and obscure) in clipboard, then select only for generated pass, lets you move windows once rather than go back and forth.

Secondly Firefox password management, on certain websites which expose multiple domain names need to search in list. That lets you copy user/pass into paste buffers, great, but if you only have 1 without the clipboard you have to go back to get the second, which is awkward and wastes time as the security pass dialog blocks the data entry in other tab.

Gräßlin: Next Generation Klipper

roblucid — Thu, 10 Jul 2014 08:30:16 +0000

That's what 'undo' is for and in KDE you can EITHER middle paste or right click context menu paste, if you don't like shortcuts. IIRC that was in Motif and maybe even in Sun Tools and Sun Openview.

Gräßlin: Next Generation Klipper

dlang — Wed, 09 Jul 2014 20:09:38 +0000

most distros set things up so that hitting both mouse buttons at once is middle-mouse (and how well it works varies by the mounse, for some it works well, for others it doesn't)

Gräßlin: Next Generation Klipper

Wol — Wed, 09 Jul 2014 19:15:52 +0000

Even today, there are users who *don't* *have* a middle mouse button ... my not-that-old laptop for example! I know it can supposedly do a "middle mouse" but with no manual I don't have a clue.

Cheers,
Wol

Gräßlin: Next Generation Klipper

Wol — Wed, 09 Jul 2014 19:10:36 +0000

My problem with ctrl-c ctrl-v is I've only got to make a typo and it really screws things up.

I'd much prefer a working select-middleclickpaste to the mess that these control keys cause me ...

Cheers,
Wol

Gräßlin: Next Generation Klipper

mjg59 — Wed, 09 Jul 2014 19:08:30 +0000

tmpfs is swappable.

Gräßlin: Next Generation Klipper

Wol — Wed, 09 Jul 2014 19:07:16 +0000

> I for one do not want them persisted to disk.

Can't it create a tmpfs mount in a standard place? If the directory doesn't exist, the first app to use the clipboard creates it so all the other apps can find it.

Then when the user logs out (hopefully that's the way it'll work) the mount disappears.

Cheers,
Wol

Gräßlin: Next Generation Klipper

etienne — Wed, 09 Jul 2014 11:54:06 +0000

> in what situations select-copy makes sense

IHMO select-copy is a lower layer copy&paste, i.e. basically you only select text and the result of pasting is exactly the same as if you had pressed all the same keys. If you select a TAB character you get what a TAB does at paste time. I would even say if you select Control-A you get the result of typing Control-A. If you select few words in a word processor you get those words at paste time with the current font, background color, ... as if you did type those keys.

The upper layer copy&paste copies at a high level, can manage paragraphs with their font and formatting, can copy images and even convert in between format, remember that you did cut a WEB link and do something intelligent when you paste...

I think both are useful - they are different concepts.

Gräßlin: Next Generation Klipper

cortana — Wed, 09 Jul 2014 11:53:00 +0000

> I can't pretend it doesn't exist.

Why is this--the badly written software(which?), or are you accidentally pressing the middle mouse button resulting in unwanted pastes from PRIMARY?

Gräßlin: Next Generation Klipper

Cyberax — Wed, 09 Jul 2014 04:34:08 +0000

> The situation seems clear, no? Moving a ton of small text selections between two windows. Select-Paste-Select-Paste is much faster than Select-Control-C-click-Control-V-Click-Select-Control-C-Click-Control-V.
Back in my Windows days, I used Far Manager everywhere and almost NEVER touched a mouse. So this scenario was: keyboard-select-ctrl-c alt-tab ctrl-v. I could do it much faster than with a mouse.

I guess that you can contrive some scenario where middle-paste is useful, but should we invent a whole new mechanism for it? Really?

Gräßlin: Next Generation Klipper

bronson — Wed, 09 Jul 2014 04:16:00 +0000

The situation seems clear, no? Moving a ton of small text selections between two windows. Select-Paste-Select-Paste is much faster than Select-Control-C-click-Control-V-Click-Select-Control-C-Click-Control-V.

So Gnome 3 drove my consulting onto Macs too... I still miss focus-follows-mouse and good window/workspace management. But select-copy and middle-click paste? Nope, not one bit. Turns out I'd rather have a simple clipboard that works 100% of the time than a quicker one that developers can't quite agree on.

I guess drag and I agree on something after all!

Gräßlin: Next Generation Klipper

Cyberax — Wed, 09 Jul 2014 00:15:33 +0000

I know somebody who is still using an Amiga. It worked for him for decades, after all.

For others it would be nice to think where and in what situations select-copy makes sense. And perhaps develop something less-broken.

Gräßlin: Next Generation Klipper

jake — Wed, 09 Jul 2014 00:01:51 +0000

> In short - there must be one CONSISTENT mechanism for cut&paste and
> it must ALWAYS work.
> [ ... ]

Boy am I glad I don't live in a world where you rule. Sorry you don't like middle-click paste of the selection copy, but it works for *lots* of us, in *lots* of applications, and it has for *decades* -- perhaps you could just leave us all alone. Evidently there are systems where it is implemented to your satisfaction ... enjoy ...

thanks!

jake

Gräßlin: Next Generation Klipper

Cyberax — Tue, 08 Jul 2014 21:51:13 +0000

This topic has been already flamed to a crisp.

In short - there must be one CONSISTENT mechanism for cut&paste and it must ALWAYS work. Selection copy can never be consistent and in most cases is useless (with selection in an X-terminal being about the only exception).

So it must go, or at least be made a truly optional thing. So optional that only hard-headed cases ever turn it on.

Gräßlin: Next Generation Klipper

madscientist — Tue, 08 Jul 2014 20:24:38 +0000

> I stopped using badly written programs by switching to Mac OS X

Fantastic! A solution that works well for you. So why are you here trying to convince us that the solution that we prefer is wrong, if only we were smart enough to see it?

95% of my cut/paste action deals with plain ASCII text and all the apps I use correctly handle standard X selections. There's no amount of control key/popup menu voodoo that will allow me to be more productive than standard X selection (I include here increasing/decreasing the current selection using mouse-3) and mouse-2 paste.

Maybe your needs are different and that doesn't work for you: in that case I'm happy you've found your nirvana. Please stop trying to pee on ours.

Gräßlin: Next Generation Klipper

Cyberax — Tue, 08 Jul 2014 18:43:32 +0000

I can't pretend it doesn't exist. And I stopped using badly written programs by switching to Mac OS X. It's a really nice solution - no more "two clipboards" problem or inconsistent cut&paste keys.

Gräßlin: Next Generation Klipper

roblucid — Tue, 08 Jul 2014 16:09:32 +0000

Yes, Glipper worked pretty well

Gräßlin: Next Generation Klipper

roblucid — Tue, 08 Jul 2014 16:07:29 +0000

Actually, I do remember how clumsy Mozilla used to be, partly due to bloat, but there was an impedance mismmatch between KDE and GTK based Mozilla.

Running a distro KDE integrated flavour of FF, is far more enjoyable.

Gräßlin: Next Generation Klipper

roblucid — Tue, 08 Jul 2014 16:03:36 +0000

Hey, it's useful! I set clipboard filling with cntrl-c/context menu copy, and have selections pasteable ONLY by highlighting. If you think it's bad design because X doesn't give end user an obviouus way to turn off middle button paste, then OK, otherwise I don't get your point at all.

IMO the bad thing with X, was the lack of a basic run through tutorial, so what's happening on select, middle mouse button is clear. Most end users, don't even seem to realise they have a middle mouse button.

Gräßlin: Next Generation Klipper

roblucid — Tue, 08 Jul 2014 15:54:53 +0000

Right! Klipper is configurable with a default chosen with the less advanced end user in mind. Both paste bufffers being saved might annoy, too much churn, then you configure Klipper by check box to ignore 'selection'.

This kind of user preference change, is exactly kind of thing that let's you be "at home" or avoid undesirable behaviour like having pass/key info saved into a temporary file, but can complicate things for writers of HOWTOs and tutorials.

I really try and live with system defaults for quite a long while and adjust, before burning time on tweaking.

Gräßlin: Next Generation Klipper

cortana — Tue, 08 Jul 2014 10:02:42 +0000

1. Pretend it doesn't exit
2. Stop using badly written programs that operate on PRIMARY when you issue cut/copy/paste commands

The only program I run into these days that screws up the clipboard is Xchat.

Gräßlin: Next Generation Klipper

lkundrak — Tue, 08 Jul 2014 07:14:05 +0000

Years ago, I remember successfully using Klipper with GNOME.

There seem to be other alternatives too; Glipper or gpaste shell extension.

Gräßlin: Next Generation Klipper

zlynx — Mon, 07 Jul 2014 22:21:15 +0000

Yes.

Currently, the security is done by wiping the clipboard after pasting the password. However, if there is clipboard history being maintained I am not sure how that works.

Gräßlin: Next Generation Klipper

raven667 — Mon, 07 Jul 2014 21:25:37 +0000

As this is a common use case it seems that the clipboard manager has some security requirements to not leak clipboard contents in the clear.

Gräßlin: Next Generation Klipper

zlynx — Mon, 07 Jul 2014 21:04:42 +0000

My password manager program uses the clipboard to move passwords. Select the item, hit Ctrl-P and it copies the password.

Other options just won't work as well. A browser plugin only solves the problem for web sites.

So yes, the clipboard often has passwords in it.

Gräßlin: Next Generation Klipper

mgraesslin — Mon, 07 Jul 2014 16:35:19 +0000

I'm a heavy user of the middle-click to paste feature. Features I use will be supported in Plasma -)

Gräßlin: Next Generation Klipper

efitton — Mon, 07 Jul 2014 16:23:36 +0000

Then have it optional in Wayland, but lots stop with the thinking that we have to protect the user and deciding what features to which the user should have access.

Gräßlin: Next Generation Klipper

drag — Mon, 07 Jul 2014 15:27:49 +0000

> Having two clipboards is powerful, useful and easy.

It's just a artifact of extremely bad historical design choices in X.

It wouldn't be so bad except for the fact that a huge number of X applications get copy and paste so incredibly wrong. I still have problems with trying to copy and paste URLs in and out of Firefox's navigation bar.

And, no, you can't really turn it off. It's part of X.

Gräßlin: Next Generation Klipper

efitton — Mon, 07 Jul 2014 13:54:59 +0000

And absolutely no reason that you can't have _both_.

Gräßlin: Next Generation Klipper

roblucid — Mon, 07 Jul 2014 11:21:21 +0000

Klipper's more powerful and more intuitive, than the highlight/middle mouse select/paste context menu seperation, it makes more sense to the unschooled user. It's more discoverable as you can actually see what adds contents to the clipboard.

Gräßlin: Next Generation Klipper

mathstuf — Sun, 06 Jul 2014 23:55:46 +0000

Perfect use case for the mouse selection buffer ;) .

Gräßlin: Next Generation Klipper

Cyberax — Sun, 06 Jul 2014 23:51:43 +0000

How can I turn off X's selection buffer? I haven't found a solution that works (short of patching X's source code directly).

Gräßlin: Next Generation Klipper

efitton — Sun, 06 Jul 2014 18:33:42 +0000

And I hope not. Having two clipboards is powerful, useful and easy. You are more than welcome to turn them off but I would thank you to not impose a more limited environment on me.

My limited understanding is that the clipboards are now managed at the widget level, not with X. If GTK+ does away with the second clipboard I am guessing we will see that forked as well.

Gräßlin: Next Generation Klipper

drag — Sun, 06 Jul 2014 16:32:03 +0000

The 'two clipboard buffer' thing is terrible. I hope they get rid of it completely in Wayland if at all possible.

Gräßlin: Next Generation Klipper

drag — Sun, 06 Jul 2014 16:30:35 +0000

Where does this come from?

In Gnome there is a clipboard manager built into the environment and I can get a list of past buffers by installing the gpaste integration extension.

Gräßlin: Next Generation Klipper

roskegg — Sun, 06 Jul 2014 04:32:58 +0000

That sounds interesting. Can you explain in more detail?