Re: KDE Review: Rust Qt Binding Generator
Op maandag 4 september 2017 07:46:28 CEST schreef Kevin Ottens: > On Sunday, 3 September 2017 18:14:49 CEST Jos van den Oever wrote: > > [...] > > The idea of this binding generator is that you write each part in the most > > appropriate language. Rust bindings for Qt are hard to get right and will > > still have caveats for a while. With this generator, you write the UI in > > C++ or QML. The generated code has no dependencies apart from Qt Core and > > the Rust crate libc. > > So what's the intent with this one? Is it a stop gap measure until > cpp_to_rust is more complete? > https://github.com/rust-qt/cpp_to_rust cpp_to_rust is an ambitious project. cpp_to_rust lets you call Qt libraries from a Rust project. This means that the qt_core, qt_gui etc crates have to take care of thread-safety and ownership. Qt has quite a few ways of dealing with ownership. A QObject is responsible for destroying and deallocating its children. QString is value type with a reference-counted memory block inside. I spent time on another binding project and sent patches to it, but it was not active anymore. Then I realized that it is early for depending on a project that tries to wrap Qt as a Rust crate. If you'd like to use Rust in an existing KDE project, you'd not take that approach either. You'd call new Rust code from your Qt code. cpp_to_rust focusses the other way around. The interesting part of writing Qt code is custom implementations of QObject and QAbstractItemModel that you pass to Qt elements. QComboBox, QTableView, QListView all take QAbstractItemModel implementations. So the binding generator, which I'm fine to call a stop gap measure, focusses on that part. You implement QObject and QAIM with Rust code that does not feel like Qt, but feels like Rust code. For example, here is an implementation of a QAbstractItemModel that is used as model in QtChart and (Q)TableView in the demo. It does not look like a QAIM at all. https://cgit.kde.org/scratch/vandenoever/rust_qt_binding_generator.git/tree/ demo/rust/src/implementation/time_series.rs Of course, it's a bit simple, because it's static data. When cpp_to_rust has a stable release and is easy to use from exisiting C++/ CMake projects, this project can be ported to use that. The code that generates Qt implementations could then be a Rust macro. > Are you contributing to it as well? (I started patching it locally but still > need to clean up my work for upstream contribution) No, I contributed to a previous binding project. cpp_to_rust is an attractive idea because it allows you to code only in Rust. Enticing as the idea is, I wanted something that works now. In addition, I like the idea of separating UI and logic. > > [...] > > This project is not a typical C++ KDE project, but I hope it can be part > > of > > KDE anyway. > > Of course take the above more as curiosity and wondering how that will fit > regarding the larger Rust ecosystem. I don't see a problem with things like > this to be part of KDE. Cool. Thanks for taking a look. Cheers, Jos signature.asc Description: This is a digitally signed message part.
Re: KDE Review: Rust Qt Binding Generator
Hello, On Monday, 4 September 2017 09:43:46 CEST Jos van den Oever wrote: > Op maandag 4 september 2017 07:46:28 CEST schreef Kevin Ottens: > > On Sunday, 3 September 2017 18:14:49 CEST Jos van den Oever wrote: > > > [...] > > > The idea of this binding generator is that you write each part in the > > > most appropriate language. Rust bindings for Qt are hard to get right > > > and will still have caveats for a while. With this generator, you write > > > the UI in C++ or QML. The generated code has no dependencies apart from > > > Qt Core and the Rust crate libc. > > > > So what's the intent with this one? Is it a stop gap measure until > > cpp_to_rust is more complete? > > https://github.com/rust-qt/cpp_to_rust > > cpp_to_rust is an ambitious project. cpp_to_rust lets you call Qt libraries > from a Rust project. This means that the qt_core, qt_gui etc crates have to > take care of thread-safety and ownership. Qt has quite a few ways of dealing > with ownership. A QObject is responsible for destroying and deallocating > its children. QString is value type with a reference-counted memory block > inside. > > I spent time on another binding project and sent patches to it, but it was > not active anymore. Then I realized that it is early for depending on a > project that tries to wrap Qt as a Rust crate. > > If you'd like to use Rust in an existing KDE project, you'd not take that > approach either. You'd call new Rust code from your Qt code. cpp_to_rust > focusses the other way around. > > The interesting part of writing Qt code is custom implementations of QObject > and QAbstractItemModel that you pass to Qt elements. QComboBox, QTableView, > QListView all take QAbstractItemModel implementations. > > So the binding generator, which I'm fine to call a stop gap measure, Note that I didn't mean that to diminish your work, I was really wondering if your intent was to see your binding generator as something temporary or something with longer term plans. Looks like it's longer term which sounds good. > focusses on that part. You implement QObject and QAIM with Rust code that > does not feel like Qt, but feels like Rust code. > > For example, here is an implementation of a QAbstractItemModel that is used > as model in QtChart and (Q)TableView in the demo. It does not look like a > QAIM at all. > > https://cgit.kde.org/scratch/vandenoever/rust_qt_binding_generator.git/tree/ > demo/rust/src/implementation/time_series.rs > > Of course, it's a bit simple, because it's static data. > > When cpp_to_rust has a stable release and is easy to use from exisiting C++/ > CMake projects, this project can be ported to use that. The code that > generates Qt implementations could then be a Rust macro. Thanks a lot for the extra insights. Makes sense. > > Are you contributing to it as well? (I started patching it locally but > > still need to clean up my work for upstream contribution) > > No, I contributed to a previous binding project. cpp_to_rust is an > attractive idea because it allows you to code only in Rust. Enticing as the > idea is, I wanted something that works now. In addition, I like the idea of > separating UI and logic. Sure, it always make sense to separate them, I don't perceive this as an argument for different languages though. > > > [...] > > > This project is not a typical C++ KDE project, but I hope it can be part > > > of KDE anyway. > > > > Of course take the above more as curiosity and wondering how that will fit > > regarding the larger Rust ecosystem. I don't see a problem with things > > like this to be part of KDE. > > Cool. Thanks for taking a look. Interesting stuff anyway, looking forward to it having stable releases. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Review Request 130239: Exclude kconf_update from catching by uac on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/130239/ --- Review request for kdelibs. Bugs: 384334 http://bugs.kde.org/show_bug.cgi?id=384334 Repository: kdelibs Description --- This patch fixes an issue that on the first start of KMyMoney (and on some computers on every start for example reported by https://forum.kde.org/viewtopic.php?f=69&t=141673&sid=ba4dcaa26018f16e19d21c58c34ad4e9) on running kconf_update the user account control pops up and forces the user to allow or deny this application. Diffs - kconf_update/CMakeLists.txt 6bf3bf1f923baf11aad63e10fe249d70ce1b4d33 Diff: https://git.reviewboard.kde.org/r/130239/diff/ Testing --- Tested with KMyMoney snapshot for Windows downable from https://software.opensuse.org/package/mingw32-kmymoney-portable Thanks, Ralf Habacker
