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

python-wnck removed in Ubuntu 18.04 #95

Closed
bl4ck5un opened this issue May 1, 2018 · 72 comments
Closed

python-wnck removed in Ubuntu 18.04 #95

bl4ck5un opened this issue May 1, 2018 · 72 comments

Comments

@bl4ck5un
Copy link

bl4ck5un commented May 1, 2018

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
Copy link
Owner

ssokolow commented May 1, 2018

Ahh. I didn't catch that because, as every *buntu upgrade I've ever done has unpredictably broken things, I haven't been able to speculatively budget a huge block of time for an upgrade from 14.04 LTS yet.

I suspect python-wnck is gone because applications are expected to use PyGI and the language-agnostic GObject Introspection bindings for libwnck rather than PyGTK and python-wnck.

The proper solution will be me migrating it to Python 3.x and PyGI when I can spare the time (the API adapter to ease porting PyGTK apps to PyGI segfaults when I hook QuickTile up to it, so I need to do it the long way... which also takes time I haven't had).

@bl4ck5un
Copy link
Author

bl4ck5un commented May 2, 2018

Okay. make sense. I'm not familiar with PyGI etc at all so can't help there. For now, using python-wnck from 17.10 works flawlessly.

@fidergo-stephane-gourichon

If you're reading this because you just want a python-wnck that work on Ubuntu Bionic Beaver 18.04, download it for your architecture from https://packages.ubuntu.com/artful/python-wnck . Thanks @bl4ck5un for the tip!

To @ssokolow: thanks for all.

It seems python-wnck package was removed a month ago, ref https://launchpad.net/ubuntu/bionic/amd64/python-wnck with reference to https://bugs.launchpad.net/ubuntu/+source/gnome-python-desktop/+bug/1739797

gnome-python-desktop was recently removed from Debian Testing since it is GNOME2 tech that has been unmaintained for years.

@Falieson
Copy link

Falieson commented Jun 7, 2018

sudo sh -c "echo 'deb http://cz.archive.ubuntu.com/ubuntu artful main universe' >> /etc/apt/sources.list" 

then you can run the apt install command

EDIT by ssokolow: For people who don't scroll down to my reply, don't use > unless you're echoing to a brand new file in /etc/apt/sources.list.d/ or you'll wipe out your regular list of package sources. >> will append instead.

@perlun
Copy link

perlun commented Jul 8, 2018

The situation is the same with Debian Testing (Buster) which is what Ubuntu 18.04 is based on; python-wnck is unavailable. But, it's available in Debian Unstable i.e. sid - those of you running Debian Testing can download the sid/stretch packages here: https://packages.debian.org/sid/python-wnck and https://packages.debian.org/stretch/python-wnck

@fidergo-stephane-gourichon

It looks like there is a way to directly have wnck available from python without dedicated python-wnck package, using the GObject introspection infrastructure. Details are on https://stackoverflow.com/a/43349245/1429390

apt-get install python3-gi gir1.2-wnck-3.0

then

>>> import gi
>>> gi.require_version('Wnck', '3.0')
>>> from gi.repository import Wnck

@ssokolow
Copy link
Owner

ssokolow commented Jul 25, 2018

I've been aware of that for a while, but there are three problems with it:

  1. That's libwnck 3.x, which is for GTK+ 3.x, while QuickTile is a GTK+ 2.x application.
  2. I don't think it's possible to mix PyGTK and PyGI in the same event loop and, even if it is, it's likely to introduce random crashes.
  3. I've tried to start porting from PyGTK to PyGI in the past, but, when I just swapped in the API shim PyGI provides to ease porting of PyGTK apps, I got segfaults on my *buntu 14.04 LTS system.

Basically, while I do eventually want to use that, it requires a very involved porting process that I'm still trying to make time for:

  1. Port from Python 2.x to Python 3.x, because Python 2.x is soon to be end-of-lifed
  2. Port from PyGTK to PyGI, because PyGTK is end-of-lifed
  3. Port from GTK+ 2.x to GTK+ 3.x, because GTK+ 2.x is end-of-lifed (that's why libwnck 2 is going away)

...and since PyGTK isn't available for Python 3.x and PyGI's support for GTK+ 2.x is flaky at best, I have to do it all at once.

(And it's impossible to keep it working during the intermediate steps so I can port incrementally and test for bugs along the way. It many ways, the complexity approaches a complete rewrite and, if there were a suitable equivalent to libwnck in the Qt ecosystem, I'd probably port to PyQt 5 instead.)

I'd hoped to write an automated test suite first, but other things kept cropping up.

@tonoono
Copy link

tonoono commented Jul 28, 2018

For those that want to add the artful repo as mentioned by @Falieson I would recommend using the following command:

sudo sh -c "echo 'deb http://cz.archive.ubuntu.com/ubuntu artful main universe' >> /etc/apt/sources.list"
Make sure that you have two >> and not just one > The reason being that > will overwrite the file, but >> will append it to the end of the file. Trust me you don't want to wipe out your /etc/apt/sources.list file. I got my setup running using @Falieson command (thanks!) and my little tweak.

@ssokolow
Copy link
Owner

I recommend adding a file to /etc/apt/sources.list.d instead. That way, you're not even touching sources.list.

sudo sh -c "echo 'deb http://cz.archive.ubuntu.com/ubuntu artful main universe' > /etc/apt/sources.list.d/artful-main-universe.list"

@kbsali
Copy link

kbsali commented Nov 5, 2018

@ssokolow obviously same issue on 18.10,
any plan on fixing this? (maybe you are not an Ubuntu user!? :) )

@peteruithoven
Copy link

I wasn't really looking forward to play around with sources so I've figured out a crude way of doing quarter tiling using this script:
https://gist.github.com/peteruithoven/db0cba0b0849c8cb5e267f6e75126304
You'll have to adapt some values based on your screen size, top panel size, window margins etc. The default window margins are elementary OS specific for example.

@kbsali
Copy link

kbsali commented Nov 5, 2018

@peteruithoven nice, although this looks very very basic! :) quicktile does a lot more than just quarter tile! I've been using quicktile for years now and couldn't find a better option (I'm biased & used to it). You script looks good for 1 single "fixed" monitor, I use it on my laptop which I connect to different external devices.

@ssokolow
Copy link
Owner

ssokolow commented Nov 5, 2018

@kbsali Oh, I certainly intend to fix it.

It's just that my life has been so busy lately that I'm still on Kubuntu 14.04 LTS despite its support period ending in only a few months.

The problem is that switching to what's supported in newer releases requires a port from GTK+ 2.x to GTK+ 3.x, and that's more complicated than it sounds because of the need to also port from PyGTK to PyGI. (And staying on Python 2.x initially and using the PyGTK->PyGI porting shim to port in stages is complicated by the fact that, last time I tried that, PyGI segfaulted.)

@ssokolow
Copy link
Owner

ssokolow commented Nov 6, 2018

I had some free time today, so I decided "appears to work, but potentially buggy" is better than "nothing testable", and I've started to work on getting it ported to PyGI and Wnck 2.x.

I'm to the point where the only thing left that static analysis is complaining about is the handful of sparse unit tests I have, which are use GdkRegion for mocking... and there's no apparent "rename X to Y" porting path for that, so I'll need a little more time to rewrite the relevant bits.

UPDATE: ...and manual testing reminded me of how heavily I use GdkRegion in the code without directly referencing the type name. Time to figure out what the APIs which used to return it are returning now.

UPDATE: To clarify, GdkRegion was replaced with cairo_region_t, but I'm having trouble figuring out how to access it via a Python binding. (The API exposed by PyGI doesn't seem to have a way for me to instantiate one and I'm still on PyCairo 1.8.8, when cairo.Region didn't get exposed until 1.11.0.)

