Re: flow box

[Matthias Clasen <matthias clasen gmail com>]

On Mon, Sep 30, 2013 at 1:53 PM, Tristan Van Berkom <tristanvb 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