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

[Philip Van Hoof]

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:

http://cvs.freax.be/cgi-bin/viewcvs.cgi/clipman/src/clipman.c?rev=1.3&content-type=text/vnd.viewcvs-markup

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?


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20050313/1fde17ea/attachment.htm