Gräßlin: Next Generation Klipper [LWN.net]

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 0:07 UTC (Sat) by roblucid (guest, #48964) [Link]

Well it'd be confusing to have a redundant choice of what you paste and be able to ignore an accidental selection, when you can simply go back and find that place that you wanted to copy again.

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 1:34 UTC (Sat) by bokr (guest, #58369) [Link] (17 responses)

I would suggest making the representation of clipboard items
independent of KDE and X (or Wayland), and simply put the
items into a directory as files, e.g. in directory ~/.klipper.d or such,
and name them with a user-chosen optional name, made unique any way you
like.

Then keep a single file , e.g. ~/.klipper.d/index.csv logging the above
files one line at a time as csv with helpful metadata. This can then serve
to represent the state of the clipboard, and you can easily manipulate
it as a stack or sliceable list etc using python or bash or whatever,
and you can rsync or ftp or make a tarball out of ~/.klipper.d and
attach it to an email.

With a simple low level self-contained state representation,
you enable an open tool evolution process, and make sharing easier.

I have used xclip to get script access to the X clipboard, but it requires
X running. I would suggest making klipper runnable by another name from the
user command line, so that piping something to it appends the item, and
running it without args writes the last item to stdout. If you named it
stack, an interaction could go like:

[02:53 ~]$ /usr/games/fortune |& stack
[02:53 ~]$ stack
When a fly lands on the ceiling, does it do a half roll or a half
loop?
[02:53 ~]$ /usr/games/fortune |& stack
[02:54 ~]$ stack
A bird in the hand is worth what it will bring.
[02:54 ~]$ stack -pop
A bird in the hand is worth what it will bring.
[02:54 ~]$ stack -pop
When a fly lands on the ceiling, does it do a half roll or a half
loop?

It should sense its conditions and work under both GUI and console
or xterm etc. Add useful command options like -pop to taste.

Note that you can then run vim or gvim and do :r!stack -pop
for example. Or select some text and use :!stack to pipe the
selection to stack as if it were a filter like sort or uniq,
then use u (undo) to restore the selection.

Also, on the klipper menu there should be an option
to select pipe output or input from an arbitrary command for copying
from or to the clipboard state. This lets klipper do what vim can do
with :r! and :! and opens up a lot of scripted possibilities.

Sharing data via clipboard should not be within walled gardens only.

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 4:08 UTC (Sat) by roskegg (subscriber, #105) [Link] (2 responses)

Good suggestions. That sounds closer to the proper Unix way to do things. Maybe even THE proper Unix Way. I hope KDE gives your plan serious thought. What is up with all these young coders pissing on "The Unix Philosophy" by Mike Goncarz, as if it went out of date?

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 9:13 UTC (Sat) by roblucid (guest, #48964) [Link] (1 responses)

Klipper's worked really well since KDE1 days, it needs to operate invisibly for a smooth UI experience and NOT add any latency or delays, to copy/paste operations. Being memory based, with load/store across login's meets the requirement.

I actually used ed(1), at times when booting off tape and adjusting BSD kernel config during the install process.

ed(1) DID not split your text file up line by line, into seperate files but used a data structure in memory, and klipper which makes persistent what is already highlighted and stored, ought to take the same approach, as that IS the true UNIX way, doing 1 simple job and doing it well, getting out of the user's way, rather than generating a whole load of crappy temporary files. This is why McIlroy's idea of pipes is so superior to FS based alternatives.

Gräßlin: Next Generation Klipper

Posted Jul 6, 2014 4:32 UTC (Sun) by roskegg (subscriber, #105) [Link]

That sounds interesting. Can you explain in more detail?

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 17:20 UTC (Sat) by barryascott (subscriber, #80640) [Link] (13 responses)

The problem with using files is that items like paswords go into the clipboard.
I for one do not want them persisted to disk.

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 20:15 UTC (Sat) by arekm (guest, #4846) [Link] (7 responses)

Would be nice if clipper was able to figure out that something is a password and then keep it only for configured time, like 2 minutes.

(so passwords won't be there for days if someone selects rarely or set clipper app to remember big number of entries)

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 20:23 UTC (Sat) by juliank (guest, #45896) [Link] (6 responses)

I thought this was about clipboard? Why do you have passwords there?

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 22:18 UTC (Sat) by roblucid (guest, #48964) [Link] (2 responses)

You generate a password in some way that's unique for one of those websites you rarely visit or comment at, then want to paste it into those boxes, that try and make you type it twice.

Gräßlin: Next Generation Klipper

Posted Jul 6, 2014 23:55 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

Perfect use case for the mouse selection buffer ;) .

Gräßlin: Next Generation Klipper

Posted Jul 10, 2014 8:40 UTC (Thu) by roblucid (guest, #48964) [Link]

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

Posted Jul 7, 2014 21:04 UTC (Mon) by zlynx (guest, #2285) [Link] (2 responses)

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

Posted Jul 7, 2014 21:25 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

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

Posted Jul 7, 2014 22:21 UTC (Mon) by zlynx (guest, #2285) [Link]

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

Posted Jul 9, 2014 19:07 UTC (Wed) by Wol (subscriber, #4433) [Link] (4 responses)

> 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

Posted Jul 9, 2014 19:08 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

tmpfs is swappable.

Gräßlin: Next Generation Klipper

Posted Jul 10, 2014 8:45 UTC (Thu) by roblucid (guest, #48964) [Link] (2 responses)

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

Posted Jul 10, 2014 10:58 UTC (Thu) by JGR (subscriber, #93631) [Link] (1 responses)

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

Posted Jul 17, 2014 16:47 UTC (Thu) by ssokolow (guest, #94568) [Link]

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

Posted Jul 5, 2014 2:31 UTC (Sat) by atai (subscriber, #10977) [Link]

GNOME has gclip_select

https://mail.gnome.org/archives/gnome-announce-list/2013-...

Gräßlin: Next Generation Klipper

Posted Jul 5, 2014 16:45 UTC (Sat) by Richard_J_Neill (subscriber, #23093) [Link] (25 responses)

Under Gnome and other Desktop environments, use parcellite
(or xfce4-clipman). It just works, since the system-tray is a common interface for all modern desktops.
(Personally, I like to bind Ctrl-Alt-V to be "pop up next to mouse cursor")

In general, you have 2 clipboard buffers, and you can choose to merge them or not. xclip lets you copy from clipboard to cli and back. HTH.

Gräßlin: Next Generation Klipper

Posted Jul 6, 2014 16:32 UTC (Sun) by drag (guest, #31333) [Link] (24 responses)

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

Posted Jul 6, 2014 18:33 UTC (Sun) by efitton (guest, #93063) [Link] (23 responses)

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

Posted Jul 6, 2014 23:51 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

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

Posted Jul 8, 2014 10:02 UTC (Tue) by cortana (subscriber, #24596) [Link] (11 responses)

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

Posted Jul 8, 2014 18:43 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

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

Posted Jul 8, 2014 20:24 UTC (Tue) by madscientist (subscriber, #16861) [Link] (8 responses)

> 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

Posted Jul 8, 2014 21:51 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

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

Posted Jul 9, 2014 0:01 UTC (Wed) by jake (editor, #205) [Link] (6 responses)

> 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

Posted Jul 9, 2014 0:15 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

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

Posted Jul 9, 2014 4:16 UTC (Wed) by bronson (subscriber, #4806) [Link] (3 responses)

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

Posted Jul 9, 2014 4:34 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> 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

Posted Jul 9, 2014 19:10 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

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

Posted Jul 10, 2014 8:30 UTC (Thu) by roblucid (guest, #48964) [Link]

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

Posted Jul 9, 2014 11:54 UTC (Wed) by etienne (guest, #25256) [Link]

> 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

Posted Jul 9, 2014 11:53 UTC (Wed) by cortana (subscriber, #24596) [Link]

> 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

Posted Jul 7, 2014 11:21 UTC (Mon) by roblucid (guest, #48964) [Link] (2 responses)

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

Posted Jul 7, 2014 13:54 UTC (Mon) by efitton (guest, #93063) [Link] (1 responses)

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

Gräßlin: Next Generation Klipper

Posted Jul 8, 2014 15:54 UTC (Tue) by roblucid (guest, #48964) [Link]

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

Posted Jul 7, 2014 15:27 UTC (Mon) by drag (guest, #31333) [Link] (6 responses)

> 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

Posted Jul 7, 2014 16:23 UTC (Mon) by efitton (guest, #93063) [Link] (1 responses)

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

Posted Jul 7, 2014 16:35 UTC (Mon) by mgraesslin (guest, #78959) [Link]

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

Posted Jul 8, 2014 16:03 UTC (Tue) by roblucid (guest, #48964) [Link] (2 responses)

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

Posted Jul 9, 2014 19:15 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

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

Posted Jul 9, 2014 20:09 UTC (Wed) by dlang (guest, #313) [Link]

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

Posted Jul 8, 2014 16:07 UTC (Tue) by roblucid (guest, #48964) [Link]

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

Posted Jul 6, 2014 16:30 UTC (Sun) by drag (guest, #31333) [Link]

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

Posted Jul 8, 2014 7:14 UTC (Tue) by lkundrak (subscriber, #43452) [Link] (1 responses)

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

Posted Jul 8, 2014 16:09 UTC (Tue) by roblucid (guest, #48964) [Link]

Yes, Glipper worked pretty well