Re: Some introspection on GtkContainer children.
- From: Damon Chaplin <damon karuna uklinux net>
- To: Tristan Van Berkom <tristan van berkom gmail com>
- Cc: Dan Winship <danw novell com>, gtk-devel-list gnome org
- Subject: Re: Some introspection on GtkContainer children.
- Date: Fri, 16 Sep 2005 11:02:49 +0100
On Thu, 2005-09-15 at 15:46 -0400, Tristan Van Berkom wrote:
> as specially noted that there are in effect three types of child
> widgets; "normal", "added as a result of a property value"; "added
> as a composite child which is constantly present".
>
> I think that if we're going to talk of ideal scenarios, GtkContainer
> should probably be a GInterface and allow for any object to have child
> objects; which also could be composite or not; children also tend to
> have different relationships to parents; for example a GtkMenuItem
> parented by a GtkMenu isnt exactly a GtkContainer --> GtkWidget relationship,
> its also concievable that a parent object can have multiple children
> of multiple relationship types.
I think you guys should probably give up on the idea of handling
standard GTK+ widgets generically. There are so many special cases that
it is almost impossible.
But what you should aim for is to be able to handle external widget
libraries generically (e.g. there is very little special-case code to
handle the GnomeDB widgets in glade-2).
You can then write up a guide for widget developers who want to be
compatable with GUI builders - e.g. use widget properties to configure
everything, don't use construct-only properties, avoid composite
children unless absolutely necessary (and even then only use simple
ones).
You can probably cover over 95% of all external widgets that way.
(You could also add hints to the widget description catalog files to
support things like Dan's gtk_container_get_max_children() idea.
It doesn't all have to be introspection if its just for GUI builders.)
Damon
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]