We had two sessions because we ran out of time. The important discussion was again on ICU. We decided to continue using the OS API wherever possible for collation, date/time and locale support. The only OS with lacking support is actually Windows XP: for that OS to work properly, the user will have to deploy ICU. For newer Windows, the dependency will be optional.
My notes: h1. QtCore h2. Discussion Tuesday * QProcess ** forkfd / spawnfd *** Waiting for QNX to test spawnfd *** Would be nice to know from a macro when QNX supports fork so we use forkfd instead ** adding support for multiple output, besides stdin, stdout and stderr *** like shell: foo 3> bar 4<baz *** depends on the flexible event loop ** TTY *** KPtyProcess -> it's tier 2 in KF5 *** Would be nice if it were tier 1 *** will not provide in Qt *** just needs a bit of infrastructure support in QProcess * QEventLoop with restricted file descriptors ** QProcess and QtNetwork waitFor* functions do select() directly ** Interferes with out-of-band QEventDispatchers, like QNX and OS X ** Would be nice to have a QEventLoop that limits *which* file descriptors to poll * QIODevice with multiple channels ** like QProcess's stdout and stderr, SCTP, TCP's OOB data * QIODevice-for-Qt6 ** would like to see some prototypes ** zero-copy for reading and writing ** QByteArrayRef? * QSettings / QConfig ** KConfig, KConfigXT - tier 1 ** Having an API based on KConfigGroup ** Idea from 2013 was to have INI human-editable config files, with QJsonDocument binary cache ** Push notifications of changes *** Publish and subscribe *** jsondb? *** gconf, dconf, buxton, protocol buffers ** should we provide kconf_update too? or schemas that determine how to read old files? ** use of QSaveFile - different protocol for locking ** https://bugreports.qt-project.org/browse/QTBUG-28893 about QT_QSETTINGS_ALWAYS_CASE_SENSITIVE_AND_FORGET_ORIGINAL_KEY_ORDER * QCryptographicHash ** replacing the implementation of the algorithms: *** performance *** FIPS certification ** provide run-time dispatching via function pointer *** QtNetwork will install the OpenSSL hooks when it loads OpenSSL * QLocale ** We don't want to ship CLDR inside Qt ** Let's just use ICU! -> all the usual trouble ** Minimum support: C locale, Current locale *** ICU as an optional backend (dynamic loading) *** ICU can be set as the only backend -- default on non-OSX Unix builds ** Largest problem: Windows XP support (non-Vista API) *** Default build from Qt Project may not support running on XP -- requires rebuilding * C++14 macros for features ** Start using h2. Discusssion Wednesday * File engines ** Not public API in Qt 5, but used internally by resources, Android assets ** Use-case comes back every now and then ** VFS layer is required ** Maybe a full, new and pluggable I/O layer * Qt6 containers ** Maybe add a non-shared, exclusive-copy version of the containers, whose data can be std::move'd into the shared versions * QVersion * Size optimisations ** QMetaType size reductions - use only the stateful API, make the stateless call the stateful ** Feature system: not maintained by Qt Project, but patches accepted ** But we could investigate moc/rcc/qmake extra dependencies and create coarse QT_NO_xxx macros * Build options: optimisation levels / C++11 / C++14 ** Provide c++14.prf ** Enable c++14 when we can ** Suggestion: drop Visual Studio 2008 support when we start supporting VS14 * QDateTime Qt::LocalTime: ** LocalTime just returns whatever mktime/locatime says is system tz, so if system tz changes results will change without app knowing it, may be what they want, but may also cause problems ** Suggestion to optimise by caching tz offset at creation, never updating, but change in behaviour, so would need way to tell apps of any change so they can respond ** Would solve problem with ambiguous time at Daylight Time switchover, cannot be solved with system mktime calls, can be solved by using cached QTimeZone instead, probably a performance gain, but change in existing behaviour if system changes tz ** Could monitor for system tz change and signal a QEvent when does, allow user to decide policy of auto or manual update, but possibly very inefficient due to file monitoring on Linux (Windows WM_TIMECHANGE? Mac autoupdating tz?) *** Best-effort signal, which can be detected with connectNotify() *** provide testing infrastructure (mock) ** Could check system tz for change at every api call, but possibly very inefficient, back where we started ** Just live with it? ** Conclusion - Don't change behaviour, too dangerous. Time Zone change signal generally useful, implement on best efforts basis but cannot guarantee so can't use in QDateTime. Need different solution for ambiguous time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
