[Development] QtCS - QtCore session

Thiago Macieira thiago.macieira at intel.com
Sun Jun 15 02:38:45 CEST 2014

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 

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 
** 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 

* 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  

* 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 

* 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 
** 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

More information about the Development mailing list