On Thu, Feb 12, 2009 at 3:34 PM, Germán Diago <germandi...@gmail.com> 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 difference to use one type of object or another. I think
> it should just be wrapped properly to hide
> the difference.


The difference reflects issues at the GTK level. I believe it would need to
changed there first.


> 2.- Maybe it would be good, instead of using Gtk::manage, to be able
> to use in the wrappers a system like
> the one Qt uses to free memory. That is, provide a parent which will
> manage the memory of its children.
> That would be done providing as first argument of the constructor the
> parent of the widget. It would
> be easy. In every object, provide a container to push pointers to
> objects that must be deleted (in GObject base class).


This already exists. You use manage () before adding the child to a parent.
Its a more flexible system than Qt because you can choose whether the
container manages its children or not - both styles are useful.

   Gtk::Foobar* foo  = new Foobar;
   some_container.pack_start (*(manage (foo), ...);

4.- C++0x: Move semantics for all widgets.


not sure what this refers to.


> 5.- Another difficult one: it would be VERY convenient to have some
> way to make signal autoconnection.


gtkmm signals are provided by libsigc++ which absolutely does not aim at
providing runtime signal definition. i don't think any of the people use who
libsigc++ with and without gtkmm are likely to be thrilled about a
fundamental redesign.

it is always possible (i believe) to use new sigc::signal<void>() to create
signals - the problem is looking them up by name. libsigc++ does not try to
provide this, and i'm not sure gtkmm should either, but opinions may differ.


>
> 6.- Minor one: Gtk::Main should not be an object, like in all the
> other wrappers. It should be Gtk::Main::init and Gtk::Main::run, with
> static functions. I think it does not make sense in other way.


this is a stylistic quibble. other people like the current design. neither
position is correct, or incorrect.
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to