New clipboard proposal

[Philip Van Hoof]

On Thu, 2004-12-30 at 18:11 -0800, John Davidorff Pell wrote:
> On 30 Dec 2004, at 17:12, Philip Van Hoof wrote:
> > On Thu, 2004-12-30 at 16:03 -0800, John Davidorff Pell wrote:

> >> I don't like the dependance on dbus. Why can't the X server itself  
> >> maintain the contents of the various clipboards? 
> >> [CUT]

> > There's several reasons for it. One might be that X11 already is
> > designed and tends to keep backwards compatibility a high priority. For
> > such a solution it would be difficult to maintain that backwards
> > compatibility.


> > Another reason with such a solution might be that for every selection
> > you'd set, the selected data would have to be copied to the
> > xserver-process. While most of the selections you do, won't be used for
> > pasting at all.

> Good point, but a clipboard manager using dbus would do the same thing, 
> no?

A clipboard manager with such a history plugin, yes. The clipboard
manager I have in mind will only request the clipboard if the current
clipboard owning xclient is about to get destroyed. The xfixes
extensions will be used for that.

The clipboard manager, however, is an optionally component of the
proposal. The core of the proposal is to start using an IPC (like
DBUS). 

I've understood that the dependency on such an IPC is your main concern.
Therefor it's important that applications keep backwards compatibility
in tact.

My plans are to create a lowlevel library that will ease the use of this
new system. Using this lowlevel library will keep things backwards
compatible. Luckily it isn't so that all the available targets are to be
transfered in any case a clipboard-request happens. So we can make them
available on the old-style clipboard handling while they won't take any
resources until an old-style client requests one.

New applications, however, can (and will using the lowlevel library) use
the IPC-method if possible. If not possible (the xclients live on
different hosts), the old mechanism is still available.

Backwards compatibility stays in tact. It's even important it stays in
tact.


> I'm not saying that advertising new targets are bad, just that it is a 
> trick that I don't think is necessary. OOo advertises TARGETS that are 
> probably only used internally, but they don't need to be. Also, some 
> time in the future OOo will be splitting back into separate apps, so 
> they will actually use the clipboard between them just like any other 
> app might.

Okay

> >
> >> a new library, dependance on dbus,
> >>
> > DBUS is actually ment for the purpose of inter process communication
> > between desktop applications. X11 is typically deployed for desktop
> > usage. Copying and pasting is a typical communication between two
> > processes. Since DBUS is being developed by freedesktop.org it sure
> > looks like the most ideal candidate IPC available.

> D-Bus may become common on GNU/Linux distros, but I'm not sure if it 
> will in other places, especially commercial UNIX flavours. I would much 
> prefer if the clipboard system could be improved, rather than providing 
> a replacement that is platform specific. (When I say platform specific, 
> I don't meant hat it doesn't run on many platforms, but rather that it 
> is only commonly available on certain platforms.)

I'm planning to make the IPC-part a plugin. So which IPC you prefer to
use will be an implementation detail for the platform. I'm planning to
implement a DBUS plugin and perhaps a CORBA (ORBit) plugin. Maybe later
also a DCOP one. That all that are just plans at this moment. No
promises :-).


> >> fallback to a sub-optimal protocol,
> > The current protocol is actually sub-optimal. For clipboard data to get
> > transfered from one xclient to another, it needs to go all the way to
> > the xserver (which might be located on another host) and from the
> > xserver to that other xclient. While in most cases both xclients live 
> > on
> > the same host. So they'd better use a shortcut-path. And if that ain't
> > possible, there's still the current protocol.

> That's what I mean. What I'm trying to say is that the sub-optimal 
> protocol should be improved, while still providing 100% backward 
> compatibility... actually, the interface would not change at all.

So another shortcut between two xclients? Currently, afaik, the only
connection two xclients can have is through X or using pipes, files,
shared memory or an IPC-system.

So then xlib would have to be patched and would need to start using
something like shared memory blocks. And xlib-linked application would
need to start signalling each-other to let each-other know about
changes. Stuff like that. IMHO thats stuff an IPC-system should be
doing, no?


> > What massive clipboard management? By default (without the history
> > plugin as explained below) the only situation a clipboard manager would
> > need to catch the current clipboard and store it, is when the current
> > clipboard-owner application is going to die.

> I did not understand that from your proposal, so my comments may have 
> seemed a bit odd. Ok, so really this is just a replacement for the 
> clipboard that is limited to distributions that choose to support it?

yes

