[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KDE Applications December 2014 release: which apps are targeting Qt4/Qt5?
From: Todd <toddrjen () gmail ! com>
Date: 2014-07-22 9:11:38
Message-ID: CAFpSVpJxc-7bE+Edfi9TJTWrk-P4BRPwFjiCbs6msd+ReuYe1A () mail ! gmail ! com
[Download RAW message or body]
On Jul 22, 2014 12:30 AM, "Frank Reininghaus" <frank78ac@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.
[Attachment #3 (text/html)]
<p dir="ltr"><br>
On Jul 22, 2014 12:30 AM, "Frank Reininghaus" <<a \
href="mailto:frank78ac@googlemail.com">frank78ac@googlemail.com</a>> wrote:<br> \
><br> > Hi,<br>
><br>
> 2014-07-21 23:34 GMT+02:00 Albert Astals Cid:<br>
> > El Dilluns, 21 de juliol de 2014, a les 13:26:32, Frank Reininghaus va<br>
> > escriure:<br>
> >> Hello everyone,<br>
> >><br>
> >> after KDE SC 4.14, the next release of the KDE applications that \
are<br> > >> part of the KDE SC is planned for December. It will contain not \
only<br> > >> applications that are still based on Qt4+kdelibs 4.x, but \
also<br> > >> applications that have the first stable release of their \
Qt5+KF5 ports<br> > >> [1]. All application developers/maintainers can \
decide if they want to<br> > >> release another Qt4+kdelibs 4.x-based \
version, or if they want to<br> > >> release their first Qt5+KF5-based \
version.<br> > >><br>
> >> I think it would be helpful if there was a central site where<br>
> >> information about the choices that developers have taken so far is<br>
> >> collected, i.e., a place where everyone can look up quickly if<br>
> >> application XYZ will have a Qt4-based or a Qt5-based release, or if \
it<br> > >> is still in the "not decided yet" state. One of the \
reasons why I<br> > >> consider such a thing useful is that quite a few \
applications have<br> > >> runtime dependencies that are provided other \
applications. For<br> > >> example,<br>
> >><br>
> >> * Many applications have an embedded terminal, which is provided by<br>
> >> the Konsole KPart. If Konsole does not release a Qt5-based version \
in<br> > >> December, then any application which does will not have an \
embedded<br> > >> terminal any more.<br>
> >><br>
> >> * All of Konqueror's functionality is provided by KParts that \
are<br> > >> provided by libraries and applications and that are loaded at \
runtime.<br> > >> If some of these KParts will not have a Qt5-based release, \
then the<br> > >> functionality of a Qt5-based Konqueror would be severely \
limited.<br> > >><br>
> >> There are probably many more (and less obvious) examples of such<br>
> >> run-time dependencies. Releasing these Qt5-based applications \
without<br> > >> their runtime dependencies will result in feature loss, and \
I'm afraid<br> > >> that this might lead to some users, who will \
probably expect a smooth<br> > >> transition to Qt5+KF5 because they can \
read everywhere that the port<br> > >> should be much simpler than the \
Qt3->Qt4 transition was (except for<br> > >> projects which take the \
opportunity to make some other architectural<br> > >> changes at the same \
time, such as Plasma) and the media saying "It's<br> > >> the old \
KDE 4.0 story again". I think that we should try to prevent<br> > >> \
that, and I believe that a central site where everyone can look up the<br> > \
>> release plans of all applications would be helpful.<br> > >><br>
> >> I've created a draft of a wiki page where this information could \
be<br> > >> collected at<br>
> >><br>
> >> <a href="https://community.kde.org/User:Freininghaus/draft-Qt4-Qt5-appli \
cation-overvi">https://community.kde.org/User:Freininghaus/draft-Qt4-Qt5-application-overvi</a><br>
> >> ew<br>
> >><br>
> >> What do you think about this idea? If there is agreement that my \
idea<br> > >> makes sense, I would move this page to a suitable place \
(maybe<br> > >> <a \
href="https://community.kde.org/Frameworks/Application-release-status-December-201">ht \
tps://community.kde.org/Frameworks/Application-release-status-December-201</a><br> \
> >> 4 ?) and send a message to k-c-d and kde-devel, asking all<br> > \
>> maintainers/core developers to fill in any relevant information that<br> \
> >> they already have.<br> > ><br>
> > I'm not against it, having some kind of central place to coordinate \
makes<br> > > sense.<br>
> ><br>
> > OTOTH i would only expect a maintainer to port stuff to KF5 if he knows \
the<br> > > dependencies of its app are ported or are going to be ported by the \
required<br> > > timeframe<br>
><br>
> I fully agree :-)<br>
><br>
> But at the moment, there is, to my knowledge, no easy way to find out<br>
> if there will be a stable Qt5/KF5-based release of the dependencies in<br>
> December 2014. This is the reason why I proposed to collect this<br>
> information in a central place.<br>
><br>
> Note that it's *not* enough that a dependency is ported to KF5. If the<br>
> maintainer of that dependency decides that they prefer to have another<br>
> kdelibs 4.x-based release in December in order to give the KF5 port<br>
> some more time to mature, then users of most distros, which only ship<br>
> stable releases of our software unless the user explicitly enables<br>
> some extra package repositories, would still have no access to<br>
> dependency. Any KF5-based application that tries to use that<br>
> dependency at run time would lose features, and preventing that is<br>
> just what I'm trying to achieve with this effort.<br>
><br>
> Thanks and best regards,<br>
> Frank</p>
<p dir="ltr">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.<br>
</p>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic