[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-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-Decemb \
er-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