[gtkmm] Re: Custom TreeModel (was RE: signals versus vfuncs)

[Christof Petig <christof petig-baender de>]

Murray Cumming Comneon com schrieb:
> Christof wrote:
>
> > Do you still feel that a custom tree model is unnecessary? My feeling is 
> > that for _massive_ amounts of lines the C++ wrapper imposes too much 
> > overhead (vfunc indirection, iterator conversion etc. sum up once the [] 
> > operator on a Gtk::Tree::Row is used many times to access the columns).
> >
> > My std::map based model easily handles sorted insertion/reorganization 
> > of 100k rows into a tree without significant slowdown.
>
>
> I would like to see some proof that it's faster in GTK+ when using normal
> TreeStores or ListStores. Such proof should be in bugzilla as a gtkmm
> performance bug.

I really have no intention to port a three additional library involving, 
heavily STL using _example_ program to C (custom smart pointers, custom 
GValue like with user defined sort order etc.).

And to be honest, I really gave up to further research this issue once 
you told me so, back then. The implementation was using STL's 
lower_bound on Gtk::TreeStore and performed poorly, now with minimal 
changes and std::map it flies.

Perhaps I might code an trivial example in C++ with Gtk::TreeModel vs. 
GtkTreeModel. If you _really_ want to analyze this. And if I ever find 
the time for it. Feel free to ask/confirm.

> > PS: It seems that because of the 
> > Gtk::TreeModel::add_interface(get_type()); call during type creation I 
> > cannot use the Glib provided custom type infrastructure.
>
>
> I'm not sure what you want to do instead, or can't do. What "Glib provided
> custom type infrastructure" do you mean? API docs URLS are nicest.

I did not find any API docs when I researched implementing Gtk::Interfaces.

While I really like the easy Glib::ObjectBase(typeid(...)) way of 
getting a GType (e.g. custom cellrenderer), I have to use 
Glib::ObjectBase("MyTreeModel"), 
Glib::Object(Glib::ConstructParams(myclass.init(), (char*) 0)), create a 
custom Class struct:

class MyTreeModel_Class : public Glib::Class
{public:
        const Glib::Class& init();
        static void class_init_function(void* g_class, void* class_data);
};

a custom GTypeInfo
and call g_type_register_static and Gtk::TreeModel::add_interface. IMHO 
it should be possible to just derive from some class (e.g. 
Gtk::CustomTreeModelBase) and override the vfuncs.

Perhaps the key to this overhead is the fact that a TreeModel is not a 
GObject and there's no way to specify additional things to be done at 
GType registration "TreeModel::add_interface" (is there?).

> The problem, I think, is that the Gtype must come from the derived type, but
> you want that type to be registered in the base C++ class, whose constructor
> runs before the derived part of the class exists. I don't think the
> add_interface() call is too bad for something that is very rarely done.

add_interface is ok with me. It's the bulk of lines needed to get a 
minimal custom TreeModel that bothers me.

   Christof