And another thing…

The addOnStartup and addOnActivate functions on gtk.Application:Application appear to require a function taking a gio.Application:Application as a parameter whereas everything you want to do in the callback requires access via the original type. It maybe just me, but it seems awkward.

(gtk-rs seems to have this sorted better.)

On 14-10-17 15:27, Russel Winder wrote:

I think this is just me needing reassurance…

Gtk has (amongst others) the application level events activate and startup. For C++ gtkmm gives conventional names to the handlers as part of the inheritance hierarchy from Gio::Application. Rust (gtk-rs) on the other hand just presents the functions to bind handlers since it doesn't have inheritance per se (it handles the Gtk inheritance but doesn't offer anything to application developers).

D has classes and inheritance as C++, but GtkD doesn't present an inheritance hierarchy as gtkmm does, it just presents the binding functions as gtk-rs does.

At first sight this would seem to mean GtkD isn't going the class/inheritance route for handling Gtk but is going the functions route. I am guessing this is a consequence of doing the easiest simplest transform of the C API using the GIR files, whereas gtkmm puts a lot of effort to make as C++-like a binding as possible.

I am not saying GtkD should replicate the gtkmm architecture, but has it been constructively eschewed?

Could you elaborate a bit more about the inheritance, or is it just
about the signals?

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.