You can contribute to KDE with non-C++ code
rabbitictranslator.com
rabbitictranslator.com
It's unfortunate that a UI layer ties you into a particular programming language. It feels like something that should be provided by the OS somehow.
The OS is also written in a language and its idiosyncrasies sometimes do show through in system calls.
From what you're saying it sounds like the problem is less that Qt is not part of the OS than that the Qt API wasn't designed with interop at all in mind. A well-designed API can live outside of the OS and vice versa.
That would be a major shift in mentality, and there are reasons why this has become less common over time, rather than more so. But it seems to me that the balance has shifted, and this is becoming a better idea than it was.
Specifically, Unix, and therefore Posix, benefited greatly from being implemented in a high-level language (meaning: not assembly). It was a time of many architectures, with more invented all the time, and someone could write a backend for cc and bootstrap a whole OS.
But architectures are consolidating, and programming languages are proliferating. But the de-facto C ABI for any given platform remains the lingua franca, and it's a fairly impoverished way to communicate.
It's an intriguing prospect to develop a more sophisticated common language for object code. Different languages have different needs, that won't change, but I see a lot of room to develop something more full-featured, that would allow an OS to provide a UI layer without tying itself up in the details of C++ or Objective C.
Who knows, maybe Zig can lead the way on that, when the time's right.
This is true to some degree, yes. But all those languages manage to speak C ABI through some sort of extern directive or other. I don't believe that's because the de-facto C ABI for any given platform is the optimal common language, but rather, it's the only thing we can rely upon.
I'm not a compiler engineer, just an interested amateur, so any detailed proposal I could offer would be painfully naïve. Getting good results would involve attracting the interest and talent of skilled professionals.
I'll start by noting that I'm not proposing a Common Object Model which all languages are expected to target. It's been tried, there's prior art, such a format might even be adequate, but: that's a lot of work, the result is sure to be unsatisfactory, and, most important, language core teams aren't going to do this.
The idea here is a better interface, for code which is expected to speak to other code. It might be productive to think of it like protobufs for function calls. Libraries could compile in metadata in a binary format, defining the necessary structure of the stack, and the register discipline, for calling into a particular function. This would require some ability to talk about aggregates, to be able to cover constructs like vtables (where the function pointers themselves would define a binary prototype included with the library). This would include a plain-text intermediate format representing the same data, to make life easier on everyone, but it would nonetheless be possible to link against a version of a system library directly, by extracting this definition language from the object code.
This reduces the problem space, from having to find a common object format acceptable to every language, to providing a more enriched surface area which languages could publish for the API of library code. A large part of what makes the de-facto C ABI so sticky is that object code is flying blind: I keep emphasizing de-facto because the ABI is a matter of convention, and there's no good way to vary that convention and also let a linker know that you have.
I'm optimistic that something along these lines could be designed, such that systems languages could both produce and consume this format, with managed languages consuming it using the standard FFI adaptation technique. It's likely it would be an improvement on the status quo, where everyone just does what the nearest C compiler does, and hopes not to step on one another's toes in the process.
After 30 years pushing for COM, if you want a good editing experience fo COM IDL, meaning syntax highlighing, code completion, and integration between generated code and Visual Studio projects, one needs to use 3rd party tools.
This in what concerns C++ development, where C++ Builder provides a much better experience.
If using Delphi, or .NET, it isn't as bad, but then again, mostly because writing IDL isn't needed other than in specially cases not supported out of the box, usually it is driven by language attributes instead.
I think it is unavoidable that it ties you to a programming language paradigm. For example, it may assume the existence of booleans, reference counting, garbage collection or of multiple inheritance. If your preferred language doesn’t support them, that will make the bindings look uglier than needed.
Conversely, if your preferred language supports them, but the API of the UI layer doesn’t, the bindings will look cumbersome in places where using those features looks natural.
So, what you end up with is either plain C (ugly for everybody, including C programmers, even they may not want to admit it), C++ or the JVM, or something like it that looks fine for C respectively C++ respectively Java programmers but feels strange in some degree to others, the more so the less their language ‘feels’ like C respectively C++ respectively Java, or COM/SOM/CORBA, which claim to be language agnostic, but don’t do that for the feel of an API.
All desktop OS, and mobile OSes, designed top to bottom, not like a UNIX puzzle, do provide their UI frameworks in the box.
Naturally, tied to the programming languages officially supported by the OS SDK.
The only thing worth noting (at least from the glimpse I took), Is that the actual KDE is still C++. As an example:
- Web stacks (JS/HTML/etc) suggests it's only for websites.
- Rust is focused on bridging/binding (with Rust)
- Java is for KDE connect on Android, and I guess some binding with Android.
Getting started through a language I already know might be a good way to build some familiarity with the way things are done and structured, bridging the gap without having to learn a new language at the same time I learn the rather intimidating Qt bindings.
I will save this for later and go over it again for sure.
I've contributed some security findings and UX improvements to KDE in the past year and it was quite a bad experience for me as a contributor. KDE feels like a slow organization and stakeholders have their own incentives apart from software quality.
Only contributed a couple of fixes, but the experience was great overall.
You should do this even if you are a regular contributor and have a good working relationship with the maintainers.
I don't know anything about KDE's processes or culture, but I think this is (or at least should be) universal when dealing with any project. I really do not understand how anyone could just go from zero to PR without talking to a maintainer first about what they want to do, and how they want to do it.
I usually open a PR with at least a proof of concept implementation without prior discussion. I find that trying to discus a new feature without a concrete thing to look at often goes nowhere or even goes completely unanswered. On the other hand, with a concrete implementation to point at it's much easier to discuss direction and details and have everyone on the same page instead of talking past each other. But I realize the maintainer's vision may not align with my ideas, so I'm okay with them saying "no, we don't want this" and closing the PR outright.
You should do both: get a soft ok that they'll consider the change ("If I put up a PR/POC will you be able to take a look? Will you be able to approve? If not you then who would I reach out to?") and then put up the PR so there are concrete things to discuss. This saves you time because why put together even a POC if they're never gonna approve it.
Personally I don't bother contributing unless I'm getting paid - otherwise I have no incentive to deal with the people bs.
FOSS is 100% determined by the license under which software is released. Several notable open source projects, Lua and SQLite leap to mind, are entirely closed-development. Others are pure anarchy, most are somewhere in the middle. The polemic which coined these terms was mainly making a case that the bazaar model is surprisingly effective and worth considering, a controversial claim in its day, but no longer so.
> not listed
Lots of other garbage is though.