Clipboard deamon?

[UbuWu]

Has the inclusion of a clipboard deamon in ubuntu ever been discussed? After installing breezy on a new partition I was quickly reminded of one of my greatest headaches when first using linux. I have this (http://members.chello.nl/~h.lai/gnome-clipboard-daemon/index.html) one installed, but I was wondering why it isn't in ubuntu by default. It is small and has been a real blessing to me :grin:

[sinbad782]

There's something about this type of thing in the tutorial on ubuntuguide.org - I'm not sure if it's the same clipboard daemon though. It would seem sensible to me to have this included by default..

PJS

[stoffe]

Just a "me too". :) I still get tripped by this on a regular basis and it would be really nice to have this included by default, if nothing else because it is a real stumper for people coming from other OS:es.

[shimon]

there are problems with it.... Like try copying a 500MB file... and also it goes all into your ram... I am thinking of something like this:'
When closing window send contants to daemon if bigger than max size allowed then dump it...

Also a black list for some extentions...

[UbuWu]

there are problems with it.... Like try copying a 500MB file...

Luckily 99,99% of all copy/paste's are not 500MB files. And if I am right that would not even be a problem if copying large files, only when copying large amounts of data from applications.

[tlepes]

Okay I am not a real programmer here (just a wannabe) so bear with me not really knowing how the clipboard interfaces work already... I am going to guess how the process works and where maybe intelligent design might come in...

Based on the behaviour we have now, I presume that the originating application keeps it's data local and just passes some sort of handle to the clipboard daemon letting it know there is data to be had. When the data is pasted, the receiving application uses the clipboard daemon or service or whatever to retireve the data, and the originating app is engaged to transfer the data via some call-back function conformant to the clipboard api, whatever that is. I suspect that the existing clipboard handlers don't actually ever touch the clip data but rather just broker the exchange between api compliant apps.

So to have a persistent clipboard, it seems you have to get the clipboard daemon to pull the data to itself as if it were the destination application, and hold it in memory until it is requested by another application. This way the source app can close if it wants to because the clipboard daemon keeps it's own copy of the data and becomes the source app.

Am I even close to the mark here so far?

This has two main problems... (1st) It is inefficient when a program is clipping and pasting within itself (the source and destination apps are the same app), and more importantly to this discussion it is (2nd) inefficient with regard to large data objects in that there is a duplication of the clip data in memory (one copy in the source app and one in the clip daemon). At the time of a paste (at least between apps), there could be three (or more) copies in memory... the original, that posted to the clip daemon, and the pasted copy(s) in the destination app(s).

Now I agree that most of the time clip data is not all that big so there is not much problem here... most of the time. But there are times when it is an issue... so here are my thoughts...

Threshholds... Have the clip daemon configurable so that there is a data-size theshhold... If the data is under the bar, copy it to the clipboard daemon for persistence. If the data is too big, do it the old fashined way... let the source app keep it until needed. That makes big clips non-persistent but makes the other 90-odd percent persistent. [Yes, this is basically what Shimon suggested]

This can be expanded upon... say that it is a big object being clipped... the clip daemon can come up with a warning and ask the user whether to make a persistent copy or not. Or at least warn the user that it is over the theshhold. This could be configurable so that users can enable or disable such warnings. We all hate stupid pop-ups ("Do you REALLY REALLY want to quit?"). Maybe even a dual-threshhold... up to such-size replicate. Large but not enormous, ask. Enormous, don't even ask... but perhaps (as a switchable option) warn the user that it is just too big for persistence. You get the idea here, right?

The idea there is to avoid changing the extant clipboard api's.... otherwise a gazillion little (and big) programs have to be revamped to use a new clip api.

Now here's another thought, but it depends on how the current clip apis work...

Does the clipboard know when a program that has posted data (a source app) is wanting to shut down? Maybe there is a way to let the program typically hold the data (as we have now), but when the program wants to exit and tells the clip api that it's data is going bye-bye, the clip daemon can sneak in a data-grab right then to get a copy as the program is about to exit. That saves on duplication in memory while the originating app is running.

It also gives the clip daemon a chance to ask the user. Maybe it will automagically snag small clip data, but for big clip-data, it can warn the user "Hey! Program Datasaurous Maxx is exiting with 500 Enormabytes of data on the clipboard. Do you want to keep this data on the clipboard or discard it?" At this point, it can copy the data to itself if the user so chooses.

Having threshholds and options helps. If you just start pulling all clip data to the clip daemon willy-nilly, of course you'll have problems with large objects. Because with the source app still open, you are looking at having at least 3 copies in memory (orig, clip, and dest.), as opposed to two (orig and dest). But if you use threshholds to decide whether to pull the data to the clip daemon or not you can get around most of the issues. Small memory users can have smaller threshholds, and king kamayamaya memory gods with enough ram to simulate an alternate universe can have higher or even no threshholds.

