python-wnck removed in Ubuntu 18.04

[bl4ck5un]

python-wnck is no longer available in Ubuntu 18.04. I'm using the package from artful (17.10) as a workaround. Would be great to know how to install quicktile properly in 18.04.

[ssokolow]

Ahh, yes. That's a known regression. The GTK+ 2.x version used gtk.gdk.Region to figure out what parts of the screen were usable but GTK 3.x replaced it with cairo.Region and the GIR-accessible APIs are a broken mess.

I have no experience implementing something like gtk.gdk.Region and I was stuck on figuring out an internal representation which would allow me to sanely do useful tiling operations on things like "A rectangle, but with the corner nipped out".

I had to write my own Rectangle, UsableRegion, and StrutPartial classes and, in order to get something usable out by New Years, I had to regress the layout calculations to a per-monitor version of _NET_WORKAREA, which returns a rectangle.

[torsava]

I wanted to test this on Fedora 31, but I was not able to find these two dependencies: gir1.2-gtk-3.0 gir1.2-wnck-3.0. I've tried running it without them, but it doesn't work without wnck (at least):

...
  File "/home/torsava/bin/quicktile/quicktile/quicktile/__main__.py", line 17, in <module>
    gi.require_version('Wnck', '3.0')
  File "/usr/lib64/python3.7/site-packages/gi/__init__.py", line 133, in require_version
    (namespace, version))
ValueError: Namespace Wnck not available for version 3.0

I tried looking for wnck for Python 3, but I don't think it's available at all:

$ sudo dnf search wnck
Last metadata expiration check: 2:07:56 ago on Thu 02 Jan 2020 11:35:12 AM CET.
======================================================================= Name & Summary Matched: wnck ========================================================================
libwnck-devel.x86_64 : Libraries and headers for libwnck
libwnck-devel.i686 : Libraries and headers for libwnck
libwnck3-devel.i686 : Libraries and headers for libwnck
libwnck3-devel.x86_64 : Libraries and headers for libwnck
gnome-python2-libwnck.x86_64 : Python bindings for interacting with libwnck
============================================================================ Name Matched: wnck =============================================================================
libwnck.x86_64 : Window Navigator Construction Kit
libwnck.i686 : Window Navigator Construction Kit
libwnck3.i686 : Window Navigator Construction Kit
libwnck3.x86_64 : Window Navigator Construction Kit
perl-Gnome2-Wnck.x86_64 : Perl interface to the Window Navigator Construction Kit

I also haven't found it using pip (PyPI).

[ssokolow]

@torsava That's because gir1.2-wnck-3.0 isn't a Python-specific dependency.

With Python 2.x and PyGTK, each library had to have a specific Python binding. With Python 3.x and the approach that only really got fully debugged in GTK+ 3, each library has a language-agnostic GObject Introspection (GIR) definition file, then PyGI just knows how to read any GIR metadata you might have installed.

It's probably bundled into libwnck3.x86_64 alongside the library itself.

I'm assuming Debian doesn't do that because it'd be wasted space if all your applications are written in languages like C and C++ where the GIR metadata is only needed at compile time.

You probably don't need to worry about gir1.2-gtk-3.0 because gi.require_version('Gtk', '3.0') comes before gi.require_version('Wnck', '3.0') in that QuickTile file and it didn't complain. If you check which package provides /usr/lib/x86_64-linux-gnu/girepository-1.0/Gtk-3.0.typelib and that'll tell you how Fedora packages the files Debian put in gir1.2-gtk-3.0 which, in turn, should tell you where to look for the equivalent file for Wnck.

Once you find it, let me know which packages need to be installed so I can re-add Fedora to the README.

[timwhite]

@ssokolow Thanks for the work on this! It feels great to have quicktile again under 18.04. It's working a treat for me. :smile:

[torsava]

@ssokolow I see, interesting system. The paths on Fedora are slightly different, but I found the packages:

$ rpm -qf /usr/lib64/girepository-1.0/Gtk-3.0.typelib
gtk3-3.24.13-1.fc31.x86_64
$ rpm -qf /usr/lib64/girepository-1.0/Wnck-3.0.typelib
libwnck3-3.32.0-2.fc31.x86_64

So the final list of dependencies on Fedora 31 is:

python3 python3-pip python3-setuptools python3-gobject python3-xlib python3-dbus gtk3 libwnck3

And it works like a charm! Thank you so much for your work!

[ssokolow]

@torsava

I see, interesting system.

It's basically the bindings equivalent to the Language Server Project. Instead of M*N bindings, one per language-library combo, you have M+N bindings, where each library exposes bindings to some intermediate interface definition language layered on top of a stable C ABI and then each language can write a loader or code generator that can work with anything for that IDL and automatically gain access to the whole ecosystem.

