Awesome 4.3 Window Manager Brings Better DPI Handling, Widget Improvements

[phoronix]

Phoronix: Awesome 4.3 Window Manager Brings Better DPI Handling, Widget Improvements

Over two years since the unveiling of the Awesome 4.0 window manager and one and a half years since the Awesome 4.2 release, out today is Awesome 4.3 for this X11 window manager...

http://www.phoronix.com/scan.php?page=news_item&px=Awesome-WM-4.3-Released

[tildearrow]

As AwesomeWM always used pixels as the de-facto metric for sizes, enabling auto_dpi will break most existing configs.

Why couldn't they use floating-point scaled pixels?
By this I mean: setting the DPI will scale the pixel metric.

[Elv13]

Why couldn't they use floating-point scaled pixels?
By this I mean: setting the DPI will scale the pixel metric.

Dev here,

Because Awesome let user use raw code in their settings and extension. This code uses Cairo and these users developed it with pixels in mind. If you know a couple things about this, you will "hey, but you can scale the surface". If you do that, then there will be subpixel rendering issue because layouts wont be aligned. If you say "hey, then port all the widgets to HiDPI and ignore the all users breakage". Then *again*, the problem with that is that it adds complexity to places where complexity would break even more user settings and extension. The best plan for now is to wait for a more major release where some breakage are explicitly allowed. v4.3 is a point release of the 4.x serie and the last thing we want is our users waking up one morning after and update and being locked into GDM/SLIM/LightDM/Bash and unable to log in.

[Cape]

Dev here,

Because Awesome let user use raw code in their settings and extension. This code uses Cairo and these users developed it with pixels in mind. If you know a couple things about this, you will "hey, but you can scale the surface". If you do that, then there will be subpixel rendering issue because layouts wont be aligned. If you say "hey, then port all the widgets to HiDPI and ignore the all users breakage". Then *again*, the problem with that is that it adds complexity to places where complexity would break even more user settings and extension. The best plan for now is to wait for a more major release where some breakage are explicitly allowed. v4.3 is a point release of the 4.x serie and the last thing we want is our users waking up one morning after and update and being locked into GDM/SLIM/LightDM/Bash and unable to log in.

May I ask you: are you perhaps planning a Wayland port of some kind? Maybe using wlroots?

[Guest]

This AwesomeWM definitely looks okayish.

[schmalzler]

May I ask you: are you perhaps planning a Wayland port of some kind? Maybe using wlroots?

Yeah, wayland would be way cooler than X11. Ah, wait, it already exists...

https://github.com/way-cooler/way-cooler

[kpedersen]

How the hell does something as tiny as a lightweight tiling window manager drag in so many sodding dependencies?

https://github.com/way-cooler/way-cooler/blob/master/.build.yml

[skeevy420]

How the hell does something as tiny as a lightweight tiling window manager drag in so many sodding dependencies?

https://github.com/way-cooler/way-cooler/blob/master/.build.yml

Let's see, we have: script engine, build tool, build tool, wayland support, wayland support, mesa support, xorg wayland, image support, image support, input support.

The first 10 are lua scripting, the build system, wayland, cario, and input....going on farther it's mainly more graphical support, input suppot, and build tools.

1/5 of the dependencies are the tools to build it.

[Elv13]

How the hell does something as tiny as a lightweight tiling window manager drag in so many sodding dependencies?

(dev here)

Awesome/Way-Cooler are not really tiny tiling manager. The featureset is much closer to XFCE than, let say, i3 or DWM. AwesomeWM is a development framework to create custom window managers. The default one is just an "hello world" demo. See https://github.com/awesomeWM/awesome/issues/1395 for better examples of what happen when you enable the other 95% features that are not enabled by default.

[Elv13]

May I ask you: are you perhaps planning a Wayland port of some kind? Maybe using wlroots?

As schmalzler the Wayland version of Awesome is Way-Cooler. Right now the main developer is busy rustifying wlroot and Awesome running inside Way-Cooler is not usable. Hopefully it will eventually change. In a perfect world Running Awesome on top of the awesome-x11 or way-cooler backend should not make any difference.