Re: GtkStatusbar and its GtkBox interface.

[Bastiaan Veelo <bastiaan sarc nl>]

Xan wrote:

<...>
> It's probably possible to add yet another workaround to this, but I
> agree with you that a cleaner design would
> be much better.
>
> If you have any ideas feel free to re-open the bug and comment there
> or post some patch.
>
> Cheers!

I have a hack in place for the moment, but I may be able to have a look 
at this a little later.

I have been thinking though, you are welcome to think with me:
On the one hand, we want GtkStatusbar to support the interface of 
GtkHBox. On the other hand we want the outer-most graphics to be drawn 
by GtkFrame. So you want to derive from GtkHBox for its interface, but 
you don't want it to be (isa) an hbox, rather a label. Are there other 
places in GTK+ where these multiple-inheritance questions pop up? What 
is the resolution?

I think inheriting the right API is the most important, so let's keep it 
that way. I see two solutions then:
1) Have GtkStatusbar draw its own frame (code duplication)
2) Re-implement/override the virual functions and forward the calls to 
an hbox that lives inside the frame.

I feel most for 2) but there will be a lot of functions with trivial 
contents. And what happens when sometime the parent API is extended and 
GtkStatusbar left untouched...?


Regards,
Bastiaan.