lithium: Port bl-xinerama-prop to py3/gtk3 & implement bl-reload-gtk23

[ghost]

• Port bl-xinerama-prop to Python 3, and drop all dependencies on GTK2 libraries in favour of python-gi, the new "standard" Python interface to GTK objects. pygtk is dead. Works now on X11 as usual (based on the DISPLAY environment variable) but also on Wayland.
• Implement bl-reload-gtk23: Method to notify GTK2/3 clients of changed configuration settings / theming information. For GTK2, we re-implement the notification algorithm strictly based on Xlib functions as current pygobject does not support GTK2, and pygtk only supports py2 which we want to drop. The implementation is equivalent to the one found in libgdk2. For GTK3, we implement only the xsettingsd-based notification method. In either case, we won't update any settings/RC files for the calling application. This tool is used from bl-obthemes instead of relying on pygtk2. This tool is expected to exit with non-zero exit codes on partial success (for example, if only gtk2 reload). The exit codes are 0 (both gtk2 & gtk3 reloads succeeded), 1 (gtk2 failed), 2 (gtk3 failed), 3 (both failed).
• Integrate bl-reload-gtk23 with bl-obthemes. bl-obthemes does not implement xsettingsd.conf output in order for GTK3 theme reloading to be effective, but it will make use of the gtk2 theme reloading.

Effectively, we now can drop all py2 dependencies from this package.

[ghost]

• [x] Test bl-xinerama-prop under Wayland => Verified using Fedora 32 Workstation with DISPLAY (from XWayland) unset
• [ ] Test bl-reload-gtk23 with xsettingsd/GTK3 => requires a correct xsettingds.conf which is not written by any BL tools yet. => gtk2 reloading works, tested on lithium test ISO and custom-built package

[ghost]

Utilities that have been touched:

• bl-kb
• bl-obtheme (removed inline python and call bl-reload-gtk23 instead)
• bl-xinerama-prop (rewrite)
• bl-reload-gtk23 (new, used by bl-obtheme)

[ghost]

@johnraff That'd be fine with me. I'll be looking into preserving the commit history in bunsen-common from the affected files here (should be possible using git filter-branch). I'll open a separate PR for b-c and update this one here.

[johnraff]

bl-kb and bl-xinerama-prop tested OK. Now testing bl-reload-gtk23 as discussed here: https://github.com/BunsenLabs/bunsen-common/pull/5

-- One small point: Debian Python Policy deprecates the /usr/bin/env shebang. https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_loc It's up to you though.

[johnraff]

I think the problems I was having with bl-reload-gtk23 were largely because I was mistaking some gtk3 apps for gtk2. Pure gtk2 apps (eg mirage) do indeed immediately reflect edits to .gtkrc-2.0 after running the reload.

Confirmed also that bl-obthemes is working as before when restoring themes. Gtk3 apps like geany needed restarting to show the new theme, and that has not changed.

Now to reinstall xsettingsd and try with gtk3.

[ghost]

On Fri, 15 May 2020, at 04:39, John Crawley wrote:

One small point: Debian Python Policy deprecates the /usr/bin/env shebang. https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_loc It's up to you though.

The point of /usr/bin/env is, as is also implied by that resource, that "python3" is freely looked up in the $PATH.

I reject the Debian suggestion of directly referencing /usr/bin/python3 for 3 reasons:

1. The code is supposed to run anywhere, not just on Debian. Although "python3" maybe present, what about /usr/local/bin/python3? Won't work.

2. The standard/common Python development workflow makes use of venvs, which work by modifying PATH to point to a specifically created and populated directory tree. From inside a venv, /usr/bin/env python3 will therefore correctly use the "python3" provided by the venv. When hard-coding /usr/bin/python3, that wouldn't work and break expectations. It's pretentious (typical Debian) to demand that upstream code conform to Debian policy instead of community standards.

3. When using python3 setup.py install (which we don't provide here, but proper Python packages do -- if more BL code is becoming Python, then that's what I would do -- in fact, I have a branch for that here, but it seems like overkill for the simple scripts with minimal code duplication as they are now) as the Debian dh_python debhelper does to install packages into the build's package root, Python setuptools will adjust the shebangs in all .py files anyway to match the interpreter used to run setup.py, in which case the Debian policy is not just wrong but pointless.

I don't get some of the stuff the Debian folks are writing down. The Debian policy makes sense from a security point of view, because PATH can be spoofed easily. But even then, all points still hold.

[johnraff]

I reject the Debian suggestion of directly referencing /usr/bin/python3

This is fine. I was expecting you'd have some good reasons.

[johnraff]

OK so this PR gets rid of python2 dependencies in bunsen-utilities, supports existing functionality and introduces no regressions. Let's merge it in.

(And think about GTK3 at leisure.)

GitHub is offering a "squash" merge button, but I guess you'd prefer to keep all the commit history intact? If so, I'll checkout your branch, merge locally and push.

[ghost]

@johnraff I have rebased, merged into lithium and pushed it upstream to here. Closing this PR.

I haven't added a tag though - are we ready to release the next changes from this packages?

[ghost]

Nevermind, created the tag 10.2.2-1 myself.

[johnraff]

All the other BL packages that we need for Lithium have now had their changelogs updated, released to the experimental repo and been tagged on GitHub.