Qt-contributors-summit-2014-QtCore

From Qt Wiki
Jump to: navigation, search
This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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.