Now in an ideal world, we could just revamp the whole clip api and force all the app developers to retrofit their code tomorrow or die. Muah ha ha... But that is not an ideal that I (nor, I suspect, the app developers) subscribe to. Just seems, so, um, Microsoftish. Bad taste! Bad taste! ... (spits) ... better.

Oh, looks like my two-bit-o-meter has run out. Peace!

Tim LePes

[doclivingston]

The other problem is to do with the type of data that the clipboard daemon stores. I'm not an expert on the X clipboard architecture, but this is my takes on how it works.

If you copy some text out of a word processor it will tell X that it wants to replace the contents of the clipboard, and that it can provide the data in several formats (e.g. styled text, simple text, etc.).

If you then try to paste it in another word processor it will say it can accept styled text, and so will get given that by the original application. If you try to paste it somewhere that only accepts straight text (e.g. a terminal window) it will get that instead.

The problem is that the clipboard daemon doesn't know what the destination application will accept - the only way to be sure that it gets the data in the best format is to store _all_ possible formats, which could be a *huge* amount of data. I'm sure there are some techniques that clipboard daemons can use to reduce this, but (having not really looked very hard) I'm not sure if it is still a potentially big problem.

[sanjeevdas]

The other problem is to do with the type of data that the clipboard daemon stores. I'm not an expert on the X clipboard architecture, but this is my takes on how it works.

If you copy some text out of a word processor it will tell X that it wants to replace the contents of the clipboard, and that it can provide the data in several formats (e.g. styled text, simple text, etc.).

If you then try to paste it in another word processor it will say it can accept styled text, and so will get given that by the original application. If you try to paste it somewhere that only accepts straight text (e.g. a terminal window) it will get that instead.

The problem is that the clipboard daemon doesn't know what the destination application will accept - the only way to be sure that it gets the data in the best format is to store _all_ possible formats, which could be a *huge* amount of data. I'm sure there are some techniques that clipboard daemons can use to reduce this, but (having not really looked very hard) I'm not sure if it is still a potentially big problem.

So, I am just curious. If it is such a hard problem, how does windows deal with it?

[doclivingston]

I'm not sure, but thereare probably some things that it can do:

a) realise that it can get some formats from others. In the above case the daemon would keep the styled text, which it can convert to pure text if it needs to. This would probably save a lot of space for some formats

b) some other way of not keeping all the formats around

c) copy them all as a last resort


I don't think its really a problem, unless you are copying a fair bit of data which has qutie a few possible formats. I'm not saying that you shouldn't use a clipboard daemon because of it, but it could potentially cause a large amount of extra memory to be used for a reason most people couldn't figure out.

[UbuWu]

The problem is that the clipboard daemon doesn't know what the destination application will accept - the only way to be sure that it gets the data in the best format is to store _all_ possible formats, which could be a *huge* amount of data. I'm sure there are some techniques that clipboard daemons can use to reduce this, but (having not really looked very hard) I'm not sure if it is still a potentially big problem.

I am not totally sure, but I think I read somewhere gnome clipboard deamon already converts the data on-the-fly as needed by the application which the data is pasted to. so that wouldn't be a problem :grin:

[subterrific]

Quoted from the gnome-clipboard-daemon website (http://members.chello.nl/~h.lai/gnome-clipboard-daemon/):

I've tried to submit a patch for gnome-settings-daemon before but it was rejected. See this link (http://mail.gnome.org/archives/desktop-devel-list/2003-September/msg00193.html)for discussion.

The link is a long thread on the gnome desktop-devel list where people point out every minor edge case that would make gnome-clipboard-daemon break. Which basically boils down to:


There is no standard for inter-application clipboard communication of complex structured data. I think they mention GIMP and Gnumeric as examples of apps that store custom data on the clipboard.
It would take up too much memory if people selected megabytes of text to copy.


So rather than have something that works for the majority of cases (copying a few lines of text) they throw it out based on the case that a hypothetical unexperienced user happens to have a file with a few hundred megs of text in it and they select all+copy. They also started to hash out a solution, but the thread was in Sep 2003 and the behavior is still broken.

[intangible]

*bump*

I've searched the forums and haven't found much more about this, is there any official standing on getting this into Ubuntu?

[Burgundavia]

This would be a getting this into Gnome/Freedeskop.org issue, and I believe that there something in the works for 2.12 and possibly in Freedesktop as well.

Corey

[Amaranth]

gnome-settings-daemon in the latest GNOME 2.11.x release has a clipboard daemon that follows the spec on freedesktop.org

[intangible]

Thanks, now when people ask, I can tell them "it will be fixed in Gnome 2.12" instead of "install this because the clipboard in X is retarded and there's no plans to fix it" :D