Re: custom treemodel?

["Murray Cumming" <murrayc murrayc com>]

>> > I don't have a lot of experience with GObject stuff, so I have no idea
>> > whether these should be necessary or not.  But it seems to run fine
>> > and doesn't issue a warning when those lines are commented out.  Any
>> > thoughts?
>>
>> Yes, I think I comment them out in Glom too.
>
> OK.  Then maybe I'll just get rid of them in the example.  Any objections?

No.

> So now the example runs without any warnings, and I've been working on
> ideas for a 'generic' custom treemodel.  I'm thinking about something
> like this:
>
> template <class T>

So T is a Standard C++ Container? Using
template <class T_Container> makes that a little clearer.

> class CustomTreeModel : public Gtk::TreeModel, public Glib::Object
> {
>   public:
>     Glib::RefPtr<CustomTreeModel> create(T container);
>     ...
>
>   protected:
>     CustomTreeModel(T container) :
>         Glib::ObjectBase(typeid(CustomTreeModel<T>)),
>         Glib::Object(),
>         m_container(container)
>     {}
>
>     // implement virtual functions
>     ...
>
>   private:
>     T m_container;
>     ...
> };

Yes, this is the ideal.

> Then an application developer would implement a specialization of
> this.  Something like:
>
> class MyListModel : public CustomTreeModel< std::list<MyAppType> >
> {
>   public:
>     typedef std::list<MyAppType> value_type;
>     Glib::RefPtr<MyListModel> create(value_type val);
>
>   protected:
>     MyListModel(value_type val) :
>         CustomTreeModel(val)
>     {}
>
>     // override any virtual methods for getting a value, number of
> columns, etc...
> };

Why would he need to derive a class? Wouldn't the templated class be enough?

> In fact i have a skeleton like this implemented to play around with,
> but I can't get it to instantiate.  When I call the
> MyListModel::create() function, I keep getting errors like this:
>
> glibmm-CRITICAL **: Glib::Interface::Interface(const
> Glib::Interface_Class&): assertion `gobject_ != 0' failed

Maybe you need to call the Glib::Object (or maybe ObjectBase, I forget)
constructor differently, if the example does that. Remember our discussion
about virtual inheritance.

> Now, I readily admit that I don't understand the GObject stuff very
> well.  I don't even really know why the custom treemodel should
> inherit from Glib::Object.

Glib interfaces are implemented by GObjects. That's just how the GObject
type system works. So we need a GObject type, and each of our class
instances will need an instance of that GObject type.

>  I just did it that way because the example
> in cvs did it that way.  One of the differences between my example and
> the example in CVS is that my class is a template class.  Could this
> line be causing problems because of the template?
> Glib::ObjectBase(typeid(CustomTreeModel<T>))

I don't think so.

> Or should I be doing the GObject type registration in the most derived
> class (MyListModel) instead of CustomTreeModel?  Or is my approach
> just flawed in some basic way?

Yes, I suspect that you might need to call the Object constructor in the
most derived class. And that is where you are doing the type registration,
I  think.



Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com