Simplify our UI declarative language, a strawman proposal

[esodan (Daniel Espinosa)]

Right. Lets remove programmers from the equation. Just focus on UI designers: a task to be performer by a programmer at some point if she/he has no external help on.

[fabrixxm]

That looks quite like QML

[esodan (Daniel Espinosa)]

Then what we are talking about is GML (Gtk Meta Language) as a proposed name.

[zbrown (Zander Brown)]

It’s based on GtkCssParser, GObject Sheet? (GOS?)

[ebassi (Emmanuele Bassi)]

Can we please stay on topic, instead of going down the rabbit hole of naming things?

[felipeborges]

@ebassi

Having a simpler/human readable format is entirely possible as an add on on top of a low level UI definition format. You can take a JSON-like/Elm-like approach and transform it into GtkBuilder XML already, today; it doesn’t need to live in GTK at all.

Yes, I think that would be a good approach. Build a format on top of the existing one, independent from GTK.

[esodan (Daniel Espinosa)]

Open this sub-thread for: how is this format going to be used

Initial use:

1. Initially as a meta-format to create native UI XML based definitions used by GtkWidgets
2. As a UI source code making easy to write by hand UI definitions
3. As a readable UI source code

[esodan (Daniel Espinosa)]

Open this sub-thread for: what kind of tooling can be built around it :

1. Source Code Editor with previewer for UI definitions
2. Glade like UI designer with embedded source code editor
3. New Format to XML Gtk UI native format validator and compiler
4. A plugin for GtkWidget to support new Format directly without compiler

[esodan (Daniel Espinosa)]

Open this sub-thread for: what kind of use cases is this format going to facilitate :

1. UI designers will get a clean and simplified format to write down UI definitiions
2. Avoid to write XML UI definitions by hand
3. Avoid Glade like tools to create XML UI definitions with hidden widgets like containers not in use
4. CSS like format is going to facilitate on set properties to modify UI constraints
5. Possibly is unnecessary to define object containers, because the direct access to CSS properties can help on arrange the UI object around others

Open this sub-thread for: what kind of use cases are out of scope for this format :

1. No UI definitions and UI logic mix
2. No embedded scripts
3. Programming Language specific syntax

Open this sub-thread for: what kind of conversion mechanisms are going to be available to port existing UI descriptions from GtkBuilder to FancyNewBuilder? :

1. An XML UI reader can take the current structure and tries to convert to new format, but limitations will be present, because maybe expressive syntax could be hard to be produced based on unexpressive but structured source like XML, more if there will be CSS in use, because no structure or per object association is present. Instead the new format should be able to use external CSS definitions

Open this sub-thread for: how do we deal with out-of-tree widgets and object types?

1. New format should be able to define classes, a class should have child nodes describing its child nodes and class’s name should be able to be imported in other sources when the class is instantiated in current UI definition.

class mywidget {
   button {
        id: "button1";
        label: "Clickme!";
    }
    entry {
        id: "entry1";
    }
}

diaglog {
    mywidget;
}

Open this sub-thread for: how do we deal with out-of-tree widgets and object types for which we don’t have source access?

1. Like in Vala, there should be .uidef kind of file, where all details about the library/object containing the widgets definitions and widgets classes to call should be present; the package name should be pkg-config foundable, so compiler can just check the class exists and produce the XML UI definition introspecting the Widget type’s name from the library in use.

module {
    pkg: "libmywidgets-1"
    classes {
        mywidget;
    }
}

Open this sub-thread for: how do we deal with versioning?

1. Versioning will be implicit in the package’s name referencing to the library to link against

Open this sub-thread for:
how do we deal with property bindings?
how do we deal with settings bindings?
how do we deal with custom elements/attributes?

1. The Programming Language in use should use standard GObject mechanism to implement any binding.
2. No custom element/attributes should be allowed, the same way no custom attributes or elements can be defined in CSS, attributes hould be enough to modify the UI aspect
3. Above means nothing for custom properties modifying the widget aspect, using your favorite programming language

Open this sub-thread for: who is going to do the work?

1. The hardest question. Any one?

[aruiz (Alberto Ruiz)]

I don’t think that discussing this here is of much value. If someone is interested in working on this, they should sit down and write a prototype or initial implementation of the idea and iterate around that to the point that it can be useful.

I do feel this is important given the fact that I don’t think Glade will support GTK4 anytime soon if ever, we need something that is more intuitive to write just by looking at devhelp or a vapi. I am somewhat enticed to help but as of now it is hard for me to commit much if any time on this.