Patch for panel bugs 51201 and 52703

[Dave Dribin <dave dribin org>]

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