Sorry for the previous message. It was a mistake.
> Possibly the rationale behind Glib::RefPtr could be explained a bit
> more in the documentation.
I don't really mind the internal implementation of Gtk+ objects. It
should be a way
to construct any object uniformly, that's the point of using an
> However, Germán's point does raise the issue why pure GObject objects
> are always created in gtkmm by factory functions, rather than being
> created as auto objects or by the new expression as in the case of
> objects derived from GInitiallyUnowned/GtkObject. The fact that pure
> GObjects have
On Thu, 12 Feb 2009 17:43:19 +
Chris Vine wrote:
[snip]
> Since objects derived from Gtk::Widget are not intended to be copied
> (see more below), it would be pointless to obtain them by factory
> function. They can be constructed as auto objects (on the stack)
> or with operator new on the h
On Thu, 12 Feb 2009 15:43:49 +0100
Paul Davis wrote:
> On Thu, Feb 12, 2009 at 3:34 PM, Germán Diago
> wrote:
> > 1.- One of the things I think gets a lot in the way of the
> > programmer in gtkmm is the difference between
> > objects that use Glib::RefPtr and objects that don't. I think this
>
On Thu, Feb 12, 2009 at 3:34 PM, Germán Diago wrote:
> 1.- One of the things I think gets a lot in the way of the programmer
> in gtkmm is the difference between
> objects that use Glib::RefPtr and objects that don't. I think this is
> an implementation detail and it should
> not make any differe
Hello. I would like to report some feedback on using gtkmm during some
time (maybe 4 or 5 months).
These are just some suggestions I think would improve the API.
The API is ok, but I think, that when Gtk+3.0 comes, it should be
reshaped a little. My proposals would be
the following:
1.- One of th
