Minimal Qt version for the default branch

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Minimal Qt version for the default branch

Torsten-3
During preparation of the 5.1 release, some discussions came up whether
to drop Qt4 support afterwards. Actually, some planned bug fixes (e.g.,
bug #55855, based on bug #55822) would require Qt5.

Do we agree on dropping Qt4 support and requiring Qt5 (e.g., 5.4) for
building octave on the default branch?

Torsten





Reply | Threaded
Open this post in threaded view
|

Re: Minimal Qt version for the default branch

Mike Miller-4
On Sat, Mar 09, 2019 at 12:03:46 +0100, Torsten wrote:
> During preparation of the 5.1 release, some discussions came up whether
> to drop Qt4 support afterwards. Actually, some planned bug fixes (e.g.,
> bug #55855, based on bug #55822) would require Qt5.
>
> Do we agree on dropping Qt4 support and requiring Qt5 (e.g., 5.4) for
> building octave on the default branch?

I would like to drop support for Qt 4 on the default branch.

I would also be fine with requiring Qt 5.6 or newer. Qt 5.6 is the
oldest LTS still supported by Qt (end-of-life is March 2019 actually),
it was released in March 2016. But some Ubuntu users may want us to keep
supporting Qt 5.5 if possible.

IMHO, as far as implementation, I think we should *not* have configure
do a hard version check, but we could have a feature test that requires
the newest feature that we actually use (like QStandardPaths), and
delete all older feature tests and conditionals.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Minimal Qt version for the default branch

John W. Eaton
Administrator
On 3/9/19 2:00 PM, Mike Miller wrote:
> On Sat, Mar 09, 2019 at 12:03:46 +0100, Torsten wrote:
>> During preparation of the 5.1 release, some discussions came up whether
>> to drop Qt4 support afterwards. Actually, some planned bug fixes (e.g.,
>> bug #55855, based on bug #55822) would require Qt5.
>>
>> Do we agree on dropping Qt4 support and requiring Qt5 (e.g., 5.4) for
>> building octave on the default branch?
>
> I would like to drop support for Qt 4 on the default branch.

I'm OK with this.  I built with Qt 4 (4:4.8.7+dfsg-17) today and here is
the list of feature test results:

checking for QAbstractItemModel::beginResetModel in
<QAbstractItemModel>... yes
checking QStandardPaths usability... no
checking QStandardPaths presence... no
checking for QStandardPaths... no
checking for QGuiApplication::setDesktopFileName... no
checking for QHeaderView::setSectionResizeMode... no
checking for QHeaderView::setSectionsClickable... no
checking for QHeaderView::setSectionsMovable... no
checking for QHelpSearchQueryWidget::searchInput... no
checking for qInstallMessageHandler... no
checking for QLineEdit::setPlaceholderText in <QLinedEdit>... yes
checking for QMouseEvent::localPos... no
checking whether QObject::findChildren accepts Qt::FindChildOptions... no
checking for QScreen::devicePixelRatio in <QScreen>... no
checking for QTabWidget::setMovable in <QTabWidget>... yes
checking whether Qt message handler accepts QMessageLogContext... no
checking for QFont::ForceIntegerMetrics in <QFont>... yes
checking for QFont::Monospace in <QFont>... yes
checking for QGuiApplication... no
checking QOpenGLWidget usability... no
checking QOpenGLWidget presence... no
checking for QOpenGLWidget... no
checking QGLWidget usability... yes
checking QGLWidget presence... yes
checking for QGLWidget... yes
checking QGLFunctions_1_1 usability... no
checking QGLFunctions_1_1 presence... no
checking for QGLFunctions_1_1... no
checking whether Qt works with OpenGL and GLU... yes
checking QOffscreenSurface usability... no
checking QOffscreenSurface presence... no
checking for QOffscreenSurface... no
checking whether Qt supports full offscreen OpenGL rendering... no

That's a big list of missing features and problems to work around.  It
would be nice to simplify things.  But what is the real loss of
functionality and the cost of continuing to keep these conditionals in
the code?  I'd say not having off-screen rendering is pretty big.  As
for the development cost, are we constantly hitting things that break
with Qt 4 and we have to spend a lot of time working around the
problems?  If that's the case, then I'd say we should drop support.  But
if it is just that the old code adds some clutter, then I wouldn't
necessarily rush to delete it.

> I would also be fine with requiring Qt 5.6 or newer. Qt 5.6 is the
> oldest LTS still supported by Qt (end-of-life is March 2019 actually),
> it was released in March 2016. But some Ubuntu users may want us to keep
> supporting Qt 5.5 if possible.

What does the output for the list of tests above look like for Qt 5.5?

> IMHO, as far as implementation, I think we should *not* have configure
> do a hard version check, but we could have a feature test that requires
> the newest feature that we actually use (like QStandardPaths), and
> delete all older feature tests and conditionals.

If we do decide to drop support for old versions, then I agree that we
should not have a version check.  It sounds like you are proposing that
if we don't find QStandardPaths, then we should disable the GUI.  Is
that correct?  Is that feature absolutely necessary?  Is it difficult to
work around if it is missing?  If not, then maybe we should pick a
feature that we don't really have any work around for, like
QOffscrenSurface?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Minimal Qt version for the default branch

Mike Miller-4
On Tue, Mar 12, 2019 at 02:59:20 -0400, John W. Eaton wrote:

> I'm OK with this.  I built with Qt 4 (4:4.8.7+dfsg-17) today and here is the
> list of feature test results:
>
> checking for QAbstractItemModel::beginResetModel in <QAbstractItemModel>...
> yes
> checking QStandardPaths usability... no
> checking QStandardPaths presence... no
> checking for QStandardPaths... no
> checking for QGuiApplication::setDesktopFileName... no
> checking for QHeaderView::setSectionResizeMode... no
> checking for QHeaderView::setSectionsClickable... no
> checking for QHeaderView::setSectionsMovable... no
> checking for QHelpSearchQueryWidget::searchInput... no
> checking for qInstallMessageHandler... no
> checking for QLineEdit::setPlaceholderText in <QLinedEdit>... yes
> checking for QMouseEvent::localPos... no
> checking whether QObject::findChildren accepts Qt::FindChildOptions... no
> checking for QScreen::devicePixelRatio in <QScreen>... no
> checking for QTabWidget::setMovable in <QTabWidget>... yes
> checking whether Qt message handler accepts QMessageLogContext... no
> checking for QFont::ForceIntegerMetrics in <QFont>... yes
> checking for QFont::Monospace in <QFont>... yes
> checking for QGuiApplication... no
> checking QOpenGLWidget usability... no
> checking QOpenGLWidget presence... no
> checking for QOpenGLWidget... no
> checking QGLWidget usability... yes
> checking QGLWidget presence... yes
> checking for QGLWidget... yes
> checking QGLFunctions_1_1 usability... no
> checking QGLFunctions_1_1 presence... no
> checking for QGLFunctions_1_1... no
> checking whether Qt works with OpenGL and GLU... yes
> checking QOffscreenSurface usability... no
> checking QOffscreenSurface presence... no
> checking for QOffscreenSurface... no
> checking whether Qt supports full offscreen OpenGL rendering... no
>
> That's a big list of missing features and problems to work around.  It would
> be nice to simplify things.  But what is the real loss of functionality and
> the cost of continuing to keep these conditionals in the code?  I'd say not
> having off-screen rendering is pretty big.  As for the development cost, are
> we constantly hitting things that break with Qt 4 and we have to spend a lot
> of time working around the problems?  If that's the case, then I'd say we
> should drop support.  But if it is just that the old code adds some clutter,
> then I wouldn't necessarily rush to delete it.
Thanks for the feedback and the perspective. I agree it might be nice to
look at this feature test list as a good first step in identifying
things that can be simplified.

> What does the output for the list of tests above look like for Qt 5.5?

I'll try to find that out, maybe for a handful of different Qt 5
versions for comparison.

> If we do decide to drop support for old versions, then I agree that we
> should not have a version check.  It sounds like you are proposing that if
> we don't find QStandardPaths, then we should disable the GUI.  Is that
> correct?  Is that feature absolutely necessary?  Is it difficult to work
> around if it is missing?  If not, then maybe we should pick a feature that
> we don't really have any work around for, like QOffscrenSurface?

Yeah, the existence of one enum in QStandardPaths is something we can
easily work around.

As you saw in bug #55883, the logic around QtOpenGL vs QOpenGLWidget is
getting very confusing. This only affects libgui/graphics, but how about
making QOpenGLWidget and QOffscreenSurface hard requirements and
dropping support for deprecated QtOpenGL as a first simplification?

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Minimal Qt version for the default branch

John W. Eaton
Administrator
On 3/12/19 12:51 PM, Mike Miller wrote:

>> What does the output for the list of tests above look like for Qt 5.5?
>
> I'll try to find that out, maybe for a handful of different Qt 5
> versions for comparison.

OK.  BTW, for 5.12, the only ones that fail for me are:

checking QGLWidget usability... no
checking QGLWidget presence... no
checking for QGLWidget... no
checking QGLFunctions_1_1 usability... no
checking QGLFunctions_1_1 presence... no
checking for QGLFunctions_1_1... no

but I think that's because these tests are done without the Qt5OpenGL
module.  So that's another error in the current configure tests that we
could eliminate more easily if we could simplify things.

> Yeah, the existence of one enum in QStandardPaths is something we can
> easily work around.
>
> As you saw in bug #55883, the logic around QtOpenGL vs QOpenGLWidget is
> getting very confusing.

Yes, definitely.  And the more confusing, the more time wasted and the
more fragile these checks tend to become.  After this experience, I'm
leaning much more toward dropping support for Qt4.

> This only affects libgui/graphics, but how about
> making QOpenGLWidget and QOffscreenSurface hard requirements and
> dropping support for deprecated QtOpenGL as a first simplification?

Are you saying still support Qt4 for the main GUI but if QOpenGLWidget
and QOffscreenSurface are not available, then disable the Qt plotting
widget?

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Minimal Qt version for the default branch

Mike Miller-4
On Tue, Mar 12, 2019 at 13:02:26 -0400, John W. Eaton wrote:
> Are you saying still support Qt4 for the main GUI but if QOpenGLWidget and
> QOffscreenSurface are not available, then disable the Qt plotting widget?

That was just one example of a big simplification that has a very
practical benefit. I was saying we could do that. But dropping Qt 4
conditional logic from configure is yet another big practical benefit. I
think we should do both.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Minimal Qt version for the default branch

John W. Eaton
Administrator
On 3/12/19 1:14 PM, Mike Miller wrote:
> On Tue, Mar 12, 2019 at 13:02:26 -0400, John W. Eaton wrote:
>> Are you saying still support Qt4 for the main GUI but if QOpenGLWidget and
>> QOffscreenSurface are not available, then disable the Qt plotting widget?
>
> That was just one example of a big simplification that has a very
> practical benefit. I was saying we could do that. But dropping Qt 4
> conditional logic from configure is yet another big practical benefit. I
> think we should do both.

Yeah, I would rather drop the version 4/5 logic rather than just go
halfway and try to eliminate the QtOpenGL module while still supporting
Qt4 for the main GUI.  Trying to accommodate both versions adds a lot to
the complexity, especially on systems that might have both (maybe
partially) installed.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Minimal Qt version for the default branch

Mike Miller-4
In reply to this post by John W. Eaton
On Tue, Mar 12, 2019 at 13:02:26 -0400, John W. Eaton wrote:
> On 3/12/19 12:51 PM, Mike Miller wrote:
>
> > > What does the output for the list of tests above look like for Qt 5.5?
> >
> > I'll try to find that out, maybe for a handful of different Qt 5
> > versions for comparison.
>
> OK.  BTW, for 5.12, the only ones that fail for me are:

I compiled a table of configure feature test results for various
versions of Qt available on Debian and Ubuntu stable releases, and
included your 4.8.7 results. I hope this is useful:

  https://gitlab.com/snippets/1834909

I didn't have a Qt 5.4 readily available, but you can see that 5.5 is
the first Qt version with QOpenGLWidget and QOpenGLContext for working
offscreen rendering. I expect the same results with 5.4.

If we drop checking for Qt 4 (only look for Qt5Core, not QtCore), and
drop checking for QGLWidget (only look for QOpenGLWidget and require
that for AMCOND_BUILD_QT_GRAPHICS), the table shows that would eliminate
the need for more than half of these feature tests.

If we come to a consensus on this I am happy to do the work and/or test
this big change, and I now have test environments set up for each of
these Qt versions.

--
mike

signature.asc (849 bytes) Download Attachment