> >
> >> btw. History could be added by having some application catch all  
> >> changes to whichever clipboard it is listening to and storing it, 
> >> which  is what your clipboard manager would do anyway.
>
> > I mentioned keeping histories. My exact words where that it could be an
> > option in the form of a plugin for that clipboard manager. As a matter
> > of fact there are a few applications today doing this for you. One
> > example is Klipper. Many people use Klipper. Others don't. Therefor
> > keeping clipboard history isn't going to be the main purpose.
> >
> > Making it easy for applications like Klipper to pop/push and query this
> > history would be delegated to such a plugin.

> If the X server kept track of the contents of the clipboard, then 
> klipper would continue to work exactly as it does today, no changes 
> necessary. :-)

yes, however. At this moment are applications like Klipper (gcm) using
hacks and tricks to do the task for which they are designed. I'd be
better if they didn't have to perform hacks and tricks to get the job
done.

I've e-mailed with the author of Klipper (Aaron Seigo). A short version
of his reply is that he's interested. He questioned the need for a
manager daemon. And insisted that a library-approach would be used and
the need for the manager to be reduced. So I started thinking about a
"more library"-version of my initial thought. I can't for every problem
remove the need for a daemon. For example the rescuing of a clipboard
owned by an xclient that is to be destroyed. 

I really do fear that it wont ever get solved as another x-extension.
Mainly because people dislike touching X (except Keith, it seems) and
because most developers feel that X shouldn't grow nor should get any
more tasks than it already has.

> > The xclient isn't altering the list of targets between advertisement of
> > it's targets and providing (converting) one such target to a requester.
> > Nothing about the current clipboard-handling protocol is different from
> > now. Only one target is added (which is something any xclient who's
> > owning the selection is allowed to do -- take a look at 
> > openoffice.org's
> > list of targets --). There's noting "strange" about it.

> It seems like what you are proposing is to do nothing for existing 
> applications, but provide a better clipboard for applications that link 
> to your library in the future. 

Exactly :). The old applications are lost without the proposed clipboard
manager. The manager can know (also for older applications) when they
are about the die. The manager, which is a hybride, will, just like
Klipper does, fetch all the targets of that application and will rescue
it's clipboard. The clipboard manager can do this for both new-style and
old-style xclients.

Copying every clipboard set to the xserver process for the sake of have
the possibility to rescue it, would cause a lot overhead. Since the most
used clipboard is the PRIMARY. It's the clipboard used for selecting
things. It would mean that everything you select something, the
clipboard-data (all targets) need to be copied to the xserver. Selecting
stuff would become very slow, for example if the xserver lives on
another host.


> I don't think that's a good idea as it 
> creates a dependancy that many smaller apps will just choose not to 
> include, or that many users won't install when building smaller apps. 
> It also does not solve the existing problems, such as losing the 
> clipboard when clients quit.

DBUS is a very small dependency. Much smaller than xlib. As far as I
know are the plans for DBUS to support it on as much platforms possible.
Most likely it will be supported on any platform also supported by the
XServer of freedesktop.org. Since the clipboard manager depends on the
XFixes extensions of freedesktop.org, the freedesktop platform of
freedesktop.org is "the" dependency for any proposed proposal I've been
doing so far.

I can't replace the clipboard of a proprietary X11 implementation :-).


> >> I think you're looking for over-kill. Why can't we write a (very) 
> >> small  extension to the X server that just keeps track of the 
> >> contents of the  various selections?
> >>
> > Because storing that selection isn't the task of the xserver. It's the
> > task of the xclient. And it's the task of an application following the
> > CLIPBOARD_MANAGER specification to take-over the selection if a
> > clipboard-owner is about the die. There's documentation about this
> > subject.

> I've not read that spec, I will if someone sends me a link. :-)

Regretfully the link on freedesktop.org ain't available :-(

http://pdx.freedesktop.org/Standards/clipboards-spec

> If X implements this spec, or if KDE/GNOME do, then the tiny X ext 
> would not need to copy the selection every time, only when an app 
> announces that its about to quit. Better yet, screw the extention and 
> just make klipper do this. If an app announces its about to die, then 
> klipper should request all TARGETS provided by that app. I get the 
> feeling that this is not how most apps work, though.

Which is what the clipboard manager would do (in my proposal) and would
make available to Klipper using an IPC (like DBUS). The author of
Klipper expressed his interests in this (private E-mail). Simply because
it's better when both GNOME and KDE can share it, than when both desktop
environments have to re-implement the exact same thing.

> > The most user-visible problem is the fact that many applications aren't
> > providing useful targets. It's only since very recently you can copy 
> > and
> > paste formatted text from mozilla to evolution's e-mail composer.
> That won't be solved by either solution. It can't be.
> 
> > At this moment copy/pasting between openoffice.org's calc and gnumeric
> > is very buggy and won't always work.

