<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.5.7"> </HEAD> <BODY> Hi there Matthias and Anders, I've been quickly reading the sources of "clipboard-manager 0.3". I found you guys in the AUTHORS file. You can easily remove the need for gdk_window_add_filter and catch clipboard notifications while not owning the selection using the newer xfixes extensions. This is a very very very simplistic example that will print some text when events like clipboard owner-has-changed, clipboard-owner-has-destroyed and clipboard-owner-is-closing happen: <A HREF="http://cvs.freax.be/cgi-bin/viewcvs.cgi/clipman/src/clipman.c?rev=1.3&content-type=text/vnd.viewcvs-markup">http://cvs.freax.be/cgi-bin/viewcvs.cgi/clipman/src/clipman.c?rev=1.3&content-type=text/vnd.viewcvs-markup</A> Perhaps using these xfixes extensions might remove some of the reasons not to use clipboard-manager? It can remove the need of XSetSelectionOwner each time a clipboard selection-owner change happened. The only case it's still needed is after rescuing the clipboard of an application thats dying/closing. 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. 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. There's many solutions to that problem. The daemon can limit the amount of targets or data to receive. Or the application owning the clipboard could add a new TARGETS-like target in which it lists unique clipboard targets to rescue in the event of a catastrophe like "the user shutting that application down while it's owning the selection". Another solution might be to develop a clipboard-macro language and pass only the macro-program which describes the clipboard to such a daemon. A major disadvantage is that all clipboard handling of all applications needs to be rewritten (short: this is not a solution). 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). I'm adding xdg-list in CC, just in case somebody else might also be interested in solving this clipboard-saga. I am interested but so far my attempts didn't really caught the attention of those people who would have to support such solutions. IMHO all people who are interested in getting the X clipboard into shape should come together IRL and discuss how it can be done. Perhaps on GUADEC this year? <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> <PRE> -- 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 <A HREF="http://www.freax.be">http://www.freax.be</A>, <A HREF="http://www.freax.eu.org">http://www.freax.eu.org</A> </PRE> </TD> </TR> </TABLE> </BODY> </HTML>