Playlist column widths forgotten on restart #580
Labels
Milestone
Comments
|
Hm, I can't reproduce the issue on my system. What I did to test this:
And the column is still the same width. I also don't encounter the other weirdness that you get. Could you run Exaile from a terminal and see if there are any error messages displayed? |
|
Console output, two errors displayed: ...and on quit: |
|
I can reproduce this on Mint 18.3. Column width settings ( Automatic column sizing is not affected by this, so as a temporary workaround you may want to use that (View → Columns → Autosize). |
|
While #585 fixes the symptoms, it seems to me that the underlying cause of this problem is the delay on the If the decorator is removed, the pattern of Interestingly, the non-delayed handler is called fewer times per column than the delayed one, so there may be a deeper interaction at play here, but so far I haven't been able to figure it out. |
|
The Mint 18.3 machine that I used for testing this just died, so unfortunately it's going to be difficult for me to help now (it doesn't happen on my Arch machine). Let me know if you figure it out or if you don't want #585 merged yet. |
|
You can merge #585 to have the bug fixed (the additional validation does not hurt anyway). I will try to instrument the Gtk in my Mint 18.3 VM with some additional traces to see what is going on with the width, but my current hypothesis is that after column notifies us of the width change (with correct width), the width is internally modified/reset without notification (either because the column is being realized or because of resizing/realization of adjacent columns), and with the added delay, we pick up the modified value instead of the one we were supposed to be notified of... |
|
It seems the above hypothesis is correct. Below are two logs, one with enabled delays and one with disabled delays. Both are obtained with Gtk library that has additional traces in methods that modify GtkTreeViewColumn's width property (prefixed with GTK). And there is an additional trace in exaile in the (I have included full logs here - the relevant part is displayed again at the end of this post). Delayed version: Non-delayed version: The relevant part is for delayed version vs. for the non-delayed one. The So I would say that the proper fix is to remove the delay - unless we have it there for a specific reason? |
|
The delay is meant to prevent excessive processing. I think the idea here is that Perhaps a better fix is to call def on_width_changed(self, column, widget):
self._delayed_width_changed(self.get_width())
@common.glib_wait(100)
def _delayed_width_changed(self, width):
if not self.destroyed and width != settings.get_option(
self.settings_width_name, -1
):
settings.set_option(self.settings_width_name, width) |
|
Indeed, that should both fix the problem and preserve the delayed behaviour. |
sjohannes
added a commit
to sjohannes/exaile
that referenced
this issue
Feb 5, 2019
When the delayed/batched function gets called, the widget may be in an inconsistent state. On some older GTK+ versions (e.g. 3.18.9 on Linux Mint) this resulted in column widths of 0 to be saved on startup. This change calls get_width immediately in the signal handler and passes the value to the delayed function. Fixes: exaile#580
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to Reproduce (for bugs)
Quit and re-open Exaile.
This was observed after an upgrade to LM18.3 (based on U16.04) that broke some GStreamer codec plugin dependency for mp3 in the repository-provided version 3.3.2, causing this bug despite all qualities of codec plugins being installed, resulting in me testing the latest version.
Expected Behavior
The playlist columns should be at the same width as they were when the application last ran.
Current Behavior
When Exaile starts after quitting, all columns are at their minimum width (nothing in the column can be read), except for the right-most column, which takes up the rest of the screen width.
Also, sometimes when dragging out the collapsed columns to appropriate widths, as soon as the edge of the last (left-most) column "#" for track number is clicked on, the entire application crashes. This last part has been unreliable - e.g. it happened on the first 2 of 3 times this morning, but I only observed it so far on 4.0.0beta2, currently available as .deb installer via PPA.
There is also slightly different starting visual behaviour - in 4.0.0beta2, all the columns begin collapsed onto the same pixel-width, whereas in 4.0.0rc3, they begin with a few pixels regularly spaced between each column edge.
Environment
Linux Mint 18.3 XFCE 32bit edition
Exaile 4.0.0rc3 from source
GStreamer: 1.8.3
GTK+: 3.18.9
GTK+ theme: Mint-X
Locale: en_GB UTF-8
Mutagen: 1.41.1
PyGObject: 3.20.0
Python: 2.7.12
Peculiarity - I also have Python 3.5 installed, but it seems to be defaulting to 2.7 when running.
I looked at another system already running LM18.3 64bit, and Exaile was not shown in the repository at all. Executing from the github release would not start, probably lacking dependencies.
The text was updated successfully, but these errors were encountered: