- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GtkNotebookPage
- Date: 11 Dec 2000 13:55:15 -0500
Tim Janik <timj gtk org> writes:
> hey owen,
> * gtk/gtknotebook.[ch] docs/Changes-2.0.txt: Move structure
> definition for GtkNotebookPage into .c file, since it is private.
> we can't do that, we have lots of code out there ala
> app->notebook->cur_page->child, as we have for other containers.
> people know that they outght to not modify those structures, but
> especially for containers where the child widgets aren't immediately
> accesible, we have to preserve easy access to the child pointers.
Is there a lot of code like that? I'd as soon break it now
The notebook code is very messy. I cleaned it up some, but it
could still use a lot more cleanup - there are _four_, count them,
four, separate ways that a page is referred to in gtknotebook.c.
- As an integer index
- As a GtkNotebookPage *
- As the child widget of the page
- As the GList link that points to the page.
Having implementation details exposed in the headers constrains
my ability to do such a cleanup.
I really disagree that poking around in the structures is an
appropriate way to access a container's children. Containers
may store their children in various, not necessarily simple
ways, and what's more, if we don't have proper API's to access
the children (GtkNotebook does), language bindings have to
invent their own.
> Mon Dec 11 11:41:12 2000 Owen Taylor <otaylor redhat com>
> * gtk/gtkinvisible.c (gtk_invisible_init): Flag invisible
> widgets as TOPLEVEL.
> * gtk/gtkwidget.c (gtk_widget_queue_resize): Don't assume
> TOPLEVEL widgets are containers.
> is such a good idea, i could make quite some simplifications in
> things like gerd/gle/beast when we finally had the TOPLEVEL<->GtkWindow
> constraint. GtkWindow might be overkill for gtkinvisible.c, but especially
> for the resizing code, i'd really like to keep at least TOPLEVEL<->GtkContainer.
Well, it's a question of whether we want to keep this constraint
or the constraint that
REALIZED (widget) && !widget->parent => TOPLEVEL (widget)
I think this latter one is more important, and more useful. And
I think if you really want to know if something is a window
use GTK_WINDOW ().
The constraint I'm happy with introducing is:
IS_CONTAINER (widget) && TOPLEVEL (widget) => WINDOW (widget)
Which is indeed necessary for the resize code. But GtkInvisible
is a useful widget, and I see no reason to bloat it into
a descendant of GtkWindow.
] [Thread Prev