Artyom BologovOkay y’all, I’ve condensed my ideas about a new UI tool into one (hopefully) coherent document. Can y’all be so kind to see if this is a good approach to programming UIs?
flo@flo thanks! Yeah, I tried to make it something I’d use myself 😌
bouncepaw 🍄@aartaka are you sure you want to approach styling this way? My first thoughts are supporting dark/light themes etc. Many programs are straight up illegible in my light terminal. I'm not sure what the right approach is.
@bouncepaw yeah, theming is fun indeed. But then, if the user can (and probably should) change the styles to the ones they like, it’s not a problem?
An alternative could be to make a palette and allow styling this palette instead. Which is as restrictive as per-element styling, but might be more universal and harder to break. Hmmmmmm.
@aartaka afaik you state in the spec that all programs should ship with default styles. Maybe say ‘should not’ instead? This way, they come with default sensible colours by default (and the user may override them as they please).
@bouncepaw hmmm, this is not stated anywhere, actually. The more we talk about it, the more I think that programs should never touch the styles—only the end user. Which is a misnomer—programmer and the user is likely the same 🤔
@aartaka oh, I've gravely misread, sorry
or, what?@aartaka So this is for static UIs? Reading spec over a couple times it seems like the only modification you can make is @/delete and there is no means to replace elements with new ones.
@andnull you can also append new ones, by writing them out in the REPL, and clear them all with @/clear. But yeah, more modifications might be needed.
@aartaka My main observation is the lack of any sort of data binding system or a means of injecting updates into existing slots. You could maybe use
@/exit paired with spinning up a new script with a new state a la web 1.0 updates.@aartaka Since this system seems to be intended with a persistent state backing it, doing whole UI rebuilds could work okay. You might get into pref-shaped problems but.
@andnull perf-shaped problems? Given that it’s intended for local / native use, I’m not sure I’d ever hit these. The only bottleneck is communicating with an underlying shell, and I yet have to benchmark it.
@aartaka The main thing is if you have a very stateful application with many components to it, you will be doing full redraws of the whole application to update the state of it instead of targeting the updated elements and doing partial redraws.
@aartaka (tho, your other reply make it seem like update heavy applications are out of scope)
@andnull they are! Small shell tool wrappers are the main focus!
@aartaka Then yeah, simple mechanism of changing scenes, pulling state, presenting new scene would be pretty good. Honestly, I think it could be nicer than the preformant designs of diff trees (no that one couldn't be used by an implementation internally).
Would a every flickgame vibe where you transition to a whole new scene when you need a new layout. The sketch of my feed reader for a simplified feed format would work well with this.
(currently each view is one command)
@andnull oh, thanks for reminding me of flickgame! I should re-read your post on it 🖤
@aartaka If you do, a worth wild set of thoughts after gaining better clarity of my own idea
https://social.nouveau.community/@andnull/116581428966014528
... and and and and ... (@[email protected])
I should touch this page up one day with some better names for the last two tiers cause I've kinda gained some better understanding of them. I'd call Type-2 "Flat Object-Oriented Flicklikes". They are oriented around objects which execute commands against the world. However, they themselves cannot contain objects within them. Type-3 would then be "Recursive Object-Oriented Flicklikes" where objects can contain not just scripts, but other objects. Thus, the system becomes self similar. Each object in the scene is itself a scene of objects. This basically describes "normal object-oriented game engines". https://www.sheeeeeeeep.art/flicklike.html
@andnull yeah, that’s fair indeed. Well, for the HTML port I’m thinking of doing some of the updates on the client via JS. So that it all spreads in time. It’s a matter of implementation then?
@andnull so my idea is:
• Inputs have state and preserve it across actions.
• Buttons have outputs, which may point at other elements. So this is a small escape hatch for modification of other elements. I’m not sure I should even retain it instead of appending outputs right after buttons / sections.
I don’t want UI that jumps around. So yeah, it should be as static as possible in a minimal implementation. Web 1.0 and server-side rendering is a good reference.
@aartaka I like the design! I'm amazed you managed to write such a good big document in such a short time. I'll read in detail later...
P. S. I read the name as constrictor.
@bouncepaw writing is my full-time activity, thus the speed, ahah.
Huh, this name interpretation is fun too! An idea for a mascot!
@aartaka ah right, you're free now
Konrad Hinsen