Sounds like a dup of bug 67972, which was closed because I
couldn't reproduce it any more.

To reproduce run libbonoboui/test/test-ui and press 'Press me to test'
a few times until you get a grip and the "This is a very long
string..." blurb in the status bar, and give a bit of a gragging to
that resize grip.

HTH.

Couldn't figure this out in a few minutes of looking at it.
The attached patch is probably needed as a start of fixing
the problem,since the label was getting completely bogus
allocations.

Created attachment 7300 [details] [review]
Partial fix to get reasonable allocations. (Not applied to CVS)

Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.

Moving a number of non-critical or hard-to-fix bugs to 2.2.0

Move various non-critical bugs onto 2.2.1 milestone.

Created attachment 12818 [details] [review]
Extension to testgtk

The patch I just attached extends the statusbar test in testgtk so that 
it gets a new button that pushes a long text on the statusbar. 

With this patch, a similar problem can be reproduced by using the
"Properties" tool to make the long label selectable, then select a
part of the label that extends beyond the resize grip, and finally resize
the window a bit. You can then see the blue select color between the
window and the resize grip.

In my opinion the best fix is to add a GtkResizeGrip widget in 2.4 and
then simply add that widget to the statusbar. That will get rid of 
the not-quite-sane hacks that goes on in statusbar_size_allocate().

A resize grip is useful outside of statusbars anyway.

Looks like the wrong patch is attached above?

I don't think you can compatibly turn this into adding
a widget ... if you add extra things packed into the
status bar, you'll cause problems for people who are
already packing stuff in there.

Created attachment 14004 [details] [review]
The right patch

(I just attached the correct patch)

Maybe it would be possible to add an internal method on hbox, "put
this widget at the end, always". I think that would be a better
solution than more messing with hbox internals in gtkstatusbar.

Owen, your patch to get reasonable allocations fixes things as far as
the statusbar is concerned. The remaining problem is selectable labels
drawing the selection and the cursor outside of their allocation. The
following fix seems to fix the problems with text bits showing up to
the   right of the resize grip. It doesn't fix the problem that the
resize gri p should really be a shaped window (or be implemented
without any extra window).

Created attachment 16598 [details] [review]
combined patch for statusbar and selectable label

Created attachment 16599 [details]
remaining clipping problems

Couple of comments about the GtkLabel patch:

+      clip = gdk_region_rectangle (&widget->allocation);
+      gdk_gc_set_clip_region (gc, clip);

Could use gdk_gc_set_clip_rectangle() instead.

+	  area = gdk_region_rectangle (&event->area);
+	  gdk_region_intersect (clip, area);
+          gdk_region_destroy (area);	  

Could just use event->region (which is also more exact
than the event->area bounding box.) Or did you mean 
widget->allocation?

For the remaining problems shown, it would be pretty
trivial to switch to an input-only window and drawing
on the parent window.  That could have the strange
effect of children of the statusbar going *over* the
resize grip if you had !NO_WINDOW children, like
GtkProgressBar (why didn't we fix that? Must have
forgotten about it.)

I don't think the shaped window is possible, since 
drawing the resize grip is themed, so it might not
follow the same pixels.

Wouldn't the "drawing over" simply be fixed by shrinking the child 
allocation to reserve room for the resize grip ? I think in the long 
run, promoting the resize grip to a real child widget is better.


If you fear compatibility problems, we could simply implement


an adjusted add() method which would force the resize grip to stay 


at the end (the simplest way to do it might be to remove the resize 
grip, add the new child, then put the resize grip back at the end...)




Ok to commit the patches with the changes you outlined ?

You can't have an "adjusted add" function, because 
pack_start/pack_end, in GtkHBox aren't virtualized.

I'm wondering if my initial statusbar change was on
the wrong track, and whether the right fix was instead
to make get_grip_rect() use requisition width/height
rather than allocation width/height.

I think it's very unlikely that a statusbar will
get allocated taller than it's requisition, so 
I think making the grip rect's size equal to the
width of the requsition should be fine. If we didn't
do that, then we'd need width-for-height geometry 
management to get this right. 

Owen, looking again at this, I came across another problem with the
current resize grip implemenation: If the label in the statusbar is
made selectable, the resize grip becomes dysfunctional, since the
button presses are handled by the label and
gtk_statusbar_button_press() doesn't get called.

You may be right that turning the resize grip into a regular child
widget can't be done compatibly, so here is a compromise proposal:

Lets add a GtkResizeGrip widget, deprecate
gtk_statusbar_[gs]et_has_resize_grip(), but leave it there for 
compat reasons.

The "adjusted add" I suggested originally was about creating a

       _gtk_hbox_add_at_end (GtkHbox *hbox, GtkWidget *child)

that would cause the HBox to always position child as the end of the hbox.

Not particularly nice; Matthias' compromise may be better.

Here is a first cut at GtkResizeGrip. The screenshot shows that using
a widget instead of drawing over the label is not 100% visually
compatible, but I think that is ok. There are examples for both
visuals on other platforms, e.g IE uses the old appearance, Excel the new.

Created attachment 18797 [details]
gtkresizegrip.h

Created attachment 18798 [details]
gtkresizegrip.c

Created attachment 18799 [details] [review]
testgtk patch

Created attachment 18800 [details]
screenshot

Some comments:

    - How does this interact with RTL? Who is responsible for changing
      the window edge property when the widget gets moved to the other
      end of its container?

    - I think there should be style properties "width" and "height"
      (or at least a "size" property)

    - the string passed to "paint_resize_grip" should probably be
      "resize_grip", not "statusbar"

Unless of course this is to be internal-use API only, in which case
none of the comments above apply.

    - How does this interact with RTL? Who is responsible for changing
      the window edge property when the widget gets moved to the other
      end of its container?

The GtkResizeGrip does flipping on its own. If you set
edge = GDK_WINDOW_EGDGE_SOUTH_EAST and the text direction to RTL,
the effective edge is GDK_WINDOW_EDGE_SOUTH_WEST. See get_grip_edge().
You can test this in testgtk with the "flipping" example.

    - I think there should be style properties "width" and "height"
      (or at least a "size" property)

Should these control the size of the widget or only the size of the
drawn grip and the input window ?

    - the string passed to "paint_resize_grip" should probably be
      "resize_grip", not "statusbar"

Yes.

Created attachment 18977 [details]
new version

To me, packing a GtkResizeGrip in just doesn't feel very natural;
I'm not sure I can quantify exactly why, possibly:

 A) Because it doesn't make much sense most places in the window
 B) Because it would be nice to keep flexibility for a 
    over-the-top GtkResizeGrip

Note also that I don't see how you aer going to make the GtkResizeGrip
widen as the statusbar gets taller with a separate widget, if
you do it as a separate widget.

I think I'd rather do it with some magic hidden GtkHBox API
then as a separate widget, though I'm not really convinced
you can't do it by simply overriding GtkSizeRequest/Allocate
for GtkHBox and chaining up.

It is pretty clear that this isn't ready for 2.4.0 at this point.

*** Bug 137107 has been marked as a duplicate of this bug. ***

It feels like several of the patches in this bug could be marked obsolete or
needs-work but I'm not quite clear on the relationship between them all, so
perhaps someone could go through and do that who is more clear with the
situation. Just a though.

Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.

I have fixed the clipping/overdraw problems now.