Qt-contributors-summit-2014-QtCore

QtCore

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.io/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

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.