On Mon, Sep 30, 2013 at 1:53 PM, Tristan Van Berkom <trista...@openismus.com > wrote:
> Hi Matthias, > > On Sun, 2013-09-29 at 22:28 -0400, Matthias Clasen wrote: > > I've pushed a flowbox branch, which adds a GtkFlowBox widget. It is a > > copy of the EggFlowBox widget that has been developed in the > > egg-list-box module for a while, which is in turn based on an earlier > > EggSpreadTable in libegg. > > Based on EggWrapBox... EggSpreadTable was something a bit different. > I stand corrected...its been too long. o The flow box doesn't really flow anymore, i.e. differently sized > items can no longer wrap freely in the allocated space. > > This is a bit disappointing, I also notice that this is already > missing in EggFlowBox, which removes the 'allocation-mode' and adds > a 'homogeneous' property. > > The result is that wrapping/flowing widgets in this GtkFlowBox can > only ever show up as columns. > > FWIW, the mode that does still exist was a sort of hack to optimize > what would otherwise be 'homogenous' mode, which turns a flow box > into grid like columns anyway. > > An example of the functionality we are missing from wrap box: > +-------+---------------------+------+ > | A | B |//////| > +-------+----+-------+-------++------+ > | C | D | E | F | > +------------+-------+-------+-------+ > > In the above, the items A-F flow/wrap freely into the available > space, potentially showing the most content possible using less > height to do so. > > To see it in action, try running: > > ./libegg/libegg/wrapbox/testwrapbox > o Set the test items to "wrappy" for different sized items > o Set the allocation mode to "wrap free" > Yeah, that has been removed. Don't know any particular motivation, other than 'we don't need that'. I was tempted to apply the same reasoning to the vertical orientation, but I've left it in so far. It does add considerable complication to the keynav handling and other areas. > o gtk_flow_box_insert() or gtk_container_add() add an intermediate > child, breaking the logical widget hierarchy. > > For most of the history of GTK+, one can rely on the logical > hierarchy being preserved, i.e. adding a widget to a parent will > always pass the 'gtk_widget_get_parent (child) == parent' check. > > Honestly I would be more comfortable with a policy where only a > specific child type can be added to the flowbox. The GtkToolBar > and GtkMenuShell apis are clearer by limiting what types of > children can be added, without breaking the logical widget > hierarchy. > > In any case, I think this is worth at least a mention in > the gtk_container_add() documentation. > This is following recent precedents - we are now automatically inserting viewports between a scrolled window and its child, and GtkListBox is automatically wrapping its children in GtkListBoxRow intermediaries. I agree that we should add some hints about this to the the gtk_container_add docs. > o Problem in the demo/testflowbox... check and then uncheck the > "Filter" option, for some reason the items which were filtered out > don't show up again. > > Not sure if this is a bug in the test case of in the widget code. > I'll have a look. Thanks for the review ! Matthias
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