And it works like a charm! Thank you so much for your work!

Glad to hear it.

As someone whose last RPM-based distro was Mandrakelinux 10.1, I have one more question. What's the complete command that's currently recommended for installing that set of packages on Fedora? (If following Phoronix has taught me one thing, the answer to that question has changed over the years.)

I'll push an update to the README as soon as I get it.

[ssokolow]

Oh, also, what Fedora package provides Gio-2.0.typelib? I'm planning to retire python3-dbus in favour of the more modern (and more likely to be installed by default) GDBus via python3-gobject at some point and it wouldn't do to just assume that it'll be a dependency of gtk3.

[torsava]

@ssokolow Yeah, the binding system sounds awesome!

The full command to install the dependencies is:

sudo dnf install python3 python3-pip python3-setuptools python3-gobject python3-xlib python3-dbus gtk3 libwnck3

And Gio-2.0.typelib is provided by the gobject-introspection package. Thanks for supporting Fedora!

[ssokolow]

Yeah, the binding system sounds awesome!

I just wish Qt would retrofit it or something similar onto their QWidget API. I'm not a fan of the direction GNOME has taken GTK+ 3 and Rust has no mature QWidget bindings.

(The only thing that kept me from following the LXDE guys in upgrading QuickTile from GTK+ 2.x to Qt 5 is that the Qt ecosystem appears to have no libwnck equivalent. As-is, as soon as I have PPA experience from QuickTile work, I need to make a PPA for gtk3-mushrooms.)

And Gio-2.0.typelib is provided by the gobject-introspection package.

Hmm. Is there a site equivalent to http://packages.debian.org/ and https://packages.ubuntu.com/ where I can check what else is inside gobject-introspection? (That's actually one of my biggest unsolved gripes with RPM-based distros. I can never seem to find a good equivalent to those two sites.)

The fact that the Gio GIR file isn't part of a glib or gio package makes me worry that one of the Gtk and Gdk GIR files (or something else I depend on) may also be in there.

[torsava]

Hmm. Is there a site equivalent to http://packages.debian.org/ and https://packages.ubuntu.com/ where I can check what else is inside gobject-introspection? (That's actually one of my biggest unsolved gripes with RPM-based distros. I can never seem to find a good equivalent to those two sites.)

The main go-to page is Fedora Pagure: https://src.fedoraproject.org/rpms/gobject-introspection

From there you can either go to Files -> open the spec file and read how the package is built: https://src.fedoraproject.org/rpms/gobject-introspection/blob/master/f/gobject-introspection.spec

Or better yet in this case, click on Packages -> Contents and you can directly see the files contained in there: https://apps.fedoraproject.org/packages/gobject-introspection/

[ssokolow]

The main go-to page is Fedora Pagure: https://src.fedoraproject.org/rpms/gobject-introspection

Thanks. For some reason, that never seems to turn up in my searches. Instead, I get RPM-ecosystem search engines and hosts for analogues to PPAs and non-default ebuild sources.

Or better yet in this case, click on Packages -> Contents and you can directly see the files contained in there: https://apps.fedoraproject.org/packages/gobject-introspection/

Thanks. It looks like it's an interesting grab-bag of everything GTK depends on that isn't part of the GTK package itself, so I would have been depending on it if the bindings to Cairo's cario.Region weren't such a mess that I had to find an alternative solution for replacing gtk.gdk.Region.

[ssokolow]

Done. The README has been updated.

[ssokolow]

OK, I'm back to working on this and I'm part-way through converting the documentation to Sphinx to get rid of the last Python 2.x dependency.

@fidergo-stephane-gourichon Would you mind opening a separate issue for https://github.com/ssokolow/quicktile/issues/95#issuecomment-570089109 to make sure that it doesn't get lost in the shuffle?

[ssokolow]

Status Update: The Sphinx rework of the documentation is coming along nicely.

I don't want to git push until I've got everything from http://ssokolow.com/quicktile/ adapted so I can update gh-pages at the same time, but:

1. I ported the basic look and feel of the existing site onto Sphinx's Alabaster theme to maintain a sense of continuity with so much else changing.
2. I managed to keep all the URLs listed on the landing page unchanged. (I'm still trying to decide whether I prefer simple filenames or continuity of URLs more in naming the per-module API documentation pages. At the moment, I'm using simple filenames.)
3. I've expanded the keybinding syntax guide from the README into a full reference for the configuration file.
4. The command guide now has illustrations for all commands except the ones relating to workspaces (where I still need to brainstorm how to depict that).

Here's a preview of the progress so far:

I still want to:

