[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Minimal Qt version for the default branch

From: John W. Eaton
Subject: Re: Minimal Qt version for the default branch
Date: Tue, 12 Mar 2019 02:59:20 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]