[dev] freetype2/fc pain
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
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
Re: [dev] Re: freetype2/fc pain
On Sun, 23 Sep 2018 at 04:59, Quentin Rameau wrote: > > 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. > > Maybe drw is not needed at all and could be put back into main code. This is another option, though there are commonalities between dwm and dmenu in terms of font drawing, which is why it once was put into a common place. It is a good question how much stricter abstraction would harm or benefit. I'm in the process to determine that. > > I will reassess if the xlib dependent part in dwm can be separated > > further as well, to allow a more agnostic WM core. > > Hum, this was tried for st, and imo it didn't bring much benefit, only > a half-separation of code into files, but not totally separated. Well I gave up on this already. The issue is that any potential abstraction of X would not be a good interface for other non-X environments like considering a suckless wayland compositor or implementing the dwm on top of something else. It is too much overengineering for no benefit. > > 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 use Xinerama, but I can live with it being stripped off into the > patches section. > Would it really bring much more simplicity? This rearrangement of the code actually looks promising -- I'm not talking about putting Xinerama support away as separate patch, but rather putting it into a separate file and having a simple dwm per screen (with some extra sugar to allow sending windows across the screens like before if Xinerama is enabled). Best regards, Anselm
Re: [dev] freetype2/fc pain
Hi Roberto, On Sun, 23 Sep 2018 at 01:59, Roberto E. Vargas Caballero wrote: > On Sat, Sep 22, 2018 at 09:10:37PM -0700, AR Garbe wrote: > > 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. > > I feel the same about st. I also think that adding freetype was a really > bad idea. Maybe we should begin to think about going one step back. I totally agree. I'd be in favour in a st just using plain X fonts. This emoji unicode porn and anti-aliasing TTF support doesn't make sense to me. The pattern here is thinking really longterm. The XFont* calls have been pretty damn stable for two decades, whereas this freetype shit breaks every year. On each new install I need to fiddle with font paths font caches, weird config files etc. It has to stop. Best regards, Anselm
Re: [dev] freetype2/fc pain
On Sun, 23 Sep 2018 at 06:37, wrote: > st has a clean wayland fork? BTW, suckless wayland compositor, still too early > to talk about it? I think a suckless wayland compositor - if it is something to be worked on, should become a separate project. Best regards, Anselm
Re: [dev] freetype2/fc pain
On 23 September 2018 at 11:56, Eric Pruitt wrote: > On Sun, Sep 23, 2018 at 09:14:11AM -0700, AR Garbe wrote: >> I totally agree. I'd be in favour in a st just using plain X fonts. >> This emoji unicode porn and anti-aliasing TTF support doesn't make >> sense to me. > > It's not just about Emoji or anti-aliasing. If you work with languages > that use non-Latin characters, support for fallback fonts is a must. Well, are you using st with glyphs that require fallback fonts? I wonder if at suckless we should aim for the general purpose. I weigh code clarity and consistency higher than being able to render all kinds of glyphs through fallback font declarations. If a user needs to display cyrillic, there are plain old xfonts with excellent support. Best regards, Anselm
Re: [dev] freetype2/fc pain
Hi there, On Mon, 24 Sep 2018 at 06:42, Cág wrote: > Anselm wrote: > > Back in the days I also concluded that the introduction of Xinerama > > and multihead support was a bad idea after all. > > > > What do you guys think about this idea? > > A couple of ideas: > 1. Having Xft and Xinerama support in the patches section I wouldn't suggesting going that far, rather separating the related handling a bit further. > 2. Create ifdefs for Xft as they are now for Xinerama (don't bite me) Well, this is something that needs to be determined. I more and more conclude, that the libsl idea wasn't so bad and that it should be solved by introducing a suckless text drawing library as true static linkage dependency for dwm, dmenu and st. This library could become something like harfbuzz for the terminal case, but way simpler and take onboard the ideas discussed in this thread with different strategies to have a list walk through to find the proper glyph of a certain range. But it should also have a proper default that just relies on the XFont API, like it used to be in d*. No fuzz, if your system is limited to Xlib only. This is kind of my conclusion now. The interesting aspect is coming up with a nice .h file that would allow to clean up dwm/dmenu/st from font handling and text drawing. It is a bit of effort. Best regards, Anselm
Re: [dev] freetype2/fc pain
Hi Silvain, On 25 September 2018 at 14:25, wrote: > The suckless futur proof solution: it is over, st goes 7bits ascii only with > it's own bitmap fonts... non english-only terminal users will just trash it. Sounds like a better plan for longevity. > ... or a suckless futur proof unicode/font stack will have to be coded: > - unicode normalizer (NFD) (like ICU) > - a full xml smile/svg vector renderer (like librsvg/expat for the svg > part) > - a ttf/otf -> xml svg translator (in freetype). Sounds like a dumb idea to me ;) > ... or st becomes like surf: an app which is a thin suckless wrapper around a > huge pile of ... You know what: st would be better of being a thin wrapper > around libvte then, because it would be even thiner. We need a simple terminal that sucks less. No extra dependencies. Thanks for sharing your thoughts. To me it becomes more obvious now what the next steps are. Best regards, Anselm
Re: [dev] freetype2/fc pain
Hi Laslo,
On 25 September 2018 at 16:06, Laslo Hunhold wrote:
> On Tue, 25 Sep 2018 21:25:12 +
> sylvain.bertr...@gmail.com wrote:
>struct sfl { ... };
>
>sfl_init(struct sfl *s, char **files, size_t nfiles);
>sfl_draw(...);
>sfl_free(struct sfl *s);
This is something I was considering, however it looks like the water
of the babie's bathtub is poisoned with freetype2/fc bacteria. I don't
wanna introduce abstractions that might be premature, hence I suggest
to fully revert back to XFont* API until something like this is proven
to be work properly. It can only improve the performance of st as well
;)
Best regards,
Anselm
Re: [dev] freetype2/fc pain
On 25 September 2018 at 16:32, Laslo Hunhold wrote: > On Tue, 25 Sep 2018 16:28:22 -0700 > AR Garbe wrote: >> This is something I was considering, however it looks like the water >> of the babie's bathtub is poisoned with freetype2/fc bacteria. I don't >> wanna introduce abstractions that might be premature, hence I suggest >> to fully revert back to XFont* API until something like this is proven >> to be work properly. It can only improve the performance of st as well >> ;) > > what a fitting analogy! :D > > I am also in favor of going back to XFont. It's the best compromise, but > we should not forget the drawbacks. Hehe, well there are drawbacks, but at least we are well aware of the limitations and we won't see people complaining about crashes on emoji glyphs ever again ;) -Anselm
Re: [dev] [dwm] Emacs ediff popup window does not get focus
Hi Sean,
try forcing that window as floating window via:
{ "Ediff", NULL, NULL, 0,1, -1 },
or
{ "Emacs", "Ediff", NULL, 0,1, -1 },
in the rules[] section of config.h
BR,
Anselm
Re: [dev] freetype2/fc pain
Hi David, On Fri, 19 Oct 2018 at 05:47, David Demelier wrote: > Le 24/09/2018 à 08:19, AR Garbe a écrit : > > On 23 September 2018 at 11:56, Eric Pruitt wrote: > >> On Sun, Sep 23, 2018 at 09:14:11AM -0700, AR Garbe wrote: > >>> I totally agree. I'd be in favour in a st just using plain X fonts. > >>> This emoji unicode porn and anti-aliasing TTF support doesn't make > >>> sense to me. > >> > >> It's not just about Emoji or anti-aliasing. If you work with languages > >> that use non-Latin characters, support for fallback fonts is a must. > > > > Well, are you using st with glyphs that require fallback fonts? > > I wonder if at suckless we should aim for the general purpose. > Unfortunately, I remember having terminus not rendering some kind of > unicode characters not even emojis. I think it was some drawing characters. > > Many tools like to use those characters (just even tree). Are you referring to curses border characters? They shouldn't be a problem at all with plain old xfonts. > Also, I'm not sure if many bitmap fonts render correctly on 4k screens. > I just love how Fira Mono renders on mine. But I should test some. To me xfonts (like terminus) look way more crisp on such monitors (with say size 24px or something similar depending on resolution) than those heavily AA TTF freetype fonts. But a matter of taste I presume. BR, Anselm
Re: [dev] freetype2/fc pain
On Fri, 19 Oct 2018 at 07:04, David Demelier wrote: > Le 23/09/2018 à 06:10, AR Garbe a écrit : > > 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. > > Are you saying that you would like to remove the support for multiple > screens? No. However I've come up with a smaller dwm.c that excludes most of the Screen abstraction and allows to be compiled without XINERAMA support enabled and a xinerama.c that introduces the Screen primitives and contains the sendmon() et. al. functions. It's still not final yet, but I'm considering this as right move. > If yes, please don't minimize the number of multiheads setups, both at > work and at home I have two monitors. Or as Quentin said at least in a > separate patch. No worries, xinerama will be supported, but I wanted to have a leaner core dwm without xinerama. Best regards, Anselm
