Re: [Development] Contribute to the Qt
Hi Edi, On Friday 24 July 2015 05:11:40 Edi Anderson wrote: > I have time available and just need > someone to tell me what to do and how to start. Andrew told you already how to start. As for what to do: Where do your interests lie? Would you like to work on a new feature you have in mind? You could browse bugreports.qt.io for enhancements from users that pique your interest. Or do you want to optimize some exisiting code? Or do you want to help improve the C++11 support in Qt? Or... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribute to the Qt
Hi Edi, On 07/24/2015 06:11 AM, Edi Anderson wrote: > Hello guys I'm a programmer and would like to gain more experience in large > projects, so I would contribute to Qt. That's wonderful; welcome to the Qt Project! > I have time available and just need > someone to tell me what to do and how to start. Can someone help me ?. I can try. You should first read http://wiki.qt.io/Contribute and http://www.qt.io/contribute/ To get the most out of your experience, join #qt-labs on IRC and pitch in to the discussion. Once you have some code to contribute, push it to code review (http://wiki.qt.io/Gerrit_Introduction) and start adding reviewers. Git log/blame to find out who to add as a reviewer, or otherwise ask in IRC about who might be able to help. We look forward to your code :-) > And > sorry for bad English, I began to study English in three months. No need to apologize. Perfect English is the exception to the rule around these parts ;-) Cheers, Andrew > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Contribute to the Qt
Hello guys I'm a programmer and would like to gain more experience in large projects, so I would contribute to Qt. I have time available and just need someone to tell me what to do and how to start. Can someone help me ?. And sorry for bad English, I began to study English in three months. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] MSVC2015 and Qt5.5 -- dot release plans?
On Thursday 23 July 2015 07:09:05 Tom Isaacson wrote: > > I don't know whether we'll be able to produce binaries for it for 5.5.1. > > That depends on how soon we can bring it up in the old CI. > Any idea when 5.5.1 is due now? The Wiki says the original date was > September but will this be pushed out? https://wiki.qt.io/Qt-5.5-release I don't see any reason why it would be pushed out. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 23 July 2015 19:22:46 Marc Mutz wrote: > I believe we should strive to have the LTS release warning-free in this > regard. It's going to be in use for a long time, and the demand for nullptr- > correctness will only grow with time. Agreed. I'd say go ahead with cleaning up zero-as-null in public headers and then add it to headersclean. For 5.7, we can do s/Q_NULLPTR/nullptr/g. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is QFutureInterface internal like the other d-pointer classes?
On Thursday 23 July 2015 16:34:40 Lorenz Haas wrote: > 2015-07-23 13:20 GMT+02:00 Marc Mutz : > > It's undocumented, and considered private, but since it's a template and > > thus must be visible, it effectively is public API and falls under the > > same restrictions for changes as public API. IOW: it cannot change > > (incompatibly) until Qt 6. > > > > If you're fine with that, go ahead and use it in your code. > > Thanks for the clarification. > > Are there any plans to make QFuture/QFutureInterface (completely) > public in Qt 6 as a Qt counterpart to std::future/std::promise? There are no plans on either way. We'll probably have to decide on std::future when we get to Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 23 July 2015 15:47:10 Knoll Lars wrote: > On 23/07/15 14:23, "Marc Mutz" wrote: > >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > >> * Q_NULLPTR - strongly encouraged > > > >Ok, trying to summarize the discussion so we can move forward. > > > >There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about > >Qt > >headers not compiling with -Wzero-as-null-pointer-constant, sometimes not > >even > >when locking the Qt headers away behind an -isystem. I understood the > >discussion in this thread as follows: > > > >- ok to use Q_NULLPTR in public headers (the bug report suggests that this > > > > should actually be enforced by headersclean). > > > >- ok to use in new code or as a drive-by iff the 0 isn't immediately > >visible > > > > as a nullptr. Example: > > validator(0), // Q_NULLPTR ok here > > > > Counter-example: > > const char *msg = 0 // Q_NULLPTR not wanted here > > > >- otherwise, we don't want Q_NULLPTR. We're waiting until we can move > >directly > > > > to nullptr. In particular, we cannot use Q_NULLPTR for its potentially > > disambiguating characteristics, until we require C++11 nullptr. So code > > > >must > > > > still compile (modulo warnings) (and have the same meaning) if the > > > >Q_NULLPTR > > > > is replaced back to 0. > > > >Consensus? > > Mostly. But it looks like VS 2012 support nullptr, so I’d say we wait for > 5.6 to be branched. After that we should globally get rid of Q_NULLPTR. > i.e. Do a search and replace Q_NULLPTR -> nullptr in our code base. Then > IMO the first two rules above should be taken into use with > s/Q_NULLPTR/nullptr/. I believe we should strive to have the LTS release warning-free in this regard. It's going to be in use for a long time, and the demand for nullptr- correctness will only grow with time. Otherwise, I agree. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-07-23 08:23, Marc Mutz wrote: > On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_NULLPTR - strongly encouraged > > Ok, trying to summarize the discussion so we can move forward. > > There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about Qt > headers not compiling with -Wzero-as-null-pointer-constant, sometimes not > even > when locking the Qt headers away behind an -isystem. I understood the > discussion in this thread as follows: > > - ok to use Q_NULLPTR in public headers (the bug report suggests that this > should actually be enforced by headersclean). The bug reporter would appreciate that, yes :-). Especially in macros (e.g. Q_OBJECT¹) and default parameter values. (The reporter would also appreciate https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486 getting fixed, but that doesn't seem likely to happen any time soon :-(. And no, I'm not asking Qt to fix GCC bugs; just mentioning it because it is pertinent.) (¹ Pedantic: the original report indicates that the problem in Q_OBJECT is indirect, via QT_TR_FUNCTIONS. IIRC in 4.8.x there are a lot more such issues in Q_OBJECT, most of which have been fixed by now. Also, QT_TR_FUNCTIONS may be fixed already in 5.5; I haven't checked yet.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is QFutureInterface internal like the other d-pointer classes?
2015-07-23 13:20 GMT+02:00 Marc Mutz : > It's undocumented, and considered private, but since it's a template and thus > must be visible, it effectively is public API and falls under the same > restrictions for changes as public API. IOW: it cannot change (incompatibly) > until Qt 6. > > If you're fine with that, go ahead and use it in your code. Thanks for the clarification. Are there any plans to make QFuture/QFutureInterface (completely) public in Qt 6 as a Qt counterpart to std::future/std::promise? Lorenz ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 14:27, "Marc Mutz" wrote: >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > >- Required to be used consistently within a class, because Clang warns be > default if one function has override and another doesn't. >- Even add to old code. The benefits outweigh the git history churn. > >Consensus? Yes, but again, I’d propose we wait until 5.6 is branched and then start using the keyword directly, not the macro. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 14:27, "Marc Mutz" wrote: >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > >- Required to be used consistently within a class, because Clang warns be > default if one function has override and another doesn't. >- Even add to old code. The benefits outweigh the git history churn. > >Consensus? > >Thanks, >Marc > >-- >Marc Mutz | Senior Software Engineer >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >Tel: +49-30-521325470 >KDAB - The Qt Experts >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 14:23, "Marc Mutz" wrote: >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_NULLPTR - strongly encouraged > >Ok, trying to summarize the discussion so we can move forward. > >There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about >Qt >headers not compiling with -Wzero-as-null-pointer-constant, sometimes not >even >when locking the Qt headers away behind an -isystem. I understood the >discussion in this thread as follows: > >- ok to use Q_NULLPTR in public headers (the bug report suggests that this > should actually be enforced by headersclean). >- ok to use in new code or as a drive-by iff the 0 isn't immediately >visible > as a nullptr. Example: > validator(0), // Q_NULLPTR ok here > Counter-example: > const char *msg = 0 // Q_NULLPTR not wanted here >- otherwise, we don't want Q_NULLPTR. We're waiting until we can move >directly > to nullptr. In particular, we cannot use Q_NULLPTR for its potentially > disambiguating characteristics, until we require C++11 nullptr. So code >must > still compile (modulo warnings) (and have the same meaning) if the >Q_NULLPTR > is replaced back to 0. > >Consensus? Mostly. But it looks like VS 2012 support nullptr, so I’d say we wait for 5.6 to be branched. After that we should globally get rid of Q_NULLPTR. i.e. Do a search and replace Q_NULLPTR -> nullptr in our code base. Then IMO the first two rules above should be taken into use with s/Q_NULLPTR/nullptr/. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Sérgio Martins for Approver status
On 21 Jul 2015, at 13:27, Giuseppe D'Angelo wrote: > Hi, > > I'd like to nominate Sérgio Martins for the Approver status in the Qt project. > > In the last years Sérgio has pushed lots of patches in a number of > components: he worked on the QNX/BB platform plugin, on sensors support in > QtMobility for BB10, on Windows and Windows CE features and bugfixes, on the > addition of the qmllint tool; these days he's very active doing various > optimizations throughout the entirety of the Qt code base. > > You can find his work on Gerrit here: > >> https://codereview.qt-project.org/#/q/owner:%22S%25C3%25A9rgio+Martins+%253Csergio.martins%2540kdab.com%253E%22,n,z > > Would anyone like to second? +1 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
> Non-C++11 but also useful:
>
> * Q_DECL_{PURE,CONST}_FUNCTION - encouraged
>
> A pure function is a function that will return the same value if called
> twice with the same parameters. Pure functions are allowed to read from
> pointers passed to it, including the "this" pointer. Pure functions are
> not allowed to have observable side-effects (rule of thumb: no writing to
> dereferenced pointers or to global variables).
>
> A const function is a function that is pure and does not dereference any
> pointers.
>
> Quite by definition, const and pure functions cannot return void. Any such
> calls would be discarded by the compiler.
Consensus, I think? Esp. useful for out-of-line qHash(), e.g.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_DECL_NOTHROW / Q_DECL_NOEXCEPT - strongly encouraged > > To public functions (all modules); any function in modules compiled with > exception (QtCore, QtXmlPatterns, QtConcurrent). > > You probably want Q_DECL_NOTHROW instead of Q_DECL_NOEXCEPT. > > Do not add to functions that: > * allocate memory > * call functions that may throw, especially user functions > * call POSIX cancellation points > * have narrow contracts -- that is, you could conceivably add a Q_ASSERT > on input parameters > > If the function is an inline template function and the exception depends > on the template argument, use Q_DECL_NOEXCEPT_EXPR. Consensus, I think? I'd add that having a nothrow move ctor and move assignment operator is a very important optimisation for std::vector. User-defined copy ctors and copy assignment operators, but also a user-defined dtors (even if empty) inhibit the synthesising of move special member functions by the compiler, so remove them when you can or manually add the move special member functions, preferably with Q_DECL_NOTHROW / Q_DECL_NOEXCEPT_EXPR. Example changes for both situations: https://codereview.qt-project.org/121833 https://codereview.qt-project.org/121824 Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_CONSTEXPR - use only where required > > You probably don't need this. You'll need it when accessing const data from > a Q_DECL_CONSTEXPR function. Otherwise, you won't need it. > > You could use this to create a static-initialisation-time const variable of > a non-POD type, but since our sources still compile in C++98 and we still > have a rule against non-POD statics, you should not do this. Consensus, I think? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_DECL_OVERRIDE - required in new code, don't add to old code - Required to be used consistently within a class, because Clang warns be default if one function has override and another doesn't. - Even add to old code. The benefits outweigh the git history churn. Consensus? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_DECL_EQ_DEFAULT - really discouraged > > I can't think of any case where you could use this and let the code still > compile in C++98, so don't use it > > * Q_DECL_EQ_DELETE - strongly encouraged, use with care > > Let's the compiler print an error instead of allowing a linker error for > an unresolved symbol. > > * Q_DECL_CONSTEXPR / Q_DECL_RELAXED_CONSTEXPR - strongly encouraged > > Use where it makes sense. If possible, use the C++11 restricted constexpr > as we have still too few compilers with C++14 relaxed constexpr support > (Clang 3.5, GCC 5), but feel free to use Q_DECL_RELAXED_CONSTEXPR when > there's benefit for constexprness but impossible to solve in C++11 > > * Q_DECL_FINAL - optional, use with care > > There's a small benefit in optimisation by devirtualising calls. Use it > with care. > > Use in public classes is discouraged, since people can compile with a > C++98 and derive / override what they shouldn't. All of the above is consensus, I think? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > * Q_NULLPTR - strongly encouraged Ok, trying to summarize the discussion so we can move forward. There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about Qt headers not compiling with -Wzero-as-null-pointer-constant, sometimes not even when locking the Qt headers away behind an -isystem. I understood the discussion in this thread as follows: - ok to use Q_NULLPTR in public headers (the bug report suggests that this should actually be enforced by headersclean). - ok to use in new code or as a drive-by iff the 0 isn't immediately visible as a nullptr. Example: validator(0), // Q_NULLPTR ok here Counter-example: const char *msg = 0 // Q_NULLPTR not wanted here - otherwise, we don't want Q_NULLPTR. We're waiting until we can move directly to nullptr. In particular, we cannot use Q_NULLPTR for its potentially disambiguating characteristics, until we require C++11 nullptr. So code must still compile (modulo warnings) (and have the same meaning) if the Q_NULLPTR is replaced back to 0. Consensus? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is QFutureInterface internal like the other d-pointer classes?
On Thursday 23 July 2015 11:24:05 Lorenz Haas wrote: > Hi, > > most - if not all - d-pointer/private implementation files are > *internal* and should not be used in a "normal" project - meaning a > project that just uses Qt. These files/classes are clearly marked by > > // > // W A R N I N G > // - > // > // This file is not part of the Qt API. It exists purely as an > // implementation detail. This header file may change from version to > // version without notice, or even be removed. > // > // We mean it. > // > > What about QFutureInterface? Is it safe to use it in a normal project > or can it be changed at any time like the other internal classes? > > qfutureinterface.h/.cpp does not have the cited warning. > QFutureInterfaceBase is furthermore exported, QFutureInterface not. > Why? I also do not understand the comment in qfuture.h: > > public: // Warning: the d pointer is not documented and is considered > private. mutable QFutureInterface d; > > Okay, it is not documented, but I can read the source code, or is all > not documented Qt code considered *internal*? Hope not. The comment > also mentions "private". This is only related to the access > specification, is it? Or does private here also means *internal*? It's undocumented, and considered private, but since it's a template and thus must be visible, it effectively is public API and falls under the same restrictions for changes as public API. IOW: it cannot change (incompatibly) until Qt 6. If you're fine with that, go ahead and use it in your code. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtbase 5.5 CI broken again ?
Hi, >As far as I know, no. No one has a clue why the creation of a temporary >directory is failing. It is simply running out of patterns to try since the mime DB tests leaked temp dirs. https://codereview.qt-project.org/#/c/121381/ fixed QDir::removeRecursively() to try harder removing files and https://codereview.qt-project.org/#/c/121383/ fixed the test to set write permission on the temp files it creates; the test should no longer leak. All that remains to be done is reboot the Windows CI nodes and clean out their temp directories. Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FileRe: Move ctors for q_declare_shared types
> > If a change is related to a discussion on the mailing list, I expect that > > the change is posted to the discussion. > > I already quoted you the mail where I ... > > > Because not doing that, circumvents the discussion on the mailing list and > > goes against the spirit of The Qt Governance Model. > > > > You circumvented the discussion and did not inform the mailing list on the > > changes, which clearly were related: > > https://codereview.qt-project.org/115376 > > ... shared this ^ change on the ML. Now you _again_ claim I didn't. I never claimed that you didn't share this change. Also I mentioned that change exactly once so far. Can you please not grossly misrepresent what I actually wrote? I wrote and this is from the only mail in which I mention that change, and I hope you read it this time: "You circumvented the discussion and did not inform the mailing list on the changes:" You only informed the mailing list on that change after it was already in the repository. You didn't wait until the discussion came to a conclusion. If you would have posted that change for discussion, I would have pointed out the how broken that change is without a change to the container classes. I stand by my point, you circumvented the discussion on the mailing list. > > https://codereview.qt-project.org/#/c/120771 > > https://codereview.qt-project.org/#/c/120804/ > > These just implement what was discussed on the ML. Again: no-one spoke out > against the solution Thiago and I came up with (publicly on the ML). > I posted one change, I didn't post them all, no. They contain no new > information. I was under the impression that you wanted to not fix the container classes at all. Can you quote me the mail on the mailing list where you or Thiago propose and agree on fixing the container classes? > I have a few dozen of changes (re)adding move semantics to Qt > types. Do you want to see them all? I can CC you from now on on Gerrit. I > doubt everyone else will want to be spammed on the ML. Again, and I'm not sure why this is complicated for you to understand: A change that is related to a ongoing discussion on the mailing list, should be discussed on the mailing list. You shouldn't create hard facts by pushing a change. > > In my opinion this is unprofessional. > > Then I guess I'm unprofessional. > > You got what you lobbied for. What, exactly, are you complaining about? Your unprofessional behaviour. I thought I made clear that I'm fine with the fixes in Qt. daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Is QFutureInterface internal like the other d-pointer classes?
Hi, most - if not all - d-pointer/private implementation files are *internal* and should not be used in a "normal" project - meaning a project that just uses Qt. These files/classes are clearly marked by // // W A R N I N G // - // // This file is not part of the Qt API. It exists purely as an // implementation detail. This header file may change from version to // version without notice, or even be removed. // // We mean it. // What about QFutureInterface? Is it safe to use it in a normal project or can it be changed at any time like the other internal classes? qfutureinterface.h/.cpp does not have the cited warning. QFutureInterfaceBase is furthermore exported, QFutureInterface not. Why? I also do not understand the comment in qfuture.h: public: // Warning: the d pointer is not documented and is considered private. mutable QFutureInterface d; Okay, it is not documented, but I can read the source code, or is all not documented Qt code considered *internal*? Hope not. The comment also mentions "private". This is only related to the access specification, is it? Or does private here also means *internal*? Thanks Lorenz ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] MSVC2015 and Qt5.5 -- dot release plans?
> I don't know whether we'll be able to produce binaries for it for 5.5.1. That > depends on how soon we can bring it up in the old CI. Any idea when 5.5.1 is due now? The Wiki says the original date was September but will this be pushed out? https://wiki.qt.io/Qt-5.5-release Tom Isaacson ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
