Re: will the Bonobo Clipboard be accepted to be a part of the GNOME 2 API?
- From: Havoc Pennington <hp redhat com>
- To: ERDI Gergo <cactus cactus rulez org>
- Cc: gnome-2-0-list gnome org, gnome-components-list gnome org
- Subject: Re: will the Bonobo Clipboard be accepted to be a part of the GNOME 2 API?
- Date: 29 Jul 2001 14:27:27 -0400
ERDI Gergo <cactus cactus rulez org> writes:
> Why would we want to make this depend on X?
>
It is essential to interoperate with X, at minimum. From your
proposals, it's not at all clear to me how an app does that, and how
we avoid race conditions and such. A lot more detail is required.
The X mechanism is actually very powerful. You mentioned in your
proposal that you were looking for docs on this; they are in the
ICCCM, the relevant thing is "selections," of which CLIPBOARD is only
one. See http://www.freedesktop.org/standards/clipboards.txt if you
haven't, etc.
So my idea of how this works is as follows. Right now an X app can
offer various source data types of their choice, for example
GtkTextView offers six different formats:
static GtkTargetEntry target_table[] = {
{ "GTK_TEXT_BUFFER_CONTENTS", GTK_TARGET_SAME_APP,
TARGET_TEXT_BUFFER_CONTENTS },
{ "UTF8_STRING", 0, TARGET_UTF8_STRING },
{ "COMPOUND_TEXT", 0, TARGET_COMPOUND_TEXT },
{ "TEXT", 0, TARGET_TEXT },
{ "text/plain", 0, TARGET_STRING },
{ "STRING", 0, TARGET_STRING }
};
These are different sorts of encoding, etc.
The pasting application then requests the format it likes best; so
xterm will probably ask for one of the older traditional formats,
another text view would ask for the GTK_TEXT_BUFFER_CONTENTS thing
which encodes the rich markup, etc.
So, it's very simple: I could also offer the MIME type for a Bonobo
moniker or whatever is appropriate. Maybe I could simply offer the
type BONOBO_CLIPBOARD and the the content transfer phase goes via
Bonobo.
That keeps the idea of clipboard owner, etc. located in one central
place on the X server, avoiding races and inconsistencies, and
can trivially interoperate with non-Bonobo applications.
In any case I think this it's a big technical step to drop the X
clipboard, certainly something that merits a good bit more detailed
writeup on how we continue to interoperate with X and what the
application code would look like that supported both X and Bonobo
clipboards properly.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]