|
|
| 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> bar 4<baz
| |
| *** depends on the flexible event loop
| |
| ** <span class="caps">TTY</span>
| |
| *** 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 <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>! -> 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.
| |