Re: flow box
I've changed the selection behaviour to be more similar to the traditional multi-selection in GtkTreeView, and merged things to master. Please try it out. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: flow box
Hi Matthias,
Minor problem picking: I thought it might be a good idea if we use
g_return_val_if_fail(GTK_IS_FLOW_BOX_CHILD (child), FALSE) instead of
g_return_if_fail(GTK_IS_FLOW_BOX_CHILD (child)) in
gtk_flow_box_child_is_selected() when an invalid GtkFlowBoxChild* is
passed in to that function, as compilers expect a gboolean to be
returned to go without a warning/error for that.
Here's my simple fix for this, please let me know if this is OK to push.
With blessings, thank you!
From 284287fdf9df81c826fcb91e1fccd245d9e547fc Mon Sep 17 00:00:00 2001
From: Chun-wei Fan fanchun...@src.gnome.org
Date: Mon, 7 Oct 2013 12:00:30 +0800
Subject: [PATCH] gtk/gtkflowbox: Fix build warning/error
The newly-added gtk_flow_box_child_is_selected() needed to return a
gboolean, so use g_return_val_if_fail() to return FALSE when an invalid
GtkFlowBoxChild* is passed in.
---
gtk/gtkflowbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtk/gtkflowbox.c b/gtk/gtkflowbox.c
index 34a99a3..96d57f2 100644
--- a/gtk/gtkflowbox.c
+++ b/gtk/gtkflowbox.c
@@ -680,7 +680,7 @@ gtk_flow_box_child_get_index (GtkFlowBoxChild *child)
gboolean
gtk_flow_box_child_is_selected (GtkFlowBoxChild *child)
{
- g_return_if_fail (GTK_IS_FLOW_BOX_CHILD (child));
+ g_return_val_if_fail (GTK_IS_FLOW_BOX_CHILD (child), FALSE);
return CHILD_PRIV (child)-selected;
}
--
1.8.3.msysgit.0
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: flow box
Sure, please push. Thanks ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: flow box
On sön, 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. I think the widget is more or less ready to land in GTK+. It has - accessibility - height-for-width - keynav - documentation - multi-selection including rubberband selection and autoscroll Multiple selection doesn't feel quite right. Nothing is ever unselected unless you click on an already selected cell, or shift-click range-select. Usually any selection modification clears the previous selection unless you held down some modifier. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: flow box
On Tue, Oct 1, 2013 at 3:35 PM, Alexander Larsson al...@redhat.com wrote: On sön, 2013-09-29 at 22:28 -0400, Matthias Clasen wrote: - multi-selection including rubberband selection and autoscroll Multiple selection doesn't feel quite right. Nothing is ever unselected unless you click on an already selected cell, or shift-click range-select. Usually any selection modification clears the previous selection unless you held down some modifier. Yeah, its not quite what you normally expect from GtkTreeView, but it is quite similar to what e.g. gnome-documents or photos do in their selection mode. Some changes I had considered: - make rubberband selection toggle the selection instead of only selecting - make Ctrl-click clear the selection and start over like you said ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Intermediate children [was: Re: flow box]
On Mon, Sep 30, 2013 at 4:16 PM, Matthias Clasen matthias.cla...@gmail.comwrote: On Mon, Sep 30, 2013 at 1:53 PM, Tristan Van Berkom trista...@openismus.com wrote: 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. This may be a bit tangential to the flow box, but especially in light of those recent precedents I think the requirement of 'gtk_widget_get_parent(child) == parent' should be relaxed... we had some discussion about this a while ago in bug 699756 [1] but I never got around to doing anything with it after that. I like Emmanuele's idea of a has_child() vfunc in that bug's discussion though. [1] https://bugzilla.gnome.org/show_bug.cgi?id=699756 Regards, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: flow box
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 think the widget is more or less ready to land in GTK+. It has - accessibility - height-for-width - keynav - documentation - multi-selection including rubberband selection and autoscroll - sorting and filtering Some things could still be added: - baseline alignment - headers I'd appreciate review. I'm hoping to land this in the next week or so. I ran the demo, looked over the API and read some portions of the code, not line by line... here are my comments: 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 o I like how the spreading options were replaced with the align properties, it seems we achieve more or less the same effect by using the align property values. 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. 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. Cheers, -Tristan Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: flow box
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
