4 ms·

You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enough

by api 3y ago

You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enough for Qt. Qt objects have to be heap allocated anyway so you would not be adding much overhead. If you designed a specialized container it could probably be zero overhead.

jcelerier 3y ago
Well that's the thing, Qt already has its smart pointer types which work with the QObject system - e.g. QPointer. You certainly wouldn't want to have a double layer of indirection, just like std::shared_ptr<QStuff> is an antipattern
okanat 3y ago
> You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enough for Qt. Shoving Arc everywhere is a great way to leak memory with Rust. No, compiler doesn't prevent that. It is not a safety bug. The problem is Qt has its own ownership model that goes against Rust's ownership model. It is a prime C++98 era library at its heart and it didn't change that much in the core architecture. Moreover Qt relies on heavy use of inheritance-based OOP which is Rust also against. So current Rust GUI libraries using Qt stuff like Slint has to implement a second level of abstraction and state tracking which costs performance. I think the best way ahead is implementing a GUI library (at least the Widgets layer all the way down until rendering engine) in Rust. However I am not really hopeful. Writing GUI toolkits from scratch could be one of the hardest software engineering problems out there. The days when benevolent software companies released open source full-featured GUI frameworks with relatively permissive licenses are mostly behind. Nokia didn't have much to gain from releasing Qt as LGPL but they did it anyway. I don't think today's big tech would do the same unless there is a clear, guaranteed way of monetizing it. Dealing with N dimensional space of multiple OSes with multiple graphics APIs, multimedia engines, high DPI screens and complex text rendering is 90% painful software development. Somebody can do it but I don't think it will be open source, neither cheap.

by api 3y ago

jcelerier 3y ago

Well that's the thing, Qt already has its smart pointer types which work with the QObject system - e.g. QPointer. You certainly wouldn't want to have a double layer of indirection, just like std::shared_ptr<QStuff> is an antipattern

okanat 3y ago

> You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enough for Qt. Shoving Arc everywhere is a great way to leak memory with Rust. No, compiler doesn't prevent that. It is not a safety bug. The problem is Qt has its own ownership model that goes against Rust's ownership model. It is a prime C++98 era library at its heart and it didn't change that much in the core architecture. Moreover Qt relies on heavy use of inheritance-based OOP which is Rust also against. So current Rust GUI libraries using Qt stuff like Slint has to implement a second level of abstraction and state tracking which costs performance. I think the best way ahead is implementing a GUI library (at least the Widgets layer all the way down until rendering engine) in Rust. However I am not really hopeful. Writing GUI toolkits from scratch could be one of the hardest software engineering problems out there. The days when benevolent software companies released open source full-featured GUI frameworks with relatively permissive licenses are mostly behind. Nokia didn't have much to gain from releasing Qt as LGPL but they did it anyway. I don't think today's big tech would do the same unless there is a clear, guaranteed way of monetizing it. Dealing with N dimensional space of multiple OSes with multiple graphics APIs, multimedia engines, high DPI screens and complex text rendering is 90% painful software development. Somebody can do it but I don't think it will be open source, neither cheap.