Use template-glib

[Prince781]

https://gitlab.gnome.org/GNOME/template-glib

I overlooked this library by @chergert when designing Valdo. template-glib is far more versatile. We should use this instead.

[chergert]

Personally I'd love to see us have a templating system for all of the apps/libraries/etc in Builder outside of Builder and just consume a library/tool for them. But since that code gets really messy really quickly, I never really formulated much of an API around it, let alone something that could be stable.

[lw64]

What about this as public API for a library?

namespace Valdo {

    [Flags]
    public enum TemplateLanguage {
        C,
        C_PLUS_PLUS,
        PYTHON,
        VALA,
        GJS,
        C_SHARP,
        RUST
    }

    public enum TemplateType {
        ANY,
        GNOME,
        ELEMENTARY
    }

    public enum License {
        GPL_3_PLUS,
        LGPL_3_PLUS,
        AGPL_3_PLUS,
        MIT_X11,
        APACHE_2_0,
        GPL_2_PLUS,
        LGPL_2_1_PLUS,
        NONE
    }

    public class Template : Object {
        public TemplateLanguage languages { get; }
        public TemplateType type { get; }
        public string name { get; }
        public Icon icon { get; }
    }

    public class Generator : Object {
        public License license { get; set; }
        public string app_id { get; set; }
        public string template_name { get; set; }
        public TemplateLanguage language { get; set; }
        public bool version_control { get; set; }
        public string location { get; set; }

        public async void generate_template () throws Error;
    }

    public errordomain Error {
        GENERATOR,
        BROWSER
    }

    // list of Template's
    public class TemplateBrowser : Object, ListModel {
        public TemplateType type { get; set; }
        public TemplateLanguage language { get; set; }
    }
}

Would this fit the needs of gnome-builder?

[chergert]

I don't mind Vala for sketching out an API, but Builder has a moratorium on Vala code, so we won't be introducing any dependencies into the Builder UI process itself that use it.

[lw64]

So the only alternative would be to write it in GObject C?

[lw64]

And I have understand it right that also if it would be a completely external project to gnome-builder, it wouldn't become a dependency?

[chergert]

It's possible we could consume a CLI tool, but then we'd want something that can describe all the possibilities up-front so that we can consume them and populate API.

[lw64]

Ok. That could work. This API could be also represented by a cli tool. Only the icon could be difficult. How should that be handled?

[chergert]

I would probably start by doing something like:

$ some-tool-name info --json
{
  "licenses": [ {"id": "gpl3plus", "name": "GPLv3+" }, ... ],
  "languages": [ {id: "c", name: "C"}, {id: "vala", name: "Vala"}, ...],
  "templates": [
    { "name": "GNOME Application",
      "description": "A GNOME Application with a single application window",
      "icon": "/path/to/pattern.svg",
      "languages": [ "c", "vala", "cplusplus" ],
      "variables": [ {"id": "app_id", "type": "app-id", "name": "Application Identifier", "summary": "A unique identifier for the application" },
                     {"id": "name", "type": "string", "validation-regex": "^[a-zA-Z0-9_-]$", ... } ],
...

Since the tool is expected to be used from the same execution context as the consuming application (in this case Builder), it doesn't need to worry about paths across file-system namespace boundaries. Builder would just bundle the tool.