Re: will the Bonobo Clipboard be accepted to be a part of the GNOME 2 API?

[Owen Taylor <otaylor redhat com>]

ERDI Gergo <cactus cactus rulez org> writes:

> Hi,
> 
> On 28 Jul 2001, Havoc Pennington wrote:
> 
> > Can you point me at the bonobo clipboard proposal?
> 
> http://mail.gnome.org/archives/gnome-components-list/2001-July/msg00237.html
> http://mail.gnome.org/archives/gnome-components-list/2001-July/msg00314.html
> 
> > I always thought that the way we'd do clipboard with bonobo was that
> > you put a "moniker" data type on the X clipboard, which bonobo-aware
> > apps would request.
> 
> Why would we want to make this depend on X?

Cut and paste is a desktop feature. I don't see a clipboard
being interesting unless you have a desktop running...
so I see no harm at all on depending on X. Maybe you mean
"what if Bonobo was ported to windowing system Foo?". 
I think that's a cross-the-bridge-when-you-come-to-it
question. Or, if you want to solve it right now, you need
to go and actually study how the clipboard works on
Windows and figure out how you would interoperate with
it. It's very hard to design a cross-platform API by
guessing how other platforms should work.

You really need public API's that hide the implementation
details. (The public API's can be locally activated
Bonobo components, etc. They don't need to be evil
C apis)

I think it is pretty darn essential that we interoperate as
well as possible with the X clipboard. There are two
ways of doing that:

 As you proposed: use a bridge between the Bonobo clipboard
 and the X clipboard.

 As Havoc proposed: Use the X clipboard as the core of your 
 implementation

I think the second generally will give better integration
and certainly avoids a number of race conditions. The
temptation of the first is clearly that it provides an
easy way to fix the two major problems of the X clipboard:

 1) There is no way for data to persist in the clipboard
    after an application exits

 2) There is no notification when the clipboard ownership
    changes.

(Yes, I know that you can partially address these problems in
xclipboard style, by requesting the in least-common-denominator 
form immediately, and taking ownership with a copy. I don't 
consider this very acceptable.)

However, it "solves" them only to the extent of punting
on solving them for anything but Bonobo based applications.

We need to solve them platform wide -- and at this point,
that means addressing them at the X level. Not interoperating
well with GtkEntry widgets, with Mozilla, with KDE apps
is not acceptable.

One the issues are addressed at the X level, I think
the difference between the two architectures should
be fairly small to the user.

Coming up with a proposal for a fix at the X and getting it adopted
certainly will take some time and effort; perhaps choosing an
architecture that can works well with or without such fixes makes
sense. But I don't think we can avoid addressing the 
issue at the X level. Bonobo is only a small part of the
platform.

Regards,
                                        Owen