Qt-contributors-summit-2013-QtCore CS 2013

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 notes from Qt Contributor Summit 2013

Topics to be discussed:

• QFileSelector:
  needs to be discussed with Alan (need to wait for Alan explaining the use case together with Plasma guys), use case: load Android specific file etc.

• QObject, meta-object & kernel
  • meta types: mostly stable, some minor issues. Jendrek made stuff more generic for 5.1 (eliminating case switches in QVariant internals). Thiago: we need to remove static meta data, continue with stateful meta data, also need to investigate what to do further with meta types: Can we rely on RTTI? use typeids? boost::any? Request type name for C++14? -> need to do research. SKelly: Also: What does QML etc. need? They forked some things from QMetaType. Thiago: V4 will remove some of the hacks, needs investigation. in future: make sure QML stays close to main line.

• Extending the new connection syntax to other uses
  APIs taking a const *, inconsisencies -> generalize new connection syntax. Thiago: 5.2 going forward: c++11 standard functions, if you don't have c++11: bad luck, for C++98: leave as it is. skelly interested.

• Exception-safety for tool classes
  tried to promise our tools classes are exception safe. right now: QtCore is built with exceptions, throwing exceptions from a slot will crash. 2 stages: 1. minimal exception safety: don't crash. 2. exception safe: roll back to previous stage. anybody interested in exception safety of the tools classes? jendrek: tried to improve QVector, and no agreement that it should be exception safe. QArray* are exception safe, code is just not finished. Also need to look into QMap, QHash, QList… main problem: do we care? implementing that would be challenging c++. (nobody volunteers).
  some methods are not possible to make exception safe. take() might always throw an exception, std::library equivalents should be exception safe. implicit sharing makes it hard to make it exception safe. Needs verification. Maybe say containers are not exception safe? Need to investigate whether that is achievable. main use case: OOM situations, save users work and prevent data loss. moving there also costs performance. (xmlpatterns is using exceptions, qtconcurrent has exceptions as well). -> Qt 6: revisit containers properly.

• Calendaring & Time-zone support
  jlayt: formatters for numbers etc. working. date & time formatting: classes are just wrappers around ICU on Mac, Windows: they may not support stuff, what about the other platforms?. thiago: question: continue with ICU? fgladhorn: maybe start with ICU on new platforms and write own backends if needed. If we want to get rid of ICU, we need other stuff on Windows.

• Unicode & ICU → separate session

• Threading
  • Replacing QtConcurrent
  • Improving the API
    the only wait to do threading is to derive from it, at one point we said do not subclass QThread. right now requires a lot of boilerplate: start QThread, move object to thread etc. dfaure: make QThread member of object, thiago: std::thread gives a function which you pass a functor. Thiago: need the same thing in Qt: start an object, start a functor. dfaure: with functor there is no object to connect to. research is being done. returning QThread, QFuture. richmoore: needs to fit into QTimer API. thiago: 1st fix QTimer problem. 5.2: need thread discussion. dfreddi: has ideas of how to connect to functor and give meaningful context. thiago: 1st figure out QTimer single shot problem, harmonise QObject connect etc., next: move on to doing the threading. dfreddi: user will need to do something like QtConcurrent::run(), thiago: extend it with associate with thread pool. solution: need to figure out what best practice is. in 5.2: fix QObject::connect, QTimer, maybe 5.3. dfreddi: have a factory for passing to QThread. also need to fix the documentation.

• QCommandLineParser
  ported all of kdelibs to it. could port tooling to it to test it, thiago: we could deprecate old use. dfaure: also supports "-feature". also other tools have tried it out (qpath).

• Logging with categories
  forgot for 5.1., person working on it not worked on anymore, need to take it out and extend QLogging class again. dfaure: should it be in QtCore or a seperate module? thiago: belongs in QtCore, unless you make it a monster. might want a new QSettings as well, looks like a lot of work for 5.2. start with categorizing, configure later.

• "Natural compare" of strings
  exists in QtCollate. dfaure: doesn't have all the features, natural ordering of numbers etc., needs investigating. dfaure: code that does that is private, in QFileSystemModel, might extend QtCollate.

• Password hashing in QtCore
  might fit into QCryptographicHash, if not: discuss export restrictions.