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

Re: Resizing/Repainting of container when child-button is resized...



Owen Taylor schrieb:

> [...]
>
>None of this stuff can be right. I'd strip it all out, go back to 
>a simple approach and tell us what doesn't work with that. A small
>standalone compilable test case might help.
>
>In almost all cases, you just need to tell GTK+ what you want it
>to do (change the text in a label, say), and GTK+ will figure out
>resizing and repainting it needs to do it.
>  
>
Alright,

found out what causes this ... but not why ...

I have this callback connected to the configure-event on the main window 
which
moves a child window around with the main window if they are locked 
together.

//
// on move of window move frame too if locked
static gint on_configure_event(GtkWidget *w, GdkEventConfigure *e) {
    gint x, y, pwidth, pheight;
   
    if (IsFrameLocked()) {
        gtk_window_get_position( GTK_WINDOW(w), &x, &y);
//        gtk_window_get_size( GTK_WINDOW(w), &pwidth, &pheight);
//        y += pheight + FRAME_OFFSET;
//        GtkChangeFrame(x, y, XVC_frame_rectangle.width, 
XVC_frame_rectangle.height);
    }
}


If they are not locked, i.e. none of the stuff in the callback is 
actually executed,
the resizing works perfectly (but not the moving around of the child 
window, of
course) .... if I only have the ...get_position active, it does not.
Guess I'm somehow interfering with the default handling of the 
configure-event,
but connecting with ...connect_after doesn't help (in fact the child 
window doesn't
get moved at all).

Can anybody shed any light on this ?

TIA,

Karl.






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