Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
Qt-contributors-summit-2014-QtCore
Jump to navigation
Jump to 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
- forkfd / spawnfd
- 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
- replacing the implementation of the algorithms:
- 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.