Re: Resizing/Repainting of container when child-button is resized ...
- From: "Karl H. Beckers" <karl h beckers gmx net>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Resizing/Repainting of container when child-button is resized ...
- Date: Fri, 07 Nov 2003 20:19:43 +0100
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]