Wireshark-bugs: [Wireshark-bugs] [Bug 8468] GTK3: Interface List dialog does not expand properly
Bill Meier
changed
bug 8468
| What |
Removed |
Added |
| Status |
IN_PROGRESS
|
CONFIRMED
|
Comment # 9
on bug 8468
from Bill Meier
Some comments:
Now that I look a little bit more closely at the code, it looks like there's
tricky stuff involved with trying to determine window sizes
------
https://developer.gnome.org/gtk3/3.5/GtkWindow.html#gtk-window-get-size
Quote "Note 1: Nearly any use of this function creates a race condition,..."
------
http://stackoverflow.com/questions/2675514/totally-fed-up-with-get-gtk-widget-height-and-width
In fact, a recent patch (SVN #48122) added gtk_widget_show/gtk_widget_hide
around a gtk_widget_get_preferred_size.
----
So: maybe the Wireshark code needs an in-depth review
Unfortunately I don't have the time to really dig into this code right now.
So: I've removed the "in progress" status I set.
==============
(In reply to comment #4)
> On a whim I flipped these two around in capture_if_dlg.c:capture_if_cb(),
> like so:
>
> window_present(cap_if_w);
>
> capture_if_refresh_if_list();
>
> Now the window pops up with the correct height and then expands to the right
> when filled with the entries.
Maybe because determining the size requires that the window/widgets be shown
(realized ?) first.
> Could we make that work in one go, first populate than show with the correct
> size that is.
>
> Therefore I flipped this conditional at the end of
> capture_if_refresh_if_list(), like so
>
> if (!cap_if_w) {
> gtk_window_get_size(GTK_WINDOW(cap_if_w), &curr_width, &curr_height);
>
> This works perfectly for me.
>
> I wonder, what is it intended to do anyway? Why would you want to call a GTK
> function on a NULL gtk window handle???
>
> Can someone try this flipped conditional on their !(Debian GNU/Linux testing
> / KDE) platform to see if it breaks on GTK2 / GTK3 for them?
I must be missing something here.
The original code had
if (cap_if_w) {
...
}
What was the reason again for flipping the test ?
Is the effect that the get_window_size doesn't normally get called ?
If so, maybe that relates to the issues described in Gtk3 doc about
gtk_get_window_size being problematical.
=========
Comment: cap_if_w is a global;
I haven't spent time really understanding this code; However the test here in
the middle of the code suggests to me that there's potentially a race condition
(such as a window destroy callback happening someplace).
Interrupts... Ugh...
You are receiving this mail because:
- You are watching all bug changes.
