Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Awesome 4.3: beautiful.gtk is not supported #60538

Closed
stefano-m opened this issue Apr 30, 2019 · 5 comments · Fixed by #61161
Closed

Awesome 4.3: beautiful.gtk is not supported #60538

stefano-m opened this issue Apr 30, 2019 · 5 comments · Fixed by #61161

Comments

@stefano-m
Copy link
Contributor

Cc: @dtzWill

Issue description

First of all, thanks to everyone for working on NixOS.

Awesome 4.3 has a module called beautiful.gtk, it allows

Querying current GTK+ 3 theme via GtkStyleContext.

It can be used for theming, as shown in Awesome's example gtk theme.

However, the current build does not include the typelib files needed by the module making it unusable.

Investigation

The beautiful.gtk implementation uses lgi to obtain Gtk via gobject-introspec

    return require('lgi').Gtk

Since the current build does not include the typelib files needed, the above call fails.

After some experimentation, I found out that both gtk3-x11 and atk are needed.

For example:

  1. run lua and try to load Gtk: fails with Typelib file for namespace 'Gtk' (any version) not found
$ lua
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> Gtk = require('lgi').Gtk
...26fkq-lua5.2-lgi-0.9.2-1/share/lua/5.2/lgi/namespace.lua:158: Typelib file for namespace 'Gtk' (any version) not found
stack traceback:
        [C]: in function 'assert'
        ...26fkq-lua5.2-lgi-0.9.2-1/share/lua/5.2/lgi/namespace.lua:158: in function <...26fkq-lua5.2-lgi-0.9.2-1/share/lua/5.2/lgi/namespace.lua:155>
        (...tail calls...)
        stdin:1: in main chunk
        [C]: in ?
>
  1. install gtk3-x11 (the package that actually includes the typelib file) and add the girepository-1.0 folder to the GI_TYPELIB_PATH environment variable: fails with Typelib file for namespace 'Atk', version '1.0' not found
$ nix-env -iA nixpkgs.gtk3-x11
$ export GI_TYPELIB_PATH=/nix/store/nav1j5p1ac814y47ngiapwzdk75hzly5-gtk+3-3.24.5/lib/girepository-1.0:$GI_TYPELIB_PATH
$ lua
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
>
> g = require('lgi').Gtk
...26fkq-lua5.2-lgi-0.9.2-1/share/lua/5.2/lgi/namespace.lua:158: Typelib file for namespace 'Atk', version '1.0' not found
stack traceback:
        [C]: in function 'assert'
        ...26fkq-lua5.2-lgi-0.9.2-1/share/lua/5.2/lgi/namespace.lua:158: in function <...26fkq-lua5.2-lgi-0.9.2-1/share/lua/5.2/lgi/namespace.lua:155>
        (...tail calls...)
        stdin:1: in main chunk
        [C]: in ?
>
  1. install atk and add it to GI_TYPELIB_PATH and finally Gtk loads.

Steps to reproduce

  1. start Awesome as window manager
  2. modify ~/.config/awesome/rc.lua to load the example gtk theme
beautiful.init(
  gears.filesystem.get_themes_dir() .. "gtk/theme.lua"
)
  1. restart awesome
  2. observe the warnings issues by Awesome:
$ journalctl --user --since=today | grep 'GTK'
xsession[28002]: W: awesome: Can't load GTK+3 introspection. Seems like GTK+3 is not installed or `lua-lgi` was built with an incompatible GTK+3 version.
xsession[28002]: W: awesome: Can't load GTK+3 theme. Using 'xresources' theme as a fallback.

Possible solution

I suggest that both atk and gtk-x11 are added as build inputs to the awesome package, I tried this out and it actually works. The catch is that the closure size increases by 123.9M:

  • build awesome without gtk3-x11 and atk
    nix path-info ./result | grep awesome-> 99.6M

  • build awesome with gtk3-x11 and atk
    nix path-info ./result | grep awesome -> 223.4M

So, instead of adding the packages unconditionally, we could add an optional flag, like e.g. withGtkSupport, defaulting to false. In this way, one could always build awesome and add it to services.xserver.windowManager.awesome.package. Ideally one could even add something like awesome-gtk3 to the top level nixpkgs, a bit like gtk3-x11:

gtk3-x11 = gtk3.override {
x11Support = true;
};

If a decision is made, I'd be happy to submit a PR.

Technical details

  • system: "x86_64-linux"
  • host os: Linux 4.19.36-hardened, NixOS, 19.03.172361.cf3e277dd0b (Koi)
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.2.2
  • channels(root): "nixos-19.03.172361.cf3e277dd0b"
  • channels(user): "unstable-19.09pre177249.dfd8f84aef1"
  • nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

awesome 4.3 (Too long)

  • Compiled against Lua 5.2.4 (running with Lua 5.2)
  • D-Bus support: ✔
  • execinfo support: ✔
  • xcb-randr version: 1.6
  • LGI version: 0.9.2
@jtojnar
Copy link
Member

jtojnar commented Apr 30, 2019

It should not be necessary to use gtk3-x11, gtk3 should work just fine.

See #43150 for docs on wrapGAppsHook, which will populate the environment variable automatically.

@stefano-m
Copy link
Contributor Author

Thanks, I'll have a look. For the record, I used gtk3-x11 because that's where nix-locate told be the typelib files where.

I am still keen on hearing what the correct solution would be regarding how to add support (closure size, optional arguments etc.).

Thanks.

@stefano-m
Copy link
Contributor Author

@jtojnar thanks for our suggestions. Here are my thoughts:

  1. using gtk3 seems to work as well, the closure size is 222.9M instead of 223.4M
  2. wrapGAppsHook seems quite conveniet, but awesome needs additional --search options in the wrapper and it's unclear to me whether we could do that after introducint wrapGAppsHook
  3. wrapGAppsHook uses wrapProgram that seems to have negative effects, see Awesome Window Manager appends same options to command line upon restarts #60229 so we may have to look for alternative solutions anyway (Awesome does not seem to use much of GTK anyway as it's not a GTK app)

@jtojnar
Copy link
Member

jtojnar commented May 2, 2019

  1. weird how could it shrink?
  2. You can use gappsWrapperArgs as described in the doc PR to add more options.
  3. Yeah, I am aware of that but other than hardcoding the typelibs like we do in GNOME Shell extensions, we do not have anything better at the moment. See General problems with environment variable wrappers #60260 for deeper analysis.

@stefano-m
Copy link
Contributor Author

weird how could it shrink?

¯_(ツ)_/¯ maybe it's got less dependencies built than the gtk3-x11 one?

You can use gappsWrapperArgs as described in the doc PR to add more options.

I see, I somehow missed that.

Yeah, I am aware of that but other than hardcoding the typelibs like we do in GNOME Shell extensions, we do not have anything better at the moment.

It seems that makeWrapper works OK (I am using this in an overlay on NixOS waiting for the patches to land in the stable channel):

#60229 (comment)
https://github.com/stefano-m/nixpkgs/commit/8708123689798d076df0031571e6888495e83aa8
https://github.com/stefano-m/nixpkgs/commit/42351c50c08ce866cbc90ad52c263482533622b3

In the end, AwesomeWM should not need the whole of gtk, I think that gtk should be made optional so one can turn it on or off.

See #60260 for deeper analysis.

Thanks, I did notice that and I'll keep an eye on it

tadeokondrak pushed a commit to tadeokondrak/nixpkgs that referenced this issue May 17, 2019
Add optional gtk3 support to Awesome so that the `beautiful.gtk` module can be
used.

The `beautiful.gtk` uses `lgi` to obtain Gtk via gobject-introspect:

    return require('lgi').Gtk

Since the current build does not include the typelib files needed, the above
call fails.

It turns out that both `gtk3` and `atk` (Accessibility toolkit) are needed, so
this commit adds them as optional build inputs.

Setting `gtk3Support` to `true` e.g. in an overlay will make `beautiful.gtk`
work at the cost of an increased closure size (currently 99.6M vs 223.4M).

Fixes NixOS#60538
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants