[HN Gopher] You can contribute to KDE with non-C++ code
___________________________________________________________________
You can contribute to KDE with non-C++ code
Author : jrepinc
Score : 88 points
Date : 2024-08-04 09:59 UTC (13 hours ago)
(HTM) web link (rabbitictranslator.com)
(TXT) w3m dump (rabbitictranslator.com)
| captn3m0 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| rock_artist wrote:
| 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 wrote:
| You had me at the ability to contribute in rust.
| AndyKelley wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| Someone wrote:
| > It's unfortunate that a UI layer ties you into a particular
| programming language
|
| 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.
| tormeh wrote:
| What about QML?
| SuperNinKenDo wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-04 23:01 UTC)