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

[Philip Van Hoof]

On Sun, 2005-04-03 at 21:54 +0200, Lars Hallberg wrote:
> Philip Van Hoof wrote:

> > 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.


I like the idea and it's, of course, possible to build it that way.

But not only we'll need developers, we'll also need acceptance of all
important X11 (or at last X.Org) developers including the ones who are
building the popular GUI toolkits.

And we'll need so called "backwards compatibility" for old applications
that wont convert (because it just works). Perhaps by by bridging the
old and the new world using a hybride application or plugin.

Getting that acceptance is much harder than implementing it. And then,
once accepted by everybody, getting everybody to use what they just
accepted is probably an impossible task.

Nevertheless I'm pro this idea. And once you are ready to implement and
develop this, I'll be available and interested (in my free time) to help
you.

I've once proposed this on a mailinglist:
http://mail.gnome.org/archives/gnome-hackers/2003-July/msg00092.html


> 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.


> > 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
-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org