[Gtk-sharp-list] Adding sorting and filtering to nodeview/nodestore
mkestner at gmail.com
Tue May 5 17:54:12 EDT 2009
On Tue, 2009-05-05 at 14:43 -0400, Vladimir Giszpenc wrote:
> Hi Mike and others who can help me,
> I am considering adding filtering and sorting functionality to the
> NodeView/NodeStore and wanted to get some help with the design before
> I get started. I realize that this was a "failed experiment" in the
> eyes of Novell, but I believe it is a very elegant widget that is
> missing some functionality.
If I said "failed" before, I didn't intend to send that impression. It
was an experimental feature that reached a certain small level of
capability and proceeded no farther for various reasons. It is simply
incomplete. All it is lacking is someone to give it the love to push it
the rest of the way. It has warts, but they are not terminal. Also
note that my opinions expressed on my blog and on this list are my own
opinions, and not necessarily consistent with my employer's
> My thoughts are based on TreeModelFilter and TreeModelSort
My gut reaction is that you are probably holding closer to the
GtkTreeView mindset than NodeStore is really trying to do. The idea is
to hide as much of that as possible from the user. So, figure out what
user operations are exposed by Filter, and add API to NodeStore to
perform them. This might be as simple as adding a FilterFunc property,
but it most likely would not be of type TreeModelFilterVisibleFunc
because that exposes TreeIter and TreeModel and all the details we are
trying to hide with NodeStore.
Also keep in mind that anything that can reasonably be exposed by adding
an attribute of a property or class should be exposed as such, as that's
the nodestore paradigm. It may be that to do filtering or sorting
efficiently, you will need a second "store" type, but it would be worth
avoiding that if possible just to keep the discovery simpler for a new
> public class NodeStoreSort : NodeStore, Gtk.TreeSortable
Note that NodeStore itself does not expose Gtk.TreeModel. It has an
internal class which implements all that an hides all that TreeIter,
TreePath stuff from the user. Even if you add an additional "wrapper"
store like a NodeStoreSort, it should not directly expose the
TreeSortable interface, but instead expose a node-based alternative API.
> I don't fully understand the Adapters.
> How do I need to use TreeModelAdapter and TreeSortableAdapter? I want
> to use them to register for events I think.
The idea is this: when you implement a GInterface with C# code, you
want to implement the "Implementor" interface, which for sorting would
be TreeModelSortableImplementor. In order to pass an object which
implements the Implementor iface to a method which expects the full
consumable interface, you need to "adapt" it with the Adapter class.
You can also use the adapter class within the implementation to get
access to signal raising mechanisms, and event connections.
There is a somewhat more detailed description of this at:
With an example of how a TreeModel could be implemented.
Mike Kestner <mkestner at gmail.com>
More information about the Gtk-sharp-list