Re: XCB + deprecating gtkx.h ?

[John Ralls <jralls ceridwen us>]

On Jun 25, 2010, at 8:28 AM, Bastien Nocera wrote:

> On Fri, 2010-06-25 at 08:11 -0700, John Ralls wrote:
>> On Jun 25, 2010, at 7:48 AM, Havoc Pennington wrote:
>> 
>>> Hi,
>>> 
>>> On Fri, Jun 25, 2010 at 10:11 AM, Stuart Axon <stuaxo2 yahoo com> wrote:
>>>> I was reading about XCB and trawled through the gtk list archives noticed
>>>> there was some discussion, but that deprecating gtkx.h seemed to stall things.
>>>> Maybe now that gtk3 is coming up it would be the time to consider deprecating
>>>> this, so that in future it could move to XCB?
>>>> 
>>> 
>>> You can't really just deprecate it without a replacement, since there
>>> are plenty of legitimate reasons to get at the underlying X stuff.
>>> 
>>> I guess maybe gdkx.h could avoid including the actual xlib or xcb
>>> headers, and instead use its own XID typedefs, and have some kind of
>>> API to abstract Display* vs. xcb_connection_t* etc. But that's the
>>> real hard part I would think.
>> 
>> Here we go again. Is Gtk+ a cross-platform toolkit or is it a wrapper for X11?
> 
> What does that have to do with anything? GDK allows access to the
> underlying windowing system, be it OS X, Windows, or X11. That's a
> feature.
> 
Not exactly, and its being a feature is debatable.

Consider that gtkx.h exposes more than 50 functions (more than 60 if MULTIHEAD_SAFE isn't defined). gdkquartz.h exposes 5 and gdkwin32.h exposes 6, plus 5 more with the comment "For internal GTK use only". Hardly equal access to the underlying windowing system. It's because Gdk's close adherence to the X11 interface means that it implements a lot of features which make no sense at all outside of X11. 

The claim that " there are plenty of legitimate reasons to get at the underlying X stuff", when applied to application-level code, is antithetical to cross-platform development. If Gtk+ is a cross platform tookit, then aggressively deprecating outside access to underlying windowing systems should be a priority. I can see handing out a graphics context, so that applications which draw directly can get a speed up by having separate code for each platform. I can see a valid interest in being able to intercept platform events, which in turn requires being able to see the platform window and corresponding GdkWindow. I don't see exposing 50 functions worth of platform design details that aren't useful on other platforms.

There's nothing wrong with an application programmer tailoring her application to a particular platform, if that's what she wants to do. But make that tailoring explicit by requiring her to include the necessary platform headers and to write native platform code for the specialization.

Now, as for what that has to do with XCB and gtkx.h, nothing. ISTM that the OP misunderstood this old post [1]; deprecating gtkx.h isn't going to accomplish anything. As [1] says, the way to get XCB into gdk is to write an xcb backend to gdk, which would of course have its own gdkxcb.h. It appears that there was a bit of discussion about it, and some work by a single developer who got discouraged [2].

A better answer to the OP would therefore be: No, the roadblock has nothing to do with deprecating gtkx.h. Having Gdk-xcb requires that the work begun in 2006 get finished and updated to integrate into the current gdk, then merged into the distribution tree so that developers can start trying to use it to port applications. None of the core devs have much interest in this, so an outside group would have to do the work, then sell one or more of the core devs on committing the new directory. It's very unlikely that that could be accomplished in time for 3.0.


Regards,
John Ralls

[1] http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00027.html
[2] https://sourceforge.net/projects/gtk-xcb/