> And I hope they're working on this, but either solution doesn't do a 
> thing about this.

Indeed. The solution for this problem lies in an organisation like
freedesktop.org telling developers what MIME-types to use and how to
format them correctly.

> > That problem, however, can't be tackled by any "tool" or "daemon" or
> > whatever. It can be, however, tackled by creating standards and 
> > agreeing
> > on MIME-types.

> Agreed! Ok, so an app should advertise appropriate MIME types... which 
> can then be requested via the X selection routines.



> > Yes. The difference is, however, that the xserver might be located on a
> > different location than most of the xclients. While most of the 
> > xclients will be located on the same host.

> I think that this is not a good assumption, but I do understand your 
> concern. I would guess, however, that in many cases the 
> dbus/clipboard-manager daemon might be running on the same host as the 
> X server, creating the exact same issue, just with a different daemon.

Well no. The current X11 protocol isn't designed to do transfers of
large datasets from one process to another. When they designed X11 then
didn't think about the desktop usage of today. Today everybody copies
and pastes huge amounts of data from one application to another. It used
to be only very small pieces of plaintext. An IPC is (or can be)
designed for transferring data between processes. Some can even do this
assynchrony.


> How easy is it for these apps to talk directly? I know that the dbus 
> messages can be sent from one app directly to another, but how much 
> interaction with the dbus daemon is need to do this? How easily can an 
> app be written to support this?

My idea is to create a lowlevel library (and to get that in the
GtkClipboard and QClipboard objects).

> This is cool, and is definitely something that we all want, but a 
> clipboard manger won't do this. Transferring images embedded in 
> formatted text is something that must be solves by both sides of the 
> transaction supporting a specified format for doing just that. D-Bus 
> may make it faster in some cases, but it does not solve the problem.

No indeed. It isn't trying to solve the problem. It's only trying to
make it fast :). The problem is solved by first making it fast. Then
creating a standard for it. Then using it.

> > How does it solve the problem? It makes the user the guilty entity by
> > asking him a stupid question. Of course does the user want that
> > clipboard saved. Well. Perhaps he or she doesn't want it saved, but he
> > or she sure doesn't want to get bothered with such a question. It's a
> > computer! It should know all by itself whats best.

> Should it?

Mine should ;-)

> > And the only difference might be the fact that the Microsoft solution
> > isn't using a process. So it's more monolithic. Being monolithic,
> > however, isn't the preferred design pattern for UNIX softwares. X11 is
> > huge all by itself. It doesn't need yet another task (like persisting
> > the clipboard of xclients that are to be shut down).

> Windoze also doesn't have to worry about sending the clipboard to 
> another host.

Indeed. Which is a huge benefit.

> >> As for clipboard persistence between invocations of the X server, I  
> >> personally don't see that as useful in any but corner cases. It can,  
> >> however, be addressed in the same way that history is provided: by a  
> >> very small watcher application that just loads its initial history 
> >> from  file before it starts watching for X selection changes.

> > And what do you think a clipboard manager would have to do? Exactly, be
> > that small watcher application that just loads its initial history from
> > file before it starts watching for X selection changes.

> Like klipper, but what it sounds like you are talking about is much 
> much larger and requires a number of changes for a client to use it. 
> That's the part I don't like. It doesn't help those of us who do not 
> run a KDE or GNOME session, or who don't run entirely KDE or GNOME 
> apps. That is where all my objections come from. Your clipboard manager 
> via dbus doesn't address the problems that currently exist, though I do 
> give you credit for trying to prevent them in future apps (that happen 
> to use your library/clipboard, that happen to be on hosts where it is 
> available).

Newer non-gtk/non-qt applications can also support this, of course. 

To fix the clipboard of older applications while keeping things
backwards compatible is very very difficult. I fear, impossible.


> If I understand you correctly, then an app that supports your 
> clipboard-over-dbus that is asked to paste would check the available 
> TARGETS, notice the dbus one, then ask dbus for another list of 
> available formats, then choose among those? What's to stop an 
> application from just ignoring the X server and going directly to 
> d-bus, destroying interoperability with other apps?

The fact that it ain't going to use the lowlevel library I am planning
to provide. Using that library will enforce correct usage. You can
always, of course, manually query the IPC-mechanisms. But you can also
manually connect with the X unix socket and start doing funny things
with X. 

> P.S. I'm not on the xdg list, so I think my messages are awaiting 
> moderator approval.


I've noticed indeed. Therefor I've tried to include most of your
original text. I hope those moderators are done partying newyear soon so
they can release your E-mails :-).


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