Awesome: Support HiDPI

[berlam]

Changing the DPI in .Xresources has no effect to the awesome font rendering and wibox scaling.
Currently I am using Debian Testing with awesome 3.5.6 and a DPI of 144.
Other GTK apps are shown in the right scaled size.

I am not an expert on this kind of programming, but I think this might be a problem with the configuration of Pango and Cairo which should already support HiDPI.

After a quick look into the awesome sources I found following code in core.lua and other components:

    local ctx = PangoCairo.font_map_get_default():create_context()
    ctx:set_resolution(beautiful.xresources.get_dpi())

Is HiDPI currently supported?

[psychon]

Not in 3.5 and I think the code you showed above isn't in 3.5. Can you try with the latest Git version (which should pick up Xft.dpi from your .Xresources)? (make packages should provide you a .deb that you then can (hopefully) install with dpkg -i the-file.deb. However, that was merged to git just yesterday and I guess you'd be the first one to try this. :-) )

[berlam]

I will give it a try later this day and report back here (for Packaging and HiDPI). Thank you! :-)

[psychon]

Oh and: There were API changes since 3.5. Your current config likely won't work. I suggest trying this with the default config (this should be enough to see what the font size looks like).

[actionless]

it works more or less correctly only when setting this theme: https://github.com/awesomeWM/awesome/tree/master/themes/xresources

otherwise only fonts will be scaled but some controls won't. but they will attempt to enlarge to fit the bigger font so probably you'll have only some problems with margins' sizes.

also it will pick up the colors from your ~/.Xresources (they should be set unprefixed, ie *color1: #aa3683)

@psychon what do you think about setting it as a default theme btw?

[psychon]

@actionless Uhm, I don't know. Why not? I guess, if the fallbacks look similar to the default theme, most people won't even notice. However, this makes it harder to change the theme and so would kind of defeat the point of having beautiful.... at least a bit?

[actionless]

we could change fallback to look a bit closer to the default because now it set to this theme http://dotshare.it/public/images/uploads/873.jpg

imho it makes thing with beautiful even easier because you still have a choice to hardcode any color or inherit it from xrdb colorscheme

[Elv13]

Or just "merge" the HiDPI parts into all other themes and ignore the xressources colors?

[actionless]

or that

but i thought what picking not only dpi but also colors as well from ~/.Xrexources could be even nicer

and, as @psychon suggested, if we will change the fallback values to match the curernt default theme users who are not set them will not notice any difference

[Elv13]

I am not sure it wont make a difference. Many people just set those colors and expect them in terminals. I know you can add namespace, but I don't think people expect those colors to be used outside of X11 terminals emulators anymore. AFAIK, no toolkit still use them.

[psychon]

(awesome doesn't ask for a specific namespace in the resource database, does it?)

I like @Elv13 suggestion. Why shouldn't all themes use dpi() for stuff that's specified in something-similar-to-inches?

[actionless]

it doesn't by default (it's supported in the current c api though, class argument), if we gonna support it the logic should be what it should first try to read prefixed value and if it's not found use the common one

i don't mind both ways

---

as an offtopic:

but I don't think people expect those colors to be used outside of X11 terminals emulators anymore. AFAIK, no toolkit still use them.

IIRC kde sets at least *background and *foreground in xrdb
and in general the point what no toolkit does that is not really good, because for example per-screen dpi wasn't supported in any of the toolkits when it was implemented in awesome and only a bit later it appeared in Qt

[psychon]

Reporter vanished ("I will try later this day" four months ago), the discussion went a bit off-topic and the issue should already be fixed in master (but not in 3.5). Closing.

[l0b0]

Any idea when this will be released? Building awesome-git in Arch Linux seems to be broken ATM.

[psychon]

The comment with -DGENERATE_DOC=False is right. Since Arch doesn't have a non-broken ldoc, disabling doc generation is needed.

[l0b0]

Where do I have to put -DGENERATE_DOC=False?

[psychon]

It is an argument to cmake, so inside of the PKGBUILD: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=awesome-git#n47
Edit: And when you edit it, you can as well drop the dependency on ldoc.

[l0b0]

Thanks, that got me some way further towards compiling. After installing xcb-util-xrm I'm still getting this error:

$ makepkg --syncdeps --install
[…]
[  3%] Linking C executable awesome
CMakeFiles/awesome.dir/awesome.c.o: In function `main':
awesome-git/src/build/awesome.c:620: undefined reference to `xcb_xrm_database_from_default'
awesome-git/src/build/awesome.c:622: undefined reference to `xcb_xrm_database_from_string'
CMakeFiles/awesome.dir/xrdb.c.o: In function `luaA_xrdb_get_value':
awesome-git/src/build/xrdb.c:42: undefined reference to `xcb_xrm_resource_get_string'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/awesome.dir/build.make:1113: awesome] Error 1
make[1]: *** [CMakeFiles/Makefile2:70: CMakeFiles/awesome.dir/all] Error 2
make: *** [Makefile:128: all] Error 2

Do you know if Awesome is compatible with xcb-util-xrm 1.0-3, which is what is currently in Arch Linux?

[actionless]

remove build files and try again, i've noticed the same problem when was building it with xrm patch for the first time

[l0b0]

Thank you, that worked! Now for running it:

$ Xephyr :30 -screen 1024x768 &
$ DISPLAY=:30 download/awesome-git/pkg/awesome-git/usr/bin/awesome &
[…]
error while running function!
stack traceback:
        /usr/share/awesome/lib/awful/tag.lua:635: in main chunk
        [C]: in function 'require'
        /usr/share/awesome/lib/awful/client.lua:9: in main chunk
        [C]: in function 'require'
        /usr/share/awesome/lib/awful/init.lua:12: in main chunk
        [C]: in function 'require'
        /etc/xdg/awesome/rc.lua:3: in main chunk
error: /usr/share/awesome/lib/awful/tag.lua:635: attempt to call a nil value (method 'add_signal')
2016-11-03 22:29:47 E: awesome: main:732: couldn't find any rc file

I have a working ~/.config/awesome/rc.lua. Adding --config ~/.config/awesome/rc.lua did not help.

(Also, please let me know if this is not the right place for this extended help session.)

[blueyed]

Hmm, the line does not match?!
It is not that one:
https://github.com/awesomeWM/awesome/blob/0e81479a3f905f4551c88e4ad480972f1a9cff7b/lib/awful/tag.lua#L635 ?!

function tag.getmwfact(t)
    util.deprecate("Use t.master_width_factor instead of awful.tag.getmwfact")

    return tag.object.get_master_width_factor(t or ascreen.focused().selected_tag)
end

[blueyed]

But let's stop spamming this issue: please create a new one, or ask on IRC.

[l0b0]

Thank you; I can confirm that font scaling does work on an up-to-date Arch Linux. I've reported a minor issue with the square in the corner of the tag indicators separately.

[kierun]

Any idea when a new release of Awesome will happen so that this change can filter into Fedora? Currently, the Fedora package installs version 3.5.9 (Mighty Ravendark).

[psychon]

Right now there seem to be many people with not enough time to work on the remaining issues. So sorry, but no, I cannot answer that question.
(Remaining things are mostly minor stuff that anyway has to be done)

[kierun]

@psychon Thank you. I was just curious, nothing bad implied. ☺