On Sat, Jan 8, 2022 at 7:54 AM Aleix Pol <aleix...@kde.org> wrote: > > On Thu, Jan 6, 2022 at 8:27 PM Ayush Singh <ayushdevel1...@gmail.com> wrote: > > > > I am a University student and the author of the rust crate ki18n. This > > crate allows using the KI18n Framework from Rust and can be used in > > conjunction with the qmetaobject crate to allow writing QML applications > > for KDE using Rust. > > > > The Proposal for my project is to create a rust wrapper for the KConfig KDE > > Framework. With this crate present, it will be possible to create a > > QML/Kirigami + Rust application without C++. I already have some other Rust > > crates ready to help make the wrapper. > > > > Currently, the primary GUI solution for creating Rust applications is > > GTK-rs. If Rust wrappers of at least the essential parts of KDE are > > present, it can become a viable toolkit for GUI development in Rust. If > > this project is done as part of the Season of KDE, it might also help to > > inform people about crates like qmetaobject, which works almost flawlessly > > to create QML + Rust applications. > > > > I am looking for someone to mentor my project. The mentor does not need to > > have Rust skills but should be familiar with KConfig. I haven't used > > KConfig much and might miss important parts of the Framework. I would also > > like to make the Bindings ergonomic and would need someone who has a better > > understanding of the Framework. > > > > My goal with this project is to increase the use of Rust in KDE as a whole. > > But for that to happen, we first need a base to allow people to start > > seeing KDE Frameworks as viable for Rust-based GUI. > > > > Here is my alternate email to contact me directly: ayushsingh1...@gmail.com > > > > Thank You > > Rust sure looks interesting but I wonder whether having bindings for a > framework will make applications suddenly pop. > > Is there any KDE project that would be furthered by having (and > maintaining) these bindings? > > Aleix
Having Rust bindings will not really make applications pop up suddenly (at least not according to me). However, they will allow pre-existing Rust KDE applications (like [Ikona](https://invent.kde.org/sdk/ikona) and [Angelfish](https://invent.kde.org/plasma-mobile/angelfish)) to migrate more code to Rust if they desire to do so. Having said that, it is only true in the short term. Last year when I was not as familiar with KDE Frameworks and qmetaobject, I tried to find a way to write KDE Application in Rust. I came across Rust Qt Binding Generator but I decided not to use it since it meant I had to maintain a JSON file on top of everything else. It might not seem like a big thing in big projects but it is a big commitment for small applications which people like to create when they are not really invested in technology. I also came across qmetaobject and it actually was quite good. However, most KDE applications used Kirigami and KI18n at least, so it while it made creating QML + Rust applications possible, it was still difficult to create an application specifically for KDE. In the end, I ended up moving on since I did not have the technical skills to write the C++ bindings myself at the time and there didn't seem to be much interest from the KDE side in Rust either. However, after seeing the work on GTK-rs with GTK4, I was once again decided to give Rust + KDE development a try, but with one major difference. I decided that if something does not already exist, I will simply write it myself. And that's how I ended up with writing bindings for KI18n since it is literally one of the 3 packages that are present in the Kirigami Getting Started guide. The reason I am repeating this story is that I found out something as I was searching to find a mentor for my project. People from the Season of KDE team directed me to message in #kde-rust channel to find a mentor. However, they in turn directed me back to the #kde-soc team to find a mentor. There were many people who found my proposal interesting but in the end, the interested people weren't really able to mentor it. The reason they gave is that there is not much Rust in KDE. And well, I think I know the reason why now. 1. It is hard to manually use C++ from Rust. There are crates that help a lot, like rust-cpp and Google's autocxx. However, once you start passing data from C++ to Rust and vice versa, things become a mess. There is a lot of unsafe involved and unless someone has a very good understanding of both Rust and C++ memory models, it is pretty much not possible to create anything halfway decent. This means currently, the ceiling for Rust usage in KDE is very high. 2. This first point kinda means that no new KDE applications can be written in Rust even if the developer has an interest in doing so. If they really want to use Rust, they are much better off using GTK. This is fine if the developer is a complete beginner, however, this also detracts intermediate developers who might have the skills to do it but just don't think it to be worth their time or effort. This makes attracting new developers to use Rust extreamly difficult. 3. This only leaves rewriting the internals in Rust like KDE Solid Framework. However, since there are no new Rust developers who learn more about KDE Frameworks from writing user-facing applications, they never evolve into experienced KDE developers who might be able to write internals in Rust. This creates a vicious loop that stalls any Rust + KDE development. There are many projects which just use Kirigami and a few other components from KDE Frameworks and can be easily written in Rust but couldn't because of either lack of Rust + KDE Resources or lack of community around it. Finally, I don't really think everything should be rewritten in Rust. C++ is an amazing language and C++20 simply blew me away. So rather than rewriting everything in Rust, I would prefer applications that actually can utilize the advantages of Rust to be written in Rust. Rust has pretty great async support and some amazing libraries for parsing and other things. Its macro system is quite powerful and the borrow checker is amazing. The reason why I chose to write a wrapper for KConfig is that it can be very useful even outside KDE (see https://www.kdab.com/kde-frameworks-part-1-kconfig/). This means it can be used in normal Rust + QML projects. There are already projects that actually use qmetaobject (like https://gitlab.com/whisperfish/whisperfish/-/tree/master) and they might be interested in using KConfig. Also, my current goal is to write wrappers that can be used with QML in particular and so KConfig sounded like a good idea. Also if it can attract new Rust developers for KDE, that will help improve KDE as a whole. Ayush