GNOME Bugzilla – Bug 707945
GTK2/Quartz: 'typeahead find' in GtkTreeView no longer accepts text input
Last modified: 2018-04-15 00:39:12 UTC
Searching with the “typeahead find” feature of list and tree views no longer works as expected with the Quartz backend of GTK+ 2.24 (2.24.20 + all patches from git branch gtk-2-24 up to 4437ccb8). Steps to reproduce: 1) launch gtk-demo 2) open 'Tree View > List Store' 3) start typing e.g. the string "Add" to select a row further down in the list Expected result: The row with the description field matching the search is highlighted and the list auto-scrolls to show the highlighted item. Actual result: Nothing (the search entry field does not pop up unless triggered with 'Cmd+F', and even when visible and focused it does not accept any text input). Workaround: Keyboard shortcuts apparently still work - it is thus possible to trigger a search by pasting the search string from the clipboard: 1) launch gtk-demo 2) run 'Tree View > List Store' 3) copy the search string (use e.g. this report to copy the string "Add") 4) open search entry with 'Cmd+F' 5) paste the search string into the entry with 'Cmd+V' Not reproduced with: - GTK+/Quartz 2.24.17 - GTK+/X11 2.24 (2.24.20 + all later patches from git branch gtk-2-24) - GTK+/Quartz 3.8.4 - GTK+/X11 3.8.4 Tested on: - OS X 10.7.5 (MacBookPro8,1), default input method (Language: English, Keyboard layout: de_CH) - GTK+ and dependencies installed with MacPorts (trunk) + local port repository with - gtk-demo (Tree View, File Chooser) - GtkFileChooserDialog in Inkscape (0.48.4, trunk) and GIMP (2.8, git master)
I'm not able to replicate this in-tree, but I do see it in a bundled app, which leads me to think that there's some ancillary file that's not getting bundled and which may be missing or mis-located in the MacPorts build.
Thanks for the hint - indeed I missed to update the post-destroot hook in the local portfile to the recent changes wrt immodules.cache ($PREFIX/etc/gtk-2.0/gtk.immodules -> $PREFIX/lib/gtk-2.0/2.0.10/immodules.cache): due to the old post-destroot hook, in the end both files had been created. Correcting this minor error didn't re-enable 'typeahead find' with gtk-demo though (the paths for the installed modules in 'immodules.cache' are correct).
Testing 'typeahead find' with archived older versions of GTK+/Quartz 2.24 (otherwise unchanged environment): - works with 2.24.18 - fails with 2.24.19, 2.24.20, 2.24.20+patches from git
Adding another detail I noticed while testing this issue with Inkscape (current stable 0.48.4 and trunk (r12522), GTK+/Quartz 2.24.20+, not bundled, no menu integration): 'Typeahead find' accepts regular text input in tree/list views in dialogs docked in Inkscape's main window, after having toggled 'Full Screen' mode on and off (<F11>). If the dialogs are floating (either detached from the dock, or not dockable), toggling full screen mode for the main window has no affect ('typeahead find' in the floating dialog still does not accept any text input). The effect of toggling full screen on/off only lasts during the current inkscape session, and only affects that one document window which has been toggled to full screen mode, even if multiple document windows have been opened from within Inkscape in the current session. I haven't figured out a way to reproduce this e.g. with 'gtk-demo' (no 'Full Screen' menu option combined with a GtkTreeView widget in any of the demos AFAICT).
I found that by disabling the imquartz input module I'm able to restore this function.
(In reply to comment #5) > I found that by disabling the imquartz input module I'm able to restore this > function. I confirmed it, and I also confirmed that Windows backend (imime) has same problem (although it's enabled only on CJK locale).
*** Bug 710525 has been marked as a duplicate of this bug. ***
I am currently experiencing this in (even recent) builds of Gnucash on OS X. I'm not sure why this is still marked UNCONFIRMED when jrails has confirmed it as well. Any chance this can be fixed?
I've figured out what the problem is, though I'm not yet at a solution. The problem is that the key event goes first to GdkQuartzView insertText:, and the GdkWindow with focus at that moment is the TreeView, so the text is stored as a property TIC_INSERT_TEXT on the GdkWindow. The keypress is then passed to the TreeView's search window and passes the insert GdkEvent on to it. That's a different window, so when output_result (in imquartz.c) asks for the text back from the window, there's nothing there. This is true even if the search window is explicitly opened with command-f and then given focus with the mouse.
Created attachment 293417 [details] [review] Use the event's GtkWindow to retrieve the keypress, because that's where it was stored. Here's a patch that seems to fix the problem. Please test it. It should apply cleanly to both gtk-2-24 and master.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new