[Webkit-unassigned] [Bug 80030] [GObject bindings] Supplemental interfaces are not disabled with the "Conditional" attribute

Thu Mar 1 09:01:43 PST 2012

https://bugs.webkit.org/show_bug.cgi?id=80030

Zan Dobersek <zandobersek at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zandobersek at gmail.com

--- Comment #1 from Zan Dobersek <zandobersek at gmail.com>  2012-03-01 09:01:43 PST ---
(In reply to comment #41)
> (In reply to comment #34)
> > (In reply to comment #33)
> > 
> > > If including config.h somewhere along the way is not feasible or practical, maybe we can do an exception for GObject and just check #if defined(ENABLE_XXXX) && ENABLE_XXXX directly or define just the ENABLE macro somewhere appropriate?
> > 
> > One important consideration, which I hope does not complicate the matter terribly, is that the API should change as little as possible with different configuration flags. For instance, some distributions may compile WebKit with --disable-geolcation. Ideally, the GObject binding API should be the same in either case, even if the geolocation methods are stubs when disabled. The reason for this is that downstream applications need to be able to rely on certain API points being present to use them effectively.
> 
> Thing is, as I said in comment #8, that those API might have references to objects that are not generated. That's the case of geolocation for example. Maybe we could create empty objects but I'm sure that people will start to complain about non working stuff.

This is a valid concern. Generating bindings for a feature that's not supported in Gtk port, regardless of that feature being enabled, doesn't really make sense and can backfire in the shape of confused users. Generating bindings unconditionally for features that are fully supported and are enabled by default in the Gtk port is not as radical, but again, it is possible that some distributions may ship the library with geolocation (or any other feature) support disabled, causing problems.

An alternative, as already mentioned, is to create new API for feature detection, an equivalent to the ENABLE macro, and use that.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.