@ssokolow
Copy link
Owner

ssokolow commented Nov 9, 2018

I decided I'll just leave the GTK+ 2.x version easily accessible in a branch for anyone needing pre-1.11.0 PyCairo, so I upgraded my copy of PyCairo and I've continued to work on the porting to GTK+ 3.x.

Still not complete enough to run without dying from "no such method" errors, but progress is being made.

@kbsali
Copy link

kbsali commented Nov 10, 2018

Great news, thanks for the effort! 💪

@fidergo-stephane-gourichon

Download python-wnck for 18.10

I've been, trying Xubuntu 18.10.
The link I mentioned above is already broken because artful is considered an old release.
You can now find a version for your architecture on:
http://old-releases.ubuntu.com/ubuntu/pool/main/g/gnome-python-desktop/

Fail?

But... it did not work for me. Why? See commands and error below.

# I issued those commands (success, result hidden).
wget http://old-releases.ubuntu.com/ubuntu/pool/main/g/gnome-python-desktop/python-wnck_2.32.0-0ubuntu6_amd64.deb
sudo dpkg --install python-wnck_2.32.0-0ubuntu6_amd64.deb 

# I then ran quicktile which failed, see output.
quicktile --daemonize 

Traceback (most recent call last):
  File "/usr/local/bin/quicktile", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3105, in <module>
    @_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3089, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3118, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 578, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 895, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 781, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'python-wnck' distribution was not found and is required by QuickTile

