Need to use the "gio.application.Application" in gtk.application.Application subclasses.

[dejlek]

After the 0.9.4 i had to modify all handlers and explicitly use gio.application.Application type in them. Example: void onActivate(gio.application.Application app) even though it is a method of gtk.application.Application! I wonder what can we do to reduce writing this boilerplate?
Luckily it is not many that need this, so I can live with that for now. :)

[elementgreen]

The reason you have to specify it is because it conflicts between gio.application and gtk.application right? So you should be able to do something like this if you want to create an alias for it:

import gio.application : ApplicationGio = Application;

[dejlek]

Yes, I am aware of that. I guess my point is that both gtk.application.Application and gio.application.Application should be accepted... Even in this C code they are passing a callback that actually expects a pointer to the GtkApplication https://docs.gtk.org/gtk4/getting_started.html#basics :)

It is not a big deal as I only have it in two-three places, but is something I would like eventually to sort out...

My point is - we really do not need to import gio.application in code that imports gtk.application.

[elementgreen]

Oh, I see what you meant now. I guess this could be taken care of by having a public import of gio.application in gtk.application. I guess it would still need to be fully qualified though when using it in callbacks which are gio.application.Application specific, but at least the import wouldn't be necessary. The question becomes, should gidgen do the appropriate public imports for all external symbols used by the exposed API? Not sure if there are any pitfalls with that.

[dejlek]

100% :)

[elementgreen]

@dejlek I just committed a re-write of the SignalWriter to generate signal connect templates which use constraints. This allows for the ability to use derived object types in callbacks and I also made it to where all callback arguments are optional. So if you don't need any of them, because all of the needed variables are available in the delegate context, you can just have no parameters. Or as many parameters in sequence as are useful. For this reason it seems like it was a good idea to have the object parameter be the last one, since it is rarely needed. Here is an example of using a variable number of callback arguments:

    columnView.connectActivate(&onColumnViewActivate);
    columnView.connectActivate((uint pos) { writeln("pos: ", pos); });
    columnView.connectActivate(() { writeln("activate!"); });

  private void onColumnViewActivate(uint position, ColumnView columnView)
  {
    /* ... */
  }

Here is an example of using a child derived type (though the app variable could have just as easily been accessed in the parent context and no parameters given for the connectActivate lambda):

import std.stdio;
import gio.types;               // ApplicationFlags
import gtk.application_window;  
import gtk.label;               // Label
import gtk.box;
import gtk.types;               // Orientation
import adw.application;         // Application

int main() {
   auto app = new Application("org.lekic.gid-examples.adw1.Mini",  ApplicationFlags.DefaultFlags);

   app.connectActivate((Application appArg) {
      auto label = new Label("Hello World!");
      auto box = new Box(Orientation.Vertical, 4);
      box.append(label);

      with (new ApplicationWindow(appArg)) {
         setTitle("Hello");
         setDefaultSize(200, 200);
         setChild(box);
         self.present;
      }
   });
   
   return app.run();
}