[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: flow box
From: Matthias Clasen <matthias.clasen () gmail ! com>
Date: 2013-09-30 23:16:37
Message-ID: CAFwd_vAWVW=cy8GUGMxa1wN3SUyuLevisfTdTSCJmtQqi73kTA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<div dir="ltr">On Mon, Sep 30, 2013 at 1:53 PM, Tristan Van Berkom <span \
dir="ltr"><<a href="mailto:tristanvb@openismus.com" \
target="_blank">tristanvb@openismus.com</a>></span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi \
Matthias,<br> <div class="im"><br>
On Sun, 2013-09-29 at 22:28 -0400, Matthias Clasen wrote:<br>
> I've pushed a flowbox branch, which adds a GtkFlowBox widget. It is a<br>
> copy of the EggFlowBox widget that has been developed in the<br>
> egg-list-box module for a while, which is in turn based on an earlier<br>
> EggSpreadTable in libegg.<br>
<br>
</div>Based on EggWrapBox... EggSpreadTable was something a bit \
different.<br></blockquote><div><br></div><div>I stand corrected...its been too \
long.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
o The flow box doesn't really flow anymore, i.e. differently sized<br>
items can no longer wrap freely in the allocated space.<br>
<br>
This is a bit disappointing, I also notice that this is already<br>
missing in EggFlowBox, which removes the 'allocation-mode' and adds<br>
a 'homogeneous' property.<br>
<br>
The result is that wrapping/flowing widgets in this GtkFlowBox can<br>
only ever show up as columns.<br>
<br>
FWIW, the mode that does still exist was a sort of hack to optimize<br>
what would otherwise be 'homogenous' mode, which turns a flow box<br>
into grid like columns anyway.<br>
<br>
An example of the functionality we are missing from wrap box:<br>
+-------+---------------------+------+<br>
| A | B |//////|<br>
+-------+----+-------+-------++------+<br>
| C | D | E | F |<br>
+------------+-------+-------+-------+<br>
<br>
In the above, the items A-F flow/wrap freely into the available<br>
space, potentially showing the most content possible using less<br>
height to do so.<br>
<br>
To see it in action, try running:<br>
<br>
./libegg/libegg/wrapbox/testwrapbox<br>
o Set the test items to "wrappy" for different sized items<br>
o Set the allocation mode to "wrap \
free"<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> o gtk_flow_box_insert() or \
gtk_container_add() add an intermediate<br> child, breaking the logical widget \
hierarchy.<br> <br>
For most of the history of GTK+, one can rely on the logical<br>
hierarchy being preserved, i.e. adding a widget to a parent will<br>
always pass the 'gtk_widget_get_parent (child) == parent' check.<br>
<br>
Honestly I would be more comfortable with a policy where only a<br>
specific child type can be added to the flowbox. The GtkToolBar<br>
and GtkMenuShell apis are clearer by limiting what types of<br>
children can be added, without breaking the logical widget<br>
hierarchy.<br>
<br>
In any case, I think this is worth at least a mention in<br>
the gtk_container_add() documentation.<br></blockquote><div><br></div><div>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.<br> <br></div><div>I agree that we should \
add some hints about this to the the gtk_container_add docs.<br></div><div> \
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">
o Problem in the demo/testflowbox... check and then uncheck the<br>
"Filter" option, for some reason the items which were filtered out<br>
don't show up again.<br>
<br>
Not sure if this is a bug in the test case of in the widget \
code.<br></blockquote><div><br></div><div>I'll have a \
look.<br><br></div><div>Thanks for the review !<br><br><br></div><div>Matthias \
<br></div></div><br> </div></div>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic