The Qt Company Is Now Working On Qt For Microcontrollers

[kpedersen]

I wish GTK would just rewrite from scratch in rust...

But then the non-native scripters wouldn't have their Python or Javascript bindings.

Just like C++, Rust makes creating language bindings more complex than C.

Its not a safety or a "trendy language" thing. It is a practicality thing. Rust and "Modern" C++ have the same flaws.

Gtk supports more platforms than Rust too; so Rust would be a bottleneck when it comes to portability. This will hopefully change as Rust matures though.

[carewolf]

It would be nice if Qt get hi-res interfaces right - they are not scaling properly now. The priorities on more markets kills confidence they care about the installed base.

On which platforms? Qt tries to scale similar to native applications on every platform. On Linux it does it's own thing because it _is_ a standard in itself there. Unfortunately the system values Qt uses from X11, GNOME at some point decided to override with false values (for some reason..), so system scaling is a mess on X11, and non existing on Wayland.

[wizard69]

You say that like $5500/yr is a bad thing

A drop in the bucket for lots of commercial micro controller projects. By the way this move is very interesting due to the lack of a well accepted 2D graphics API in the micro controller world. I can see QT being very successful if they come up with the right set of striped down features and performance. The trick with microcontrollers is always that balance between the size of generated code and performance as you simply do t have the RAM/ROM space for huge libraries.

As a side note im surprised ARM hasn’t attacked the need here with an embedded 2D API for the 2D hardware. That is build a 2D API right into the “GPU” on the micro controllers to provide basic functionality to the programmer.

[wizard69]

I wish GTK would just rewrite from scratch in rust... but then they'd be forced to abandon 20 years worth of kludges.

It'd be even more hilarious, if the actually did it... and then the entirely of the code was written with unsafe on, cause that is kinda how they roll...

A fully open solution would be nice but I’m not sure porting to a micro controller would leave much of GTK left. Micro controller programming is all about cramming everything in.

By the way im fully convinced that we need a tool kit that is more modern and does away with C. I’m not sure RUST is the right path though. Personally I’d rather see the open source community adopt Swift. In either case though a completely new API is in order that leads to easier /faster app development. Of course the other problem, in the context of this thread, is the issue of cross compiler for either language to micro controllers.

[wizard69]

But then the non-native scripters wouldn't have their Python or Javascript bindings.

One of the reasons I like the idea of Swift is that scripting is pretty robust there already. Yes you are talking Swift scripts as opposed to Python but there is enough language similarity there that I can actually see Swift replacing Python for many that prefer scripts!

Just like C++, Rust makes creating language bindings more complex than C.

On the flip side that is a non issue. Once the bindings are created you have them. The problem is C really has to go, there is no excuse to be using it in new software development. This especially for user apps in a GUI environment. I’d go so far as to say that the reason so many Linux apps are crap due to bugginess and general weird behaviors is that they are written in C.

Its not a safety or a "trendy language" thing. It is a practicality thing. Rust and "Modern" C++ have the same flaws.

Any train of thought that tries to justify the use of C for GUI app development in 2020 is extremely flawed. All languages have flaws by the way, but the point is a language and it’s compiler must be partners in the process of developing high quality software. C is an anti partner.

Gtk supports more platforms than Rust too; so Rust would be a bottleneck when it comes to portability. This will hopefully change as Rust matures though.

Portability is an issue for anything destined for the micro controller world. Ultimately you would have to consider just how much of a toolkit can you get to run on these devices. I actually see GTK as too big already to trim down in a meaningful manner.

[cb88]

But then the non-native scripters wouldn't have their Python or Javascript bindings.

Just like C++, Rust makes creating language bindings more complex than C.

Its not a safety or a "trendy language" thing. It is a practicality thing. Rust and "Modern" C++ have the same flaws.

Gtk supports more platforms than Rust too; so Rust would be a bottleneck when it comes to portability. This will hopefully change as Rust matures though.

What are you talking about ... Rust uses C calling conventions by default for external interfaaces it is identical to C... .which makes it harder to interface with C++ code but easier for EVERYTHING else which already works with C.

Saying that Rust and modern C++ have the same issues is just ignorant. Go watch any video or preentation on the flaws of C/C++ and it practically turns into an advertisement for rust. Entire classes of memory and concurrency bugs are impossible... things that can be extremely difficult to debug on an MCU. Note you can have concurrency bugs of course with only a single CPU...

[cb88]

A fully open solution would be nice but I’m not sure porting to a micro controller would leave much of GTK left. Micro controller programming is all about cramming everything in.

By the way im fully convinced that we need a tool kit that is more modern and does away with C. I’m not sure RUST is the right path though. Personally I’d rather see the open source community adopt Swift. In either case though a completely new API is in order that leads to easier /faster app development. Of course the other problem, in the context of this thread, is the issue of cross compiler for either language to micro controllers.

You are mixing C and toolkit... what are you trying to say a more modern language? If so then you are wasting your time if you want something that is more modern and are also ignoring rust... its basically the only new systems programming language with any mind share and traction. It is also very low overhead for what it gives you since most of the work is done at compile time, ideal for MCU programming. Rust has been ported to arm MCUs and increasingly MCUs have multiple cores, which means you need to be able to program concurrently...

[programmerjake]

Interesting. I worked on a project several years ago that used Qt on a Cortex M4F, which I would consider a microcontroller.

[kpedersen]

What are you talking about ... Rust uses C calling conventions by default for external interfaaces it is identical to C... .which makes it harder to interface with C++ code but easier for EVERYTHING else which already works with C.

Saying that Rust and modern C++ have the same issues is just ignorant.

When it comes to language bindings they do have exactly the same issues. Bindings generally need to use opaque pointers to store data. You cannot pass through i.e a std::shared_ptr or a Rust structure. With rust you generally have to get away with exposing raw unsafe pointers... just like C++.

This is a good example: https://bheisler.github.io/post/calling-rust-in-python/
The author also had to fall back to C for a lot of the complexities.

Someone who is competent in C will already have finished the project by the time you had got the Rust bindings up and running

[cb88]

When it comes to language bindings they do have exactly the same issues. Bindings generally need to use opaque pointers to store data. You cannot pass through i.e a std::shared_ptr or a Rust structure. With rust you generally have to get away with exposing raw unsafe pointers... just like C++.

This is a good example: https://bheisler.github.io/post/calling-rust-in-python/
The author also had to fall back to C for a lot of the complexities.

Someone who is competent in C will already have finished the project by the time you had got the Rust bindings up and running

Well if it can be done so fast , and is so simple... then the pitfalls don't matter but the fact is GUI libraries are neither fast to develop or simple... meaning the overhead of implementing the C apis in rust is worth while... also I'd attribute any slowness in this area to inexperience with Rust.

Also the complexities you note there come from python not C or Rust... you can mix C and Rust libraries with no issues. The point is that it can be done cleanly, while the same cannot be said of C++... at all.