Re: Building multiple backends on on same system

[Benjamin Otte <otte gnome org>]

On Mon, Dec 6, 2010 at 7:43 PM, Alexander Larsson <alexl redhat com> wrote:
> You can of course check on the type of anything, like the display or a
> window. However, sometimes there might be no display availible, like if
> its not been opened yet.
>
I think the question is if we want to support multiple different types
of displays in the same application, like cairo allows xlib surfaces
and gl surfaces to coexist in the same app. Do we envision a time when
we have a use for two different types of backends running in the same
app at the same time?

>> > * Convert GdkCursor to a GObject so we get a class vtable
>> >
>> That should have been done ages ago. Will do that now.
>
> Where are you commiting this? The gdk-backend branch?
>
master - or at least targetting it. GdkCursor should be a GObject in 3.0.

>> > * Add a GdkBackend type, derive from this in all backends
>> >
>> See my comment above about using GdkDisplay for that.
>
> This is not right at all. There can be zero or multiple display objects
> in any single gtk+ app.
>
You will not have any backends without a display though. Each and
every backend can really only be used with a display. There's not much
sense in calling x11-specific code without an open connection to a
display server.

The functions you list fall into basically two types:

> gdk_atom_intern
> gdk_set_locale
>
These are generic and don't need a backend.

> gdk_add_client_message_filter
> gdk_error_trap_pop
> gdk_query_depths
>
These operate on the default display.

So I still think that using the display instead of the backend is fine.

>> Also, do you target this for 3.0? Because I don't think it's doable in an
>> API-stable way during 3.x?
>
> What API changes do you envision? I expect this to be both API and ABI
> compat.
>
The issues are the preparation. Like hiding all the struct fields,
removing outdated APIs that do stupid things (like
gdk_utf8_to_string_target) and things like that. Not the actual
implementation of the idea.

Benjamin