Re: Building multiple backends on on same system

On Mon, 2010-12-06 at 20:39 +0100, Benjamin Otte wrote:
> 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?

While this would be nice I question the importance of it, and was not
targeting it for this work. I don't see how an app opening a window on a
wayland display at the same time as an X display is very interesting.
So, I'm just doing the minimal work so that we can avoid having to have
two versions of every single Gtk library+app when wayland becomes

> >> > * 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.

Well, i'm targeting gdk-backend for 3.0 too, and its sort of a pain to
rebase it for this. Can you not do it there, and we can cherry pick it
later if the branch failed?

> >> > * 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.

Thats not quite true. If you use gtk_parse_args() to initialize gtk+
then there will be no display opened. This is useful if you're trying to
do something more complex like opening multiple displays or migrating
stuff between displays.

However, as you say, very few gdk calls are useful with no display
connection, and the ones that do are basically generic functions that
happen to be backend specific atm, or X-specific things not calling X
that got propagated to public API, like gdk_utf8_to_string_target.

> 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.

You're not wrong theoretically, but I don't think there is time to do
anything more complex than just adding a GdkBackend singeton (like
making the atom code work on all backends) and use it as the default
when making all current "global" functions.

However, for future work we might want to keep the GdkBackend object an
internal thing, and have user code that want to do runtime backend
checks look at the default display type.

> >> 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.

I don't plan to do these in order to make 3.0 (except for the class
hiding, but thats not really an API break, these cannot be derived in
user code atm anyway). Obviously they could be done in 4.0 after the
minimal work is landed for 3.0.

 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a notorious bohemian jungle king from the Mississippi delta. She's a 
warm-hearted motormouth socialite looking for love in all the wrong places. 
They fight crime! 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]