Feature Request: Markup format (think qml) to create GUIs about ui

[andlabs]

My stance on the matter is simple: you can build a declarative API on top of a non-declarative one, but not the other way around. libui itself likely won't come with one, but it won't stop you from writing one, and I could build a Go-specific one myself if I wanted.

[andlabs]

This is in my thoughts; it will be provided as a subpackage. (Keep open until implemented.)

[SaadHafiane]

Wouldn't just providing JSON tags for the structs provide such a feature out of the box?

package main

import (
    "encoding/json"
    "fmt"
)

type Layout struct {
    Buttons []Button `json:"Buttons"`
}

type Button struct {
    Text string `json:"Text"`
    Type string `json:"Type"`
}

func main() {
    b := []byte(`{"Buttons": [{"Text":"simple ui.Button", "Type":"default"},
                           {"Text":"radio ui.Button", "Type":"radio"}]
                 }`)
    var m Layout
    if err := json.Unmarshal(b, &m); err != nil {
        fmt.Println(err)
        return
    }
    fmt.Printf("%#v\n", m)
}

Unmarshalled layout struct:
main.Layout{Buttons:[]main.Button{main.Button{Text:"simple ui.Button", Type:"default"}, main.Button{Text:"radio ui.Button", Type:"radio"}}}

[duckbrain]

Unmarshalling JSON won't call the stuff in the ui.New* functions. You'll get the structs, but the components won't be created. Also, I'd imagine it'd be very useful to have a way to define ID's in the JSON and have them returned in a map[string]ui.Control.

[SaadHafiane]

GUI description being declarative by nature recursive calls of the constructors should enough to create the elements.
As for the controls IDs, having an ID field in the structs themselves could allow such a behavior, and a jQuery like interface would be useful I could see such use cases:

• batch updates of elements by ID
• decoupling the variable name from the call-back binding by using an ID to call-back lookup table instead which can be updated on the fly at run time
• provide css class like abilities

[andlabs]

Merged with #276.