Release info

lsb_release -a

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.10
Release:	18.10
Codename:	cosmic
uname -a

Linux myhostname 4.18.0-11-generic #12-Ubuntu SMP Tue Oct 23 19:22:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Package info

dpkg -L python-wnck 

/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python-wnck
/usr/share/doc/python-wnck/AUTHORS
/usr/share/doc/python-wnck/examples
/usr/share/doc/python-wnck/examples/wnck_example.py
/usr/share/doc/python-wnck/NEWS.gz
/usr/share/doc/python-wnck/copyright
/usr/share/doc/python-wnck/README
/usr/share/doc/python-wnck/changelog.Debian.gz
/usr/share/pyshared
/usr/share/pyshared/gtk-2.0
/usr/lib
/usr/lib/pyshared
/usr/lib/pyshared/python2.7
/usr/lib/pyshared/python2.7/gtk-2.0
/usr/lib/pyshared/python2.6
/usr/lib/pyshared/python2.6/gtk-2.0
/usr/lib/python2.7
/usr/lib/python2.7/dist-packages
/usr/lib/python2.7/dist-packages/gtk-2.0
/usr/lib/python2.7/dist-packages/gtk-2.0/wnck.so
/usr/lib/python2.6
/usr/lib/python2.6/dist-packages
/usr/lib/python2.6/dist-packages/gtk-2.0
/usr/lib/python2.6/dist-packages/gtk-2.0/wnck.so
/usr/lib/pyshared/python2.7/gtk-2.0/wnck.so
/usr/lib/pyshared/python2.6/gtk-2.0/wnck.so

@ssokolow
Copy link
Owner

ssokolow commented Nov 28, 2018

It looks like setuptools (the thing which generates the /usr/local/bin/quicktile launcher) isn't seeing python-wnck for some reason.

Does running python2 -m quicktile --daemonize (which should bypass that aspect of setuptools) work?

If so, three options come to mind:

  1. Just run that instead
  2. Uninstall and reinstall QuickTile to see if setuptools will un-confuse itself.
  3. Uninstall QuickTile, remove the test_for_imports("wnck", "python-wnck", "python-wnck") line from setup.py, and then reinstall it so that the dependency on python-wnck is invisible to setuptools.

