7 ms·

You can contribute to KDE with non-C++ code

110 points by jrepinc 2y ago

captn3m0 2y ago
This is an excellent list. I started using KDE on my secondary system recently (because Asahi recommends it), and this is very helpful to let me pick projects where I can be helpful.
bflesch 2y ago
Yeah and then your contribution gets shot down because the maintainers have a totally different vision about their product than you do. 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.
- Flex247A 2y ago
  Honestly, the most welcoming open-source project I found was Blender. They are quite open to criticism, and follow ups are timely. Only contributed a couple of fixes, but the experience was great overall.
- kelnos 2y ago
  Any time you're planning to make a change that seems even remotely contentious or controversial, you should talk to the maintainers about it first. 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.
  - GrantMoyer 2y ago
    > 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.
    - almostgotcaught 2y ago
      > 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. 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.
    - exe34 2y ago
      I feel like you, and in another environment entirely, I found it's useful to make the working implementation in secret, and open the ticket as if it's a new idea and steer the conversation towards your implementation. People like to feel like things are their ideas, so if you can guide them suggest the idea to you, it'll definitely get accepted. Personally I don't bother contributing unless I'm getting paid - otherwise I have no incentive to deal with the people bs.
  - SuperNinKenDo 2y ago
    People tend to think bazaar == open source, and cathedral == proprietary, and for many projects the design process is more bazaar than cathedral. But almost any large open source project is cathedral, or more like, Democratic Centralism. I guess in people's defence, these cathedral projects in the open source world tend to follow totally bespoke procedures that don't necessarily align with those of another project, so it can be a pain or intimidating to try and learn the bespoke incantations for every project you want to submit a patch to.
    - samatman 2y ago
      It's true, they do tend to think that. Which is too bad, because The Cathedral and the Bazaar has very little to say about proprietary software. esr's type-case for Cathedral development is GNU software, and the Bazaar is Linux. 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.
rock_artist 2y ago
It's very useful to have such a list for any project to better engage contributors. 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.
xyst 2y ago
You had me at the ability to contribute in rust.
AndyKelley 2y ago
Using Qt bindings sucks big time though. That's effectively still writing C++ code. You might as well stop pretending and write actual C++ code so you can limit yourself to having to deal with C++'s idiosyncrasies instead of those, plus the ones introduced by a second language, plus the ones introduced by a bindings layer. 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.
- OvbiousError 2y ago
  Don't know about other languages but the python bindings are pretty ok to use imo. You can also stay in qml longer than you'd think, especially with all the tooling kde provides.
- lolinder 2y ago
  > 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.
- samatman 2y ago
  The way forward for something like that is for operating systems to start defining their interface in terms of ABI. 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.
SuperNinKenDo 2y ago
I really love the KDE project and have been thinking about ways to contribute. Eventually I want to use it as an excuse to finally learn C++, which has always held a fascination for me since I started programminh from a gamedev perspective, but never picked up the industry standard language with its esoteric scribblings so uncanny familiar, yet foreign. 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.
Am4TIfIsER0ppos 2y ago
Really? How do I use QT from C? > not listed Lots of other garbage is though.

110 points by jrepinc 2y ago

This is an excellent list. I started using KDE on my secondary system recently (because Asahi recommends it), and this is very helpful to let me pick projects where I can be helpful.

bflesch 2y ago

Yeah and then your contribution gets shot down because the maintainers have a totally different vision about their product than you do. 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.

Flex247A 2y ago
Honestly, the most welcoming open-source project I found was Blender. They are quite open to criticism, and follow ups are timely. Only contributed a couple of fixes, but the experience was great overall.
kelnos 2y ago
Any time you're planning to make a change that seems even remotely contentious or controversial, you should talk to the maintainers about it first. 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.
- GrantMoyer 2y ago
  > 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.
  - almostgotcaught 2y ago
    > 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. 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.
  - exe34 2y ago
    I feel like you, and in another environment entirely, I found it's useful to make the working implementation in secret, and open the ticket as if it's a new idea and steer the conversation towards your implementation. People like to feel like things are their ideas, so if you can guide them suggest the idea to you, it'll definitely get accepted. Personally I don't bother contributing unless I'm getting paid - otherwise I have no incentive to deal with the people bs.
- SuperNinKenDo 2y ago
  People tend to think bazaar == open source, and cathedral == proprietary, and for many projects the design process is more bazaar than cathedral. But almost any large open source project is cathedral, or more like, Democratic Centralism. I guess in people's defence, these cathedral projects in the open source world tend to follow totally bespoke procedures that don't necessarily align with those of another project, so it can be a pain or intimidating to try and learn the bespoke incantations for every project you want to submit a patch to.
  - samatman 2y ago
    It's true, they do tend to think that. Which is too bad, because The Cathedral and the Bazaar has very little to say about proprietary software. esr's type-case for Cathedral development is GNU software, and the Bazaar is Linux. 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.

rock_artist 2y ago

It's very useful to have such a list for any project to better engage contributors. 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.

xyst 2y ago

You had me at the ability to contribute in rust.

AndyKelley 2y ago

Using Qt bindings sucks big time though. That's effectively still writing C++ code. You might as well stop pretending and write actual C++ code so you can limit yourself to having to deal with C++'s idiosyncrasies instead of those, plus the ones introduced by a second language, plus the ones introduced by a bindings layer. 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.

OvbiousError 2y ago
Don't know about other languages but the python bindings are pretty ok to use imo. You can also stay in qml longer than you'd think, especially with all the tooling kde provides.
lolinder 2y ago
> 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.
samatman 2y ago
The way forward for something like that is for operating systems to start defining their interface in terms of ABI. 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.

SuperNinKenDo 2y ago

I really love the KDE project and have been thinking about ways to contribute. Eventually I want to use it as an excuse to finally learn C++, which has always held a fascination for me since I started programminh from a gamedev perspective, but never picked up the industry standard language with its esoteric scribblings so uncanny familiar, yet foreign. 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.

Am4TIfIsER0ppos 2y ago

Really? How do I use QT from C? > not listed Lots of other garbage is though.