Re: [dev] gtk3 support for surf?

From: Markus Teich <>
Date: Fri, 10 Jan 2014 01:05:46 +0100

Sylvain BERTRAND wrote:
> It's a bit on the side of the topic but GTK+ is now hard dependent through
> pango on harfbuzz, a c++ component (object oriented cluster f....), which
> pulls a dependency on c++ compiler/runtime.

WebKitGTK is also written in C++ so we need a C++ compiler and runtime anyway.

> To safeguard netsurf from the toxic c++, a good thing would be to be able to
> compile the entire user level stack of netsurf with a C compiler like tinycc.

I am confused. Are you talking about NetSurf [0] or surf [1]?

> Another way to see thing would be to go to EFL. After discussing that with the
> EFL developer in charge, the EFL text layout engine can be set to use harfbuzz
> or a internal basic one. But the developer strongly suggested that it may
> become hard dependant on harfbuzz in the end. Then better stick with GTK+,
> since at least it's protected with a GNU (L)GPL license, then GTK+3 support
> would make sense.

I don't see how EFL can be used as or with a website layout engine. Could you
elaborate on that?

> Since a unicode text layout engine is very important for a international
> browser, and since the C toolkits are delegating that task to a c++
> component... what to do? Because, netsurf being the only C coded javascript
> www browser out there, in my humble opinion, it's important to safeguard this
> feature.

The NetSurf I mentioned above actually only has experimental js support.

> Personnally, I did a very partial C port of harfbuzz in C,
> , which is a drop in remplacement of
> harfbuzz (C api). I already mentioned it several times on this mailing list.
> I'm not working on it right now (I'm on an alternative linux radeon driver),
> but I will probably come back to unroll the original c++ code in C in the
> futur.

I don't think a port to C would work out well. If the code is as bad as you
claim, a clean rewrite should take less time and lead to a better result.

Received on Fri Jan 10 2014 - 01:05:46 CET

This archive was generated by hypermail 2.3.0 : Fri Jan 10 2014 - 01:12:07 CET