(For the record, I am still working on the port to GTK+ 3.x which will resolve this mess, but things got a little busy so I haven't had time to figure out how to port over a line which got horrendously ugly in the switch from PyGTK to PyGI.)

@fidergo-stephane-gourichon

Hi @ssokolow and thank you for reaching back.

At the moment I can just confirm that python2 -m quicktile --daemonize just works, while running only quicktile --daemonize still fails with the same error message.

I hope I'll try the other steps soon, too.

@fidergo-stephane-gourichon

Hi @ssokolow

Uninstall and reinstall QuickTile to see if setuptools will un-confuse itself.

It appeared to have un-confused itself. Now just running quicktile works.

You will find a slightly edited version of my terminal log (converted from ANSI color to HTML for reading comfort) here: https://gourichon.org/fsi/quicktile/unconfuse_log.html

Reading not only may help you (1) figuring out what became confused, but as it shows the kind of thing that actually happens when trying to follow installation instructions, it might (2) provide insights on how to adjust installation programs or human-readable instructions for maximum efficiency given the variety of people that may follow them.

Thanks again and keep up the good things!

@ssokolow
Copy link
Owner

ssokolow commented Dec 4, 2018

Yeah. I definitely need to make some changes. Here is what I gather from that log:

First, I should have explicitly pointed you at the "Removal" section in the README.

As for the issues you ran into, they seem to mostly fall into two categories:

  1. You used the tooling I provided in an unsupported way without fully understanding what it was doing.
  2. I didn't draw enough attention to the existence of uninstallation instructions.

python2 setup.py install
...
[Errno 13] Permission non accordée: [...]

I can't find any installation instructions where I forgot to say to to either use sudo or to call ./install.sh, which will do it for you, so I can only assume that you copied a line out of install.sh without also copying the earlier line (exec sudo "$0" "$@") which sets up the required environment by re-running install.sh with root permissions if it wasn't run using sudo.

I can't be responsible for things breaking because people copy-pasted random bits of my scripts without understanding what preconditions must be upheld.

sudo python2 setup.py uninstall

[...]

error: invalid command 'uninstall'

Again, you seem to be extrapolating from incorrect assumptions because you didn't know about the "Removal" section at the bottom of the README. I'll have to make it more visible.

sudo pip2 uninstall quicktile

The directory '/home/stephane/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Uninstalling QuickTile-0.3:
/usr/local/lib/python2.7/dist-packages/QuickTile-0.3-py2.7.egg
Proceed (y/n)? ^COperation cancelled by user

I don't know why you cancelled this. You were on the right track.

My best guess is that I should use sudo -H in the instructions so that warning message doesn't pop up and confuse people.

rm: impossible de supprimer '/usr/local/bin/quicktile': Aucun fichier ou dossier de ce type

The locate command doesn't verify that results still exist, so it'll list files that still existed the last time the updatedb cronjob was run. That's why my removal instructions use find instead. It's slower, but doesn't produce potentially confusing results.

rm: impossible de supprimer '/usr/local/share/applications/quicktile.desktop': Aucun fichier ou dossier de ce type

I should consistently use rm -f in my scripts and instructions rather than rm so it won't produce a spurious error message if the file was already removed.

sudo rm /usr/local/bin/quicktile /usr/local/bin/quicktile.py

Removing quicktile.py is just to make sure that ancient single-file versions of QuickTile can't cause problems when someone uses ./install.sh to upgrade. There's a reason it only exists inside install.sh.

sudo: install.sh : commande introuvable

OK, I admit fault here. I never thought to test that sudo "$0" "$@" was robust in the face of less common ways to run install.sh.

landonb added a commit to landonb/reputed-tiler that referenced this issue Jan 5, 2019
- "Crude quarter tiling tool for elementary OS":

    https://gist.github.com/peteruithoven/db0cba0b0849c8cb5e267f6e75126304

  Thank you:

    github.com/peteruithoven

- See also known issue:

    ssokolow/quicktile#95
@realn0whereman
Copy link

realn0whereman commented Apr 19, 2019

sudo sh -c "echo 'deb http://cz.archive.ubuntu.com/ubuntu artful main universe' >> /etc/apt/sources.list" 

then you can run the apt install command

Can you please edit your comment from > to >> ?

@kbsali
Copy link

kbsali commented Apr 29, 2019

Anyone has a solution to work around this without adding an old ppa to my sources?
I managed to install on 18.10, but now that I have upgraded to 19.04 it does not work anymore... :/

@meoso
Copy link

meoso commented Jun 10, 2019

this worked for me today on xubuntu 19.04 (in addition to the pre-reqs):

sudo apt install libpango1.0-0 pip
# used https://pkgs.org to find python-wnck
wget http://ftp.br.debian.org/debian/pool/main/g/gnome-python-desktop/python-wnck_2.32.0+dfsg-3_amd64.deb
sudo dpkg -i python-wnck_2.32.0+dfsg-3_amd64.deb 
sudo -H pip2 install https://github.com/ssokolow/quicktile/archive/master.zip

@ssokolow
Copy link
Owner

ssokolow commented Aug 6, 2019

Just a little status update. Time was such a mess for me that I actually spent some time running Kubuntu 14.04 beyond even the LTS support window. (Yes, yes, I know. Bad programmer, no biscuit. That said, I was un-stupid enough to switch my Firefox from Canonical builds to Mozilla builds to ensure it kept getting security fixes and I make heavy use of things like uMatrix-based whitelisting.)

I'm currently on 16.04 while I squash the bugs, feature regressions, and unacceptable annoyances introduced by switching from Upstart to systemd, from KDE 4 to KDE 5, from a pre-CSD version of GTK+ 3.x to a post-CSD version, and just plain breakages that should be expected because I hacked something the first time rather than doing it properly.

Once that's done and I've finished finding Qt replacements for GTK+ 2.x apps that will go GTK+ 3.x in 18.04, I'll upgrade to 18.04 (16.04 isn't a 5-year-supported LTS like 14.04 and 18.04), squash the hopefully smaller number of bugs there, and then get back to work on QuickTile.

