On Thu, Jun 19, 2014 at 01:21:24PM -0400, Nick wrote:
> Quoth Sylvain BERTRAND:
> > Unfortunately, the C toolkits over there are turning very
> > bad:
> > GTK+ and the EFL do depend on harfbuzz for their font layout
> > computation which is an *really* ugly c++ object-oriented
> > brainfuckage (uglier that the glib SDK dependencies!). I did
> > a C
> > port of harfbuzz (drop-in replacement), but for basic text
> > layout
> > (roman style). Then to keep your GUI suckless, you should
> > package
> > a version of a toolkit to allow trashing harfbuzz, or avoid
> > crazy
> > SDK deps... This is unfortunately more work.
>
> You've complained about harfbuzz before. I haven't looked at
> the
> code, and believe you that it's bad, but good international
> text
> layout is important and tricky, so might it not be a better
> idea to
> clean up harfbuzz than just nuke it?
?
I did not nuke it. The core issue with harfbuzz is c++ (c++ is
certainly not suckless). Then it has to be be rewritten from
scratch and follow its C API for drops-in replacement.
I started to rewrite it, namely I unrolled the c++ code into
plain C code. But I did it only for basic layout rendering. The
API has a major race condition though (free before access), I did
try to warn the GTK+/pango devs, that was just hitting my head
against a wall.
I currently uses my *c*harfbuzz with the GTK+ toolkit... (used by
the netsurf www browser).
The pb, is when the official dev feels threaten by an alternative
implementation, usually, that dev will "enhance" its API to force
dependent components (i.e. GTK+/EFL/gecko) to break compatibility
with alternative implementations, and of course the devs of those
"upper" components will never accept code to make their
components working with alternative implementations.
Harfbuzz dev has the time and mind peace as he's financially
secure: he's a full-time employee at google and he's payed
probably near 150k$ a year.
The issue is similar with udev. Poettering did "absorb" the
"official" udev project into his systemd giga-kludge (no lies
here unfortunately). Components out there used the API version 0
of udev, now the API was "enhanced" to API version 1... don't
expect forks to follow like dogs the API changes from Poettering
on udev. And project like xorg will probably use API version 1 in
the futur and give a really hard time to alternative
implementation which stayed in API version 0, or went another
road. Basically, project like xorg should get rid of libudev dep
and be hardwired directly on linux (which has pretty stable
userland interfaces... it's not perfect, but better direct linux
than libudev API).
Sort of "embrace" and "extend".
I don't say some API changes are not required... but they
could be more of a trick to kill alternative implementations than
bringing *really* significant features.
--
Sylvain
Received on Fri Jun 20 2014 - 17:23:23 CEST