hugoamnov

I need to investigate this question :) For now, I just setup a Patreon, but in the future, I might think of a more clever business plan.

The PBR pipeline of toy is not well optimized yet: I'll have more time to tackle this issue now that the heavy lifting work has been done !

Framerates are much better in the non-web version somehow: I suspect some unnecessary texture sampling ops are to blame, but I need to investigate.

Resizing the window to a smaller helps greatly improve the framerate, which tends to show that the bottleneck is in the fragment shaders.

Hi, the license is a temporary choice. I wish to release it under a permissive license in the future, I'd just like to secure a tiny bit of funding before that !

It's thin in the way that all the goodies are in separate modules that you don't have to use, and also in the way that it still runs in the browser with all these goodies.

But it's also not so thin, you are right :)

For those that might remember a UI library called kiui that I shared a few years ago: it is the UI module inside mud (and is still usable independently).

It has also been completely revamped, and now follows an immediate/declarative paradigm that makes it much more straightforward to use, while still being entirely stylable and auto-layout.

The rest are new components I developed and refined in the mean time!

One thing you misunderstood :

You don't specify any absolute measurement when using kiUi from C++.

The whole point is to get rid of them. They are calculated under the hood.

The style gives the necessary hints. And this is done in a way entirely separate from the UI code itself.

Think of the C++ code doing what is regularly done in both HTML and Javascript, and the kiUi style sheet as what is regularly done in CSS.

I'm interested to know more about your plans for a declarative model.

I think many things in kiUi, especially the layout and style, can be seen as declarative, in a way.

But the individual widgets and interaction between them are not. And I'm curious as to how it could be different. Also you want to collaborate on something or just discuss, I'm interested.

I have a simple answer but it may not suit you :

After spending quite some time writing UI, I believe doing it in either XML or HTML is just pure madness.

UI is a very complex structure with complex wiring and interactions between components, and so it is very prone to human error. To represent such a complex system in anything else than a statically typed language like C++ is, to me, incredibly counter-productive.

You may like to write them in XML, but I want to write them in code and I wrote kiUi just for that. It's more concise, less error prone.

More essentially, I think it comes from a "fallacy" or "false dream" that a designer could design a reactive UI in XML or HTML without knowing anything about code.

The back of the coin, is that to code a real UI you need both HTML and javascript, or XML and another language. XML and HTML are just here for the layout.

But kiUi takes a rather different approach at layout, which is that you may not even need to specify layout in the first place. It's done for you already, but, the designer can still tweak it if needed.

So, kiUi inverted relationship of the primacy of layout over the rest. In kiUi the primacy is to the native code, and to the logical elements (the widgets).

You are somewhat right in that HTML and CSS heavily inspired what kiUi became. But there are two major concerns that are not adressed by your solution :

- Embedding a whole browser in your app just to display a few widgets is not my definition of "lightweight"

- Often coding UI in native code (C++) makes a lot more sense, integrate with exiting code in a much cleaner way

Game developpers would much less tend to build their own libraries from scratch, if there was at least one that satisfied all of these 'basic' requirements : lightweight, skinnable, auto-layout

Thank you. As to the draw calls, NanoVG draws everything directly each frame so this is constant whether or not you are updating. As to the overhead, not too long ago everything was updated each frame regardless of whether it was modified or not, and performance was fine. Worse than it is now, but okay. So I guess it could handle it.

But then again, that's only the default renderer. You can always roll your own and plug it in, kiUi has been designed to permit that.

If you want to strip it down, you can start by not compiling all the widgets you don't need as there are quite a lot of them. The renderer (glfw, NanoVG) takes about half of the dll size (~500kb) on windows.

Issue seems to come from Emscripten https://github.com/kripken/emscripten/issues/3171

It's great and I actually borrowed ideas from his examples. Immediate mode and retained mode UIs are entirely different beasts though, with different targets / use cases. Something like dockable windows would be much harder to implement in a IMGUI lib

yup, fixed (non-native speaker here)

one of the critical bugs I know of is in the multiline text, was that the culprit ?

the input and scrolling is handled by GLFW, I'll look into the issue. also it's specific to the web version which is weird