Qt-contributors-summit-2014-QtCore: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
=QtCore=


==Discussion Tuesday==
* QProcess
** forkfd / spawnfd
*** Waiting for <span class="caps">QNX</span> to test spawnfd
*** Would be nice to know from a macro when <span class="caps">QNX</span> supports fork so we use forkfd instead
** adding support for multiple output, besides stdin, stdout and stderr
*** like shell: foo 3&gt; bar 4&lt;baz
*** depends on the flexible event loop
** <span class="caps">TTY</span>
*** KPtyProcess -&gt; 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 <span class="caps">QNX</span> and OS X
** Would be nice to have a QEventLoop that limits '''which''' file descriptors to poll
* <span class="caps">QIOD</span>evice with multiple channels
** like QProcess’s stdout and stderr, <span class="caps">SCTP</span>, <span class="caps">TCP</span>’s <span class="caps">OOB</span> data
* <span class="caps">QIOD</span>evice-for-Qt6
** would like to see some prototypes
** zero-copy for reading and writing
** QByteArrayRef?
* QSettings / QConfig
** KConfig, KConfigXT – tier 1
** Having an <span class="caps">API</span> based on KConfigGroup
** Idea from 2013 was to have <span class="caps">INI</span> 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
*** <span class="caps">FIPS</span> 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 <span class="caps">CLDR</span> inside Qt
** Let’s just use <span class="caps">ICU</span>! -&gt; all the usual trouble
** Minimum support: C locale, Current locale
*** <span class="caps">ICU</span> as an optional backend (dynamic loading)
*** <span class="caps">ICU</span> can be set as the only backend — default on non-<span class="caps">OSX</span> Unix builds
** Largest problem: Windows XP support (non-Vista <span class="caps">API</span>)
*** 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 <span class="caps">API</span> in Qt 5, but used internally by resources, Android assets
** Use-case comes back every now and then
** <span class="caps">VFS</span> 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 <span class="caps">API</span>, 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.

Revision as of 14:11, 25 February 2015

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.