GNOME Bugzilla – Bug 702618
Regression - almost a blocker after the change to GtkSearchEntry
Last modified: 2013-07-29 14:36:19 UTC
The general idea to improve the functionality location widget is welcomed. however now I observe critical messages every time I try to enter something by creating a new clock in the gnome-clocks app: $ gnome-clocks (gnome-clocks:2279): Gtk-CRITICAL **: gtk_device_grab_add: assertion 'GDK_IS_DEVICE (device)' failed (gnome-clocks:2279): Gdk-CRITICAL **: gdk_device_grab: assertion 'GDK_IS_DEVICE (device)' failed (gnome-clocks:2279): Gdk-CRITICAL **: gdk_device_ungrab: assertion 'GDK_IS_DEVICE (device)' failed (gnome-clocks:2279): Gtk-CRITICAL **: gtk_device_grab_remove: assertion 'GDK_IS_DEVICE (device)' failed There is no need to include backtraces because it's clear where it will lead, due to the following issue: Moreover the completion list which appears below the entry once you start to enter something behaves weird (just one example): steps to reproduce with gnome-clocks: 1) enter something. say "ber" 2) pick something from the completion list. say "Berlin (Berlin-Tegel), Berlin, Germany" 3) click with a mouse or on enter (only once) to see the text added to the entry widget, which is now search entry. 4) wait 150ms :) 5) observe a new appearing completion list with two items, where one is your selection and the second item is just empty. if you wonder now how it could come out like this, it is a good change to take a look at the source code of the search entry for the first time in your life, which contains a good example how you can mess around with the "changed" signal https://git.gnome.org/browse/gtk+/tree/gtk/gtksearchentry.c I do not know how to handle this, but since you break the api a good starting point would be to remove the I_KNOW_THIS_IS_UNSTABLE flag as well, so you have no excuses next time, joking)))
Paolo, in flavour of the above seen, may I have a git repo commit access for gnome-clocks?)))
See https://live.gnome.org/NewAccounts
It would be great actually, if gtksearchentry would bind another custom created signal to the "changed" signal to do its own icon handling, so this way other derived widgets can profit from it.
(In reply to comment #1) > Paolo, in flavour of the above seen, may I have a git repo commit access for > gnome-clocks?))) Evgeny, yes please apply for an account. https://live.gnome.org/NewAccounts About this problem, I already antipated to you on irc that things were still a bit broken throughtout the whole stack (gtk, libgweather and clocks), better to find the bugs early in the cycle :)
What exactly is expected from me here? If there are warnings, I'd like to see backtraces for them, with fatal warnings enabled so we can see where they're coming from. And I'll note that new accounts are usually given on account of patch contributions, so this bug isn't quite yet a good reference for your request ;)
(In reply to comment #5) > What exactly is expected from me here? > If there are warnings, I'd like to see backtraces for them, with fatal warnings > enabled so we can see where they're coming from. And I'll note that new > accounts are usually given on account of patch contributions, so this bug isn't > quite yet a good reference for your request ;) Your opinion and participation is expected, as this issue seems to be closely correlated with the gtksearchentry logic.))) As the author of the gtksearchentry, what do you think about comment 3? is it a good idea? What do think about emitting, stopping, and forwarding of the "changed" signal in general within the body of gtksearchentry?
(In reply to comment #6) > (In reply to comment #5) > > What exactly is expected from me here? > > If there are warnings, I'd like to see backtraces for them, with fatal warnings > > enabled so we can see where they're coming from. And I'll note that new > > accounts are usually given on account of patch contributions, so this bug isn't > > quite yet a good reference for your request ;) > > Your opinion and participation is expected, as this issue seems to be closely > correlated with the gtksearchentry logic.))) > > As the author of the gtksearchentry, what do you think about comment 3? is it a > good idea? > > What do think about emitting, stopping, and forwarding of the "changed" signal > in general within the body of gtksearchentry? It already does that. I think there's more likely a bug in libgweather's search entry. I'd like to have the data asked for in comment 5.
finally fixed in bug 700229