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 opinions. ;-) > 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 NodeStore user. > 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: http://mono-project.com/ImplementingGInterfaces With an example of how a TreeModel could be implemented. -- Mike Kestner <[email protected]> _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
