Re: gtk_container_new_child (was Re: Wrapping Box Container)
I forgot that GtkWidget::parent already works: g_object_new (TYPE_FOO, "parent", box, "blah", 42, NULL) This is a pretty nice solution I think. You don't even have to save a pointer to the new object if you aren't doing anything other than adding it to parent and setting a couple of props. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
Hi, On Thu, Sep 2, 2010 at 5:38 AM, Tristan Van Berkom wrote: > On the other hand... since g_object_new() will never return NULL... > I'm not sure how much this api would be different than simply > invoking these lines of code: > > gtk_container_add_with_properties (container, > g_object_new (GTK_TYPE_FOO, > "fill", FALSE, > NULL), > "expand", TRUE, > NULL); good point, this isn't bad, at least. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
On Wed, 2010-09-01 at 10:59 -0400, Havoc Pennington wrote: > Hi, > > On Wed, Sep 1, 2010 at 6:41 AM, Tristan Van Berkom > wrote: > > I like this idea alot and as its a trivial patch I might write one > > up tonight or tomorrow ... > > well, it's trivial except for the need to add some kind of gobject API > (or you could do it in a somewhat hacky way without that, I think) > > > I can see how that can reduce some lines of code when building > > UIs directly with code (not GtkBuilder)... although I think it > > would be best to avoid as it throws property and packing property > > names into the same namespace (so if ever packing properties and > > object properties share the same name, this api will be a little > > ambiguous as to which will be assigned, or one or the other > > would be prioritized...). > > > > Thoughts ? > > I think packing props should "win" (for back compat, among other > reasons). If there's a collision and you want to set the prop on the > child, you would need to just avoid this convenience function or set > the one colliding prop separately, which seems simple enough. I don't > know that there would be too many collisions in practice especially if > we thought about that when naming props. > > It COULD be done where you had to do a NULL separator between > container and child sort of like this: > > new_child(container, "foo", 1, NULL, MY_TYPE_CHILD, "bar", 5, NULL); > > however since it's a convenience API I think "common case convenience" > might be better than "handles weird corner case of colliding > properties" > > Another option is to allow prefixes on the prop names, > > new_child(container, MY_TYPE_CHILD, "parent::foo", 1, "child::bar", 2, NULL); > > where the prefix would be optional and only needed in case of ambiguity. > > The new_child version is harder than just add_with_properties() > supporting child props, because it involves marshaling to object_newv > or something. (again needing more gobject API at least for max > efficiency) > Ahh I see I misunderstood your email... as I can see that gtk_container_add_with_properties() already exists. On the other hand... since g_object_new() will never return NULL... I'm not sure how much this api would be different than simply invoking these lines of code: gtk_container_add_with_properties (container, g_object_new (GTK_TYPE_FOO, "fill", FALSE, NULL), "expand", TRUE, NULL); Its just about the same amount of typing in C... and already has no ambiguities regarding properties/child-properties. We could also safely make g_object_set() return the input object for this type of convenience... like g_object_ref() already does. Allowing this construct: gtk_container_add_with_properties (container, g_object_set (child, "fill", FALSE, NULL), "expand", TRUE, NULL); Ofcourse its perfectly valid C code already to type: gtk_container_add_with_properties (container, (g_object_set (child, "fill", FALSE, NULL), child), "expand", TRUE, NULL); although not many people are fans of using the comma operator in this way... personally I think its quite elegant to use in some cases... for instance: "ptr = (g_free(ptr), NULL);". Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Wed, 2010-09-01 at 10:51 -0400, Havoc Pennington wrote:
> Hi,
>
> On Wed, Sep 1, 2010 at 6:37 AM, Tristan Van Berkom
> wrote:
> > SPREAD_EVEN is exactly that.. adding extra space between the children as
> > spacing, and there is SPREAD_EXPAND for the other (not sure if that
> > could be better explained).
>
> that's what I was saying, just that the docs could use a small wording
> tweak. (because "distributing extra space between children" could mean
> either "among the children" - what I read the first few times - or "in
> between" them as spacing)
>
> > What would we prefer here ? A single AttachOptions type which can
> > be used amongst many containers or a custom enumeration ?
>
> I think AttachOptions is just broken, personally (though it beats
> booleans for readability). FILL should be in an enum with start, end,
> center since it is logically exclusive with those. SHRINK is just
> broken (widgets should never get less than their min size). So only
> EXPAND is a valid flag.
>
> Obviously the main gist of my comments would be most useful if
> actually fixing up FILL and padding to be props of widget instead of
> props of containers.
Ok I just pushed in a new and slightly changed api:
void
gtk_wrap_box_insert_child_with_padding (GtkWrapBox *layout,
GtkWidget *widget,
gint index,
guinthorizontal_padding,
guintvertical_padding,
GtkWrapBoxPacking packing);
I collapsed both the horizontal and vertical expand/fill options into
a single enumeration:
/**
* GtkWrapBoxPacking:
* @GTK_WRAP_BOX_H_EXPAND: Whether the child expands horizontally.
* @GTK_WRAP_BOX_H_FILL: Whether the child fills its allocated
horizontal space.
* @GTK_WRAP_BOX_V_EXPAND: Whether the child expands vertically.
* @GTK_WRAP_BOX_V_FILL: Whether the child fills its allocated
vertical space.
*
* Specifies how widgets will expand/fill vertically and
* horizontally when placed inside a #GtkWrapBox.
*/
typedef enum
{
GTK_WRAP_BOX_H_EXPAND = 1 << 0,
GTK_WRAP_BOX_H_FILL = 1 << 1,
GTK_WRAP_BOX_V_EXPAND = 1 << 2,
GTK_WRAP_BOX_V_FILL = 1 << 3
} GtkWrapBoxPacking;
I also took care of renaming SPREAD_BEGIN --> SPREAD_START
and named the padding options "horizontal-padding"/"vertical-padding"
to be more consistent with the rest of the wrap-box api (generally
I think those are more readable than "xpad"/"ypad").
There should be no more trailing whitespace in gtkwrapbox.h as well...
Thoughts anyone ? its still early enough I can come back and change
some details...
Cheers,
-Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
Hi, On Wed, Sep 1, 2010 at 6:37 AM, Tristan Van Berkom wrote: > SPREAD_EVEN is exactly that.. adding extra space between the children as > spacing, and there is SPREAD_EXPAND for the other (not sure if that > could be better explained). that's what I was saying, just that the docs could use a small wording tweak. (because "distributing extra space between children" could mean either "among the children" - what I read the first few times - or "in between" them as spacing) > What would we prefer here ? A single AttachOptions type which can > be used amongst many containers or a custom enumeration ? I think AttachOptions is just broken, personally (though it beats booleans for readability). FILL should be in an enum with start, end, center since it is logically exclusive with those. SHRINK is just broken (widgets should never get less than their min size). So only EXPAND is a valid flag. Obviously the main gist of my comments would be most useful if actually fixing up FILL and padding to be props of widget instead of props of containers. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
Hi, On Wed, Sep 1, 2010 at 6:41 AM, Tristan Van Berkom wrote: > I like this idea alot and as its a trivial patch I might write one > up tonight or tomorrow ... well, it's trivial except for the need to add some kind of gobject API (or you could do it in a somewhat hacky way without that, I think) > I can see how that can reduce some lines of code when building > UIs directly with code (not GtkBuilder)... although I think it > would be best to avoid as it throws property and packing property > names into the same namespace (so if ever packing properties and > object properties share the same name, this api will be a little > ambiguous as to which will be assigned, or one or the other > would be prioritized...). > > Thoughts ? I think packing props should "win" (for back compat, among other reasons). If there's a collision and you want to set the prop on the child, you would need to just avoid this convenience function or set the one colliding prop separately, which seems simple enough. I don't know that there would be too many collisions in practice especially if we thought about that when naming props. It COULD be done where you had to do a NULL separator between container and child sort of like this: new_child(container, "foo", 1, NULL, MY_TYPE_CHILD, "bar", 5, NULL); however since it's a convenience API I think "common case convenience" might be better than "handles weird corner case of colliding properties" Another option is to allow prefixes on the prop names, new_child(container, MY_TYPE_CHILD, "parent::foo", 1, "child::bar", 2, NULL); where the prefix would be optional and only needed in case of ambiguity. The new_child version is harder than just add_with_properties() supporting child props, because it involves marshaling to object_newv or something. (again needing more gobject API at least for max efficiency) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
On Tue, 2010-08-31 at 18:32 -0400, Havoc Pennington wrote: > Hi, > > On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington wrote: > > With my proposed padding cleanup though that issue goes away: > > > > child = g_object_new(TYPE_MYCHILD, "padding", 5, "h-align", > > GTK_ALIGN_FILL_HORIZONTAL, NULL); > > insert_child(layout, child, 2, GTK_WRAP_BOX_PACK_Y_EXPAND); > > > > Really great would be: > > gtk_container_add_with_properties(layout, child, > "position", 2, > "y-expand", TRUE, > "padding", 5, > "h-align", > GTK_ALIGN_FILL_HORIZONTAL, > NULL); > > which would work if we made gtk_container_set() and friends fall back > to props on the child if not finding a child prop on the container. > Kind of magic, but also really handy and results in very readable > code. I like this idea alot and as its a trivial patch I might write one up tonight or tomorrow ... > > The patch is kind of a pain because gtkcontainer.c relies on weird > gobject internals (seriously, #include > ?) and stealing part of g_object_set() with public GObject API > basically isn't possible. However, either a bit of a hack in here or a > quick API addition to libgobject would make this a simple feature to > accomplish. > > EVEN MORE AWESOME would be: > > child = gtk_container_new_child(layout, MY_TYPE_WHATEVER, > "position", 2, > "y-expand", TRUE, > "padding", 5, > "h-align", > GTK_ALIGN_FILL_HORIZONTAL, > NULL); > > sweet! even construct-only properties could be set here. I can see how that can reduce some lines of code when building UIs directly with code (not GtkBuilder)... although I think it would be best to avoid as it throws property and packing property names into the same namespace (so if ever packing properties and object properties share the same name, this api will be a little ambiguous as to which will be assigned, or one or the other would be prioritized...). Thoughts ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Mon, 2010-08-30 at 22:07 -0400, Havoc Pennington wrote: > While I'm making trivial comments about wrap box - there's START/END > in several other enums, rather than BEGIN/END (just look through > gtkenums.h, wrap box is the only BEGIN) > > @GTK_WRAP_BOX_SPREAD_EVEN description says "evenly distributed between > children" which I think means "as spacing between children" but I read > it several times thinking it meant the children got the space (as in > EXPAND) Thanks a lot for your comments Havoc :) I'll make the change for BEGIN->START to be more consistent with other apis... good point. SPREAD_EVEN is exactly that.. adding extra space between the children as spacing, and there is SPREAD_EXPAND for the other (not sure if that could be better explained). Regarding your other mail in this thread... I agree the _insert_child() api has alot of arguments, my original idea was to simply reuse GtkAttachOptions enum (except I'm not sure exactly what to do with GTK_SHRINK). What would we prefer here ? A single AttachOptions type which can be used amongst many containers or a custom enumeration ? > > also, there's a lot of trailing whitespace showing up red in my emacs ;-) I'll give a look into that... Cheers, -Tristan > > Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_container_new_child (was Re: Wrapping Box Container)
Hi, On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington wrote: > With my proposed padding cleanup though that issue goes away: > > child = g_object_new(TYPE_MYCHILD, "padding", 5, "h-align", > GTK_ALIGN_FILL_HORIZONTAL, NULL); > insert_child(layout, child, 2, GTK_WRAP_BOX_PACK_Y_EXPAND); > Really great would be: gtk_container_add_with_properties(layout, child, "position", 2, "y-expand", TRUE, "padding", 5, "h-align", GTK_ALIGN_FILL_HORIZONTAL, NULL); which would work if we made gtk_container_set() and friends fall back to props on the child if not finding a child prop on the container. Kind of magic, but also really handy and results in very readable code. The patch is kind of a pain because gtkcontainer.c relies on weird gobject internals (seriously, #include ?) and stealing part of g_object_set() with public GObject API basically isn't possible. However, either a bit of a hack in here or a quick API addition to libgobject would make this a simple feature to accomplish. EVEN MORE AWESOME would be: child = gtk_container_new_child(layout, MY_TYPE_WHATEVER, "position", 2, "y-expand", TRUE, "padding", 5, "h-align", GTK_ALIGN_FILL_HORIZONTAL, NULL); sweet! even construct-only properties could be set here. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Mon, 2010-08-30 at 18:20 -0400, Behdad Esfahbod wrote: > On 08/24/10 13:42, Tristan Van Berkom wrote: > > Is this a kind of widget that we are interested in adding to GTK+ ? > > What are the usecases for such a container? The selection of features looks a > bit arbitrary to me. I wanted it for Glom, which has vertical columns of widgets, flowing the widgets into the next column, like text in newspaper columns: http://www.glom.org/wiki/index.php?title=File:Small_glom_data_details.png Glom currently uses an awful buggy hacky C++ widget that I wrote, but GtkWrapBox should work properly. Gimp apparently has something similar, maybe for its tool pallete or tool preference windows: http://developer.gimp.org/api/2.0/app/GtkWrapBox.html -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
While I'm making trivial comments about wrap box - there's START/END in several other enums, rather than BEGIN/END (just look through gtkenums.h, wrap box is the only BEGIN) @GTK_WRAP_BOX_SPREAD_EVEN description says "evenly distributed between children" which I think means "as spacing between children" but I read it several times thinking it meant the children got the space (as in EXPAND) also, there's a lot of trailing whitespace showing up red in my emacs ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
Hi, On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington wrote: > I think "guint" here is just misleading; it's not like you can use > UINT_MAX, GTK uses signed int for most layout internally to avoid > screwy bugs caused by subtraction ending up < 0. > Also public API like set_size_request and GtkSizeRequest iface is all > signed int. > nevermind, that function isn't about pixels :-) (though I'm still not sure UINT_MAX is going to be relevant!) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
it'd be great to avoid the GtkBox stuff I was whining about in the padding thread, e.g. void egg_wrap_box_insert_child (EggWrapBox *layout, GtkWidget *widget, gint index, guint xpad, guint ypad, gboolean xexpand, gboolean yexpand, gboolean xfill, gboolean yfill); when you type this in it reads: insert_child(layout, child, 2, 5, 5, FALSE, TRUE, TRUE, FALSE) which is completely unreadable without going back and forth to the docs... worse, no compiler error if you mix any of these up. Bools and ints are really only OK as args if the function name makes clear what they are, imo. Otherwise, go enum or struct... if not doing the nice padding cleanup, I would consider: insert_child(layout, child, 2, 5, 5, GTK_WRAP_BOX_PACK_Y_EXPAND | GTK_WRAP_BOX_PACK_X_FILL) I'd be tempted to name it insert_child_with_padding honestly so it'd be clear what those numbers were when reading. With my proposed padding cleanup though that issue goes away: child = g_object_new(TYPE_MYCHILD, "padding", 5, "h-align", GTK_ALIGN_FILL_HORIZONTAL, NULL); insert_child(layout, child, 2, GTK_WRAP_BOX_PACK_Y_EXPAND); i.e. dump padding and fill/alignment out of the wrap box code entirely. Woohoo! One other trivial thing I noticed: void egg_wrap_box_set_natural_length (EggWrapBox *layout, guint length); I think "guint" here is just misleading; it's not like you can use UINT_MAX, GTK uses signed int for most layout internally to avoid screwy bugs caused by subtraction ending up < 0. Also public API like set_size_request and GtkSizeRequest iface is all signed int. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On 08/24/10 13:42, Tristan Van Berkom wrote: > Is this a kind of widget that we are interested in adding to GTK+ ? What are the usecases for such a container? The selection of features looks a bit arbitrary to me. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Thu, Aug 26, 2010 at 10:43 PM, Tristan Van Berkom > > I'm happy that this was so well received :) > > Maybe a decent property name alternative could be: > "minimum-line-children"/"natural-line-children" > > "minimum-children-per-line" would fit the description > but seems to me absurdly long while "minimum-children" > seems a little vague/general. > > Shall I go ahead and add this to git master after > making these trivial changes ? > - Change property name > - Initialize priv->children = NULL > - Use correct packing defaults in GtkContainerClass->add() > implementation. Yes, I'd like that. Nobody has spoken up against it. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Fwd: Re: Wrapping Box Container]
Oops I sent this privately to Hans earlier without CCing the list. Forwarded Message From: Tristan Van Berkom To: Hans Breuer Subject: Re: Wrapping Box Container Date: Fri, 27 Aug 2010 11:53:53 +0900 On Tue, 2010-08-24 at 23:09 +0200, Hans Breuer wrote: > At 24.08.2010 20:31, Matthias Clasen wrote: > > On Tue, Aug 24, 2010 at 1:42 PM, Tristan Van Berkom > > wrote: > >> Hi developers, > >> Last week I was busy writing up a new container > >> widget for GTK+ and would like to propose it for > >> inclusion in 3.0. > > > > Hey, sounds like a useful addition. I've actually had it somewhere > > deep on my todo list to look at a wrapbox implementation, now that we > > have hfw. Thanks for doing this. > > > Without looking too much into the new details, > what about finally integrating Tim Janik's work from 1999 ? > > See e.g.: http://git.gnome.org/browse/dia/tree/app/gtkwrapbox.h > Hi Hans, The main difference is that the "size-request" signal/vfunc implemented by widgets is replaced by a more elaborate height for width interface for requesting sizes of widgets: http://library.gnome.org/devel/gtk/2.90/GtkSizeRequest.html meaning in the end the whole requesting/allocating bit needs to be reconsidered anyway. Actually the GtkSizeRequestIface somehow broke the GtkWrapBox used internally in gimp iirc (with GTK+ git master I think its a toolbar that fails to wrap)... my hope is that this container can be a drop in replacement for these wrap boxes that might be broken when running against GTK+ 3.0. Cheers, -Tristan > Regards, > Hans > > Hans "at" Breuer "dot" Org --- > Tell me what you need, and I'll tell you how to > get along without it.-- Dilbert > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Tue, 2010-08-24 at 20:20 -0400, Matthias Clasen wrote: > On Tue, Aug 24, 2010 at 1:51 PM, Tristan Van Berkom > wrote: > > On Wed, 2010-08-25 at 02:42 +0900, Tristan Van Berkom wrote: > > [...] > >> PS: I've been trying to send this mail all day, at this point from > >> several email addresses... I'm dropping the .tgz attachment and will > >> follow up with another mail after uploading it somewhere if this email > >> does indeed hit the mailing list. > >> > > > > Looks like it finally went through after removing the attachment, > > you can build and try the demo by simply downloading it from here: > >http://people.gnome.org/~tvb/eggwrapbox.tgz > > > > I've given this a quick spin, and it seems to work as advertised, very nice. > For some reason I had to add a priv->children = NULL to init to keep it from > segfaulting. Which is curious, because I was convinced that we > 0-initialized privates. > > I also took a look at the code, and couldn't spot anything obviously > wrong (I admit that I didn't study the hundreds of lines of size > allocation code...). The one thing I noticed is that egg_wrap_box_add > should probably use the default values for the child properties (which > is FALSE for all the booleans, not TRUE as the function currently > uses). > > Since the minimum-length is a number of children, it would probably be > more natural to speak of it as the 'minimum number of children' > instead of the 'minimum amount' or 'minimum length'. I'm happy that this was so well received :) Maybe a decent property name alternative could be: "minimum-line-children"/"natural-line-children" "minimum-children-per-line" would fit the description but seems to me absurdly long while "minimum-children" seems a little vague/general. Shall I go ahead and add this to git master after making these trivial changes ? - Change property name - Initialize priv->children = NULL - Use correct packing defaults in GtkContainerClass->add() implementation. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Tue, Aug 24, 2010 at 1:51 PM, Tristan Van Berkom wrote: > On Wed, 2010-08-25 at 02:42 +0900, Tristan Van Berkom wrote: > [...] >> PS: I've been trying to send this mail all day, at this point from >> several email addresses... I'm dropping the .tgz attachment and will >> follow up with another mail after uploading it somewhere if this email >> does indeed hit the mailing list. >> > > Looks like it finally went through after removing the attachment, > you can build and try the demo by simply downloading it from here: > http://people.gnome.org/~tvb/eggwrapbox.tgz > I've given this a quick spin, and it seems to work as advertised, very nice. For some reason I had to add a priv->children = NULL to init to keep it from segfaulting. Which is curious, because I was convinced that we 0-initialized privates. I also took a look at the code, and couldn't spot anything obviously wrong (I admit that I didn't study the hundreds of lines of size allocation code...). The one thing I noticed is that egg_wrap_box_add should probably use the default values for the child properties (which is FALSE for all the booleans, not TRUE as the function currently uses). Since the minimum-length is a number of children, it would probably be more natural to speak of it as the 'minimum number of children' instead of the 'minimum amount' or 'minimum length'. Great work, Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
At 24.08.2010 20:31, Matthias Clasen wrote: On Tue, Aug 24, 2010 at 1:42 PM, Tristan Van Berkom wrote: Hi developers, Last week I was busy writing up a new container widget for GTK+ and would like to propose it for inclusion in 3.0. Hey, sounds like a useful addition. I've actually had it somewhere deep on my todo list to look at a wrapbox implementation, now that we have hfw. Thanks for doing this. Without looking too much into the new details, what about finally integrating Tim Janik's work from 1999 ? See e.g.: http://git.gnome.org/browse/dia/tree/app/gtkwrapbox.h Regards, Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Tue, Aug 24, 2010 at 1:42 PM, Tristan Van Berkom wrote: > Hi developers, > Last week I was busy writing up a new container > widget for GTK+ and would like to propose it for > inclusion in 3.0. Hey, sounds like a useful addition. I've actually had it somewhere deep on my todo list to look at a wrapbox implementation, now that we have hfw. Thanks for doing this. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
I'm not even reading the whole email: +1 !!! :-) 2010/8/24 Tristan Van Berkom : > On Wed, 2010-08-25 at 02:42 +0900, Tristan Van Berkom wrote: > [...] >> PS: I've been trying to send this mail all day, at this point from >> several email addresses... I'm dropping the .tgz attachment and will >> follow up with another mail after uploading it somewhere if this email >> does indeed hit the mailing list. >> > > Looks like it finally went through after removing the attachment, > you can build and try the demo by simply downloading it from here: > http://people.gnome.org/~tvb/eggwrapbox.tgz > > Cheers, > -Tristan > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Wed, 2010-08-25 at 02:42 +0900, Tristan Van Berkom wrote: [...] > PS: I've been trying to send this mail all day, at this point from > several email addresses... I'm dropping the .tgz attachment and will > follow up with another mail after uploading it somewhere if this email > does indeed hit the mailing list. > Looks like it finally went through after removing the attachment, you can build and try the demo by simply downloading it from here: http://people.gnome.org/~tvb/eggwrapbox.tgz Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
