[dev] freetype2/fc pain

[AR Garbe]

Hi there,

I have been revising dmenu/dwm/libsl in terms of simplicity due to a
migration to OpenBSD recently.

I can't get my head around on how much the elegance and clarity of
dwm/dmenu/libsl code has suffered from the introduction of freetype2
and fc usage.

Back in the days I also concluded that the introduction of Xinerama
and multihead support was a bad idea after all.

I'm really at a point to consider forking dwm and dmenu to simply rely
on X11 as it used to be, perhaps with going the extra mile to remove
Xinerama support as well and to rely on single headed setups.

What do you guys think about this idea?

I barely use multihead setups and I don't give a f*ck about
anti-aliasing. This whole freetype2 move seems utterly wrong. I didn't
see it as critical before, but now I more and more conclude it has to
go.

Best regards,
Anselm

[dev] Re: freetype2/fc pain

[AR Garbe]

On Sat, 22 Sep 2018 at 21:10, AR Garbe  wrote:
> I can't get my head around on how much the elegance and clarity of
> dwm/dmenu/libsl code has suffered from the introduction of freetype2
> and fc usage.
[..]
> I barely use multihead setups and I don't give a f*ck about
> anti-aliasing. This whole freetype2 move seems utterly wrong. I didn't
> see it as critical before, but now I more and more conclude it has to
> go.

I did investigate the options and made up my mind. Here is my verdict:

 The idea behind libsl has to be improved in code and I will work on
this. The drw.h API is not strictly enough defined and both dwm and
dmenu access certain aspects of drw.h that they shouldn't, which makes
it currently impossible to cleanly implement either simple plain X11
support or let the Xft/fc abomination survive in one possible
direction or to introduce a different implementation like cairo-based.

I will reassess if the xlib dependent part in dwm can be separated
further as well, to allow a more agnostic WM core.

I know that I did raise the multihead question a couple of times in
the past, and mostly the picture I gathered was 50/50 -- one half uses
Xinerama setups, the other doesn't. Thus my old idea of arranging the
code in a different way might be an answer, which would allow building
dwm single-headed (without Screen) and multi-headed (witch Screen
derived from Xinerama).

I think this whole effort will lead to 6.2 rather than some fork. But
I want it be easier to built a clean dwm without the cruft in setups
where most of the cruft is (fortunately still) absent.

BR,
Anselm