Re: Patch for panel bugs 51201 and 52703
- From: Dave Dribin <dave dribin org>
- To: gnome-devel-list gnome org
- Subject: Re: Patch for panel bugs 51201 and 52703
- Date: Wed, 18 Jul 2001 13:44:04 -0500
Doh! The line numbers below are from the code in CVS as of last
night. session.c is CVS revision 1.187 and basep-widget.c is CVS
revision 1.89.
-Dave
On Wed, Jul 18, 2001 at 01:37:23PM -0500, Dave Dribin wrote:
>
> Hello,
>
> I think I have a patch for panel bugs 51201 and 52703 (which are
> basically duplicates). I'd like to discuss it a bit with someone who
> knows the panel/libgnomeui code better than I.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=51201
> http://bugzilla.gnome.org/show_bug.cgi?id=52703
>
> I am seeing this bug with an aligned panel in the lower right corner.
> I am using Ximian GNOME 1.4 on top of Red Hat 7.1 (both fairly fresh
> installs). Hence I am using XFree86 4.0.3 and Sawfish 0.38.
>
> I am not familiar with X lib programming (nor GNOME/GTK programming
> for that matter), but I have managed to come up with some code that
> fixes this bug on my machine. I'll walk you through my convoluted and
> long-winded reasoning. I added some debug print statements and came
> up with this sequence of events when the user logs in:
>
> 1) Panel initializes all saved panels in init_user_panels().
> (gnome-core/panel/session.c:1247)
>
> 2) Panel creates a new aligned_widget. At this point
> avoid_on_maximize has been read from saved data and the value *is*
> correct.
> (gnome-core/panel/session.c:1421)
>
> 3) aligned_widget_new() calls border_widget_construct().
>
> 4) border_widget_construct() calls basep_widget_construct().
>
> 5) basep->avoid_on_maximize is *correctly* set.
> (gnome-core/panel/basep-widget.c:1464)
>
> 6) Some time later basep_widget_realize() is called.
>
> 7) basep_widget_realize() calls basep_widget_update_winhints()
> (gnome-core/panel/basep-widget.c:135)
>
> 8) basep_widget_update_winhints() calls gnome_win_hints_set_hints(),
> taking int account basep->avoid_on_maximize.
> (gnome-core/panel/basep-widget.c:1225)
>
> 9) gnome_win_hints_set_hints() is supposed to correctly set the
> _WIN_HINTS X Window property.
>
> Ok, now this sequence of events actually seems correct.
> basep->avoid_on_maximize is correctly being read in on session
> startup. It is also correctly being passed into the basep constructor
> and is being saved inside basep state. However, the only bit of
> information that I noticed is "weird" is that the basep_widget is
> *NOT* mapped for this entire sequence of events.
>
> My hypothesis is that gnome_win_hints_set_hints() does not (or cannot)
> set _WIN_HINTS when the widget is not mapped.
>
> To back this up a bit more, I looked at the code from
> gnome_win_hints_set_hints(). It calls XSendEvent() if the widget is
> not mapped and XChangeProperty() if the widget is mapped. Now this is
> where my lack of understanding shows throw. I have no idea if this is
> correct behavior. Maybe it is impossible to call XChangeProperty()
> on a widget that has not been mapped. Whatever the case, the
> behavior of gnome_win_hints_set_hints() is different between a mapped
> widget and an unmapped widget.
>
> So, in assuming that gnome_win_hints_set_hints() is correct and the
> bug is in basep_widget, I decided to to a little experiment. I added
> a basep_widget_map() function as such:
>
> static void
> basep_widget_map (GtkWidget *w)
> {
> BasePWidget *basep = BASEP_WIDGET (w);
>
> g_return_if_fail (IS_BASEP_WIDGET (basep));
>
> if (GTK_WIDGET_CLASS (basep_widget_parent_class)->map)
> GTK_WIDGET_CLASS (basep_widget_parent_class)->map (w);
>
> basep_widget_update_winhints (basep);
> }
>
> Basically, it calls the super class map() method followed by setting
> the window hints. This ensures that the window hints are *always* set
> when the widget is mapped. And this fixed the problem! Maximizing a
> terminal worked correctly upon login.
>
> Now, this is where someone with more knowledge than I can help out. :)
> Is this just a silly hack around a bug in gnome_win_hints_set_hints()
> (or XFree86)? Or is this a possible fix for basep_widget calling
> gnome_win_hints_set_hints() at the wrong time during init?
>
> BTW, on a semi-related note, xprop *never* shows the _WIN_HINTS
> property being set to 39 whenever "Avoid On Maximize" is set. It is
> set to 7 all of the time. This seems a little odd as I thought the
> WIN_HINTS_DO_NOT_COVER flag (value 32) inside _WIN_HINTS was used to
> tell the window manager whether or not to cover on maximize.
> Obviously the WM is getting this information somehow because changing
> the GNOME panel property actually works. Maybe xprop is only showing
> 8 bits of information? Maybe this information is stored elsewhere? I
> dunno... I figured I'd throw this out there too, as it caused me much
> anguish while trying to debug this problem.
>
> Thanks,
>
> -Dave
>
>
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]