• Finish translating over the stuff from the landing page of the site
• Incorporate the MyPy annotations to bring the amount of information it provides back up to parity with ePyDoc. (At the moment, it's still running on the common subset of ePyDoc and Sphinx's understanding of reStructuredText.)
• Move as much of the rest of the README into the Sphinx manual as I feel is doable without making the README do a poor job of selling QuickTile to people who land there. (At the very least, I want full "Installation" and "Usage" sections in the manual.)

I'm also considering switching to ReadTheDocs-hosted documentation and just hosting some <meta http-equiv="refresh" content="0;url=... pages at http://ssokolow.com/quicktile/ so I don't have to do anything fancy to get automatic regeneration of the docs when I push an update.

EDIT: Never mind. I'll stick to generating my own docs and read up on how to use Travis-CI for deployment to gh-pages. That amount of initial extra setup is worth sticking to my principles about keeping my project sites ad-free. (Docs for libraries, on the other hand, I'm willing to mirror to RTD for availability and discoverability.)

[fidergo-stephane-gourichon]

@fidergo-stephane-gourichon Would you mind opening a separate issue for #95 (comment) to make sure that it doesn't get lost in the shuffle?

Done. #108

[ssokolow]

Another status update:

• There is now 100% illustration coverage on the command reference.
• The API documentation is now all polished up (and full of convenient cross-referencing hyperlinks for easy onboarding if you want to hack on the code) and I fixed up some other code smells I noticed while doing that.
• There's now a "Command-Line Arguments" documentation page generated from the argparse definition, which has also been plumbed into cd docs; make man.

The main remaining things that need to be done in the manual are:

• Integrating the rest of the stuff from the current landing page and README
• Adding an "Installation" section to the manual
• Adding a "Usage" section to the manual

I did accidentally introduce and almost not catch a bug in wm.WindowManager while fixing the code smells so I may decide to make at least a little progress on the functional testing before I git push the changes I've been accumulating.

[ssokolow]

...and, since I got so much done, another one quick on its heels.

• The "Installation" and "Usage" sections are done.
• The README has been pruned down so each section is just the most common case and a link to the manual for alternatives. I also adjusted the phrasing to be simple and concise.
• I made various tweaks to improve the aesthetics of the rest of the docs and fixed various typos and flaws I managed to shake out.
• I bashed together a custom Sphinx directive to get the pretty-printing behaviour I wanted out of quicktile.__main__.DEFAULTS.

All that should be left now is the existing site's landing page and the aforementioned "maybe some work on functional testing" before I git push the changes. I'll see how much of that I can fit in tomorrow.

[ssokolow]

OK. I've just got one more little bit to migrate over on the docs, and then I'll decide whether to do that little bit of functional test improvement or just git push without it.

I did a lot of stuff (including writing a basic Developer's Guide section, polishing up the mobile and print stylesheets, and fixing some accessibility flaws baked into the defaults in Sphinx's Alabaster theme), so I'll just put up a screenshot as a preview:

...and yes, that illustration is a GIF that acts like a hand-drawn screencast. (All 65KiB of it.)

[ssokolow]

Done. The changes are now pushed to the gtk3_port branch. My next goals will be to resolve regressions #107 and #108 and issue #45 (a partial workaround for which didn't get ported to the GTK+ 3.x version) so I can merge this into master as soon as possible.

If anyone wants to look at the manual, you can generate it by installing the Sphinx-related packages in dev_requirements.txt and then running (cd docs; make html).

(If you're just curious about the animation, it's at docs/animation/animation.gif with no build process needed.)

EDIT: Oh, and hacking together a quick and dirty test window for the functional test harness did prove worthwhile. It turns out that python-xlib sometimes fails to expose the Xinerama method for querying the number of monitors. No clue why, but I switched to using GDK's wrapper for it.

EDIT: I figured out the problem I'd fixed. It was "QuickTile will crash on attempting to retrieve the number of monitors if the X server doesn't have the XINERAMA extension enabled because python-xlib doesn't provide a dummy 'query number of monitors' function that always returns 1 like GDK does." (I also enabled Xinerama in my test harness.)

[ssokolow]

OK. The 0.4.0 release candidate is now in the gtk3_port branch. Please everyone try it out and let me know if you encounter any problems.

[ssokolow]

I just ran into a problem (#109) which made me realize a feature change I should do (#110) and another bug to be fixed (#111) but, since #109 is a heisenbug I can't reproduce and I think the GTK+ 2.x version didn't do any better on #111, I'm not letting them block the 0.4.0 release.

Barring unexpected demands on my time, I hope to have 0.4.0 tagged and pushed to master in time for the "14 days ago" anniversary of 0.4.0 entering release candidate status.

[ssokolow]

Done. The gtk3_port branch has been merged to master, the new site is now live (and auto-generated from master on every push if the tests pass via Travis-CI's deployment support), and I'll be removing the gtk3_port branch momentarily.