[Spam] Re: Some idea's for "clipboard-manager" (xfixes)

[Axel Liljencrantz]

On Sun, 2005-04-03 at 21:54 +0200, Lars Hallberg wrote:
> 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.
> 

Are the reasons outlined above strong enough reason to abandon the X
clipboard? 

Applications don't have to link with xlib. I've written a shell that
uses the X clipboard to perform copy and paste without including any X
specific code in the shell itself. The way I did this was to use a
wonderful little program called xsel
(http://www.vergenet.net/~conrad/software/xsel/), which is a small
console utility that allows you to read from and write to the X
clipboard and the X primary/secondary buffer. By internally using this
program, user of my shell can use ^K, ^Y and M-Y in exactly the same way
as in emacs to kill, yank and rotate the killring, and new kills are
copied to the clipboard, and when the user does a yank, the clipboard is
checked for new content. My shell does not need to include any X headers
and I do no t have to worry about the evils of the ICCCM specification.

Two local applications connected to a remote X server is a rare enough
thing that it should not motivate a change of standards.

The reasons outlined above do not convince me it should be dropped. 


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

Cool idea. But that can be implemented using the current X clipboard,
couldn't it?

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

These are also cool ideas. I fail to see why they can't be implemented
in the current clipboard standard.

> > 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
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg

Maybe I'm missing something, but it sounds like you both have a lot of
good ideas how to improve the clipboard, but I don't see why you would
have to defenestrate the old X clipboard to implement them.


-- 
Axel Liljencrantz <axel at liljencrantz.se>