Re: Clipboard daemon

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Dec 18, 2003 at 03:59:12PM +0100, Lubos Lunak wrote:
<snip>
>  So, let me comment on this:
> http://www.phys.lsu.edu/students/merchan/GNOME/Recommendations/Clipboard
> 
>  - Clipable Data:
>   Oh well :(. Not much to add here.
> 
>  - Clipping persistance:
>   I find it practically unacceptable to have the app stay around until
> it looses the selection ownership. Just imagine you have some app
> running with a huge document open, making it consume 100's of MiB RAM
> (and show me some app that actually does proper cleanup on exit, not
> to mention the fact that time I checked, malloc() wasn't very good at
> returning memory back to system due to fragmentation and so on).
> Moreover, the apps may be holding some global resource - e.g. many KDE
> apps use KUniqueApplication, which prevents running more than one
> instance of the app.

Poor cleanup would be most unfortunate. I won't pretend that I can offer
a solution to that.

Unique applications (but maybe not KUniqueApplication) are something I'm
counting on. Suppose Foo is a unique application in this sense: Once
Foo has started running connected to a display, future invocations of
it on the same display send a message to the first invocation and exit.
When the first invocation receives this message, it performs some
appropriate action. If Foo is just a control panel, then it shows the
control panel window. If it is a document-handling application, then it
shows the document specified in the message, possibly in a new window.
In short, every program becomes its own remote control.

Suppose then that Foo has withdrawn all its windows but remains running
because it holds clipboard data. Then the next invocation of Foo sends a
message to the lingering first invocation and exits. The first invocation
then appears to act as if it had exited and the second invocation were
running, but much more quickly. Because Foo is still running, it in fact
skips the various steps it normally performs when first invoked, such as
pulling in libraries and showing a splash screen.

A remote control such as this can be done with less than 100 lines of
Xlib code, as I recall.


>  Which means, all apps would have either to do a perfect cleanup
> (which I doubt for some strange reason), or they'd have to pass the
> clipboard contents to the clipboard daemon anyway. The latter option
> means that either the app will stay running for long anyway while
> transferring the data, or we're back to limiting transfer size. Or we
> need some other faster way of transferring the data.

Does it really take too long to transfer data? I can see that a large
transfer could stall a user interface unacceptably, but once the windows
of an application are withdrawn it can transfer data to the daemon
in the background.

To force a transfer and preserve appearances, we'd need a new protocol.
The daemon would have to claim a manager selection such as
CLIPBOARD_MANAGER so other apps can find it. Applications which would
rather exit than idle could then send to the daemon a MULTIPLE request
comprised of INSERT_SELECTION requests for all the targets to preserve.
The daemon then requests the data for the selection targets named in the
request. Upon receipt, it sends a DELETE request to the owner and claims
the same selection itself. This preserves both the data and its place in
the sequence. MULTIPLE, INSERT_SELECTION, and DELETE are all documented
in the ICCCM. The only new thing is to use them together this way for
this purpose. The MULTIPLE request wraps the INSERT_SELECTION requests
so the daemon only sends DELETE after receiving all the targets. A
request could be invented to avoid that; INSERT_ALL_TARGETS, for example.

I realize that may seem tortuous and bizarre, but it's a way to make
this work within the bounds of the selection mechanism. If you told me
the way to do this with CORBA, that would seem just as bizarre to me
because I don't understand CORBA. The ICCCM is at least shorter than
the CORBA spec.

If it does seem too bizarre, let me know and I'll try to make a better
presentation of it.  (I'm uncomfortable without a large drawing board
and an audience that can give immediate feedback - or the traditional
and more intimate conversation over drink napkins.)


>  - Clipping History:
>  Clipping history _is_ desirable. If you asked KDE users about what
> Klipper does or why they use it, they'd say it's because of the
> clipboard history, and not just the last item. But maybe the fact that
> we don't have problem with the contents disappearing on app exit plays
> a role here. In practice it's maybe that Klipper is equally often used
> for both things.

But what kinds of things do KDE users expect to cut-and-paste? If they
are used to X apps, they probably expect only text. Users of non-X
environments expect more. They expect, for example, things that can
only be done with negotiation between the source and destination.


>  If the _GNOME_SELECTION0,1,2... selections aim to be a perfect
> solution, they'll suffer from the same problem of being lost when the
> application terminates, causing holes in the history. Keeping them
> there brings us once again to the clipping persistance problem.

Yes.


>  Technically it should be doable I believe, timestamps in the events
> should make sure there will be no race conditions. However, do I
> understand it correctly that there should be no limit on the
> selections? If yes, what if I do 100 times ctrl+V of some large area
> in gnumeric? It will eat huge amounts of memory (as the large areas
> will result in large clipboard contents, otherwise Klipper wouldn't
> have a problem with it either). Even worse, what if I do those 100
> selections in different applications? There will be no way how to
> limit the amount of memory used for it, not even a way how to find it
> out.

"Ctrl+V"? That's Paste. Did you mean Copy? I'm going to assume you did,
since I don't understand how pasting so many times could be a problem,
except for the repeated requests for data. If you did mean Paste,
please explain and ignore the next few paragraphs.

If the user copies the same data over and over - as if a Copy key got
stuck - I would hope that the application would not change the selection
data for each instance. It would be a problem for any scheme to have
the same chunk of data filling the top 100 slots in the clipping history.

There's no limit to the numbered selections so that gaps are allowed.
Forbidding gaps would require that each application check the other
selections to fill the gaps and then race conditions would be created.
Gaps should only appear if an application terminates abnormally and
can't restore its selections.

The history program can be responsible for limiting the extent of the
history. When it peruses the clipboard selections and finds that there
are more than a reasonable number, such that system performance might
be adversely affected, it can send DELETE requests to the oldest
clippings. Programs idling because they hold clipboard data could
then exit.

The history could be limited to a number of clippings (as Windows does),
or the history manager could use other means to set a limit.


>  - Eliminating Clipboard Managers:
>  If you think claiming CLIPBOARD_MANAGER selection will make Klipper
> go away, you're wrong. This selection seems to be xclipboard-specific,
> at least I didn't find it documented anywhere. Moreover this part
> doesn't apply to Klipper anyway. Just BTW.

I've never found documentation of that particular selection either.
The documentation for manager selections in general is in the ICCCM.
I think I checked a Motif or CDE clipboard manager and found that it
also uses the selection, but my memory may be failing me here. The
program xclipboard is provided as part of X, and, in lieu of any
contravening specification, may be regarded as a reference. Because
xclipboard is so widely available and would interfere with other
clipboard managers (of any flavour), it is prudent to claim the
CLIPBOARD_MANAGER selection thus preventing xclipboard from running.

Even though Klipper doesn't act like xclipboard, it claims some
responsibility for the shared resource of the CLIPBOARD selection.
Right now we have xclipboard, gcm, and a proposed patch for GNOME's
settings daemon which will not interfere with each other, but will
interfere with Klipper.  To maintain sane desktop environments,
I hope XDG will adopt CLIPBOARD_MANAGER as a manager selection which
should be claimed by all clipboard history/manager apps regardless
of how they do whatever they do.

>  Well, well. It looks like all the solutions suck, each in its own
> way, just some of them require less work to suck then others. Maybe
> you have a solution for some of the problems above I'm not aware of?

I'll update my webpage within the next few weeks with some of the
material from this message.  I hope I've addressed at least one of your
concerns.


>  BTW, would it be possible to limit the following mails only to the
> xdg list? The CC list seems to be a bit long, I even don't know if
> all of the people there are still interested in this, and I also don't
> like much the mails from the gnome list about postponing.

Please do keep me on the CC list.  My neck is stretched far enough, so
I'll let someone else trim the recipient list.  :-)

Cheers,
Greg