On Thursday January 07 2016 14:13:21 Ian Wadham wrote:
>> KF5 is designed to allow for step-by-step migration of applications from
>> KDE4 to KDE5, but with the underlying idea that once an application has been
>> migrated it's the better version
>
>For KDE applications, "better version" = "only officially released version".
>There is only one
>'master' branch in each KDE repository and that is the branch from which
>releases are made.
I don't want to claim that there isn't anything to that underlying idea. Esp.
not when Qt4 itself will stop being supported.
>of dependencies from KDE to Qt library classes, the most troublesome of which
>is the shift
>from KStandardDirs to QStandardPaths… ;-)
Indeed, if you don't patch QStandardPaths ;)
>In practice, of course, porting work does get held up, sometimes for months,
>and it is possible
>(but unlikely?) for a lot of work to occur outside the 'frameworks' branch
>while it is open.
This is what has happened with most of the improvements I made to KDE4. I'm
"backporting" them one by one, slowly, and apparently hurting the feelings
(pride?) of more than 1 KDE dev doing so.
>graphics glitches in the KDE 3-to-4 port that had to be fixed. So yes, in
>this case the KF5
>version, to be released in April, will definitely be "better".
I have just had my first impressions of KDevelop5. It certainly is impressive,
but sadly not entirely in the way I had come to hope ("against better
belief"?).
There are a number of what I'll call regressions in Qt5 that are going to be
very hard to cope with, I fear, because I have no reason to believe the Qt devs
will take a position other than "you just cannot do that". For instance, I
haven't been able to get all shortcuts working in Konsole (UI shortcuts AND the
standard shell shortcuts like ^C). There's also an issue with (certain?) menu
actions (menu items in Mac jargon) which cannot be part of multiple menus where
they could in Qt4. That doesn't just lead to frequent error messages, it seems
it also leads to stability issues.
>One hope I have is that MacPorts will help us avoid the day when KDE 4 and Qt
>4 libraries are
>no longer released and apps that have not yet been ported to KF5 will just
>quietly disappear… :-(
That is only possible as long as Qt4 will build of course. We may all end up
running an antiquated OS version in a VM, crossing our thumbs that will remain
possible until the end of our days ;)
Or maybe some disgruntled peers will create the "4" equivalent to the Trinity
Desktop project (as far as that one is still alive...)
>The strategy on Linux is that an app is either KDE4 or KF5, no overlap.
> On Linux, KDE 4 libraries, Frameworks, Qt 4 and Qt 5 can co-exist, but
>that is all. Each app is either KDE 4 or KF5.
It's the same on OS X, of course. MacPorts is helped by the fact that KDE4 apps
were already installed to /Applications/MacPorts/KDE4 so it is only logical
that we'd install KF5 applications to a comparable separate directory. But
that's all just packaging.
It's actually even hard to maintain KDE4 applications in a separate subtree if
you have KF5 in the root prefix (/usr) because KF5 headers and CMake modules
are installed in such a way that it's hard to make the compiler avoid them. A
bit like with headers in /usr/local/include when building for /opt/local . I
have a hunch that situation will persist until the KDE devs realise that it
bites them too when they start working on KDE 6 ...
>I'd like to help, as long as we are just talking about KDE 4 and Qt 4 ports…
Heh, good, thanks :) What Qt4 port are you running? I hadn't yet thought of the
issues that might be caused by the sandboxed mainstream Qt4 port...
Do you use Qt5 and any Qt5 ports at all?
BTW, the easiest way to contribute to my port repository in selective fashion
might be
- check out github:RJVB/macstrop somewhere
- create an empty local port tree in a convenient separate location
- populate that tree with symlinks either to category directories in the
macstrop working copy, or with symlinks to individual port directories
That should work unless "base" refuses to consider symlinks instead of
directories, but apparently it does not do that.
>Due to continental drift (aka plate tectonics) I cannot help with that… :-)
I'd say that in your case tectonic drift can only bring us closer though in one
dimension only - in the other we'll always be about half a world away ;)
Cheers,
René
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
