Re: Toplevel windows losing active and focus properties
- From: jrick devio us (Josh Rickmar)
- To: gtk-app-devel-list gnome org
- Subject: Re: Toplevel windows losing active and focus properties
- Date: Thu, 09 Aug 2012 10:59:11 -0400
jrick devio us (Josh Rickmar) wrote:
Hi,
I'm doing some development work on xombrero. We recently (last month
or so) switched to GTK3 (3.4.4 on my OpenBSD/amd64 system), and have
noticed some recurring focus issus. Unfortunately, we haven't found a
good way to reproduce them, and that has made it incredibly hard to
debug.
For whatever reason, we've found that after a while our browser will
enter a weird state where many things begin to break. Searching a
webpage with the '/' key and pressing enter no longer focuses the
WebKitWebView, and keyboard commands no longer work. Our link hinting
works correctly in all cases except if we press enter (the hints on
the page are never cleared, until a new page is loaded). And, the
text cursor in our URL and search bars becomes completely invisible.
After some more looking around it seems that our main toplevel
GtkWindow no longer has the is-active and has-toplevel-focus
properties set to true. We think this is the cause of the invisible
cursor (just as how the cursor becomes invisible if you use your
window manager to focus a different window), and believe the other
bugs are a result of it as well (perhaps not all signal callbacks are
being run?).
I'm not sure if this is a bug in GTK3, or our fault due to a bad
switch to GTK3. Has anyone seen this sort of eratic behavior when
switching applications to GTK3? If not, can anyone point me in the
right direction about what possible things may be causing this
toplevel window from losing those active and focus properies? This
bug is driving us nuts and we'd love to get it solved before our next
major release. Any help would be greatly appreciated.
--
Josh Rickmar
http://jrick.devio.us/
So this may cause even more fallout for being so hackish, but I think
I found a workaround.
I went through the GTK source code and found the
_gtk_window_set_is_active function. I manually added a prototype for
this function to our code (because it is not declared static) and was
able to use it to confirm that it was the is-active property being set
to false that was causing all of our issues. As a workaround, I'm now
calling this function, setting this property to true, before any
GtkEntry is foucsed (to get rid of the invisible cursor), and before
any keypress is handled.
Can anyone see any potential issues with this workaround, and have a
better idea about how to remove this issue in the first place?
--
Josh Rickmar
http://jrick.devio.us/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]