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
