Some idea's for "clipboard-manager" (xfixes)
spam at micropp.se
Sun Apr 3 22:54:17 EEST 2005
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
> 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
> 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
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
More information about the xdg