42
New programming language needed for KDE? (gruenich.blogspot.com)
submitted 10 months ago by leopold@lemmy.kde.social to c/kde@lemmy.kde.social
18 comments fedilink hide all child comments
top 18 comments
sorted by: hot top controversial new old
[-] bluGill@kbin.social 7 points 10 months ago

The C++ committee is actively looking at how something like rust's borrow checker could be added to C++. Likely it won't be a borrow checker, but just enforcement that some code cannot use new/delete and so must use a container (std::unique_ptr, std::vector...) which gets rid of most of the pain. Modern C++ is a much better language than C++98, but I still see a lot of people writing C++98 code.

[-] chris@lem.cochrun.xyz 6 points 10 months ago

I have been building a Qt/KDE app in rust using that CXX-QT binding. It's pretty good, but definitely more of a headache to work through the binding than just directly with C++. That being said, I don't feel like I'm about to shoot myself in the foot with rust. Rust just protects and advises the best paths forward. Once KDAB solidifies the binding and perhaps makes it easy for others to create their own extra bindings, (which they don't want to maintain every class in QT so this is necessary) it'll be amazing.

[-] chris@lem.cochrun.xyz 4 points 10 months ago

Also, it feels so awesome to build the backbend in rust and the ui in QML.

[-] ono@lemmy.ca 4 points 10 months ago

Qt is a wonderful GUI toolkit, but new language bindings are notoriously difficult, since it depends not only on C++ (which itself is tricky to bind into other languages) but also the Qt meta-object compiler. Even so, some interesting projects have emerged on that front. For example:

Verdigris:

This (header-only) library can be used to create an application using Qt, without the need of the moc (MetaObject Compiler). It uses a different set of macro than Qt and templated constexpr code to generate the QMetaObject at compile-time. It is entirely binary compatible with Qt.

DQt:

DQt contains experimental bindings for using a subset of Qt with the D Programming Language. Qt is a library for writing cross-platform graphical user interfaces. Currently bindings exist for the Qt modules core, gui, widgets and webenginewidgets.

[-] herzenschein@pawb.social 2 points 10 months ago

without the need of the moc

I got a bit of a mind freeze reading that sentence since my first thought was "why would someone deliberately give up on Qt's reflection system" but only then realized they're still using QMetaObject (the thing that actually enables reflection and signals and slots), just building it with something else.

[-] ono@lemmy.ca 2 points 10 months ago* (last edited 10 months ago)

Yes, exactly. So a standard compiler can be used, making language bindings much cleaner, while the runtime functionality and library compatibility are preserved.

And then there's DQt, which uses DLang's compile-time function execution instead of the meta-object compiler.

[-] ami@floss.social 1 points 10 months ago* (last edited 10 months ago)

@herzenschein
If you are interested in Qt without the MOC I can also recommend @copperspice_cpp that is a fork of Qt4 but relies heavily on#modernCpp
@ono @kde

[-] copperspice_cpp@hachyderm.io 1 points 10 months ago

@ami @herzenschein @ono @kde, CopperSpice started as derivative work build includes everything up to Qt 5.6. Our team has redesigned major sections of the code base to provide real utf-8 strings, standardized containers, reduce UB, improved pointers, etc.

[-] ono@lemmy.ca 1 points 10 months ago* (last edited 10 months ago)

It's an interesting project, but as a fork, I would be concerned about its compatibility with standard Qt & KDE libraries, widgets, and styles. Can you comment on that?

Also, what language bindings does it offer?

[-] copperspice_cpp@hachyderm.io 1 points 10 months ago

@ono, Thanks for your question. One of our main goals was to maintain compatibility with Qt user code. We have worked with a significant number of projects who migrated to CS and no one lost functionality. Most code will work without any modifications.

We have a parser (PepperMill) which you run one time to convert anything in your header files which used moc. For example, we change Q_OBJECT to CS_OBJECT(class_name).

Here is a link to the macros which are modified.

https://www.copperspice.com/docs/cs_overview/m_macros_metaobj.html

[-] ono@lemmy.ca 1 points 10 months ago

I think you're talking about migration from Qt to CopperSpipce, though, yes? I'm talking about integration with existing desktop environments. Making use of the themes that are already installed. Communicating with existing libraries via the existing interfaces. Are there any hitches to be aware of on that front?

And language bindings, for those of us who are trying to get away from writing in C++?

[-] copperspice_cpp@hachyderm.io 1 points 10 months ago

@ono, In terms of using an existing library, if it is a C++ library this works great. If the library was written using Qt it will need to be migrated to CopperSpice. This has already been done for a few libraries.

Our CS team has experience with library migration and we are available to help with this process.

[-] ono@lemmy.ca 1 points 10 months ago* (last edited 10 months ago)

That's as I expected; Thanks for confirming.

Unfortunately, that leaves out the kind of integration I was asking about (and the kind implied in this post), through existing Qt & KDE shared libraries and such.

CopperSpice might still be interesting for stand-alone projects written in C++, though, and I appreciate that you're here engaging with the community.

[-] SubArcticTundra@lemmy.ml 2 points 10 months ago

Yeah, C++ is what's keeping me from switching from Vala/C + Gtk

[-] copperspice_cpp@hachyderm.io 1 points 10 months ago

@ono @leopold, Verdigris was based on our work with CopperSpice. Qt refused to accept this code and the key developer moved on. If you look at the project it has not been touched in years and may not be supported anymore.

[-] arran4@aussie.zone 2 points 10 months ago

What about Zig? But I would have to agree that C++ does seem to be holding Qt back from adoption, minus where there are decent bindings.

[-] merthyr1831@lemmy.world 1 points 10 months ago

dart would be a good candidate imo.

[-] Cwilliams@beehaw.org 1 points 10 months ago

I don't understand. What was the problem with Rust?

this post was submitted on 17 Jan 2024
42 points (95.7% liked)

KDE

5401 readers
181 users here now

KDE is an international technology team creating user-friendly free and open source software for desktop and portable computing. KDE’s software runs on GNU/Linux, BSD and other operating systems, including Windows.

Plasma 6 Bugs

If you encounter a bug, proceed to https://bugs.kde.org, check whether it has been reported.

If it hasn't, report it yourself.

PLEASE THINK CAREFULLY BEFORE POSTING HERE.

Developers do not look for reports on social media, so they will not see it and all it does is clutter up the feed.

founded 1 year ago
MODERATORS
carlschwan@lemmy.kde.social
Bro666@lemmy.kde.social
herzenschein@pawb.social
Aniqakhokhar@lemmy.kde.social