Application hell

[dejlek]

So in parallel with my new Adwaits PR I worked on a tiny example to show at least how to create and run Adwaits application.

import std.stdio;

import gio.types;               // ApplicationFlags
import gio.application;         // gio.application.Application

import gtk.label;               // Label
import gtk.application;         // gtk.application.Application
import gtk.application_window;  
import gtk.box;
import gtk.types;               // Orientation

import adw.application;         // Application


int main() {
   auto app = new adw.application.Application("org.lekic.gid-examples.adw1.Mini", 
                                              ApplicationFlags.DefaultFlags);
   // has to be adw.application.Application
   app.connectActivate((gio.application.Application appArg) {
      auto label = new Label("Hello World!");
      auto box = new Box(Orientation.Vertical, 4);
      box.append(label);

      // it has to be gtk.application.ApplicationWindow otherwise you will get a segfault
      auto window = new ApplicationWindow(cast(gtk.application.Application)appArg);
      window.setTitle("Hello");
      window.setDefaultSize(200, 200);
      window.setChild(box); // Does not work for adw.application.ApplicationWindow
      window.present();
   });
   
   return app.run();
}

The code above is more less the same what they have in this document: https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1.6/initialization.html

What I want to discuss here is if we can avoid explicitly using all those fully qualified names.
If I have to do that for a small application like this, imagine how frustrating it would be for something serious
(I know, I am migrating my DIDE application to gid:gtk3 and I had the same set of issues there too).

connactActivate takes gio.application.Application so I have to explicitly put that in the signature.
ApplicationWindow (gtk.application_window.ApplicationWindow) takes gtk.application.Application so I have to cast the gio.application.Application there...

I wanted to make as small application that is as close to the example from Adwaita as possible, and it turned out to be uglier than the C code they have there! :)

So, can we do something about this?

[elementgreen]

Don't you only need to use the fully qualified names when there is a conflict? I don't think you need to do that for ApplicationWindow. Only for the Application ones, and then you could use an alias when you import them. The alternative that I know of is to add a prefix or postfix to the class name, so that it doesn't conflict. But this becomes quite complicated, as we add new libraries, since we can't foresee what will conflict. For example, Adwaita has an Application as well. I think the way giD is doing this now, is the best way. Those who want a shorter name to use in their application can just import it as an alias. Example:

import gio.application : AppGio = Application;
import gtk.application : AppGtk = Application;
import adw.application : AppAdw = Application;

Then just use them as AppGio, AppGtk, AppAdw.

[dejlek]

Yea I do that, though I name those types the same as GTK guys do: GioApplication, GtkApplication, AdwApplication, etc...

Maybe I am asking too much, but I am expecting it all to "just work" if I just import adw.application, because Adwaita Application is a subclass of gtk.application.Application, which is a subclass of gio.application.Application . It should IMHO all work with just a single import... :) So this supersmall application needed THREE import lines for three related classes... Sigh...

classDiagram
GioApplication <|-- GtkApplication
GtkApplication <|-- AdwApplication

Loading

[elementgreen]

As I mentioned before, gidgen could potentially make a module's dependencies public imports. You'd still have conflicting Application symbols though, which would either need to be specified with their fully qualified names or aliases created for them. It might end up being a one liner though, which would be 2 less than 3 😉 .

import adw.application : AppAdw = adw.application.Application, AppGtk = gtk.application.Application, AppGio = gio.application.Application;

I'm not positive it would work that way, but it seems like it might.. Not that much better though.

I wouldn't make the aliases with the namespace prefixing the symbol as you have it, because those are actually the names of the underlying C object structures. So if one needed to do something with those, they would conflict.

One potential solution could be to add convenience aliases to them. Gidgen could even detect if there are conflicting symbols as it did before internally, but use it to create public aliases, while still leaving the original symbols untouched.

[elementgreen]

I manually added public imports and the aliases to test it out. I also cheated and used the app from the outer context in main() instead of the cast, which resulted in:

import std.stdio;

import gio.types;               // ApplicationFlags

import gtk.label;               // Label
import gtk.application_window;  
import gtk.box;
import gtk.types;               // Orientation

import adw.application;         // Application


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

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

      auto window = new ApplicationWindow(app);
      window.setTitle("Hello");
      window.setDefaultSize(200, 200);
      window.setChild(box);
      window.present();
   });
   
   return app.run();
}

[dejlek]

This brings back the ApplicationGio and ApplicationAdw... :) Code is much cleaner now, but those names are confusing as there are also GioApplication and AdwApplication. :)