libRocket VS verdigris

it's a fork of https://github.com/libRocket/libRocket which was started a long time ago.

I've found libRocket to be a great UI library paired with SDL2 and OpenGL. It allows you to use a subset of html and css to design your UI, while handing rendering off to the renderer of your choice. This gives you the flexibility to add advanced visual effects during the rendering step.

This is overly dramatic. The "keywords" are just macros. If you don't want an additional preprocessor to generate code in a separate .cpp file from these macros, you can use https://github.com/woboq/verdigris

The concurrency model, object ownership and life cycle you are mentioning are not part of C++, those are just conventions in specific C++ user groups - Qt code compiles plain and simple with pretty much every conformant C++ compiler and that makes it as much C++ as anything else.

There were a couple of attempts in that direction, but i haven't really seen them used in any production codebase.

https://woboq.com/blog/verdigris-qt-without-moc.html

Is Moc for signals and slots still needed? Mind you, I haven't used Qt in 15 years, but I was sure I heard about some standard C++ way of building Qt apps without needing the MOC prebuild step (IIRC https://woboq.com/blog/verdigris-qt-without-moc.html).

Nope, Qt 6 still uses moc. I don't think modern C++ meta programming is quite capable of entirely replacing moc. The closest thing I'm aware of is [0], but it requires additional macros compared to what moc requires, and compilation speed can suffer. Chances are moc won't be dropped until full reflection lands, if ever, and even then if compilation speed is too bad I wouldn't be entirely surprised if moc remains.

[0]: https://github.com/woboq/verdigris

Verdigris

`QML_ELEMENT` support for Verdigris. https://github.com/woboq/verdigris/pull/99

> it's possible to do Qt without moc even in C++ with https://github.com/woboq/verdigris/, why wouldn't it be possible from D ?

You're talking about an entirely different thing. While OP was referring to the current state of D's ecosystem and the impact that missing key frameworks have on hindering adoption, you're arguing about the theoretical possibility of writing a framework with a language, which really does not address OP's point.

And much more importantly, MOC specifically is a code generator which has a competitor without the code generation requirement. Fully compatible even. So no, sorry "Qt is bad because MOC" stopped being an argument years ago (if it ever was).

But copperspice is not a better version: see the benchmark here: https://woboq.com/blog/verdigris-qt-without-moc.html