Difference between revisions of "Qt-contributors-summit-2013-QtCore CS 2013"

From Qt Wiki
Jump to: navigation, search
m (Categorize)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
 +
[[Category:QtCS2013]]
 
=QtCore notes from Qt Contributor Summit 2013=
 
=QtCore notes from Qt Contributor Summit 2013=
  
Line 5: Line 7:
 
* QFileSelector:<br /> 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.
 
* QFileSelector:<br /> 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 &amp; kernel
+
* 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 <span class="caps">RTTI</span>? use typeids? boost::any? Request type name for C++14? -&gt; need to do research. SKelly: Also: What does <span class="caps">QML</span> etc. need? They forked some things from QMetaType. Thiago: V4 will remove some of the hacks, needs investigation. in future: make sure <span class="caps">QML</span> stays close to main line.
+
** 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 <span class="caps">RTTI</span>? use typeids? boost::any? Request type name for C++14? -> need to do research. SKelly: Also: What does <span class="caps">QML</span> etc. need? They forked some things from QMetaType. Thiago: V4 will remove some of the hacks, needs investigation. in future: make sure <span class="caps">QML</span> stays close to main line.
  
* Extending the new connection syntax to other uses<br /><span class="caps">API</span>s taking a const *, inconsisencies -&gt; 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.
+
* Extending the new connection syntax to other uses<br /><span class="caps">API</span>s 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<br /> 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).<br /> 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: <span class="caps">OOM</span> situations, save users work and prevent data loss. moving there also costs performance. (xmlpatterns is using exceptions, qtconcurrent has exceptions as well). -&gt; Qt 6: revisit containers properly.
+
* Exception-safety for tool classes<br /> 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).<br /> 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: <span class="caps">OOM</span> 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 &amp; Time-zone support<br /> jlayt: formatters for numbers etc. working. date &amp; time formatting: classes are just wrappers around <span class="caps">ICU</span> on Mac, Windows: they may not support stuff, what about the other platforms?. thiago: question: continue with <span class="caps">ICU</span>? fgladhorn: maybe start with <span class="caps">ICU</span> on new platforms and write own backends if needed. If we want to get rid of <span class="caps">ICU</span>, we need other stuff on Windows.
+
* Calendaring & Time-zone support<br /> jlayt: formatters for numbers etc. working. date & time formatting: classes are just wrappers around <span class="caps">ICU</span> on Mac, Windows: they may not support stuff, what about the other platforms?. thiago: question: continue with <span class="caps">ICU</span>? fgladhorn: maybe start with <span class="caps">ICU</span> on new platforms and write own backends if needed. If we want to get rid of <span class="caps">ICU</span>, we need other stuff on Windows.
  
* Unicode &amp; <span class="caps">ICU</span> → separate session
+
* Unicode & <span class="caps">ICU</span> → separate session
  
 
* Threading
 
* Threading
Line 20: Line 22:
 
** Improving the <span class="caps">API</span><br /> 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 <span class="caps">API</span>. 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.
 
** Improving the <span class="caps">API</span><br /> 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 <span class="caps">API</span>. 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<br /> 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).
+
* QCommandLineParser<br /> 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<br /> 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.
 
* Logging with categories<br /> 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<br /> 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.
+
* "Natural compare" of strings<br /> 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<br /> might fit into QCryptographicHash, if not: discuss export restrictions.
 
* Password hashing in QtCore<br /> might fit into QCryptographicHash, if not: discuss export restrictions.

Latest revision as of 17:30, 6 January 2017

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.