Re: [Cluttermm] Use of Glib::RefPtr<T> vs. Gtkmm
- From: Michael <space3000 gmail com>
- To: gtkmm-list gnome org
- Subject: Re: [Cluttermm] Use of Glib::RefPtr<T> vs. Gtkmm
- Date: Mon, 15 Mar 2010 23:28:33 +0200
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]