Some idea's for "clipboard-manager" (xfixes)

[Lars Hallberg]

Philip Van Hoof wrote:

> My idea for this "clipman" thing was/is to allow applications to share 
> their clipboards using DBUS rather than letting them use X11.
>
> Why I'd like to use a direct peer to peer connection (using DBUS) 
> between twee clipboard-capable applications?
>
>     o. This way applications who are clipboard capable don't have to 
> link with xlib
>         (console applications)
>
>     o. On a networked x11 deployment (xserver remote, xclients on the 
> same host, XDMCP)
>         this improves performance by eliminating the need to go over 
> the X11 socket with that
>         data
>
> Why DBUS?
>
>     o. Everybody (including KDE developers) loves/likes DBUS.
>     o. And perhaps not everybody loves it. Still, nobody "hates" it.

Intresting, but I like to expand the idé beond clipboard. A D-Bus based 
'typed' data transfer and converting mekanism can have broader use, that 
in the end will solve problems for the clipboard to.

Think D-Data, A D-Bus service that know about other D-Bus services that 
can convert data from type foo to type bar. A set of 'Data conversion 
services' (DCS for short) that can loaded on demand and be combined much 
like g-streamer works (but not so latancy/real time critical). The DCS 
could also be able to write data of some types to files of some types, 
and to read files of some types turning it to data of some types.

Apps provide one or several DCS for the datatypes it use. The app it 
self *can* be the DCS but it make sens to make them separate. Makes for 
leaner and cleaner apps that only works with its own native format. 
Further, a DCS need not depend on X, and D-Data might be usefull outside 
the desktop (stuff like a CMS). An app might ask D-Data to preload its 
most common DCS on startup, or leve them to be loaded on demand.

If one DCS suport a given data or file format, an that or other DCS can 
convertit to 'plain text', any text processing app can suport that file 
and data type. More functionality everyvere, more integration, more code 
reuse, less duplication of effort.

Complex DCS, like ocr might be writen. Then a scanner app can save ocr 
transformed scans to any wordprocessing fomat  having an DCS on the 
system, or directly to the clippboard, or possably directly to a runing app!

It's a lot of featails to think thru... but I think it would be realy 
usefull, and the 'right' way to get rich datatype integration to work 
between apps.

> What I want/wanted to add as extra candy:
>
>     o. A daemon that rescues the clipboard if the application who's 
> currently owning the
>         selection dies. But ONLY if the application who's dying was 
> indeed owning the selection!
>         (not always)
>
>     o. A plugin for that daemon to always store the clipboard in a 
> clipboard-history (like gcm
>         once did)
>
>     o. The possibility to let two such daemons transfers clipboards 
> (network clipboard sharing
>         and sharing of clipboard between two virtual computers  -- 
> pearpc, VMWare, qemu --).
>
> Of course I'm fully aware that lots applications can generate 
> massively large such clipboards. I know about the fact that 
> applications like gnumeric and Mozilla offer multiple TARGETS which 
> they will generate individually for those applications who are 
> interested in a particular format. And I know that such a clipboard 
> daemon would have to request all those targets. And by that generate a 
> massively large data-transfer

Having D-Data, It need only save the 'richest' format suported by 
D-Data. The clipboard can then offer any TARGET that D-Data can convert 
it to.

A clipboard app could also offer D-Data features to 'all' apps. If an 
old app offer some TARGETS, the clipboard app can offer any TARGET 
format D-Data can convert them to.

> And a final option would be not to create a daemon but to expect from 
> applications to keep their instance alive until it looses the 
> selection-ownership. Using gtk/qt libraries this doesn't need to be 
> that hard for the application developers themselves. I would call this 
> a doable quickfix. It's of course a hard requirement to use the 
> library function to exit your application then. So the gtk_exit() 
> rather that exit(). And this fools the user letting him/her think that 
> the application has shut down while it hasn't (it's waiting for a 
> selection-ownership change so that it can exit properly and 
> selection-request requests to handle).

In the D-Data case this is if the app itself is the DCS. It might then 
asc the D-Data service before closing and be told to wait as long ther 
Data of  it's type in processing. If the DCS is separate, D-Data just 
keep the still needed DCS alive for a while.

But it might also close it. D-Data shuld be able to reload the DCS if 
needed (the clipord is actuly used and with another TARGET then the one 
saved).

/LaH