@kbsali
Copy link

kbsali commented Oct 20, 2019

just upgraded to 19.10, good same old game again! 😅
So here is what I did this time :

sudo apt install python-gtk2 python-xlib python-pip libpango1.0-0
wget http://ftp.br.debian.org/debian/pool/main/g/gnome-python-desktop/python-wnck_2.32.0+dfsg-3_amd64.deb
sudo dpkg -i python-wnck_2.32.0+dfsg-3_amd64.deb 
sudo -H pip2 install https://github.com/ssokolow/quicktile/archive/master.zip

@ssokolow
Copy link
Owner

ssokolow commented Oct 31, 2019

Another status update. I've been working on this, but it's slow going because I'm still on Kubuntu 16.04 and the GTK+ 3.x and Cairo bindings appear to be broken, so I'm limited in which parts of QuickTile's codebase I can actually work on and test.

(Specifically, cairo.Region and Gdk.Rectangle seem to have no way to construct them directly and what I was able to dig up indicates that this is a bug in the API definitions... and those are pretty central to something like QuickTile.)

Since I'm still not ready to jump up to 18.04 and beyond, I may have to install something newer in a VM and develop in that to get the port done in reasonable time.

@kbsali
Copy link

kbsali commented Nov 1, 2019

This is of course none of my business, but why are you "stuck" on very old versions of Ubuntu? Nowadays the upgrade processes are pretty smooth! :)

@fidergo-stephane-gourichon

Thanks a lot for this work! This new branch works perfectly for me on Xubuntu 19.10.

@ssokolow
Copy link
Owner

ssokolow commented Jan 1, 2020

Glad to hear it... though, with the ice storm here in Ontario, Canada having brought three power outages in two days, I've become very aware of how easily a certain TODO item can cause very visible bugs, so it's likely I'll need to push and get testing on another release candidate before 0.4.0 gets tagged.

