Season of KDE Proposal: Rust wrapper for KConfig

[Ayush Singh]

On Sat, Jan 8, 2022 at 7:54 AM Aleix Pol <aleixpol at kde.org> wrote:
>
> On Thu, Jan 6, 2022 at 8:27 PM Ayush Singh <ayushdevel1325 at 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: ayushsingh1325 at 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