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.