lwindolf
Layout not remembered
New issue with latest version 1.13.3:
In Normal view, the position of divider between Headlines and article content is not remembered. After a restart, it is always at the bottom, with only a minimal slice of the article content shown.
This is not exactly new, and it looks tricky to fix.
See #570 #590 #762
To resume, we can keep this bug, or reopen bug #540 : articles or headlines being squeezed in the same way on window resize instead.
We are currently restoring the previous value at start for the pane's separator position, but as explained in #570, the value then jumps around. This is a Gtk bug that was first reported in 2014 : https://bugzilla.gnome.org/show_bug.cgi?id=733638 and as noted in #590, also in their new Gitlab here : https://gitlab.gnome.org/GNOME/gtk/-/issues/1959
Liferea always resets window size to some default value. Doesn't remember window size or positions at all ;)
Wide view.
This issue is persistent and annoying I find that every time I restart Liferea the preview bar slowly moves down the pane until it is no longer visible.
Distro: Debian GNU/Linux bullseye/sid x86_64 Liferea: 1.13.3
It is strange that this did not happen in 1.12.x but happens in 1.13.x, given that both are using GTK3...
Looking in dconf-editor at the net.sf.liferea "last-hpane-pos" key value, that value is set/saved only when Liferea quits (not while you are dragging the widget, nor on startup). On startup, that value is not changed. So my question is... is Liferea telling GTK to set that value sometime too soon, before the entirety of the UI is set up? Would it change anything if it set that value at the beginning of the startup (before showing the widgets) and also later "at the last minute"?
...because if I open the GTK Inspector, find the GtkPaned widget (in this case named "normalViewPane" and set its "position" property to anything else (like "200"), the pane positions itself correctly. Even incrementing/decrementing by one pixel the position sets it accurately. So in the case at hand, I'm just guessing, but maybe it is primarily a startup timing issue somehow?
Hi @lwindolf, I have further narrowed down the issue today.
[Edit: depending on the computer,] the pane divider positioning bug might be happening only when starting Liferea in windowed mode instead of starting it maximized. Additionally, like we see in issue #909, it might get subtly influenced by whether or not the headerbar plugin is active.
On my 1366x768 ThinkPad with Intel Sandybridge graphics and a SSD running Fedora 33,
- If you start with the window maximized (which, when run under GNOME, is the case if the window's dimensions are close-enough to the dimensions of the screen), then you won't have the GTK Pane shifting issue (at least not with the horizontal pane).
- If you start with the window not maximized (i.e. sized like a window), it depends:
- If the headerbar plugin is not active, the horizontal pane will shift DOWNwards
- If the headerbar plugin is active, the horizontal pane will shift UPwards
Maybe something weird with the calculation of the window height/coordinates based on the height of the window decorations + toolbar?
Awesome analysis. I have the feeling that your take on the timing of setting the pane sizes during startup might be the issue. One of the refactorings from 1.12 to 1.13 was moving more code to GObjects and getting rid of the hierarchical xxx_init() functions. This certainly has changed timing.
Maybe this is related to everything working when being almost/fully maximized. Rendering just takes longer, a possible race doesn't happen...
If it is a race it would open the question if it should happen sooner or later. Forcing it later could be done. On the other hand I want to rely on being able to tell GTK an absolute size of my window and to actually get it.
@antistress That one more indication of a initialization race. Thanks for the feedback!!!
Huh, interesting, my laptop's screen is 1366x768 so that was not even far off. Maybe the difference sits with the combination of technological stack between Debian and Fedora.
A random idea of additional ways you could mitigate at least a tiny part of the impacts of this issue (not an actual fix for the core issue):
- to make it easier for users to actually see where the pane went and to have a big-enough drag target to be able to drag it into space (instead of fighting with the window border's resize dragging area): you could set the panes' "wide-handle" property to True.
- maybe also set some minimum non-collapsible width and height for the content pane (ex: 150-200 pixels or so) but I'm not sure how that would be achieved (couldn't figure it out just by playing with the GTK Inspector in Liferea)
It's kinda strange that on my machines only the content pane is affected and not, thankfully, the first (feeds list) pane...
Sorry for the noise, I rely on this app a lot now and it's becoming a massive nuisance having to drag it up almost every time from nothing, having to battle to find the capture point to pull it with the mouse is frustrating. Is there anything I can do to help find the problem?
I don't know if the location of the issue in the code is already clear to @lwindolf (in which case maybe he can point to the place in the code where people could try to come up with a fix); if not, maybe you could try looking for that place, or in which commit exactly the regression was introduced (using git bisect to test your own builds of the app)...
Maybe my summary of the issue wasn't clear. You want to get rid of this issue, revert 25db4aa60d87b04cedeaf6bb5502 If you are not using a tiling window manager, you probably won't be too annoyed by #540. Edit : maybe you would have to revert the other attempt at a fix too : #573
is Liferea telling GTK to set that value sometime too soon, before the entirety of the UI is set up? Would it change anything if it set that value at the beginning of the startup (before showing the widgets) and also later "at the last minute"?
I guess we could restore the size after a random amount of time after start but that would be ugly. The window is realized so that we can restore it's size, then the position of the pane is set.
The code is here. All the relevant code is in this file plus the glade/mainwindow.ui file. If you have any ideas don't hesitate to test them.
I'm using a wide view panel layout with 3 panels.
I think the value saved in last-wpane-pos during "on_app_shutdown calling liferea_shell_destroy" is wrong.
Just tested it using the dconf editor and setting last-wpane-pos to 130 then starting liferea. The layout is fine then closed liferea. And the value written into the configuration is "395" (this will not be the same value for everyone). The app should have written 130 again because I did nothing to the ui at this time.
My guess is, that at the time "on_app_shutdown" is called, the/some panels are already resized/destroyed. This will happen in C#/.NET, too, when you are trying to save the window state at the "wrong" time. The objects are not destroyed, but their position/size-properties are not what they looked like before the "shutdown"-events. It will not happen to everything, but panel-layouts are known for being very erm sensitive... ;) You will have to save the values at the "right" time - I think a possible fix would be during resize-events of the panel itself (not the best solution, but hey... maybe it would work).
Currently I'm trying to find a way writing the configuration (liferea_shell_save_position) during a resize event of the wideViewPane, but as I'm not an gtk-developer this will take time (or never happen). Maybe it will be enough writing the wideViewPane position.
A quick (and very ugly) fix is setting a hard-coded value which is nice for your layout inside liferea_shell_restore_state. This will work quite well.
if (last_wpane_pos)
gtk_paned_set_position (GTK_PANED (liferea_shell_lookup ("wideViewPane")), 130);//last_wpane_pos);
I think the value saved in last-wpane-pos during "on_app_shutdown calling liferea_shell_destroy" is wrong.
That would be a different issue. Can you reproduce it reliably with the latest version ? How are you closing Liferea ?
To be clear, the value is only written on shutdown. So when this bug (the #570 bug) happen, the saved value you see when Liferea is running (with gsettings get net.sf.liferea last-hpane-pos for example) is not the position of the delimiter. And if you open and shutdown Liferea multiple times in a row without moving the delimiter manually, the saved value will still change and drift to an extreme over time, because the position automatically changes just after being restored, see here.
Currently I'm trying to find a way writing the configuration (liferea_shell_save_position) during a resize event of the wideViewPane,
This is a bit ugly because it constantly writes while your are resizing. Here is how to do :
diff --git a/src/ui/liferea_shell.c b/src/ui/liferea_shell.c
index 71b9eb15..9ecb12b5 100644
--- a/src/ui/liferea_shell.c
+++ b/src/ui/liferea_shell.c
@@ -331,6 +331,12 @@ liferea_shell_save_position (void)
conf_set_int_value (LAST_WINDOW_HEIGHT, h);
}
+static void
+liferea_paned_position_changed (GObject *object, GParamSpec *pspec, gpointer user_data)
+{
+ liferea_shell_save_position ();
+}
+
void
liferea_shell_set_toolbar_style (const gchar *toolbar_style)
{
@@ -1162,6 +1168,7 @@ liferea_shell_create (GtkApplication *app, const gchar *overrideWindowState, gin
gboolean toggle;
gchar *id;
FeedListView *feedListView;
+ GtkWidget *pane;
debug_enter ("liferea_shell_create");
@@ -1252,6 +1259,7 @@ liferea_shell_create (GtkApplication *app, const gchar *overrideWindowState, gin
g_signal_connect (G_OBJECT (shell->window), "key_press_event", G_CALLBACK(on_key_press_event), shell);
g_signal_connect (G_OBJECT (shell->window), "style-updated", G_CALLBACK(liferea_shell_rebuild_css), NULL);
+
/* 3.) setup status bar */
debug0 (DEBUG_GUI, "Setting up status bar");
@@ -1307,6 +1315,15 @@ liferea_shell_create (GtkApplication *app, const gchar *overrideWindowState, gin
liferea_shell_setup_URL_receiver ();
liferea_shell_restore_state (overrideWindowState);
+
+ pane = liferea_shell_lookup ("normalViewPane");
+ g_signal_connect (
+ pane,
+ "notify::position",
+ G_CALLBACK (liferea_paned_position_changed),
+ NULL);
+
+
gtk_widget_set_sensitive (GTK_WIDGET (shell->feedlistViewWidget), TRUE);
/* 10.) After main window is realized get theme colors and set up feed
Thank you - I had to connect to the wideViewPane, but this works.
But it did not solve the problem. The position saved is good - but with the real position it will not restore the state. For different application widths you can calculate different factors for modifying the position - e.g. the saved value is 427 and the factor for application width 1851 is 3,28. When I modify the saved position by this factor, the restored state will by fine.
Of course this is no solution in any way:
- the factor is different for every width and you have to do the math outside of the app using debugging-output
- it couldn't be that you have to modify a good screen position by some factor to trick the app/gtk into doing the right thing.
I will be looking into it a little bit more. For now I will be using a fixed value for the position - this solves my problem, but not the bug itself.
This turns out to be, in my humble opinion, the biggest usability issue the software currently has for non-geeks.
For example, my family members cannot use Liferea because of this, as they will not know where their content pane or list of items suddenly disappeared to, as it shifts some more on every startup, and they will not know how to fix the issue because not only are the pane's handlebars invisible (unless the "wide-handle" property were to be set to True in the future), but also: even if the draggable parts were visible, they wouldn't notice or know they can drag them back up from the bottom of the screen.
This turns out to be, in my humble opinion, the biggest usability issue the software currently has for non-geeks.
I'm a geek and it's driving me up the wall I'm so sick of dragging that stupid bar up every time. If there was another simple GTK RSS feed reader I'd have switched away from Liferea just to avoid this behaviour.
"Geeks" could patch the source-code... ;)
Example for wide view:
liferea_shell.c function liferea_shell_save_position disable conf_set_int_value for wideViewPane:
pane = liferea_shell_lookup ("wideViewPane");
if (pane) {
y = gtk_paned_get_position (GTK_PANED (pane));
//20201225 ugly fix for wrong panel width
//conf_set_int_value (LAST_WPANE_POS, y);
}
This will disable writing "wrong" positions into the configuration and overwriting the position you will set manually:
Then use dconf-editor to set org/gnome/liferea/last-wpane-pos to e.g. 150. The value will/may be different for you, of course. This value is NOT the same value liferea will normally write on exit. You may have to experiment a little to find a good value.
This will not fix the problem, but it will ease the pain as you will be getting the same layout every time ;)
FYI if you pull a new version from github you may need to apply the fix again.
A simple workaround for this issue, put these two files in the liferea plugins directory and activate plugin. It works for now in the "normalView" only. Files: https://raw.githubusercontent.com/sunwire/liferea/PanePositionWorkaround/plugins/pane.plugin https://raw.githubusercontent.com/sunwire/liferea/PanePositionWorkaround/plugins/pane.py Any comments are welcome.
Nice work around works well for me though you might want to fix up the links they don't point to the correct files.
Well damn...
- big thanks to @sunwire for making Life(rea) more bearable for us while waiting for the official fix! I will at least be able to let my family members use this, so that's a huge relief.
- since it seems this works in practice, maybe this could be the conceptual basis for the official fix in Liferea core? It seems this plugin's approach is to... simply wait 0.2 seconds before setting the position? In my view this at least confirms that it's a timing/race issue, and if Liferea could somehow set the pane positions at the very last minute / end of initialization of the GUI, maybe it would fix the issue...
@nekohayo It is not as simple as it seems. I made a small debug and I think, like many others it is a Gtk bug. The pane position is set correctly, but it changes its position and this variation depends, for example, on the height of the window. And yes, it waits 0.2 sec but in a separate thread so don't block the main window and when the window is fully realized (I experimentally assumed 0.2 seconds would be enough, but that doesn't have to be true) it just move pane to the correct position. I don't know Gtk well but maybe we can connect to the signal sent when the window is fully realized (the window and all the widgets have been drawn and their positions fixed) and then move the pane to the correct position. Is there such a signal at all?
Thanks for the plugin @sunwire
FYI for anyone wanting to know, it usually goes here:
~/.local/share/liferea/plugins
I hope this will help the developer!
Thanks for the plugin @sunwire
FYI for anyone wanting to know, it usually goes here:
~/.local/share/liferea/plugins
I hope this will help the developer!
Thanks
What about flatpak version ?
What about flatpak version ?
I guess it should be somewhere in /home/my_user/.var/app/net.sourceforge.liferea or in /home/my_user/local/share/flatpak/app/ [1] ?
[1] https://github.com/flatpak/flatpak/wiki/Filesystem
If it is a race condition, can the restore-pane-position code be delayed like after a one second timeout?
https://github.com/lwindolf/liferea/blob/34d26be00328a68d2f1625c78b54dc168da0648e/src/ui/liferea_shell.c#L1123-L1133
Even better, the restore-pane-position be done immediately once and do it again 1 seconds late. Then everybody will be happy until Gtk guys fix it (iffy).
Something like: pane-restore.txt
Based on the idea presented by @mozbugbox I created a slightly modified code (simpler?). https://github.com/lwindolf/liferea/compare/master...sunwire:PanePositionHack