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

[Todd]

On Jul 22, 2014 12:30 AM, "Frank Reininghaus" <frank78ac at googlemail.com>
wrote:
>
> Hi,
>
> 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:
> >> Hello everyone,
> >>
> >> after KDE SC 4.14, the next release of the KDE applications that are
> >> part of the KDE SC is planned for December. It will contain not only
> >> applications that are still based on Qt4+kdelibs 4.x, but also
> >> applications that have the first stable release of their Qt5+KF5 ports
> >> [1]. All application developers/maintainers can decide if they want to
> >> release another Qt4+kdelibs 4.x-based version, or if they want to
> >> release their first Qt5+KF5-based version.
> >>
> >> I think it would be helpful if there was a central site where
> >> information about the choices that developers have taken so far is
> >> collected, i.e., a place where everyone can look up quickly if
> >> application XYZ will have a Qt4-based or a Qt5-based release, or if it
> >> is still in the "not decided yet" state. One of the reasons why I
> >> consider such a thing useful is that quite a few applications have
> >> runtime dependencies that are provided other applications. For
> >> example,
> >>
> >> * Many applications have an embedded terminal, which is provided by
> >> the Konsole KPart. If Konsole does not release a Qt5-based version in
> >> December, then any application which does will not have an embedded
> >> terminal any more.
> >>
> >> * All of Konqueror's functionality is provided by KParts that are
> >> provided by libraries and applications and that are loaded at runtime.
> >> If some of these KParts will not have a Qt5-based release, then the
> >> functionality of a Qt5-based Konqueror would be severely limited.
> >>
> >> There are probably many more (and less obvious) examples of such
> >> run-time dependencies. Releasing these Qt5-based applications without
> >> their runtime dependencies will result in feature loss, and I'm afraid
> >> that this might lead to some users, who will probably expect a smooth
> >> transition to Qt5+KF5 because they can read everywhere that the port
> >> should be much simpler than the Qt3->Qt4 transition was (except for
> >> projects which take the opportunity to make some other architectural
> >> changes at the same time, such as Plasma) and the media saying "It's
> >> the old KDE 4.0 story again". I think that we should try to prevent
> >> that, and I believe that a central site where everyone can look up the
> >> release plans of all applications would be helpful.
> >>
> >> 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".  Even if not
available by default, distros may still want to have stable ported
applications available to users as an optional alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140722/6c70f800/attachment.htm>