3 ms·

and knowing three of them IRL I really trust them to make something amazing - they already do especially with the work on microcontrollers and it will likely be

and knowing three of them IRL I really trust them to make something amazing - they already do especially with the work on microcontrollers and it will likely be my first choice if I have to show an UI from an uc - but API-wise Slint is quite similar to QML with a declarative tree approach ; having worked now on maybe 3 dozens of distinct projects using either QML or Qt Widgets (traditional widget tree retained API), ranging from one-shot software used at 1 event written in an afternoon, to car dashboards, to traditional WIMP author software, to freakin Unity3D plug-ins, I still find the widget API better for many, many cases (mainly in the technical and CRUD UIs which I mostly use my computers for). But when I say "Rust does not have Qt" this is actually not what I refer to. A big point of Qt is that you have a complete consistent library with an event loop that will handle everything from GUI to network / serial port communication / media playback / JS scripting / database access / ... transparently, with APIs that are fairly cohesive. With Rust whenever I looked at it it was async API flamewar and the need to use 50 libraries that all have slightly different conventions, namings, etc. Qt brings consistency, just like boost does, and that's why I like using those ; most of the time I don't even have to think about what the name of something is going to be in a class / type I've never used, because it's obvious from the naming scheme of the library.

tialaramex 4y ago
> A big point of Qt is that you have a complete consistent library with an event loop that will handle everything from GUI to network / serial port communication / media playback / JS scripting / database access / ... transparently A kitchen sink library, re-implementing absolutely everything. I do mean everything there's even a QString to use because heaven forfend a C++ library wouldn't have its own custom String class... The temptation to build kitchen sink libraries is exactly what this proposal seems to be fighting. No, I don't expect they will win.
- pjmlp 4y ago
  Kitchen sink libraries usually work in all supported platforms, no need to play tetris with OS and compiler version support.
- cyber_kinetist 4y ago
  I think the reason QString was necessary was because STL's std::string was just really lackluster (and still is). The problems: - An barebones API that's hard to use (missing really basic functions like contains() and split(), although they might come on C++2-god-knows-fuck-when) - Until recently (C++20), didn't have a convenient way to format strings. QString::args() isn't that nice, but at least it's far better than using the stream operators. It's just sad that people were hyped that std::format was finally coming in the year two-thousand-fucking-twenty... - Dealing with encodings and locales. Unicode conversions, anyone? Like, C++17 actually even deprecated the whole <codecvt> header! I understand it was absolute shit, but the audacity to remove it without presenting an alternative...
- jcelerier 4y ago
  > A kitchen sink library, re-implementing absolutely everything yes, and having written projects in both the kitchen sink and the many-libraries approaches, the one that consistently shipped software fast is the one with the kitchen sink framework

tialaramex 4y ago

> A big point of Qt is that you have a complete consistent library with an event loop that will handle everything from GUI to network / serial port communication / media playback / JS scripting / database access / ... transparently A kitchen sink library, re-implementing absolutely everything. I do mean everything there's even a QString to use because heaven forfend a C++ library wouldn't have its own custom String class... The temptation to build kitchen sink libraries is exactly what this proposal seems to be fighting. No, I don't expect they will win.

pjmlp 4y ago
Kitchen sink libraries usually work in all supported platforms, no need to play tetris with OS and compiler version support.
cyber_kinetist 4y ago
I think the reason QString was necessary was because STL's std::string was just really lackluster (and still is). The problems: - An barebones API that's hard to use (missing really basic functions like contains() and split(), although they might come on C++2-god-knows-fuck-when) - Until recently (C++20), didn't have a convenient way to format strings. QString::args() isn't that nice, but at least it's far better than using the stream operators. It's just sad that people were hyped that std::format was finally coming in the year two-thousand-fucking-twenty... - Dealing with encodings and locales. Unicode conversions, anyone? Like, C++17 actually even deprecated the whole <codecvt> header! I understand it was absolute shit, but the audacity to remove it without presenting an alternative...
jcelerier 4y ago
> A kitchen sink library, re-implementing absolutely everything yes, and having written projects in both the kitchen sink and the many-libraries approaches, the one that consistently shipped software fast is the one with the kitchen sink framework