Re: [Cluttermm] Use of Glib::RefPtr<T> vs. Gtkmm



I'm not sure it's related, but it also has something to do with
smart pointers.
The get_object() method in Gtk::Builder class returns
Glib::RefPtr<Glib::Object>.
What would be the proper way of extracting those objects from builder
files?

Currently I'm doing it in this ugly way:
MyAdjustment=(Gtk::Adjustment*)(refBuilder->get_object("MyAdjustment").operator->());
And it works fine. But I know that it's not the proper way to do it.
What would be the correct way?

On Mon, 2010-03-15 at 17:22 +0100, Murray Cumming wrote:
> On Mon, 2010-03-15 at 16:55 +0200, Aarto Matti wrote:
> > Hello,
> > 
> > 
> > Why Glib::RefPtr<T> is used in Clutter for smart-pointer management
> > everywhere and Gtkmm doesn't bother about that much?
> > 
> > 
> > We can create a button object with Gtk::Button *button =
> > new Gtk::Button();
> 
> Clutter uses simple reference-counting for actors, I think.
> 
> GTK+ doesn't use simple reference-counting for widgets. Widgets are
> typically owned by a container, and in gtkmm we also allow you to delete
> it whenever you want.
> 
> > But we have to struggle in Clutter with that mess:
> > Glib::RefPtr<Clutter::Actor> actor = new Clutter::Actor::create();
> 
> I don't like it much either, really.
> 
> I like that the use of the smartpointer makes the memory management
> obvious. I would like to make such lines shorter somehow, while still
> keeping them clear. It's something to explore for gtkmm 3.
> 
> > and not do like this:
> > Clutter::Actor* actor = new Clutter::Actor();
> 
> Then you'd have to do manual reference/unreference like they do in C.
> 
> 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]