Re: Minimal Qt version for the default branch

[John W. Eaton]

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