On 18-10-17 19:52, Russel Winder wrote:

With gtkmm if I create a subclass of gtk::Application then I just provide methods oncommandline, on_activate, etc. and they are the event handlers, no need for explicit connection: the data model is supporting making things easy, albeit implicit by convention.

Rust has no notion of inheritance and so gtk-rs just exposes the functions to connect handlers to events. This fits well with the computational model since there is the _ parameter in closures to say "I don't care, just do the type inference thing so it all fits together".

D is like C++ and could use convention over configuration and yet actually does things as Rust does, providing the configuration tools. So currently GtkD does not provide a class/inheritance based binding to Gtk as C++ does even though it has classes and inheritance as C++ does. But in doing things like Rust, D ends up being very verbose because everything has to be declared correctly.

I am not sure this is actually a big issue, it just seems a little "missing a thing"?

Is this making any sense?

Yes, that makes sense, you can override a function like you normally
would and it will actually be used by gtk/gobject.

I've been experimenting with gtkd.Implement.ImplementClass, which has
similarities with ruby-GNOME2's "type_register".

Currently you could use it like this:

class MyApplication : Application
{
   import gtkd.Implement;
   import gobject.c.functions : g_object_newv;

   mixin ImplementClass!GtkApplication;

   this()
   {
     super(cast(GtkApplication*)g_object_newv(getType(), 0, null), true);

     setApplicationId("org.gtkd.demo.popupmenu");
     setFlags(GApplicationFlags.FLAGS_NONE);
   }

   override void activate()
   {
     new PopupMenuDemo(this);
   }
}

I still need to sort out how to handle the constructor.
And currently you will need to manually specify the C callback if the
function has an array as any of it's parameters.