Re: Some feedback about using gtkmm in real projects.





On Thu, Feb 12, 2009 at 3:34 PM, Germán Diago <germandiago 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.




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