Re: Minimal Qt version for the default branch

[Mike Miller]

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
Description: PGP signature