Fri Jan 16 00:36:31 1998 Federico Mena <federico@bananoid.nuclecu.unam.mx>
* gtk/gtkhandlebox.c: Now we use a GtkWindow of type
GTK_WINDOW_DIALOG as a destination for reparenting the child of
the handle box. This solves the problem of having X calls in
Gtk. It also makes the handle box work with KWM, OLVWM, 4Dwm (so
I expect mwm to work as well). I hadn't noticed that previously
it only worked with fvwm and twm.
* gtk/gtkhandlebox.h (struct _GtkHandleBox): Removed the
real_parent field, as it is never used.
(struct _GtkHandleBox): Added a float_window field. This is a
GtkWindow to where the child is now reparented.
Fri Jan 16 00:36:31 1998 Federico Mena <federico@bananoid.nuclecu.unam.mx>
* gtk/gtkhandlebox.c: Lots of changes all over the place. Now the
widget has two windows. The steady_window stays put in the parent
container, and the widget->window is the one that gets
reparented. Now that window is transient, in compliance with the
ICCCM, instead of an OverrideRedirect window.
We have two windows so that we can properly receive Expose events
for the thin 3D line that marks the place where the handlebox is
docked.
* gtk/gtkhandlebox.h (struct _GtkHandleBox): Added fields for
dragging (mouse position information). Added fleur_cursor so that
we look pretty. Added steady_window field; it is the window that
actually stays on the parent (widget->window is the one that gets
reparented).
Owen, this is the version with the two X calls in gtkhandlebox.c.
I'll do as you say; either we can add new calls to Gdk, or I can
modify the handle box code to use a separate GtkWindow and reparent
the child into that.
- Federico
today). Next I will make the handle box use a transient window. It should
be done that way, according to the ICCCM. We have to talk to the KDE guys
to use their window manager protocol to let the WM know that we don't want
decoration on our window. This has to be hacked into other WMs, too.
- Federico
