[Development] QtCS - QtCore session

[Thiago Macieira]

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