-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix GTK assertions about get and set the default widget #15
Comments
Have some Gtk assertions "bugs"
|
Thanks, the third one about INT64 has been fixed, it was actually causing a crash on some platforms. I'm working on resolving the others and getting to the point where it runs clean. |
I'm inclined to think that the gtk_window_get_default_widget and gtk_window_set_default messages a bug in GTK 3.18.6-2 as they don't happen in older version (RHEL 7.2) or newer versions (Rawhide). They don't seem to be causing any stability so closing this issue. For information purposes, below is the stack trace when this occurs:
|
This one has been bugging me for a long time and as part of the drive towards 1.0 I took another look at this. The good news is that I finally managed to track down what is causing it. The GTKPopover calls the get and set default widget methods in map/unmap events. Normally this is not an issue, however because when you split the terminal the session unparents and then parents the terminal it causes all widgets in the terminal, including the displayed popover, to go through a unmap/map cycle causing these messages. If you do the split through a keyboard shortcut, these error messages don't appear. Here's the relevant code in gtkpopover.c
The bad news is I haven't been able to fix it so far, I've tried explicitly hiding the popover, deferring the action via addIdle and processing events before triggering the split but no luck. However, now that I know what the issue is I'm optimistic about putting this one to rest. I'll ping the IRC channel in the morning about this as well, I'm wondering if this is a gtk+ bug in the sense that it should check if the window is available first. |
Opened GTK+ bug for this: |
A patch has been attached to the bug report in GTK and I don't see any way to work around it on my end so closing this as a GTK bug. |
This has been fixed in GTK 3.20.6 |
The text was updated successfully, but these errors were encountered: