I can't understand the logic for this

Posted Aug 13, 2024 1:52 UTC (Tue) by atai (subscriber, #10977)
In reply to: I can't understand the logic for this by Cyberax
Parent article: COSMIC desktop makes its debut

>Back in the day, GTK had to implement its own custom object-oriented language (GObject) and a basic library (glib). None of this is needed anymore.

Qt proved that in, what, 1999?

Rust is nothing new in this front.

I can't understand the logic for this

Posted Aug 13, 2024 2:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Sure. And the list of "you don't need this anymore" has grown quite a bit: no need to handle rendering and compositing, no need to handle input on your own, font handling, etc. There are libraries ready for all these purposes.

I can't understand the logic for this

Posted Aug 13, 2024 3:54 UTC (Tue) by comex (subscriber, #71521) [Link] (10 responses)

Qt implemented its own language extensions (moc) and standard library (QtCore has its own string, vector, etc. types separate from the STL ones). I don’t know whether it *had* to do that, but it probably made more sense at the time than it does with modern C++ implementations.

Oh, and more recently, Qt decided to implement its own scripting language, QML.

Not that newer UI frameworks are immune to this trend of reinventing the world. I don’t know about Iced, but Slint, one of the other Rust-based UI frameworks, also has its own scripting language similar to QML.

I can't understand the logic for this

Posted Aug 13, 2024 7:54 UTC (Tue) by hunger (subscriber, #36242) [Link] (7 responses)

Yes, slint has its own language, but it is a UI description language, not a scripting language.

Having a simple language to describe UI has a host of advantages: https://slint.dev/blog/domain-specific-language-vs-impera...

Just look at the web: Do younreally think it would be as successful as it is if you had to actually program pages in rust, C++ or any other "proper" programming language?

I can't understand the logic for this

Posted Aug 13, 2024 9:58 UTC (Tue) by anselm (subscriber, #2796) [Link]

Having a simple language to describe UI has a host of advantages

Indeed? We knew that in the early 1990s, with Tcl/Tk.

(Tcl/Tk may not be everyone's cup of tea, but at the time it ran in circles around everything else in that space.)

I can't understand the logic for this

Posted Aug 15, 2024 10:56 UTC (Thu) by khim (subscriber, #9252) [Link]

> Just look at the web: Do younreally think it would be as successful as it is if you had to actually program pages in rust, C++ or any other "proper" programming language?

That question is, essentially, impossible to answer before you would give criteria for “success”.

Would it have been successful at attracting bazillion “designer” who created bazillion barely-usable sites? Probably not.

Would it have been successful at facilitating the ability of people to communicate? Most likely yes, and even more than web achieves that today.

I can't understand the logic for this

Posted Aug 15, 2024 13:05 UTC (Thu) by jengelh (guest, #33263) [Link] (2 responses)

>Having a simple language to describe UI has a host of advantages
>
>Just look at the web: Do younreally think it would be as successful as it is if you had to actually program pages in rust, C++ or any other "proper" programming language?

And here we are, people programming web pages with Javascript (which is "proper" in the sense that it is imperative rather than declaring the UI).

I can't understand the logic for this

Posted Aug 15, 2024 19:01 UTC (Thu) by yeltsin (guest, #171611) [Link] (1 responses)

And then, on top of said imperative foundation, people invent and widely use libraries/frameworks like React that provide a (not purely) declarative model for describing the user interface (or more precisely, for deriving the user interface from the underlying data). Because the imperative model is so difficult to work with in large applications. We've come full circle.

I can't understand the logic for this

Posted Aug 19, 2024 5:04 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

I know you said not "purely".. but..

React is not a declarative model, even moderately. Maybe slightly if you squint really hard after too many drinks? But it's mostly *not* declarative.

It's very much an imperative language that lets you build components.. similar to how most object-oriented UI frameworks work. If you stretch the definition of declarative enough, maybe? But then GTK would be considered declarative...

But you very much tell it to

Build component A,
then connect it to component B,
when you get signal X, then update Y, etc.

Step by step, in an imperative fashion.

Having abstractions and components != declarative.

SQL is probably the closest thing to declarative that most folks are familiar, and it's nothing like building a React app, and is absolutely *atrocious* for building large apps out of. Large SQL queries are usually much less maintainable than code of any sort of a similar size.

Prolog is also much closer to declarative than React. And is also absolutely horrible for large programs.

A declarative language for UIs would let you declare what you want to accomplish, literally, something like: "A UI to let me update the time and timezone on COSMIC"... and then the optimizer goes off and builds that UI.

React, you have to tell it exactly what you want, and, most importantly, how to handle input, step by step. That's imperative.

I can't understand the logic for this

Posted Aug 15, 2024 16:00 UTC (Thu) by DanilaBerezin (guest, #168271) [Link] (1 responses)

> Just look at the web: Do younreally think it would be as successful as it is if you had to actually program pages in rust, C++ or any other "proper" programming language?

Ironically, if you actually do take a look at the *modern* web, you'll find that nearly everyone programs almost the entirety of their web pages in the "proper programming language" called Javascript. The original purpose of the web in providing an internationally accessible repository of documents has been relegated to the dustbin of history. The reality is that the web has been turned into its own application platform by its users. A transformation which was so egregiously abusive of it's original design that Google poured billions of dollars into creating an optimizing javascript engine, and when that proved to be insufficient and still painful, people decided to invent WASM. And now, people do (and in fact quite commonly) write entire web pages in Rust and C++ thanks to WASM.

I can't understand the logic for this

Posted Aug 22, 2024 10:04 UTC (Thu) by DOT (subscriber, #58786) [Link]

It's not all that bad, really. Yes, scripting support is mandatory for the proper viewing of web pages, but there is still the DOM lingua franca of basic display primitives, which does give tremendous accessibility benefits over a black-box OpenGL surface rendered at 60 FPS.

Any new desktop GUI library has to do the hard work of making their widgets available to accessibility tooling. On the web, this is much easier: you get most of it for free by using HTML tags, and you can easily improve on it by using ARIA attributes.

Of course, we can imagine whole websites being created as a single canvas element drawn by a WASM binary. That's not very popular though, because the DOM already gives you the primitives you need.

I can't understand the logic for this

Posted Aug 13, 2024 16:52 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

Qt predates the STL's release, so it made its own containers. In the process, it made decisions that the STL did not go with including CoW support for its containers. Now with move semantics that is less useful (e.g., forgetting a `const&` on a `std::vector<std::string>` parameter was very costly before moves were a thing), but by then there was 15+ years of existing API patterns laid down and at that point it's just easier to add move constructors to the existing APIs than to uproot it all and go with the STL instead.

I can't understand the logic for this

Posted Aug 14, 2024 8:31 UTC (Wed) by mbunkus (subscriber, #87248) [Link]

From a practical point of view: Qt's philosophy is different that STL's wrt. usability. If it makes usage easier, Qt is very eager to add utility functions to its classes, be it strings, containers or date/time types. The C++ standards committee on the other hand prefers users us the generic STL algorithms for anything they can be used. In reality this means that things are often a lot easier to remember, type, research, read & understand than equivalent STL-based code.

One thing that Qt simply doesn't have is differences in implementation quality. As the STL is only a spec, there are multiple implementations of that spec by multiple vendors (gcc's libstdcpp, clang's libstdc++, Apple clang's libstdc++, Microsoft's, the mingw implementation which is gcc's but adjusted for Windows or something like that, most likely others). Not only do they implement various differing parts of the STL specs, their quality of implementation is also often lacking. Here are two examples:

The standard's std::filesystem::path library is based on Boost's library of the same name, boost::filesystem::path. Paths are a tricky thing. Boost's implementation has had a LOT of years to mature, whereas the STL implementations haven't. One result is that the implementation in mingw doesn't support UNC paths for Windows properly (things such as \\?\C:\Test\Foo.txt). Therefore I cannot implement a simple algorithm such as "look through the directory structure going upwards until you find a directory containing a certain file" properly as certain test functions ("is this path empty?" or "is this the root path?") just don't work with it. The corresponding algorithm works just fine with boost::filesystem::path with exactly the same functions (as in, the STL's spec copied Boost's implementation almost verbatim). It also just works with Qt's path libraries. Of course this has been reported as a bug but hasn't been fixed yet.

Another bug due to different quality in STL implementations is again mingw's, this time with random number generation. For C++ with the STL you're supposed to use something like the following in order to generate random numbers:

std::random_device r;
std::default_random_engine e1(r());
std::uniform_int_distribution<int> uniform_dist(1, 6);

Unfortunately std::random_device on mingw doesn't see the RNG (which the STL specs allow!). Therefore each run of the program produces the same sequence of numbers. Meaning I cannot use std::random_device in cross-platform compatible code.

And don't get me started on the quality of the regular expression engine in the STL… Pretty much the worst one out there.

For me using Qt's own classes is much more satisfying & much less annoying. It's easier to use, easier to reason about, quicker to implement, produces faster code, more correct code.