KDE Applications December 2014 release: which apps are targeting Qt4/Qt5?

[Frank Reininghaus]

Hi,

2014-07-22 11:11 GMT+02:00 Todd:
> On Jul 22, 2014 12:30 AM, "Frank Reininghaus" wrote:
>> 2014-07-21 23:34 GMT+02:00 Albert Astals Cid:
>> > El Dilluns, 21 de juliol de 2014, a les 13:26:32, Frank Reininghaus va
>> > escriure:
[...]
>> >> I've created a draft of a wiki page where this information could be
>> >> collected at
>> >>
>> >>
>> >> https://community.kde.org/User:Freininghaus/draft-Qt4-Qt5-application-overvi
>> >> ew
>> >>
>> >> What do you think about this idea? If there is agreement that my idea
>> >> makes sense, I would move this page to a suitable place (maybe
>> >>
>> >> https://community.kde.org/Frameworks/Application-release-status-December-201
>> >> 4 ?) and send a message to k-c-d and kde-devel, asking all
>> >> maintainers/core developers to fill in any relevant information that
>> >> they already have.
>> >
>> > I'm not against it, having some kind of central place to coordinate
>> > makes
>> > sense.
>> >
>> > OTOTH i would only expect a maintainer to port stuff to KF5 if he knows
>> > the
>> > dependencies of its app are ported or are going to be ported by the
>> > required
>> > timeframe
>>
>> I fully agree :-)
>>
>> But at the moment, there is, to my knowledge, no easy way to find out
>> if there will be a stable Qt5/KF5-based release of the dependencies in
>> December 2014. This is the reason why I proposed to collect this
>> information in a central place.
>>
>> Note that it's *not* enough that a dependency is ported to KF5. If the
>> maintainer of that dependency decides that they prefer to have another
>> kdelibs 4.x-based release in December in order to give the KF5 port
>> some more time to mature, then users of most distros, which only ship
>> stable releases of our software unless the user explicitly enables
>> some extra package repositories, would still have no access to
>> dependency. Any KF5-based application that tries to use that
>> dependency at run time would lose features, and preventing that is
>> just what I'm trying to achieve with this effort.
>>
>> Thanks and best regards,
>> Frank
>
> Maybe the list could have multiple levels, such as "not ported", "unstable",
> "not feature-complete", "waiting", and "included".

I don't think that such a fine-grained list will make solving the
problem easier. Maybe it would even cause confusion - at least I am
not sure what all of these levels really mean.

> Even if not available by
> default, distros may still want to have stable ported applications available
> to users as an optional alternative.

I guess I have not made it clear yet what problem I am trying to solve here :-(

Let me try to explain it in more detail: some distros which will have
a release in the first half of 2015 will probably ship Plasma 5 as
their desktop. Additionally, they will most likely package the KDE
applications which are released in December 2014. Some of these will
be based on KF5, others on kdelibs 4.x. This will not matter much to
most users, provided the applications work at least as good as in the
previous release of their distro.

Dolphin is an example of an application which has a KF5 port (many
thanks to Alexander Richardson for doing the port!) that mostly works
well already. At run time, it uses parts of other applications which
also have a 'frameworks' branch already, in particular the Konsole
KPart which provides the terminal panel. This works fine for everyone
who builds KF5+applications from checkouts of the git repositories.
However, on the systems of our users (in particular those who only use
the packages and repositories which their distro enables by default),
something different might happen: if Dolphin decides to ship a stable
"Dolphin 5.0" release in December, but Konsole decides to give the
frameworks branch some more time to mature and ship a final kdelibs
4.x-based release in December, then the following happens:

The packagers download all KDE appliations tarballs which are released
in December 2014, build each of them against Qt4+kdelibs 4.x or
Qt5+KF5, and ship the final results to their users. No problems or
even errors will be reported at build time, but when the user tries to
show the Terminal Panel in Dolphin, nothing happens because the
KF5-based Dolphin executable cannot use the kdelibs 4.x-based Konsole
KPart. This would result in a very poor KDE user experience, and this
is what I am trying to prevent.

The best way to prevent this kind of problem is that the maintainers
of applications like Dolphin consider shipping a KF5-based release in
December only if they know that all build-time AND run-time
dependencies will also have a stable KF5-based release then. However,
to my knowledge, there is currently no good way to find out which
applications will go the KF5-way in December, and which won't. I could
of course send a message to the Konsole mailing list and ask (and do
the same for a few more dependencies), but since many applications
will have the same or very similar questions concerning their run-time
dependencies, I thought that collecting this information on a central
wiki page might be a good idea.

I hope that this was clearer now ;-)

Regards,
Frank