Re: [gtk-list] Re: GtkWiW update...need some gdk help too.

[Chris Phelps <chicane reninet com>]

Ive been working like mad for a couple of hours now. I havent made the base WiW
widget yet, but that shouldnt take all that long, as the WiW child is the really
important part. At the moment, things are looking pretty spiffy, but I have run
into a small problem with the drawing of the widget. Since it is based on a
GtkVBox, which is transparent, i have to write the code to put the background
color and such behind the WiW Child widget, as well as add a border etc. I have
this done fairly well with a single sub window, but when sub windows overlap,
the sub window on the top doesnt draw over the other widgets that are inside the
sub window that it is overlapping. Ive looked at some code for the gtkbutton and
other, and havent been able to discern a reason for this.
Here is the code:

static void paint_wiw(GtkWidget *widget, GdkRectangle *area)
{
   gdk_window_clear_area(blah blah)
   gtk_paint_box(widget->style, widget-window, GTK_STATE_NORMAL,
                                                        GTK_SHADOW_ETCHED_OUT,
                                                        area, widget, "button",
                                                        widget->allocation.x,
widget->allocation.y,

widget->allocation.width, widget->allocation.height);
}

which is mostly jacked from the gtkbutton widget.
This, along with code to redisplay all the children of the subwindow, is called
for hide, draw, and expose events.

If anyone see's something that I have forgoten, please let me know.

And keep reading for more info...

> >    Ive now started coding the GtkWiW (window in window) widget, and
> > things are going moderatly well, but the main problem that I expressed
> > yesterday remains.
> How are you handling the window bars (title bar,resize and other
> wmdependant stuff)?

Right now im just using buttons with text (yeah, just about a cheesy as they
come), but when i get the interface worked out, i will make some generic
pixmaps. I would love it if this widget eventually got into the gtk+ 1.4 release
or something, then its settings could be added to the gtkrc, and its look could
be customized.

>

> >    I am using a GtkLayout widget to hold the sub windows, because it
> > seems like it will make things easier when i get to moving windows
> > around and such (extremely easy if my calculations hold...knock on
> > wood). Apparently, GtkContainer widget have no "stacking order" ( I
> > havent actually checked, past the header file) which means that if i
> > stick one of my subwindow widgets in it, I have no way of raising it to
> > the top. So far, i have tried about 20 different methods without any
> > luck. What i have right now is a button inside the sub window widget
> > that calls a bring_to_top function when it is clicked. I then call
> > gdk_window_clear and gdk_window_hide and gdk_window_show and then
> > finally gdk_window_raise, but nothing really changes.

> How about adding a name to each window and use that as a "stacking order"
> or add an int as data to the subwindow and use that as cardinality for
> stacking order
>

I think that im going to leave this up to the layout widget GList. When i focus
a sub window, ill just change the order of the GList (namely, move the selected
one to the top).

>
> >
> >    I think that I may be able to remove the sub window widget from the
> > GtkLayout, and then put it back in, which would most likely raise it to
> > the top, but that seems like cheating, and I know there must be a better
> > way.

> Hide->Show should do with without adding then removing again. unless that's
> what you were talking about.

No, it wasnt what i was taking about, but its a hell of a lot easier, so thanks
a bunch, it works now.

> >
> > Any help is greatly appreciated, and im sure that everyone will benefit
> > from the use of the new widget.
> >
> > Later,
> > -Chicane