> Another opinion I want to express is that all the UI > libraries/frameworks/systems with all those widgets and component sets are > things of the past.
I don't know, React is built on components. Then there's boostrap, tailwind, bulma, etc. People just want to be able to tweak the components or make their own, but a lot of web devs still use some sort of components library. > I've been working on a library but it is at a very early experimental stage. > I feel hesitant to talk about this for long with a shy fear of sounding like > marketing haha, as you can tell by my posts but shameless self marketing ftw! Seriously though, I'd say share if you want to. I didn't make an announcement because it's too early, but wanted to generate some discussion too. At this stage these sort of things could help us all get better ideas. Figuro is mostly stealing ideas from others but put together in a vision that I see fit. ;) > The API is mainly built around the idea of "element"s. Each element has three > main attributes that library user can define: Content, Renderer, Observer That's pretty similar to Figuro! I call them widgets, but really they're just components making elements. Then signals / slots is really just a variant of the observer pattern. BTW, depending on how limited your box type is you can end up requiring several of them for even a lowly button. Whats hard with this model is who gets events? I haven't done it yet, but a core thing I want is to be able to define your own button component and use it in pre-canned components like say a table list, but without the MVC shenanigans. > I had actually this idea of using the same implementation for building > graphical, textual, and audio-only interfaces (accessibility matters to me) > and it gave me a huge smile when I saw the OP's 7th wish. Exactly! Having an easy text-mode UI would be sweet. :) I'd be curious to hear more about accessibility. It's a downside of many bespoke UI libraries.
