GTK 4 centers marks of the Scale widget even when the scale has a vertical
orientation. Unfortunately, the Scale widget does not provide a way to set the
alignment or to access the internal Label widget in any way. To left-align the
labels this commit add a method that traverses the all children of the songs
scale recursively and adjusts the alignment if it is a Label widget.
Replace the handlers for the “default-width” and “default-height” with an
override to the virtual “size_allocate” method to reliably react to Window
resizing.
I don't know how my cache got into this state, but I had an empty size
file:
$ cat ~/.cache/mcg/127.0.0.1/size
$ stat ~/.cache/mcg/127.0.0.1/size
File: /home/jeremy/.cache/mcg/127.0.0.1/size
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 254,0 Inode: 18493061 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ jeremy) Gid: ( 100/ users)
Access: 2022-09-14 00:18:32.942885525 -0700
Modify: 2022-09-07 12:32:44.151734944 -0700
Change: 2022-09-07 12:32:44.151734944 -0700
Birth: 2022-08-25 10:01:01.729717504 -0700
This was causing mcg's Library view to crash like this:
(.mcg-wrapped:879276): Gtk-CRITICAL **: 00:19:15.727: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed
Exception in thread Thread-1 (_set_playlist):
Traceback (most recent call last):
File "/nix/store/c1vb2z3c64i0sd92iz7fv0lb720qcvhb-python3-3.10.6/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/nix/store/c1vb2z3c64i0sd92iz7fv0lb720qcvhb-python3-3.10.6/lib/python3.10/threading.py", line 953, in run
self._target(*self._args, **self._kwargs)
File "/nix/store/l935dwmk93sq2chr4xxiipv9amyfcg43-CoverGrid-3.1/share/mcg/mcg/playlistpanel.py", line 256, in _set_playlist
cache = client.MCGCache(host, size)
File "/nix/store/l935dwmk93sq2chr4xxiipv9amyfcg43-CoverGrid-3.1/share/mcg/mcg/client.py", line 1279, in __init__
self._read_size()
File "/nix/store/l935dwmk93sq2chr4xxiipv9amyfcg43-CoverGrid-3.1/share/mcg/mcg/client.py", line 1293, in _read_size
size = int(f.readline())
ValueError: invalid literal for int() with base 10: ''
Maybe mcg crashed while writing the `size` file at some point? I see
that it writes directly to the size file, which seems potentially risky:
it would probably be safer to write to a temp file and then (atomically)
move it. Still, it seems like a good practice to be resilient here.
After this change, here's what I see get printed by mcg:
(.mcg-wrapped:889856): Gtk-CRITICAL **: 00:37:00.045: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed
2022-09-14 00:37:00,076 WARNING: invalid cache file: /home/jeremy/.cache/mcg/127.0.0.1/size, deleting file
Traceback (most recent call last):
File "/nix/store/vzgcfs00nq543hjk8hrk81k1rs8aqpqw-CoverGrid-3.1/share/mcg/mcg/client.py", line 1295, in _read_size
size = int(f.readline())
ValueError: invalid literal for int() with base 10: ''
And then the problem goes away =)
When doing a `python setup.py build` on my machine, I found that
`build/lib` would not end up with a compiled gresource file until the
second invocation of `python setup.py build`.
Before:
$ python setup.py build
running build
running build_py
creating build
creating build/lib
creating build/lib/mcg
copying mcg/connectionpanel.py -> build/lib/mcg
copying mcg/shortcutsdialog.py -> build/lib/mcg
copying mcg/serverpanel.py -> build/lib/mcg
copying mcg/application.py -> build/lib/mcg
copying mcg/window.py -> build/lib/mcg
copying mcg/playlistpanel.py -> build/lib/mcg
copying mcg/utils.py -> build/lib/mcg
copying mcg/coverpanel.py -> build/lib/mcg
copying mcg/infodialog.py -> build/lib/mcg
copying mcg/librarypanel.py -> build/lib/mcg
copying mcg/client.py -> build/lib/mcg
copying mcg/zeroconf.py -> build/lib/mcg
copying mcg/mcg.py -> build/lib/mcg
copying mcg/__init__.py -> build/lib/mcg
copying mcg/albumheaderbar.py -> build/lib/mcg
package init file 'data/__init__.py' not found (or not a regular file)
compiling gresources
compiling gschemas
$ ls build/lib/mcg/data/
ls: cannot access 'build/lib/mcg/data/': No such file or directory
Note how there is no data directory at all. Now check out what happens
on the second build:
$ git status
On branch main
Your branch is up to date with 'origin/main'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
data/gschemas.compiled
data/xyz.suruatoel.mcg.gresource
nothing added to commit but untracked files present (use "git add" to track)
$ python setup.py build
running build
running build_py
package init file 'data/__init__.py' not found (or not a regular file)
creating build/lib/mcg/data
copying data/xyz.suruatoel.mcg.gresource -> build/lib/mcg/data
compiling gresources
compiling gschemas
$ ls build/lib/mcg/data/
xyz.suruatoel.mcg.gresource
That's because the first build generated the compiled schemas and
resources (you can see evidence of that in `git status`), and then the
second build was able to copy the gresource file over according to the
`package_data` rules. The fix I've introduced here is to just do the
compilations *before* we call `super(...).run(...)`. There might be
better ways of doing this, I'm not very familiar with packaging gtk
python applications.
Things were even worse for the gschemas.compiled file: in addition to
the ordering issue it's not even mentioned in `data_files`, so even if
it does exist, it doesn't have a chance to get copied over when
installed. So I've added it to the `data_files` section. I don't know if
that'll play nicely or not with the existing `--no-compile-schemas`
flag.
