Will C# or dotnet ever be supported for building KDE apps?

Development
1

I am a full time dotnet developer. I use plasma and kde extensively. I would really love to build apps but when I try it’s really tough going because the last time I did c++ was in university. My python is also really not great. I am very capable in dotnet but I am not able to use it to build KDE apps. I’ve had some ideas for apps that I would love to build in Kirigami. I’ve always felt as a long time user it would be nice to contribute back, but the effort involved in learning a new framework in a different programming language makes this an especially uphill battle.

I maintain a small plasma widget and it’s hard enough to get QML right (but I don’t mind this). Since Plasma 6 I’ve struggled to port my widget to plasma 6, because time is always my enemy here. With a full blown application this problem is compounded to the level where I don’t even attempt it.

I was wondering if there are any ways or plans for dotnet support for building KDE apps? I think there are probably many Java developers who feel the same.

I know that packaging the runtime might be a problem, but these days dotnet supports self contained deployments and even AOT! Flatpak might also be useful for this.

I’d love to hear what others think and if they are in the same boat.

1 Like
2

As far as I know there are no existing plans. Building bindings is a bit of work, so they primarily happen for languages lots of KDE people are invested in.
Currently that is Rust and Python.

A prerequisite for KDE Framework bindings are at least QML bindings, and there doesn’t seem to be maintained ones for dotnet as far as I could find.

1 Like
3

Related: New programming language needed for KDE?

2 Likes
4

There have been attempts at both Java and C#/.NET bindings in the past, very often spearheaded by binding champion Richard Dale.

Unfortunately none of these attempts generated any uptake by application developers, let alone attracting more binding contributors so they eventually had to be abandoned.

However, there have been many changes to the overall stack which should make it much more viable to contribute when using other frameworks that C++/Qt.

For example KRunner plugins originally had to be C++ plugins which got loaded into the KRunner process.

At some point KRunner gained the capability to talk to its “plugins” via D-Bus, essentially enabling plugin development in an extremely wide range of languages.

Quick search found a KRunner NodeJS Plugin.

I recently researched requirements for a KPurpose (KDE’s “Share” action framework) plugin and it seems to also support out-of-process implementations.

Other places in KDE have traditionally supported a service oriented approach to things for a long time.

The KIO system for handling remote files, for example, had this even before the arrival of D-Bus as a cross-desktop RPC system.

KDE’s PIM applications have long used such mechanisms to augment each others functionality (e.g. passing a calendar invitation from KMail to KOrganizer).

Then we had developments in the wider Free Software desktop space with the introduction of Portals.

Previously any “foreign” framework needed quite some work to access desktop features or standard UI components, e.g. the “native” file dialog.

Many of these things are now also available via out-of-process APIs called Portals.

At this point I would not be surprised if it would not make more sense to have good client side support for these things natively than to attempt binding KDE’s implementation of them.

1 Like
5

Thank you for the comprehensive replies. I’ll look at the other post as well.

DBus is really nice, and there is a c# library that generates code bindings for DBus interfaces that I really do want to use for some automation at work.

But I would really like to build useful UI applications. The first one that comes to mind is a medicine reminder. It’s an extremely important tool for many people including myself.

I do look every year or so whether things have changed and there was a doomed qml .net project. It seemed like it was bootstrapping a c++ app in the background and it worked okay. The problem was that the author of the package had no intention of taking it further and the Qt package it installed could not support kirigami.

I wonder if it would be possible to create a bridge that would load all the Qt/kirigami bits but then provide IPC such as DBus between the UI and whatever is in the background? Almost like generic bindings? When I package my app I could use a self contained dotnet or AOT. In principle then someone can use any language as long as this bridge exists?

When it comes to file dialogs and portals I think this is great but I would still want the app to feel native to the desktop. That does mean the UI itself.

Anyway just a shot in the dark. I wanted to reach out because I am keen to build small applications but I really don’t have the kind of free time to delve back into python or C++. I’m learning rust but it’s also difficult with very little free time.

6

It is probably not impossible to come up with a more or less generic way to make a QtQuick application which talks to a backend via IPC.

Might not be doable purely runtime and require some build time steps like code generation.

The cxx-qt Rust/Qt bindings do this in-process but also essentially generate required C++ interfaces at built time that then bridge to the actual code in Rust.

Of course Rust has the advantage that it was designed with integration in mind and is by default capable of generating native code with C-style library symbols.

Unfortunately I don’t have much insight into .NET myself but having done a lot of Java before coming to C++/Qt I wonder if styling would be an option.

One of the primary UI stacks in Java is Swing, which follows a very similar approach to Qt (drawing itself instead of wrapping platform components) and has a so-called Look & Feel plugin system to adapt to platforms.

If your stack has similar capabilities it might be easier to develop a Breeze style/plugin that makes your UI look like what a Qt application would look like when running on Plasma.

Combined with the system integration points mentioned earlier this could be more viable than going for backend/frontend process separation.

7

I think it would be good to push for more framework unification under the KDE umbrella rather then less. The division between Qt Widgets and Kirigami is already very visible, and shows that implementing the same component in multiple frameworks rarely happens.
Specific to the styling portion, I think the GTK Breeze style shows the limitations of that very well.

QML finally is a fairly limited API surface that needs to be bound to the other language. Such bindings are definitely doable, but need enough community support behind them to get to a point were they are complete enough and the API well enough designed that people want to use them.

8

While the QML/C++ integration API is of course a much smaller target than, say, all of Qt or KDE Frameworks, it still requires some mechanism to build QMetaObjects either at build or runtime to mediate between QML engine and the foreign language code.

This is essentially what cxx-qt is doing at build time or Qt for Python is doing at runtime (with some built-in support in the bindings).

This might also be possible for dotnet , however might also require a different skill set than making a dotnet application look and feel as if it were using Qt.

I would be surprised if it couldn’t feel more “native” than all the Electron based apps users are installing nowadays.

In any case I think there were discussions at the last Qt developer summit around ideas of enabling other languages to be the “core” below a QML/QtQuick based UI.

But it might take a while for these ideas to result in actual code.