Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

[Havoc Pennington <hp pobox com>]

Hi,

On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
<tristanvb openismus com> wrote:
>
> What happens when another subclass wants to use
> ->adjust_size_allocation() to realign itself further ? how
> can it cooperate with GtkWidgetClass and not cause bad side
> effects ?

In the patch I posted (assuming the FIXME is fixed), what would still be broken?
I'm sort of lost what problems are unsolved. Granted, I might find out
if I tested the patch ;-)

> ... and more importantly, why is this useful
> to anybody except GtkWidget and GtkContainer ?

It is useful in any abstract base class that wants to provide "stuff
around" whatever its subclasses draw.

I think GtkContainer is actually a good enough reason to have this.
border-width is deprecated sure, but it's not going away soon, it'd be
nice to clean up all the code that has to deal with it.

Another example in GTK is GtkMisc, though we want to deprecate that
too, you could use this vfunc to delete the align and pad handling
from its subclasses and delete some code, which would be nice.

Hypothetically you could do things like:
 * a base class that aligned in a more precise way than
left/right/center (like GtkAlignment)
 * a base class providing more complex CSS-like border/margin/pad
capability with colors for each
 * a base class that provided a frame
 * a base class that adds any kind of display or status next to subclass content

All of these could also be implemented as a container, granted. (That
is, GtkMisc and GtkAlignment solve the same problem.)
However, I think there can be good reasons to do this stuff in a base
class so your widgets can have the stuff "built in"

Havoc