[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: Install presence
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2021-06-18 10:54:41
Message-ID: 5061718.TaHyACylyH () bola
[Download RAW message or body]

On Friday June 18 2021 13:19:40 Ian Wadham wrote:

> Hi Aleix,
Is Aleix actually getting these replies? Not directly in any case, unless he and Adam \
are the same person?

As usual Ian makes a number of good points (logical, he knows the cracking of the \
whip...!)

> Bugzilla is very good, but bugs sit around unsolved, wishlists are ignored and \
> features get out of date and out of fashion when an app is "unmaintained" for \
> several years. Users of apps do not like this.

A good example: KNode. It's one reason I'm still using KDE PIM 4

Since Ian mentioned Bugzilla: while very good as bug tracker (I think the only thing \
missing is a possibility to reply via email!) it is crippled (IMHO, severely) by the \
policy that patches are ignored there. This is not the place to discuss that, but I \
think it's wrong to ignore contributed fixes esp. now that peer-reviewed contribution \
has become yet a step more cumbersome.

And FWIW, this particular user doesn't at all like the tendency to make desktop and \
mobile apps look and behave the same... esp. if that means applications require \
recent and rather well-dimensioned hardware in order to run (properly). Mac-specific \
issues, Linux has always been a champion of running about just as well albeit slower \
on older, less powerful hardware - and KDE is pricing itself out of that market. I \
don't believe that technological progress in software has to come at this price. And \
yeah, that will affect install stats directly.

> Secondly, would-be authors of KDE apps fall foul of what I call LGM (Library \
> Generated Maintenance). ... I was a developer on KDE Games for about 15 years and I \
> estimate I spent about half my development time keeping up to date with library \
> changes.

Aren't you basically putting a finger on the cost of being part of an app collection \
with an imposed and (often if not mostly) artificial update cycle?

> Unfortunately, the KDE apps on MacPorts are, in a word, moribund. The apps are \
> running with KDE 4 and Qt 4 libraries (KDE 4.14.3) on MacPorts. These are compiled \
> from snapshots of the KDE repositories. I myself use KMyMoney and KDE Games quite a \
> lot. However that code is frozen solid - no new features or fixes available.

> As far as I know, nobody has succeeded in porting to MacPorts the KF5 library and \
> the latest versions of source code of KDE apps, although some of us tried very \
> hard.

This is not purely a KDE problem, though it doesn't help that most KDE developers \
seem to have a "more catholic than the pope" attitude towards what they consider is \
being native. Qt's QStandardPaths implementation dealt a huge blow to the principles \
upon which MacPorts s built (HB seem to care less), and the split of many components \
into the KDE Plasma whatever (which is not supposed to be supported outside of almost \
exclusively Linux) another. Getting feature-completeness means applying patches if \
the authors didn't do the equivalent by hand-tailoring. I spent a LOT of time and \
energy developing patches for Qt (mostly QSP but also to the QPA), writing a Mac \
version of the KDE platform theme plugin, fixing things in the QtCurve style ... and \
then patching out cheap and easy Mac "adaptations" from applications. The fact that \
the fruits of this labour never made it into MacPorts is largely their fault - but it \
does have to do in part with the considerable amount of patches. That effort has been \
all but halted by something like Ian's LGM thing. While Qt is very good in terms of \
backward compatibility they're also very quick to drop support for "older" Mac OS \
versions. As a single maintainer of the (unofficial) KF5 MacPorts port tree I'd be \
working a fulltime job just keeping my system up-to-date and maintaining my effort. \
Easier to stick to Qt 5.9 and KF5 5.60.0 and then backport whatever is truly needed \
when an application truly needs an update. That way at least I can have a life off \
the computer, and actually use the applications.

> I used to have a flourishing development setup on Apple Mac under KDE 4 and I used \
> it for KDE app development on MacBook for about 5 years. That all came to a \
> grinding halt when KF5 was released.

Actually KDevelop has been stable for an almost suspiciously long time now, with \
dependency requirements that are easy to meet even on my system. It probably works \
better with newer LLVM/Clang versions than I can run (presumably) but it works more \
than good enough for my purposes as it is. Of course my version also has a \
significant number of patches that improve behaviour on Mac ... but I think we agreed \
to disagree about most of those O:-)

> So yes, you have a LOT of work to do before you can truly say that "KDE is All \
> About the Apps". All the the best and I hope your talk goes well.

Hmmm, I though this thread was about install presence. If it's about "all about the \
apps" then, yeah, I guess you can say that. But for a very big part that should be \
read as "all about the individual apps" with a few parasol groups trying to impose a \
form of adhesion through guidelines. But ultimately it really feels like developers \
care about their application(s), and often consider them their plaything (or subject \
of research). Not illogical or wrong in itself if you think how people usually come \
to FOSS development, but  feel it's a bit too rare that the user is put front and \
central (as it should, IMHO).

R.


[prev in list] [next in list] [prev in thread] [next in thread]