Install presence

Sat Jun 19 11:21:36 BST 2021

Hi,

On 2021-06-19 12:13, René J.V. Bertin wrote:
> On Saturday June 19 2021 11:54:08 Ian Wadham wrote:
>>> Regarding mac, it's the platform I'm the least familiar with. My
>>> impression is that it's better that it's not populated at all than
>>> having every project feel half-baked there.
> 
> If you don't hand-tailor applications and do not patch Qt, half-baked
> might be more than you'd get, on Mac; for instance, applications would
> lack all icons that aren't embedded, and will probably not find their
> runtime resources because those will be installed into the wrong
> standard locations. Aleix may know this from his work on KDevelop.
> 
> 
> FWIW, I created a Phab. task once about patching the ECM so that Mac
> builds should work a bit better but can still opt to use the standard
> Unixy way of building (= like they are now, for use with patched Qt or
> simply with a hand-tailored build systems). I think that simply went
> forgotten without ever attracting any attention. Idem for questions
> I've posted on the frameworks devel ML since probably a bit before
> that already; it's as if people have moved on to whipping other cats
> (oooohhh ... KDE on mobile...??).
> 
>>> We might need someone who
>>> cares to push through. But we also need to know it's worth the 
>>> effort.
> 
> Be prepared to pay such a person, or (in case of MacPorts) to "bribe"
> the powers that be so that s/he at least gets commit access to the
> official ports tree repository in order to avoid having to fuss and/or
> being tarpitted. (I get the impression that HB is even fussier about
> accepting new entries but IIRC they already have the KF5 frameworks.)
> 
>> René, Marko Kaening and I were able to get the KDE 4 apps running much 
>> better, but had no way to advertise the fact to users.
> 
> Other than the Wiki which is probably not consulted by many. BTW, all
> of the KDE4 apps are maintained by a single person who is of a very
> careful nature (probably understandably given the huge cardhouse he is
> responsible of); Marko sadly died a few years back while we were
> gaining momentum to get an initial selection of KF5 ports up for
> inclusion review.
> 
>> So, maybe you are right - regrettably. It would be a huge effort to 
>> get current KDE releases to run in MacPorts. I think the MacPorts 
>> developers would provide help and advice, but a few years back Marko, 
>> René and I repeatedly, repeatedly, repeatedly asked for help and 
>> advice from KDE core developers and none was forthcoming.
> 
> I doubt that has changed much, with the exception of 1 new maintainer
> who seems to be on a wavelength quite similar to mine.
> 
> Right now, if we'd want to get even the KF5 frameworks accepted a
> decision would have to be made how to deal with the Qt5 problem. My
> own patched Qt5 port is designed to be an install alternative for the
> official one (I do have a minimal set of patches for Qt 5.12.6, which
> I've only been able to test on Linux so no guarantees there). I've
> found it prohibitively difficult to co-operate with the Qt5 port
> maintainer though, and the general opinion is that Qt5 is a
> problematic port that breaks easily. so the best approach might be to
> add a Qt glue library that provides at least an alternative version of
> the QSP that does work as we'd want (= point to standard XDG
> locations). My current approach already uses an alternative class
> (QExtStandardPaths) and good old CPP macros injected via the compiler
> commandline to get code to use it. If memory serves me well I already
> have a PoC glue library that could be injected in a similar fashion
> (commandline, or a CMake hook provided via the ECM).
> 
>> I fear however that Apple may come out with a new version of its OS 
>> that makes it impossible to run the KDE 4 apps.
> 
> As long as Qt4 can be made to build and Apple's SIP and related
> annoyances can still be turned off those apps should continue to run.
> If not, that might simply mean that Macs are no longer intended to be
> general-purpose desktop computers (I for one have decided years ago
> already that my 2011 MBP is the last new Mac I'll ever have bought).
> Either way, I kind of doubt that KDE as an organisation are very
> thrilled about continued use of KDE4 apps...
> 
>>> My impression at the moment is that we should only be on platforms
>>> where we're present on their main apps forum rather than just lateral
>>> ones (F-Droid, Homebrew, downloadable msi or dmg files, etc).
>> 
>> That’s your (KDE Community’s) prerogative, but watch out for babies 
>> and bath water…
> 
> Either way, the only choice KDE have in this matter is whether or not
> they appoint someone officially in charge of that presence. They could
> try legal action to get their software out of a platform but I don't
> see how that could succeed with the current licensing model.

perhaps I miss something, but the most talk here is now about "how to 
get KDE applications into MacPorts".

Actually, to create application bundles outside of the MacPorts world, 
the binary-factory.kde.org CI together with Craft
provides already now a "working" solution.

But beside Krita (with own tooling), which does a good job on macOS, no 
maintainer to far (including me)
really finalized any of the binary-factory application bundles to a 
point one would say there are
non-beta.

e.g. the nightly app bundles for Kate https://kate-editor.org/get-it/ 
work on macOS and
I use them for some of my work there, but they need polish and we have 
no people for that.

I would appreciate help with getting the Kate bundle up to shape,
but I doubt that is something that can be solved with money, one would 
just need some
Kate contributor using macOS daily, I don't.

For Windows, we had/have such people and therefore the 
binary-factory/Craft variants of Kate
there work reasonable well (and are in the "official" store there).

Greetings
Christoph

-- 
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org