Re: Gtk+ 3.0 and gtkmm-3.0

[Murray Cumming <murrayc murrayc com>]

On Tue, 2008-04-08 at 11:24 +0200, Germán Diago wrote:
> I saw this article in the web:
> 
> http://federkiel.wordpress.com/2008/03/12/gtk-30-getting-serious/

I still don't think this is likely to happen any time soon. Most things
can be done without breaking ABI.

> When I saw it I wondered if it would be a good moment (when gtk+3.0)
> to refactor a little the gtkmm API.

Yes, if there is a GTK+ ABI break then we will take that opportunity to
fix a few things, doing our best not to break API.

> This is just a post which expresses an opinion. I would like to know
> yours.
> 
> First of all, gtkmm is great for working with gtk+ from c++, but from
> my 
> point of view, it has some defficiencies.
> 
> Here is my wishlist and suggestions. Opinions are welcome.
> 
> The first one is just stetic, however, I think it could be managed
> with C++ easily.
> There are some objects in gtk+ that ask for global resources, whose
> constructor
> is protected, and a pointer to the object must be created in order to
> create the object.
> 
> 1.- I think that creation of objects should be uniform and the
> Glib::RefPtr::create() idiom should
> be hidden inside the implementation. All objects should be created in
> a uniform way (like in pygtk, for example)

I personally like that the RefPtr makes it very obvious when an object
is being shared. If the class does it itself then it's not obvious when
reading code like this

Something something2 = something;
something2.set_foo() //Also changes foo in something.

> 2.- I think that we should use std::shared_ptr when available (not for
> now).

This is difficult but not completely impossible.
There is a bug in glibmm to make RefPtr<> to do something similar.

> 3.- It's VERY difficult to introspect signals, slots and in gtkmm,
> because they use libsigc++. And they can only
> be bound at compile time. Don't get me wrong. libsigc++ is great, but
> it's very difficult to make
> an editor in which you can bind signals and slots with drag and drop.
> I think signals should be rethought
> so that they cover that so frequent use case. This would let people
> (like me) to write an IDE with these features.
> 
> I know that introspection for gobject is being implemented. Maybe with
> this one we can get signals and slots introspection.
> But I also would like to be able that, when I implement a signal or
> slot in C++, this is automatically added (or the best
> way that C++ can do this) to the gobject introspection. Because if we
> don't do this, we don't have
> all the features expected from the toolkit when we choose to use C++.

I can't imagine how this could be done, personally. C++ is not a very
dynamic language.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com