Problem with those is that they fall in the ‘cute, but mostly useless’ part, I think the big blocker for real / better UIs like that is that the input devices are so poor and so hard to retrain people from relying on. My current experiments here use an eye tracker instead, and oh boy does that make a difference.

That particular cleverness was mostly Blizzard (there’s more in the API design though..) as I took the cue from World of Warcraft back when it was in Beta. They have an interesting threat model and quite complex UIs. Other than that, I appreciate the Lua VM design, minimal runtime, implementation and API - not so much the language itself, but it’s tolerable and “mostly harmless” (unlike say, javascript, python and the likes) as a policy language.

I think I get what you mean - non-TUI apps are a few contracting ones I don’t have permission to present or at least not yet (VR etc.), along with the senseye stuff and so on. All the API design and focus has been on providing lower level primitives so they are not on the level of:

checkbox = new_checkbox("hi there")
checkbox:show()

but the step beneath that:

checkbox = {null_surface(32, 32), false}
checked = load_image("checked.png")
unchecked = load_image("unchecked.png")
image_sharestorage(unchecked, checkbox[1])
label = render_text("hi there")
link_image(label, checkbox, ANCHOR_UR)
mouse_addlistener(
{
name = "checkbox_listener",
click = function()
    checkbox[2] = not checkbox[2]
    image_sharestorage(checkbox[2] and checked or unchecked, checkbox[1])
end,
own = function(ctx, vid)
    return vid == checkbox[1];
end
})
show_image({label, checkbox[1]})

Just pulled out of thin air but should pretty much be it. So the icons, toolbars, popups, listview etc. in this (very) old clip https://www.youtube.com/watch?v=3O40cPUqLbU written in the latter style. That’s what I meant with that there are a few examples but not generalized to the first form and packaged / distributed.

Reason is time/motivation, but even more - what will be fleshed out in the coming article, but is hinted at in this one:

The philosophy behind the design is to let the server side absorb systemic complexity, and strive to make clients as trivial as possible to both develop and inspect. No multi-million lines of code toolkit should ever be necessary. The perspective is to instead emphasise the extremes, that is to focus on the small “one task” kind of clients and on integration with bigger “embedded universes” like virtual machines and web browsers, and leave the middle to fester and rot.”

Better “desktop IPC” to segment the simple clients so that they aren’t modelled around interactive UI components as more mechanisms to modify, share and compose visual/aural typed data. But again, it’s a long story.

both (assuming some amount of code literacy), but part of the point is making WM modifications “bash-scripting” levels of difficulty, not the crazy stuff needed for Xorg or WL. Take this example of a minimal wm”:

local clients = {}

function mywm()
    local alloc_fn;
    alloc_fn = function()
        target_alloc("mywm",
        function(source, status)
            if status.kind == "resized" then
                resize_image(source, status.width, status.height)
                show_image(source)
            elseif status.kind == "terminated" then
                 clients[source] = nil
            elseif status.kind == "connected" then
                 clients[source] = true
                 alloc_fn()
            end
        end
    )
    end
    alloc_fn()
end

function mywm_input(iotbl)
    for vid,_ in pairs(clients) do
        target_input(vid, iotbl)
    end
end

I havn’t tested this exact code but it is about what is required for a ‘dumb’ WM where clients can connect like ARCAN_CONNPATH=“mywm” afsrv_terminal; (included terminal emulator).

Notice the way the mywm_input function is written now. Every time the engine manages to get input from any input device (keyboard, mouse, game, …) all clients can read it. If you change it to track say a “selected” window and only send to that, well, only that client will get the input.