Damon Chaplin wrote:
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 t
On Sat, 2005-09-17 at 11:34 +0100, Damon Chaplin wrote:
> I've had a look at all the composite children that Glade uses for GTK+
> widgets. I think all of these could have been avoided if the widgets had
> been written slightly differently:
>
> GladeChildOKButton;
> GladeChildCancelButton;
>
Damon Chaplin wrote:
I've had a look at all the composite children that Glade uses for GTK+
widgets. I think all of these could have been avoided if the widgets had
been written slightly differently:
Hey,
thanks alot for compiling a list like that (I'll try to put it
to good use); I'm going
I've had a look at all the composite children that Glade uses for GTK+
widgets. I think all of these could have been avoided if the widgets had
been written slightly differently:
GladeChildOKButton;
GladeChildCancelButton;
GladeChildApplyButton;
GladeChildHelpButton;
GladeChildSaveButto
On Fri, 2005-09-16 at 12:14 +0100, Gustavo J. A. M. Carneiro wrote:
> On Fri, 2005-09-16 at 11:02 +0100, Damon Chaplin wrote:
> > avoid composite
> > children unless absolutely necessary (and even then only use simple
> > ones).
>
> I don't agree it's fair to limit developers' options on code
Gustavo J. A. M. Carneiro wrote:
[...]
avoid composite
children unless absolutely necessary (and even then only use simple
ones).
I don't agree it's fair to limit developers' options on code reuse
just for the sake of GUI builders. I'd rather pack an hbox into my
widget than duplicate its l
Damon Chaplin wrote:
[...]
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.
I definitly agree that some compromises are needed, but I dont think that
just because special cases have
On Fri, 2005-09-16 at 11:02 +0100, Damon Chaplin wrote:
> 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).
Indeed.
>
> You can then write up a guide for widget
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 idea
> Damon Chaplin wrote:
> They can also be named with gtk_widget_set_composite_name(), though this
> hasn't been used much in GTK+ itself.
And thats a damn shame :(
Right now I think the most evident practicle problems I'm seeing is:
- Composite children need to be marked as such in order to
Damon Chaplin wrote:
Composite children can be marked when created by the container calling
gtk_widget_push_composite_child()/gtk_widget_pop_composite_child().
Unfortunately, the way it works is sort of broken, because eg, if a
GtkDialog does:
gtk_widget_push_composite_child ();
butt
On Wed, 2005-09-14 at 23:27 -0400, Tristan Van Berkom wrote:
> On a more practicle note; I was thinking that internal children of
> composite widgets should be more introspectable; for the purpose
> of GUI builders and loaders, if every child widget implicitly created
> by its parent at least had
Hi all,
I know that there was much talk of introspection back in febuary;
I didnt really follow this extensive thread: (Introspection API)
http://mail.gnome.org/archives/gtk-devel-list/2005-February/msg00088.html
but I wonder what decisions essentially were taken as a big picture;
particula
13 matches
Mail list logo
