Re: [KDE/Mac] KDE4/KF5 "cohabitation"
Yeah, not expected to be. If they are that's a bonus I guess, but not expected. On Wed, Jan 13, 2016 at 2:05 PM, René J.V. wrote: > On Wednesday January 13 2016 10:53:49 Jeremy Whiting wrote: > >> Yes exactly, once an application has been released based on Qt5/KF5 it >> shouldn't be coinstallable with the same application that is >> Qt4/kdelibs4 based. Most (and eventually all) kf5 based applications > > Shouldn't, or isn't expected to be? > >> any settings. Also both kdelibs4 based and kf5 based binaries, shared >> data files etc would conflict if both were installed at once. > > The binaries are mostly not an issue under MacPorts, the shared files > sometimes a bit more, like for icon files. > But I currently have both Kate4 and Kate5, KDevelop4 and KDevelop5 installed, > idem for Kompare and Konsole (the latter is basically unusable but because of > issues in Qt). > > R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] KDE4/KF5 "cohabitation"
On Wednesday January 13 2016 10:53:49 Jeremy Whiting wrote: > Yes exactly, once an application has been released based on Qt5/KF5 it > shouldn't be coinstallable with the same application that is > Qt4/kdelibs4 based. Most (and eventually all) kf5 based applications Shouldn't, or isn't expected to be? > any settings. Also both kdelibs4 based and kf5 based binaries, shared > data files etc would conflict if both were installed at once. The binaries are mostly not an issue under MacPorts, the shared files sometimes a bit more, like for icon files. But I currently have both Kate4 and Kate5, KDevelop4 and KDevelop5 installed, idem for Kompare and Konsole (the latter is basically unusable but because of issues in Qt). R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] KDE4/KF5 "cohabitation"
Yes exactly, once an application has been released based on Qt5/KF5 it shouldn't be coinstallable with the same application that is Qt4/kdelibs4 based. Most (and eventually all) kf5 based applications include a settings/config migrator that migrates settings from kdelibs4 locations to kf5 locations if the new location doesn't have any settings. Also both kdelibs4 based and kf5 based binaries, shared data files etc would conflict if both were installed at once. On Wed, Jan 13, 2016 at 10:38 AM, René J.V. wrote: > On Thursday January 14 2016 00:54:59 ni...@macports.org wrote: > >>It is not clear to me at this point what aim you have. Are you aiming for >>full install (including applications) in parallel, or for non-conflicting >>core packages so that different applications from both KDE4 and KF5 could be >>installed ? > > I'm defining that aim as I go, basically. I'm trying to allow co-installation > of the core packages; the framework and whatever of "plasma" I'll be able to > port. As Jeremy pointed out, that is largely possible and intended because a > gradual transition has been foreseen so that KDE4 applications can function > normally "under" KF5. > As to applications: I'm not convinced that there would be much interest in > having the KDE4 and KF5 version of all applications installed. For some, like > KDevelop this can be justified for now, but for others it is probably good > enough to be able to have either the KDE4 or the KF5 version activated at any > given time. And then there is KDE PIM which shouldn't even be allowed to > co-exist: it appears that one cannot go back (without risk) after having run > the KF5 version. > Concurrent installation of the 2 "flavours" makes sense mostly if each of the > 2 flavours has advantages that the other doesn't have. > >>Which means that independently of binary compatibility, all KDE4 Portfiles >>would have to be revbumped if the change is applied. > > Yes... > >>It seems to me that the best way to get feedback would be to commit some of >>the changes, if indeed these are harmless. On the other hand, as I am under >>the impression that it is getting possible to have KF5 somewhat working >>within Macports (did not try myself), I also think that most useful thing for >>the users base at this point would be to include KF5 to Macports’ provided >>ports. > > Marko is trying out a number of KF5 ports now. It would be nice if someone > else could check the changes I've been making to KDE4 ports for side-effects > that I have missed. > > Cheers, > René > ___ > kde-...@kde.org > List Information: https://mail.kde.org/mailman/listinfo/kde-mac > KDE/Mac Information: http://community.kde.org/Mac ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] KDE4/KF5 "cohabitation"
Hey, just some suggestions.
On Wed, Jan 13, 2016 at 8:54 AM, wrote:
> Hello,
>
>> I'm sure you've noticed that I'm making progress with ports for KF5. Maybe I
>> should have asked your opinion on how to approach this (if so, apologies
>> that I didn't), but I would like to know your thoughts on the issue of
>> co-existence of KDE4 and KF5 ports.
>
> Yes, I saw the tickets you posted, and was meaning to answer for some time,
> but got swamped in other things. Furthermore, my very small knowledge of KF5
> means that I am not able to provide detailed answers.
>
>> 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 and users are not supposed to feel the need
>> to keep the older version around.
>>
>> I have some issues with that premise and know of nothing in MacPorts that
>> would make it the default behaviour to force a choice between either KDE4 or
>> KF5 versions of an application (fortunately, with all the
>> inter-dependencies).
>
> I agree that it would very appreciable to be able to install the core package
> of both KDE4 and KF5, in order to enable the installation of applications
> from both systems, in particular as several of the applications would not be
> yet ported to KF5, while others could still be better in their KF5 form.
> However, I imagine that wanting to make the whole installation in parallel
> could be much more difficult, and that the same application with its KDE4 and
> KF5 versions would conflict in several ways, as it would intend to install
> the same binaries.
>
> It is not clear to me at this point what aim you have. Are you aiming for
> full install (including applications) in parallel, or for non-conflicting
> core packages so that different applications from both KDE4 and KF5 could be
> installed ?
On linux kdelibs4 libraries and headers are coinstallable (or should
be) with kf5 versions of the same libraries and headers. Qt4 and Qt5
are also coinstallable on linux since they have different names. I'm
not sure how that works on OS X but currently on linux many of the KDE
Applications in the latest release are Qt5/KF5 based, some are still
Qt4/kdelibs4 based though and will be ported over time.
Hope that helps,
Jeremy
>
>> KF5 software doesn't leave a lot of leeway to configure it such that it
>> won't clash with KDE4 versions of the same, in line with said premise.
>> Fortunately most of the time the conflicts are limited to non-crucial things
>> in ${prefix}/share, usually even things that were not changed w.r.t. their
>> KDE4 version. So most of the time, the +kde4compat variant of a KF5 ports
>> just omits files that are already installed by the KDE4 version of the port.
>
> Does this means that executables and libraries are not conflicting? I would
> have expected them to clash with identical names.
>>
>> There are however certain modifications that have to be made to (certain)
>> KDE4 ports:
>>
>> - The most frequent conflict occurs at the level of headerfiles. This can be
>> avoided very easily by building KDELibs4 with
>> -DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers
>> under include/KDE4 but also records the path in a cmake module, so that it
>> is inherited by all dependents.
>> The nice thing is that this change doesn't break binary compatibility, so I
>> have set it unconditionally in my KDE4 PortGroup; it gets applied when a
>> port is rebuilt.
>
> Which means that independently of binary compatibility, all KDE4 Portfiles
> would have to be revbumped if the change is applied.
>
>> - CMake modules are still an issue; I haven't yet found out a good way to
>> install them to ${prefix}/lib/cmake/KDE4 . I'm looking into simply moving
>> the files to a place outside the standard cmake include path (requiring
>> CMAKE_PREFIX_PATH to be set) ... but that will only protect against file
>> name clashes and against KF5 ports picking up cmake modules from KDE4
>> software :-/
>
>> [snip
>
>>
>> This is where I could use help from others who have KDE4 ports installed,
>> the more complicated the dependencies the better.
>> There is only so much time I can devote to checking existing KDE4 ports
>> (which do not yet have a KF5 version) against the compatibility changes I've
>> been making, in addition to the time I spend developing KF5 ports.
>>
>> Help could come in 2 or 3 forms:
>> - install my KDE4 portgroup and port:kdelibs4. Check what effect that has on
>> your existing KDE4 ports; should be transparent. Check if that's still the
>> case after rebuilding them (supposing that works out OK). One set of ports
>> that I haven't rebuilt is akonadi/kdepimlibs,kdepim,kdepim-runtime because
>> those are a bit too crucial for me…
>
> It seems to me that the best way to get feedback would be to commit some of
> the changes, if indeed these are harmless. On the othe
Re: [KDE/Mac] KDE4/KF5 "cohabitation"
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
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [KDE/Mac] KDE4/KF5 "cohabitation"
Hi René and Nicolas and everybody,
On 07/01/2016, at 1:44 AM, René J.V. Bertin wrote:
> I'm sure you've noticed that I'm making progress with ports for KF5.
Yep. Good on yer, René!
And it is nice to see that David Faure and other KDE core developers are taking
an interest at last...
> 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.
It is the branch where new features are developed and bugs are fixed. A
release is "maintained"
for a few months and, during that time, bug-fixes are supposed to be backported
into the release.
> and users are not supposed to feel the need to keep the older version around.
In principle, a KF5 application, when first released, should have the same
functionality as
the KDE4 application it replaces. IIUC, the difference is supposed to be fewer
extraneous
dependencies on libraries that used to be dragged in by using kdelibs4 and some
shifting
of dependencies from KDE to Qt library classes, the most troublesome of which
is the shift
from KStandardDirs to QStandardPaths… ;-)
Porting to Frameworks and Qt 5 is done on a 'frameworks' branch of the app's
repository and
finally merged into 'master'. If that work is done quickly, there should be
few large changes
on the 'master' branch during the porting work.
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.
I have just been assisting a guy in porting KMahjongg, a KDE game. It had a
huge, years-old
branch that that ported some of the code from KDE 3 to KDE 4, but had never
been merged
into 'master.… That branch and 'master' contained a dozen or more bug fixes
and there were
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".
Hopefully, that kind of mess will be the exception rather the the rule… but
there are an awful
lot of unmaintained applications in the KDE code base these days. The
workforce is a small
fraction of the 500 or so developers KDE 4 had 5-8 years ago… :-(
> I have some issues with that premise
Having said the above, I agree entirely, René. I have, and always have had,
issues with the
idea that a newer version is automatically better...
I have experienced many regressive releases of KDE apps, some due to apps
changes and
some due to library changes --- even of my own apps, in cases where I had made
no change.
Also, if there is ever a KF5 port of KMyMoney, I would hesitate to entrust all
my finances to it
on day one… ;-) … with all due respect to Marko and the KMyMoney developers.
> and know of nothing in MacPorts that would make it the default behaviour to
> force a choice between either KDE4 or KF5 versions of an application
> (fortunately, with all the inter-dependencies).
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… :-(
On Linux, we lost a quite a few good KDE programs in the transition from KDE 3
to KDE 4.
> KF5 software doesn't leave a lot of leeway to configure it such that it won't
> clash with KDE4 versions of the same, in line with said premise. Fortunately
> most of the time the conflicts are limited to non-crucial things in
> ${prefix}/share, usually even things that were not changed w.r.t. their KDE4
> version. So most of the time, the +kde4compat variant of a KF5 ports just
> omits files that are already installed by the KDE4 version of the port.
The strategy on Linux is that an app is either KDE4 or KF5, no overlap. Apps
and the Frameworks
library are released separately, on different schedules. See
https://techbase.kde.org/Schedules …
Apps are released in KDE Applications YY.MM releases every four months and can
be a mix of
KDE 4 and KF5 apps. 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 would be very nice if MacPorts could be more flexible than that.
> There are however certain modifications that have to be made to (certain)
> KDE4 ports:
>
> - The most frequent conflict occurs at the level of headerfiles. This can be
> avoided very easily by building KDELibs4 with
> -DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers
> under include/KDE4 but also records the path in a cmake module, so that it is
> inherited by all dependents.
> The nice thing is that this change doesn't break binary compatibility, so I
> have set it unconditionall
