Re: Bonobo Clipboard 0.1 "Hey! It compiles!"

[Havoc Pennington <hp redhat com>]

ERDI Gergo <cactus cactus rulez org> writes: 
> OK, so let me explain what's currently implemented.
> Let's say you have a component that supports the PersistStream interface
> and the "text/plain" and "text/html" MIME types. If you put this on the
> Bonobo clipboard, the available X clipboard formats will be "STRING" (an
> alias for "text/plain"), "TEXT" (likewise), "text/plain", and "text/html".
> Requesting the clipboard in any of these formats will resolve the
> clipboard contents moniker for PersistStream and will save its state in
> the desired format into a temproary buffer, and then copy this buffer to
> the selection returned.
> 

This is one-way; it means I can paste from a Bonobo app to an X app,
for the subset of X clipboard types that are hardcoded in the
Bonobo-Xclipboard bridge. 

What happens if I want to interoperate with application foo and need
to add a new X selection type? Do I then need to use the X clipboard
directly? How do apps do that while also using Bonobo clipboard?

If I want to paste from an X app to a Bonobo app, what happens?  How
do Bonobo apps support that?

How does the clipboard work from a semantic standpoint, supporting
both the Bonobo and X clipboards? That is, how do I write my app to
work with both? They work in different ways, and it may not be
possible to write an abstract API that allows proper interoperation
with both.

Isn't there an inherent bug in storing the clipboard owner in two
places? This is the same as having two lockfiles for the same
operation.

You can conceivably require that apps obtain both the X and the Bonobo
clipboard in order to consider themselves the clipboard owner, but
then you've just required X again, eliminating the only advantage of
the Bonobo clipboard.

If you don't require X, you have to allow a client to own the Bonobo
clipboard without connecting to X at all. That means that you have a
problem where the X and Bonobo clipboards can be out of sync.

Isn't there an inherent race condition, where an app has its stuff on
the Bonobo clipboard but hasn't yet obtained the X clipboard
selection, or has lost the X selection but hasn't yet had the Bonobo
clipboard replaced?

Plus, as you say, it is inherently slower and lower-performance to
have two clipboards.

I would like to understand the design requirements of the bonobo
clipboard better. If you just want a Bonobo API for clipboards, then
wrap GtkClipboard. What is motivating a wheel-reinvention of the
backend, causing complexity and interoperability problems? I'm
assuming there are design requirements the X clipboard can't satisfy.

Anyhow, my basic misgiving is the following line of reasoning:
 - you have two different mechanisms with different formats,
   the X and Bonobo clipboards
 - if you keep them totally in sync (which is quite difficult),
   then the bonobo clipboard is useless; it's just a copy 
   of the X clipboard, which causes code complexity and slows
   things down
 - if you don't keep them totally in sync, then the X interoperability 
   is broken, and things suck for users

i.e., if you keep them in sync you are screwed, if you don't keep them
in sync you are screwed. Ergo you are screwed. ;-) 

That's why I think this is a Bad Idea (tm).

Again, I'm happy to be proven wrong; I'm just trying to save you
effort and time by explaining in advance why I do not think this will
work.

Havoc