Re: [dev] freetype2/fc pain
Hi, 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 barely use multihead setups and I don't give a f*ck about Well, multihead is a very common setup today, but as always it is only a question of being used to don't use it. > 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. Indeed. Roberto.
Re: [dev] freetype2/fc pain
On Sat, Sep 22, 2018 at 09:10:37PM -0700, AR Garbe wrote:
> 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
>
Hi Anselm,
I agree with all the points about Freetype2. It has been bothering me for some
time too.
I think we should remove the drw.{c,h} abstractions also. The abstractions go
against the principle of having mostly one file to hack on and increasing
readability.
At the time it seemed like a good idea (also to me) to have libdrw to support
Wayland for example. It sounded nice in theory.
I think we should keep Xinerama though, but it wouldn't be an issue if it is a
wiki patch either.
For st there was a X11/terminal code split to support Wayland, automated
testing of terminal emulator code. Now there are abstractions but it is not
useful. Maybe it should be reverted also?
If/when we revert the code we should take good care to not introduce
regressions and review and test carefully. It has happened many times big code
changes and code reverts caused regressions.
--
Kind regards,
Hiltjo
Re: [dev] Re: freetype2/fc pain
Hello Anselm, > 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. Maybe drw is not needed at all and could be put back into main code. > 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. > 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? > 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. Yes, no need for a fork, I think we all agree on the font madness and will find common choices
Re: [dev] freetype2/fc pain
On Sun, Sep 23, 2018 at 01:49:01PM +0200, Hiltjo Posthuma wrote: > For st there was a X11/terminal code split to support Wayland, automated > testing of terminal emulator code. Now there are abstractions but it is not > useful. Maybe it should be reverted also? The abstractions in st are really small and I think in this case was more about splitting the big file than introducing abstractions. The functions that are called from st.c are the same before or after the split.
Re: [dev] freetype2/fc pain
On Sun, Sep 23, 2018 at 01:49:01PM +0200, Hiltjo Posthuma wrote: > For st there was a X11/terminal code split to support Wayland, automated > testing of terminal emulator code. Now there are abstractions but it is not > useful. Maybe it should be reverted also? Hi, st has a clean wayland fork? BTW, suckless wayland compositor, still too early to talk about it? -- Sylvain
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 Sun, Sep 23, 2018 at 09:22:00AM -0700, AR Garbe wrote: > 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? And has st a wayland backend or fork? -- Sylvain
Re: [dev] freetype2/fc pain
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. Eric
Re: [dev] freetype2/fc pain
[2018-09-23 17:20] sylvain.bertr...@gmail.com > On Sun, Sep 23, 2018 at 09:22:00AM -0700, AR Garbe wrote: > > 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? > > And has st a wayland backend or fork? There is no "official" suckless project but the author of the velox[0] compositor also maintains a Wayland st fork[1]. The st fork uses an older version of a Wayland protocol but there already exists a pull request to remedy that. The author of the fork also maintains a simple Wayland drawing library[2] (which is also used in the Wayland st fork) and a Wayland compositor[3] library. Cheers, Silvan [0] https://github.com/michaelforney/velox [1] https://github.com/michaelforney/st [2] https://github.com/michaelforney/wld [3] https://github.com/michaelforney/swc
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
On Sun, Sep 23, 2018 at 11:19:46PM -0700, AR Garbe wrote: > On 23 September 2018 at 11:56, Eric Pruitt wrote: > > 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. Yes, st's fallback font support is the main reason I began to use it. I use st and dwm with Japanese and Chinese text almost every single day. > 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. If supporting languages spoken by billions of people isn't reason enough for you, then there's not much point in me arguing because I can't come up with a better rationale. Eric
Re: [dev] freetype2/fc pain
On Sun, Sep 23, 2018 at 11:31:29PM -0700, Eric Pruitt wrote: > Yes, st's fallback font support is the main reason I began to use it. I > use st and dwm with Japanese and Chinese text almost every single day. I forgot to add that supporting Japanese, Chinese and Korean is THE reason I wrote "Add Xft and follback-fonts support to graphics lib" / 14343e69cc596b847f71f1e825d3019ab1a29aa8 in dwm. I was tired of seeing missing glyph rectangles all the time, and the Pango patches I originally used no longer applied to HEAD. Eric
