[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-application-ove \
rvi">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">https://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