On Mon, Dec 6, 2010 at 7:43 PM, Alexander Larsson <[email protected]> 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 _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
