Re: Minutes of the GTK+ Team Meeting - 2008-09-23
- From: Michael Natterer <mitch gimp org>
- To: Morten Welinder <mortenw gnome org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Alexander Larsson <alexl redhat com>
- Subject: Re: Minutes of the GTK+ Team Meeting - 2008-09-23
- Date: Thu, 25 Sep 2008 19:24:25 +0200
On Thu, 2008-09-25 at 13:16 -0400, Morten Welinder wrote:
> > I think the general problem is that if you have a box type that can
> > change orientation on the fly, what type is it? A HBox or a Vbox?
>
> I cannot actually imagine why I would want such a box, but if you
> wanted to you could do
>
> #define GTK_IS_HBOX(w) (GTK_IS_BOX(w) && gtk_box_is_horizonal((GtkBox*)(w)))
>
> Sure, the widget could change orientation later, but existing code
> does not do that.
>
> Would someone please elaborate on these "*huge* benefits" this is
> supposed to bring?
Since you switched to normal language, here you go:
The *huge* benefit is not the ability to flip a box from horizontal
to vertical (only special cases need that), it's the ability
to change default values as we introduce a new widget type
(an instantiatable GtkBox which was an abstract type before).
The default values in question here are the packing defaults
which are completely insane for boxes. The default is
"everything expands unless otherwise told" where it should
be "everything shrinks unless otherwise told". In a normal
GUI you have lots of shrinking elements and *one* expanding
that is supposed to grow as the user resizes the window.
Currently 90-something-ish% of all children have to be packed into
boxes using gtk_box_pack_foo(box, child, FALSE, FALSE, pad).
That's totally redundant clutter and keeps people from using
the generic gtk_container_add() API. If the default values
were sane, only the expanding element would have to be
packed using such a verbose API.
regards,
--mitch
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]