(I was planning to wait for 0.4.1 to add the code to watch for changes like adding/removing/changing monitor rectangles or panel reservations but it turns out that QuickTile starts before Plasma reserves its panels when using ./install.sh on Kubuntu 16.04 LTS.)

@fidergo-stephane-gourichon

It's very hacky, but if you love Elementary OS like me and neeeeed window tiling,

Thanks @nreith for sharing some scripts. Looks like the debug part of it benefited the auhor.

PR for Debian package

Progress by @ssokolow on branch gtk3_port motivated me to create a debian configuration for the package and open PR #106.

This has the benefit of not requiring old packages and kludge. And the package is nicely installed by Debian and uninstallable.

Would you like to test the Debian package on branch gtk3_port?

If so, you can fetch my branch https://github.com/fidergo-stephane-gourichon/quicktile/tree/feature_debian_package and run recompile_local_debian_package.sh there.

Options: local or Docker

Notice that building the Debian package requires you to install some debian-development-related packages on your main system.

Alternatively, you can install docker and perform package creation inside it. I posted a command line on #106 (comment) . That latter option consumes a lot of bandwidth because you need to fetch a whole distribution and set of packages. The plus side is that it allows to build packages for other distributions.

Thank you for your attention.

@fidergo-stephane-gourichon

Glad to hear it...

I spoke a little fast.

There's one regression. I happen to have a xfce panel on the bottom right, with width less than width of window. Usual version of quicktile correctly expands any window on the left side to the full height. New version limits the height uselessly. See attached screenshot, bottom left.

quicktile_regression

though, with the ice storm here in Ontario, Canada having brought three power outages in two days, I've become very aware of how easily a certain TODO item can cause very visible bugs, so it's likely I'll need to push and get testing on another release candidate before 0.4.0 gets tagged.

Here in Paris it's cold, but probably no as cold as in Canada. Because of strikes, the public transportation is severely degraded to the point where it's "safer" for commuters to ride, say, 12-18km on a bike to go to work (then again back in the evening).

"They're professionals. They do this all the time. It can't possibly be this un-optimized. I must be missing something."

"Small steps"

@ssokolow
Copy link
Owner

ssokolow commented Jan 1, 2020

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
Copy link

torsava commented Jan 2, 2020

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
Copy link
Owner

ssokolow commented Jan 2, 2020

@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
Copy link

timwhite commented Jan 2, 2020

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

@torsava
Copy link

torsava commented Jan 2, 2020

@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
Copy link
Owner

ssokolow commented Jan 2, 2020

@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
Copy link
Owner

ssokolow commented Jan 2, 2020

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
Copy link

torsava commented Jan 2, 2020

@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
Copy link
Owner

ssokolow commented Jan 2, 2020

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
Copy link

torsava commented Jan 2, 2020

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
Copy link
Owner

ssokolow commented Jan 2, 2020

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
Copy link
Owner

ssokolow commented Jan 2, 2020

Done. The README has been updated.

@ssokolow
Copy link
Owner

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 #95 (comment) to make sure that it doesn't get lost in the shuffle?

@ssokolow
Copy link
Owner

ssokolow commented Jan 15, 2020

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:

Screenshot_2020-01-15 QuickTile — QuickTile 0 4 documentation

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
Copy link
Owner

ssokolow commented Jan 22, 2020

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
Copy link
Owner

ssokolow commented Jan 23, 2020

...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
Copy link
Owner

ssokolow commented Jan 25, 2020

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:

Screenshot_2020-01-25 QuickTile — QuickTile 0 4 documentation

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

@ssokolow
Copy link
Owner

ssokolow commented Jan 26, 2020

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
Copy link
Owner

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
Copy link
Owner

ssokolow commented Feb 9, 2020

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
Copy link
Owner

ssokolow commented Feb 9, 2020

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.

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

No branches or pull requests

15 participants