The developer is rediscovering the concept of a GUI library. The modern variant is the mouse-driven GUI developed by Xerox in the 1970s (and later commercialized by them as Xerox Star) which Jobs famously copied to create Apple’s Lisa, and Gates famously mimicked to create MS Windows. Since they determine the look and feel of a platform and their design determines the ease with which developers can create apps for the platform, GUI frameworks became pivotal to platform wars across all sorts of products, from OSs to browsers, graphics engines and anything else whose success was determined largely by the interface developer experience.
The README for the project is one of the most detailed READMEs I’ve ever seen. The landing page for the website has as much detail as you can reasonably expect, even including a couple of feature demos. There are clear links to the docs and the code.
The developer has clearly put a lot of thought into this content. Worth taking a second or two to see what’s available before criticising it.
Nice! It's pretty cool what you can make in a few thousand lines. Though Flex isn't my favorite as I prefer full CSS Grid. So I ended up making a CSS Grid layout library that I'm proud of in pure Nim (1). Though I'll have to checkout Clay and compare some of the layout algorithms.
It's neat to see boxes resizing themselves using an algorithm you implemented. Wonder if I could expose a C interface?
The reason I like CSS Grid is that I could imitate the formatting like this:
test "compute others":
var gt: GridTemplate
parseGridTemplateColumns gt, ["first"] 40'ux \
["second", "line2"] 50'ux \
["line3"] auto \
["col4-start"] 50'ux \
["five"] 40'ux ["end"]
Cool! I also have a standalone implementation of CSS Grid [1]. Implemented in Rust in my case (and we also support Flexbox and Block layout). Looks like the licenses are both MIT (although you may want to add a LICENSE file to make that easier to find) so feel free to steal bits if you want. We aim to be fully web compatible, although we're not quite there yet.
One thing we have that you may be particularly interested is a reasonably substantial test suite. The tests are defined as HTML snippets that we run through Chrome using webdriver in order the scrape (hopefully) correct assertions, and then format into pure-code unit tests. If you wanted to you could write your own test generator and reuse our snippets. (this test infrastructure is also partially shared with Yoga [2], the C++ Flexbox implementation that powers React Native)
Hey thanks! That's awesome and great to see other implementations. Figuring out test cases is half the battle and I've really only done the basics. I'll definitely look to stealing things. ;)
> Looks like the licenses are both MIT (although you may want to add a LICENSE file to make that easier to find) so feel free to steal bits if you want.
Correct CSS grid layout calculation is about solving system of equations and constraints. In simple cases, when there are no spanned cells (like in flexbox), it can be done relatively trivially.
You definitely don't need a general constraint solver for CSS Grid. The algorithm (including for cases where there are spanned cells) is well defined in the spec [1], and can be translated directly into code.
Just a funny note—there’s a button at the end to switch between HTML and Canvas. I think it is neat how little difference it makes… normally.
But with iOS Safari + Dark Reader, at least on my side, the HTML page is turned into dark mode with Dark Reader, while the canvas page is not. So, it basically ruins the wow factor, haha.
It won’t help with dark mode, but the canvas-place-element proposal (https://github.com/WICG/canvas-place-element) should allow those interactions on canvas-rendered text backed by a text element placed under the canvas.
My Firefox on Linux zooms fine with both renderers. Text selection doesn't work though. Also the cursor doesn't adapt when hovering text, a button etc.
The HTML renderer is definitely faster in Chrome. Why is that, I wonder? The Canvas one is also reasonably fast, but noticable in that "High performance" animation and also when scrolling.
Just wanted to drop a note - everything following the animation cannot be selected - seems focus is stolen somehow - whenever I try to select text, it immediately deselects it.
This is a delightful take on a style of UI I really love. Separating the UI logic from drawing with a set of draw commands is an excellent and very versatile idea - I first saw it in microui, and the separation allowed me to easily use the library in the browser using WASM and Canvas2D. (https://rxi.github.io/microui_v2_an_implementation_overview....)
Also, doing layout in WASM and rendering to HTML is a great idea that I can't believe I never thought of before.
It's a good first draft. I do find it a shame that the HTML output is only div elements. I think a little accessibility would go a long way. I also can't select text in many places before some re-render de-selects before I can hit control-c.
If you don't use some kind of layouting language (like XML/HTML), this is inevitably what you will always end up with. See: AWT[1], SWT[2], Swing[3], Qt[4]†, Fyne[5], etc., etc., etc.
Qt has uic xml layout engine which was cumbersome to use, you weren’t discouraged from using c++ classes instead. The discouragement came later when Qt shifted towards qml (a bad shift as it’s just as unweildly, imo), now they discourage writing qml in c++ because the qml engine can get out of sync. Qt can prevent this but they want you to pay for a premium license for it. Slint is a sister to qt that does not have this restriction afaik.
I wish there would be an elegant c++ class/function based ui framework again.
Agreed that a C++ API for qml would be great. qml by itself is great though, I don't see why it is unweildy. If anything it's unpolished, there is stuff that is more difficult than it should be, but it's miles ahead of what there was before imo.
It is unwieldily because it abstracts logic into a different language and paradigm. You need double the cognitive understanding of qt now to know how it operates.
As someone with 10,000+ lines of C++ code and 10,000+ lines of QML code in his app[1] I can say this is false. It's actually much easier and straightforward to decouple the UI (QML) and logic (C++). It also makes such a great combo - QML is amazing to write UIs in and C++ is a fast, battle tested compiled language. I wrote a little bit about my app development if you're curious[2].
By the same metric c++ qwidgets is amazing to write UIs and by keeping everything in c++ there is easily less abstraction, I can easily navigate my code, not jump between two different systems. There really is no great reason why qml objects couldn’t be c++ classes/functions. Decoupling does what for me, but introduce more syntax, documentation, and learning curves. You should give writing a Kde6 Kirigami app a try and experience the absolute pleasure of adding another abstraction layer onto qml, c++ to muck things up. Qml is the cooler brother of Uic, but at least uic was optional.
I'm very fond of QML's syntax, so can't quite understand why you don't like it. It has a learning curve, but I studied all the basics in a day (it's just so simple and intuitive, imo).
Not sure how "QML in C++" would look like, but it doesn't sound pretty. Recently someone published a declarative UI inside C++[1] (without a different syntax) but I felt a bit off with this approach. Maybe that's something you mean?
I don’t know how else to explain it that compared to qwidgets where everything can be handled in code. Qml might be all the things it claims , elegance, separation of concerns, simple syntax, etc, but that still doesn’t eclipse my initial issue that it’s an unnecessary abstraction. You might not think it’s pretty but I think it’s pretty to only use c++.
It's not difficult or disorganized to layout GUIs in a programming language. HTML exists as an alternative to having nothing. If you have a programming language you can give the data to the GUI library directly without having to learn a new markup language, have the bloat of a new markup language or learn the quirks a new markup language. You can also put format it and put newlines in there.
The thing is, most GUIs by necessity involve fairly deep hierarchies of graphical objects so you're either going to have deeply nested calls like this, or you're going to scatter the fragments across a number of files in a way that they need to be reassembled in the reader's head in order to understand what's going on.
The real issue is trying to represent graphical objects, and the relationship between those objects, with text. Graphical builders/RAD tools seem like such an obvious solution, but that approach has largely been abandoned.
cool stuff! selectable text is a MUST in the browser for me. In clients and apps that do not need that or can provide it themselves, this seems to be a very nice and tiny solution.
it's weird to watch it break text selection/copy-and-paste : feels like it might be fixable, though.
I'm a stuck record on this, but I really feel like the regressions in clipboard universality are one of most understated losses of UI shifts in the last few years (along with linkability and embedding)
Should that be part of a layout engine though? I’d expect to insert a tree of nodes with styling information that affect layout and receive a tree with calculated x, y, width and height for its elements.
Would be fun to combine this with the single-file Impeller header from the Flutter people.
The API approach could be implemented extremely cleanly in Clojure and Java, and then the whole thing would be runtime-dynamic, since Clojure generates new Java functions on the fly, and the JVM's JIT makes them fast.
This looks pretty cool, but from the page I can't tell if there's any interactivity supported...there's a button example but it seems to have no click handler?
Okay, from the examples there's something like this:
if (isMouseDown && !scrollbarData.mouseDown && Clay_PointerOver(Clay_GetElementId(CLAY_STRING("ScrollBar")))) {
I'm not a frontend person. Can anyone explain why this is better than using CSS directly or a CSS framework/library? Seems like added complexity when there are already hundreds of CSS frameworks available that seem like they do the same thing.
This isn't really meant to replace such things an environment where you have a rendering engine that supports CSS— I think demoing it on the page is more for showing off how portable it is with WASM. Off the top of my head, a few uses for this:
- Mapping components or structured document data with something like MDX or slate on to Clay components to render in different contexts outside the browser reasonably closely to what shows up in a browser preview, for example content for HUDs, in-world display panels or documents in games, or batch rendering printed documents
- Layout for UI where something like Electron or React Native would be overkill, or isn't supported
The main goal is to enable nice UI without the requirement of a whole web browser in order to get CSS. The fact that it can be used to layout web pages is just showing off to get the attention of the billion web devs out there.
This UI library can be re-targeted to Raylib, Canvas, HTML from its markup ... Good luck doing that with just CSS.
Put another way, this library is a step into writing an agnostic UI layer for your application which it just invokes from its business logic. If you can decouple your UI from your application code ala MVC or MVP architecture, as a developer you can find the right tool for the components that compose the sum of your project.
So cool! For some reason navigating to Github/Discord by clicking the links is slow on my phone (old galaxy s20fe). The click highlight of the button is normal, just going to the sites is slow.
Using CSS translations to place elements on the page is... cursed to say the least. It's probably why text selection works (assuming it qualifies as working) in such a weird way when the cursor goes between blocks.
My question may be to obvious but, how can you incorporate js to mutate your layout based on user interaction and api calls? Do you have a dynamic website example?
Both use immediate mode rendering. Both have the “single header” design. There doesn’t appear to be any shared implementation.
The examples use Raylib as a renderer behind the layout engine. I suppose it would be possible to use Dear Imgui as a renderer, but you might have to write some glue code.
Getting an empty, cream-rose-colored page, followed by a warning that the script on the page is slowing the browser down with an offer to stop the script. Just FYI.
Yes, the repo offers a couple of example renderers.
The idea is that you already have a rendering pipeline (e.g. in your game engine), but want to lay out more complex UIs in it. Then you can use this library to make nice settings / chat / stats / whatever screens, or even render realistic content onto screens of in-game computers, pages of books, etc.
the inspector at the end was a neat surprise! I had some issues trying to build the examples on windows but I think it's an opportunity to contribute to the project
If Android had provided an defining UI API like this entirely in C without using Java, Android would have 100% monopolized the mobile OS market. So fast, efficient.
Somehow I don't think it's that easy. But yeah, the way Java was used and with XML etc was horrible. Android development continues to be pretty horrible to this day, but due to a variety of reasons.
If I need to target Android natively today, I first consider Flutter (non-web).
For iOS only apps there's little reason to stay away from Swift.
"clay ui" actually fails. My top hit is: https://clayui.com/docs/get-started/how-to-use-clay which is a completely different UI library from what I can tell, and probably had the name first too as the Git repo has commits from 4 years ago.
reply