Hello,
I'm using: geany 2.0 (built on 2023-10-23 with GTK 3.24.38, GLib 2.76.5) on Linux fedora 6.5.9-200.fc38.x86_64.
I've noticed today (2023-11-06) a change in the behaviour of Geany: when accessing the symbol list by using a key binding from the editor, the focus does not change to the symbol list but stays on the editor. If I access the document list by using a key binding from the editor, the focus changes to the document list as expected. If I access the symbol list by using a key binding from the document list, the focus changes to the symbol list as expected. Accessing the editor by using a key binding from the document list or symbol list changes the focus to the editor as expected.
It makes impossible to move through the code using the symbol list without making one useless step through the document list, which is inconvenient, and wasn't the case until today (I've been using Geany for many years).
Thanks in advance for your time and consideration.
Confirmed that the keybinding `Focus->Switch to sidebar symbol list` does not work.
This seems to fix the bug for me:
``` diff --git a/src/sidebar.c b/src/sidebar.c index 9d004f392..f1d722ab6 100644 --- a/src/sidebar.c +++ b/src/sidebar.c @@ -1652,7 +1652,7 @@ void sidebar_focus_symbols_tab(void) GtkWidget *symbol_list_scrollwin = gtk_notebook_get_nth_page(notebook, TREEVIEW_SYMBOL);
gtk_notebook_set_current_page(notebook, TREEVIEW_SYMBOL); - gtk_widget_grab_focus(gtk_bin_get_child(GTK_BIN(symbol_list_scrollwin))); + gtk_widget_grab_focus(ui_lookup_widget(main_widgets.window, "treeview2");); } } ```
However, I feel like adding `GtkWidget *tree_symbols;` to `struct SidebarTreeviews` would be cleaner. One could then use `gtk_widget_grab_focus(tv.tree_symbols);` in `sidebar_focus_symbols_tab()`. I have no idea where `tv.tree_symbols = ui_lookup_widget(main_widgets.window, "treeview2");` should be done. In `prepare_openfiles()`, at the same time as `tree_openfiles` ? Sorry, if what I say makes no sense, that the first time I look into Geany's code.
Well, sorry. I was wrong and it doesn't fix the bug. It seemed to work but now it's broken again...
[This](https://github.com/geany/geany/commit/d3ded11ad2c8caeb0dd4aef2fcff517c5672b2...) changed the shape of the widget tree from:
``` Notebook page Scrolled window Symbols treeview ```
to
``` Notebook page Box Filter entry Scrolled window Symbols treeview ```
So the navigation in that function needs to be adapted to step to second child and down another level.
Edit: IIUC the current code does not work because the child of the page, the Box is not a Bin so the cast to bin will return null
Yes: ``` (geany:75738): Gtk-CRITICAL **: 11:39:58.065: gtk_bin_get_child: assertion 'GTK_IS_BIN (bin)' failed (geany:75738): Gtk-CRITICAL **: 11:39:58.065: gtk_widget_grab_focus: assertion 'GTK_IS_WIDGET (widget)' failed ``` Wouldn't `ui_lookup_widget(main_widgets.window, "treeview2")` returns the proper widget to be focus no matter the change in the shape of the widget tree ? Isn't it "treeview2" that need to be focused ?
Looking at the code `ui_lookup_widget` seems to only look for siblings, not search down the widget tree.
Ok, then modifying accordingly to the change in the shape of the widgets tree, this does fix the bug for me:
``` diff --git a/src/sidebar.c b/src/sidebar.c index 9d004f392..9885c6b7e 100644 --- a/src/sidebar.c +++ b/src/sidebar.c @@ -1649,10 +1649,15 @@ void sidebar_focus_symbols_tab(void) if (ui_prefs.sidebar_visible && interface_prefs.sidebar_symbol_visible) { GtkNotebook *notebook = GTK_NOTEBOOK(main_widgets.sidebar_notebook); - GtkWidget *symbol_list_scrollwin = gtk_notebook_get_nth_page(notebook, TREEVIEW_SYMBOL); - gtk_notebook_set_current_page(notebook, TREEVIEW_SYMBOL); - gtk_widget_grab_focus(gtk_bin_get_child(GTK_BIN(symbol_list_scrollwin))); + GtkWidget *vbox = gtk_notebook_get_nth_page(notebook, TREEVIEW_SYMBOL); + GList *vbox_children = gtk_container_get_children(GTK_CONTAINER(vbox)); + GtkWidget *scrollwin = g_list_nth_data(vbox_children, 1); + GList *scrollwin_children = gtk_container_get_children(GTK_CONTAINER(scrollwin)); + GtkWidget *tree_symbols = g_list_nth_data(scrollwin_children, 0); + gtk_widget_grab_focus(tree_symbols); + g_list_free(scrollwin_children); + g_list_free(vbox_children); } } ```
Hi, I've been using a locally compiled version with the suggested correction above for 3 days now and it's working fine. Would you like me to create a pull request ?
A GTK expert needs to comment, but maybe making a PR for them to comment on might be worthwhile.
Looking at the code ui_lookup_widget seems to only look for siblings, not search down the widget tree.
It searches for a top-level widget, because Glade calls e.g. `g_object_set_data` on top-level widgets.
The lookup does seem to work, the following prints 1: ``` g_warning("%d", GTK_IS_TREE_VIEW(ui_lookup_widget(main_widgets.window, "treeview2"))); ``` The weird thing is that `gtk_widget_grab_widget` with that lookup doesn't work. It does work if we focus the entry, which might be more useful anyway: ``` gtk_widget_grab_focus(ui_lookup_widget(main_widgets.window, "entry_tagfilter")); ``` BTW I tested the pull and the code there seems to work.
Weird indeed, especially as it works if focus is switched to the document list first. I am not sure users will want focus on the filter or the tree, certainly their usages to date will be the tree since the filter didn't exist.
Can comments be put in Glade? Perhaps on the symbols sidebar noting that code in sidebar.c depends on the layout, don't change it without changing the code.
Done.
especially as it works if focus is switched to the document list first.
Well, not really surprising if you don't actually check it *does* work per se: if the notebook is already focused, the code will switch active page and that'll be enough to bring focus to whatever make sense there.
Closed #3678 as completed via ea2458e4472fe0d42d4e8ae460596b561b1d37c7.
github-comments@lists.geany.org