Re: WebKitGTK+ as an external dependency

On Mon, May 4, 2009 at 6:22 PM, Alp Toker <alp nuanti com> wrote:
>> I'd like to end the email by requesting feedback from all the module
>> maintainers that are considering a switch to WebKitGTK+, in light of
>> the idea proposed by the Release Team of making a general switch from
>> gecko to webkit in all modules at the same time: have you tried the
>> latest releases? Are your needs covered by now? Please reply to the
>> list with any issues you might have or features you might need (or
>> even to say that all is fine), so that we can address any problem
>> earlier rather than later in the cycle.
> With my user / developer hat on, I'd like to give a thumbs up here.
> Can you give a brief view of the state of the API (soup is an API
> dependency now, what else?), particularly with regard to stability.
> What are the areas we can expect to see development in?

- Libsoup is a hard dependency and the only supported HTTP backend. We
are contributing closely with upstream (hi Dan!), and lots of new
features and bugfixes are coming from that.
- We are also using Enchant for spellchecking support. This is a
dependency right now, but we can make it optional pretty easily if
there's a need for that.
- The freetype backend is still the best supported. We'd like to move
to the Pango one as default and only backend (like we did from curl to
soup), but I'm not sure if this will happen for 2.28. The main reason
for this is pango's cross platform support and it being already an
integral part of our platform.
- GNOME Keyring can be used, optionally, to store authentication data.
- GStreamer can be used, optionally, for the HTML5 media functionality.

The main drivers for this cycle have been the needs of Epiphany and
Midori I'd say, with some other requests from other applications. I
believe most of our needs API-wise are now covered (see for example, and I expect to spend most
of the remaining time working on a11y, libsoup (see
and general WebKit bugfixing. One big thing that might happen before
2.28 is the GObject DOM API, but it might be punted if we are short on

About API/ABI stability:

- 1.2.0 will be ABI incompatible with 1.0 (this already happened in
1.1.1, our first unstable release). This was needed to add padding to
all classes and guarantee hassle-free improvements in the future.
- Quite a few APIs from 1.0 will be marked as deprecated, but will be
still available in 1.2.0, meaning that 1.2.0 is API compatible with
- We are considering having as a rule that we'll drop APIs marked as
deprecated for a whole cycle or two, similar to what GTK+ is planning
for 3.0 AFAIK. We believe this is a good compromise between stability
and the need to keep improving the code in an effective way. In any
case the rules will be made explicit and clear in the 1.2.0
- Also like GTK+, we can break newly introduced APIs during
development cycles if needed, they are only stable when released as
part of a stable release.

> Binding authors will need to adapt to some of those changes and it
> might be a good idea to coordinate the language binding set with this
> ongoing work. External dependency will probably help here too.

As mentioned, 1.2.0 will be API compatible with 1.0, so they'll only
need to wrap the new API if they wish to do so (they are of course
very welcome to do that).

> In terms of accessibility, Orca has quite a bit of hard-coded Firefox
> / Gecko specific logic. My review of that was that it wouldn't work
> well as is, but that WebKit has the opportunity to handle more of that
> logic internally to thin down the code needed in tools like Orca. Does
> that match up with what you've been seeing? Is anyone willing to put
> in the time on the Orca side?

Yes, Joanmarie has explained to me that the a11y tools have quite a
bit of code to workaround gecko issues, but she and me agree that we
can and should do better, and we are already cooperating closely to do
so (see my first email and Willie's email).

Cheers, Xan

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