>> > 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
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
