Re: Patch for panel bugs 51201 and 52703

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.


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.
> 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]