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