Re: [Development] Qt6 source changes
On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote: > Thiago Macieira wrote: > > We're studying what to do with QList, but the idea is that the name > > "QList" will be completely ok and identical to QVector. The technical > > mechanism is in flux. > > That means you will be pessimizing element inserts and removals from O(n) to > O(mn), where n is the length of the list and m the size of each element, > without offering a good alternative without that pessimization (sure, you > can use a QVector or QVector>, but those have > somewhat different semantics and less convenient syntax). Yes. Is that a widespread use? And will it be a perceptible change? Don't forget that m is a constant, for any given list. It's not a scalability problem, since no matter how many inputs the user provides, the size of the object will not change. > It won't make a difference for implicitly-shared objects (but QList already > works like a vector for those anyway), but for large in-place objects, it > can make a big difference. -- 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
[Development] Another integer typedef OR how to prepare for 64-bit in Qt 5
We have a lot of API that, for Qt 6, we've already decided to extend to 64-bit
on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit ones. We've
already created the type we want for Qt 6 and that's "qsizetype": a signed
integer the same size as size_t and ptrdiff_t. And a lot of new API already
uses it, for example:
https://doc.qt.io/qt-5/qstringview.html#at
http://doc-snapshots.qt.io/qt5-dev/qcborarray.html#at
And internally, we can use decltype(), auto or one of the typedefs to make
optimal use. Example:
struct ByteData
{
QByteArray::size_type len;
But how do we begin porting our API? For example:
https://doc.qt.io/qt-5/qstring.html#at
https://doc.qt.io/qt-5/qbytearray.html#at
These two functions are declared as taking int parameters. Similarly,
https://doc.qt.io/qt-5/qstring.html#indexOf
returns an int index.
This porting will take a lot of time, since the use of "int" is so pervasive
in our code. And we can't change them to qsizetype right now, it would be a BC
break.
What do we do?
Option 1: do nothing, wait for Qt 6 and do the change then
This is the simplest solution for now, but hardest in the future. It would
mean finding all the issues in a very short amount of time and it would make
merges across 5.15 and 6.0 very difficult.
Option 2: insert #if in our API, starting now
This works and is the same amount of work as almost all of the rest. But it's
VERY ugly.
Option 3: use #if per class, starting now
For example, change QString to have:
#if QT_VERSION >= QT_VERSION_CHECK(6,0,0)
typedef qsizetype size_type;
#else
typedef int size_type;
#endif
And then change all uses in QString from "int" to size_type in the API.
This is the cleanest and follows the precedence of the Standard Library. But
as a side-effect, we may have very long names in our code and they'll show up
in the documentation too. This would also require adding such typedefs to
classes that currently don't have them, like QPixmap and QImage.
Option 4: create a central #if and use this new type, starting now
Same as #3, but instead of per class, it would be central. Moreover, with one
preprocessor trick (-Dnewinttype=int), we can fool qdoc into generating
documentation as it is today. In Qt 6, once we decide we don't need Qt 5
merging anymore, we can also do a global search-and-replace to qsizetype
(optional).
Other options?
I think Option 4 is the best solution, among those that I listed.
--
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] Qt6 source changes
Thiago Macieira wrote: > We're studying what to do with QList, but the idea is that the name > "QList" will be completely ok and identical to QVector. The technical > mechanism is in flux. That means you will be pessimizing element inserts and removals from O(n) to O(mn), where n is the length of the list and m the size of each element, without offering a good alternative without that pessimization (sure, you can use a QVector or QVector>, but those have somewhat different semantics and less convenient syntax). It won't make a difference for implicitly-shared objects (but QList already works like a vector for those anyway), but for large in-place objects, it can make a big difference. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6 source changes
On Thursday, 1 November 2018 03:58:17 PDT Sascha Cunz wrote: > > Qt6 won't be fully source-compatible. The idea is that we'll break it > > to fix > > things, but attempt to keep compatible as much as possible to avoid > > death by a > > thousand paper cuts. > > Does this rule out some kind of smart pointer that would be used to hold > QObject*? No, it does not rule out "some kind of smart pointer". So long as "some kind of smart pointer" is 99.9% source-compatible when not opted into. Probably 99.99%. -- 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] Short CI status
>> As you may have noticed we still have several issues in our CI system which >> needs fixes. >> >> Below is the frontline of CI teams battlefield >> [...] Do we actually know what is _causing_ all the freezing and timeouts? I hope this is not a case of throwing a few system upgrades at the wall just to see what sticks. Ulf ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Short CI status
> -Original Message- > From: Heikki Halmet > Sent: Thursday, 1 November 2018 1:17 PM > To: development@qt-project.org > Subject: Short CI status > > Hi, > > > > As you may have noticed we still have several issues in our CI system which > needs fixes. > > Below is the frontline of CI teams battlefield: > > > > * Windows 10 machines are freezing time to time and the logging > suddenly stops. > > * https://bugreports.qt.io/browse/QTQAINFRA-2253 > > * We are trying to fix this by upgrading Hosts kernel > version. Correction is almost there but we got some unexpected problems > during the test. Hopefully we'll get back on the track soon. > * You can follow the process from here: > https://bugreports.qt.io/browse/QTQAINFRA-2299 > > * Lots of Configure/Qmake timeouts during builds > > * https://bugreports.qt.io/browse/QTQAINFRA-2051 > * https://bugreports.qt.io/browse/QTQAINFRA-2052 > * We assume that kernel update will help with this one. > > * When cancelling e.g. Qt5 build COIN scheduler goes stuck for a long > time > > * https://bugreports.qt.io/browse/QTQAINFRA-2257 > * We are currently making change(s) to fix this. > > * Windows VM randomly freezes and need user input before able to > continue building > > * https://bugreports.qt.io/browse/QTQAINFRA-2263 > * We have fix for this which we hope to resolve this issue - > https://codereview.qt-project.org/#/c/242149/ > > * In packaging site macos 10.13 keeps on disconnecting from Jenkins > > * https://bugreports.qt.io/browse/QTQAINFRA-2310 > * We have two plan for this > > * A. Changing Jenkins-pkg to use Coin's virtual > machines. Work on going. > * B. Upgrade Host's hypervisor (This is a long shot and > we hope that plan A will resolve this) > > > > We feel your pain and frustration. We are working hard to have more stable > CI and hopefully soon we'll have most of these problems resolved. Thanks to the CI team for all the work they're putting in! > > > > > Br > > Heikki Halmet ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Short CI status
Hi, As you may have noticed we still have several issues in our CI system which needs fixes. Below is the frontline of CI teams battlefield: * Windows 10 machines are freezing time to time and the logging suddenly stops. * https://bugreports.qt.io/browse/QTQAINFRA-2253 * We are trying to fix this by upgrading Hosts kernel version. Correction is almost there but we got some unexpected problems during the test. Hopefully we'll get back on the track soon. * You can follow the process from here: https://bugreports.qt.io/browse/QTQAINFRA-2299 * Lots of Configure/Qmake timeouts during builds * https://bugreports.qt.io/browse/QTQAINFRA-2051 * https://bugreports.qt.io/browse/QTQAINFRA-2052 * We assume that kernel update will help with this one. * When cancelling e.g. Qt5 build COIN scheduler goes stuck for a long time * https://bugreports.qt.io/browse/QTQAINFRA-2257 * We are currently making change(s) to fix this. * Windows VM randomly freezes and need user input before able to continue building * https://bugreports.qt.io/browse/QTQAINFRA-2263 * We have fix for this which we hope to resolve this issue - https://codereview.qt-project.org/#/c/242149/ * In packaging site macos 10.13 keeps on disconnecting from Jenkins * https://bugreports.qt.io/browse/QTQAINFRA-2310 * We have two plan for this * A. Changing Jenkins-pkg to use Coin's virtual machines. Work on going. * B. Upgrade Host's hypervisor (This is a long shot and we hope that plan A will resolve this) We feel your pain and frustration. We are working hard to have more stable CI and hopefully soon we'll have most of these problems resolved. Br Heikki Halmet ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
On Wed, Oct 31, 2018 at 03:41:49PM -0400, Matthew Woehlke wrote:
> On 31/10/2018 14.26, Oswald Buddenhagen wrote:
> > On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
> >> Again, how then does the consuming tool know which qt.core and which
> >> qt.gui are compatible with each other? How does it handle the case of
> >> finding a qt.core with no matching qt.gui?
> >
> > as i said below, by the sub-packages constraining their transitive
> > dependencies.
>
> That is insufficient.
>
no, it's not.
> A.X can be used by itself. A.Y also can be used by itself. However,
> mixing different versions of A.X and A.Y is an error.
>
it's a rather contrived scenario that two components of a package
could be used truly independently (without a common dependency within
the package), yet still conflict between versions. anyway, let's go with
it.
> Even if you propose to solve this by having both A.X and A.Y depend on a
> "virtual" A.base target of the same version,
>
that's indeed one way to solve it.
another way are "anti-dependencies" like dpkg's Breaks: A.X !=
> you still haven't explained how to make it so a consumer can find the
> correct version of A in the pathological scenario I outlined without a
> global dependency solver.
>
no, instead i told you that your premise of needing a _global_ solver is
wrong.
> > that answer might be unnecessarily strict, though. if i build a
> > 3rd-party qt module and install it into /opt/myqt, it might be
> > compatible with the system qt in /usr. i want to be able to use that
> > additional qt module by depending on {qt.{core,gui,3rdpartymodule}}.
>
> Well, then, don't make it part of the "Qt" package. I don't think you
> can have it both ways. (If it's a third-party module, why is it a first
> party component of the "Qt" package?)
>
because users want to think in terms of namespaces, not packages. at
least i do. at least for modules that aren't part of "qt" but are hosted
on qt-project infrastructure. qtwebkit is an excellent example, and
qtwebengine will probably follow soon due to wanting release cycle
decoupling.
> >> I think you are suggesting that finding build requirements has to be
> >> done as a single, monolithic pass; i.e. a project must specify ALL of
> >> its requirements before ANY attempt is made to satisfy those
> >> requirements.
> >
> > but that's exactly what you do anyway with the syntax above, within the
> > scope of a single package.
>
> Not quite. [...]
>
you just spent ~35 lines on ... showing that i'm right.
the TTA approach cannot possibly work without the atomic resolution
scope provided by the multi-component find_library() statement. and
given that constraint, it's absolutely irrelevant to the user what
happens behind the scenes.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Champions 2018 nominations open
Hi! We have now opened the nominations for Qt Champions in 2018! As before, please think about who has helped you out the most during the past year and nominate them via the Qt wiki at https://wiki.qt.io/QtChampions. The categories are: Community Builder Content Creator Quality Assurer Developer Fixer Ambassador Rookie of the Year Maverick The criteria for the nominations can be found on the same page. If there is anyone who should be in several categories, or has done something that does not fit in any of the categories. then please mention this too! The nominations will be kept open until the 16th December 2018 and the winners announced soon after that. Qt Champions will receive hand-picked Qt Champion items and a full Qt license for a year. So please go to https://wiki.qt.io/QtChampions and make your nominations! Kind regards, Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
On Thu, 01 Nov 2018 11:23:31 +, Tuukka Turunen wrote: > Of course mailing list discussion is also completely fine. It is more than that: it is the place where all fundamental decisions concerning the Qt project ( like f.e. deprecating modules ) have to be announced and discussed first - before writing devastating blog posts. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
> It’s convenient to quote what adds fuel to the fire of this discussion. Hence > my attempt to add water by quoting what I thought it still relevant. In a real life never add water to a fuel fire. It will cause even more fire Gatis. From: Development on behalf of Simon Hausmann Sent: Thursday, November 1, 2018 12:19:11 PM To: André Pönitz Cc: development mailing list; q...@qt-project.org Subject: Re: [Development] Build system for Qt 6 I agree, this is often the case. I just wanted to emphasize that I think it’s too early to conclude that llvm is going to switch to gn based on that email. It’s convenient to quote what adds fuel to the fire of this discussion. Hence my attempt to add water by quoting what I thought it still relevant. Simon > On 1. Nov 2018, at 12:14, André Pönitz wrote: > >> On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote: >> >>> From the same email perhaps it's also worth quoting the first paragraph: >> " >> >> first things first: If you're happy with cmake, you can stop reading now. >> Nobody is proposing that LLVM moves off cmake, and nobody is proposing >> anything that's causing people using cmake more work. >> " > > Sure, that's how one approaches larger controversial changes, not just > in software development, but also general politics: > > 1. Promise that everything is optional, and existing uses won't change, > and nobody will be affected unless opted-in. This keeps the initial > outcry a bay. Optionally, start to belittle opposition as inveterate > nay-sayers, as there is clearly no reason to oppose something people > do voluntarily. > > 2. Once installed, apply salami tactics by extending the scope of the > measure, "add value" to the new system, asked for or not, and let the old > one rot. If needed, little stabs in the back help to speed up the process. > > 3. At some time the new system will indeed be better in some setups than > the old one, and the opt-in gets opt-out. This is also a good time to > gauge remaining resistance, and either continue with 2 or directly go > to 4. > > 4. Sweep remaining issues under the carpet and declare the old system dead. > > > As I said, that's nothing specific to LLVM and Cmake. > > The pattern to message "Nobody has any intention to do X" while planning > or even already executing X is so widely used that in the presence of > such a statement it is safer to assume that this is just stage 1 of the > process above than to accept the statement at face value. > > Andre' > ___ 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] Who is in charge of qt-project.org?
Hi, Of course mailing list discussion is also completely fine. But in case someone has a concrete suggestion related to any of the websites, it can be also submitted via JIRA. Just like feature suggestions. It may be to not everyone was aware of this, thus I provided the link. Yours, Tuukka On 01/11/2018, 13.18, "Development on behalf of Uwe Rathmann" wrote: On Thu, 01 Nov 2018 10:24:16 +, Tuukka Turunen wrote: > Things can always be improved, and constructive feedback is always > welcome. The bottom line of this all is of course the fundamental question if the Qt Project is intended to be more than simply a way how to contribute to the products of the Qt Company ? If it isn't it would be a matter of honesty to move everything from qt- project.org to qt.io and tell the truth to the Qt community. Otherwise he Qt Company has to give the Qt Project more rights to make independent decisions - starting with having a clean separation between the resources owned by the Qt Project and the Qt Company. > If you have suggestions, these can be done e.g. via: > https://bugreports.qt.io/projects/QTWEBSITE. Are you seriously trying to redirect complaints about how the Qt Company is misusing qt.project.org to qt.io ? Uwe ___ 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] Build system for Qt 6
I agree, this is often the case. I just wanted to emphasize that I think it’s too early to conclude that llvm is going to switch to gn based on that email. It’s convenient to quote what adds fuel to the fire of this discussion. Hence my attempt to add water by quoting what I thought it still relevant. Simon > On 1. Nov 2018, at 12:14, André Pönitz wrote: > >> On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote: >> >>> From the same email perhaps it's also worth quoting the first paragraph: >> " >> >> first things first: If you're happy with cmake, you can stop reading now. >> Nobody is proposing that LLVM moves off cmake, and nobody is proposing >> anything that's causing people using cmake more work. >> " > > Sure, that's how one approaches larger controversial changes, not just > in software development, but also general politics: > > 1. Promise that everything is optional, and existing uses won't change, > and nobody will be affected unless opted-in. This keeps the initial > outcry a bay. Optionally, start to belittle opposition as inveterate > nay-sayers, as there is clearly no reason to oppose something people > do voluntarily. > > 2. Once installed, apply salami tactics by extending the scope of the > measure, "add value" to the new system, asked for or not, and let the old > one rot. If needed, little stabs in the back help to speed up the process. > > 3. At some time the new system will indeed be better in some setups than > the old one, and the opt-in gets opt-out. This is also a good time to > gauge remaining resistance, and either continue with 2 or directly go > to 4. > > 4. Sweep remaining issues under the carpet and declare the old system dead. > > > As I said, that's nothing specific to LLVM and Cmake. > > The pattern to message "Nobody has any intention to do X" while planning > or even already executing X is so widely used that in the presence of > such a statement it is safer to assume that this is just stage 1 of the > process above than to accept the statement at face value. > > Andre' > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6 source changes
I've seen that kind of argument before, so that's why I want put a comment in here. On Thu, Nov 1, 2018 at 12:58 PM Sascha Cunz wrote: > I've seen lots of commercial code bases in the past where QObject > inheriting classes are combined with QExplicitlySharedDataPointer - > while at the same time relying on having a parent in those QObjects. > QExplicitlySharedDataPointer? That would be rather odd. Do you mean QSharedPointer? Semantically: > - They are strongly owned by some other QObject based entity > Then that's their parent. - A lot of code stores a reference to them (In terms of a QESDP), where > either: - the reference _should_ be invalidated during destruction > QPointer or connect directly to `QObject::destroyed`. - the existence of such reference (to a child) _should_ stop the > parent from destroying that child. > Then they're not strongly owned by the parent! - The overhead of QPointer is not desirable > Other smart pointers are cheap? I know these requirements are kind of a paradox. But both variants of > this are a pattern, I find relatively often in customer's code bases. > Sounds more like antipattern. > I would really like to have an easy way to give such customers a "sane" > way forward. > That'd be to define the ownership clearly, not try to weasel out of it with some "smart" pointer. Self-owning QObject instances can still be hold in `QSharedPointer` if needed, however, then they're not owned by the parent, so you shouldn't give them a parent. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
On Thu, 01 Nov 2018 10:24:16 +, Tuukka Turunen wrote: > Things can always be improved, and constructive feedback is always > welcome. The bottom line of this all is of course the fundamental question if the Qt Project is intended to be more than simply a way how to contribute to the products of the Qt Company ? If it isn't it would be a matter of honesty to move everything from qt- project.org to qt.io and tell the truth to the Qt community. Otherwise he Qt Company has to give the Qt Project more rights to make independent decisions - starting with having a clean separation between the resources owned by the Qt Project and the Qt Company. > If you have suggestions, these can be done e.g. via: > https://bugreports.qt.io/projects/QTWEBSITE. Are you seriously trying to redirect complaints about how the Qt Company is misusing qt.project.org to qt.io ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
Especially considering that the person proposing the change is working at google which is where GN comes from. There's some conflict of interest here. On 01/11/2018 12:13, André Pönitz wrote: On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote: >From the same email perhaps it's also worth quoting the first paragraph: " first things first: If you're happy with cmake, you can stop reading now. Nobody is proposing that LLVM moves off cmake, and nobody is proposing anything that's causing people using cmake more work. " Sure, that's how one approaches larger controversial changes, not just in software development, but also general politics: 1. Promise that everything is optional, and existing uses won't change, and nobody will be affected unless opted-in. This keeps the initial outcry a bay. Optionally, start to belittle opposition as inveterate nay-sayers, as there is clearly no reason to oppose something people do voluntarily. 2. Once installed, apply salami tactics by extending the scope of the measure, "add value" to the new system, asked for or not, and let the old one rot. If needed, little stabs in the back help to speed up the process. 3. At some time the new system will indeed be better in some setups than the old one, and the opt-in gets opt-out. This is also a good time to gauge remaining resistance, and either continue with 2 or directly go to 4. 4. Sweep remaining issues under the carpet and declare the old system dead. As I said, that's nothing specific to LLVM and Cmake. The pattern to message "Nobody has any intention to do X" while planning or even already executing X is so widely used that in the presence of such a statement it is safer to assume that this is just stage 1 of the process above than to accept the statement at face value. Andre' ___ 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] Build system for Qt 6
On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote: > > >From the same email perhaps it's also worth quoting the first paragraph: > " > > first things first: If you're happy with cmake, you can stop reading now. > Nobody is proposing that LLVM moves off cmake, and nobody is proposing > anything that's causing people using cmake more work. > " Sure, that's how one approaches larger controversial changes, not just in software development, but also general politics: 1. Promise that everything is optional, and existing uses won't change, and nobody will be affected unless opted-in. This keeps the initial outcry a bay. Optionally, start to belittle opposition as inveterate nay-sayers, as there is clearly no reason to oppose something people do voluntarily. 2. Once installed, apply salami tactics by extending the scope of the measure, "add value" to the new system, asked for or not, and let the old one rot. If needed, little stabs in the back help to speed up the process. 3. At some time the new system will indeed be better in some setups than the old one, and the opt-in gets opt-out. This is also a good time to gauge remaining resistance, and either continue with 2 or directly go to 4. 4. Sweep remaining issues under the carpet and declare the old system dead. As I said, that's nothing specific to LLVM and Cmake. The pattern to message "Nobody has any intention to do X" while planning or even already executing X is so widely used that in the presence of such a statement it is safer to assume that this is just stage 1 of the process above than to accept the statement at face value. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6 source changes
On 2018-10-31 16:46, Thiago Macieira wrote: Qt6 won't be fully source-compatible. The idea is that we'll break it to fix things, but attempt to keep compatible as much as possible to avoid death by a thousand paper cuts. Does this rule out some kind of smart pointer that would be used to hold QObject*? I've seen lots of commercial code bases in the past where QObject inheriting classes are combined with QExplicitlySharedDataPointer - while at the same time relying on having a parent in those QObjects. Semantically: - There's some class for which QObject benefits like Signals/Slots are required - They are strongly owned by some other QObject based entity - A lot of code stores a reference to them (In terms of a QESDP), where either: - the reference _should_ be invalidated during destruction - the existence of such reference (to a child) _should_ stop the parent from destroying that child. - The overhead of QPointer is not desirable I know these requirements are kind of a paradox. But both variants of this are a pattern, I find relatively often in customer's code bases. I would really like to have an easy way to give such customers a "sane" way forward. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
Hi, Yes, "hard to work with" :). Cheers, BogDan. În ziua de joi, 1 noiembrie 2018, la 11:24:29 EET, Vlad Stelmahovsky a scris: > you mean "hard to work with"? > > On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote: > > Hi, > > > >GN is the closest build system to QBS, the only problem it has it's > > > > controled by Google and these guys are sometime had to work with. > > > > Cheers, > > BogDan. > > > > În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris: > >> On 10/29/18 1:17 PM, Lars Knoll wrote: > >>> Given that we are confident we can build Qt 6 with cmake, I believe that > >>> it makes most sense to follow down that route. > >> > >> Just some observation: > >> > >> LLVM/Clang is a bigger project using CMake for some longer time and > >> coincidentally, just now, there is a discussion whether they should add > >> GN build files to their repositories as, let me quote: > >> > >> """ > >> cmake is great for many use cases, but in my opinion local day-to-day > >> development isn't one of them. > >> """ > >> > >> Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html > >> LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html > >> > >> Nikolai > >> ___ > >> 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 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] Who is in charge of qt-project.org?
Hi, Materials related to contributing to Qt and Qt Project are still there, not been removed, see: https://www.qt.io/contribute-to-qt, https://wiki.qt.io/Qt_Contribution_Guidelines, https://wiki.qt.io/Qt_Project_Open_Governance, and https://wiki.qt.io/The_Qt_Governance_Model - just to mention a few pages about the Qt Project and contributing to Qt. At the time of unification qt-project.org was mainly a site for developers using Qt, built in a way that it was really laborsome to maintain. Content was carried over to more modern systems for everything that was seen relevant - including all contribution related items (which already back then were in the wiki part of the system). Because the majority of people visiting www.qt-project.org were developers of Qt applications, it redirects to the current developer page. Things can always be improved, and constructive feedback is always welcome. But to claim the The Qt Company has removed everything related to the Qt Project is not justified in my opinion. Could these be more visible, probably. If you have suggestions, these can be done e.g. via: https://bugreports.qt.io/projects/QTWEBSITE. Yours, Tuukka On 01/11/2018, 11.02, "Development on behalf of Olivier Goffart" wrote: On 01.11.18 08:49, Tuukka Turunen wrote: > > Hi Christian, > > What comes to the mistake with the mailing list archive, we of course fix it. Meanwhile, use the workaround described by Andy: " It is there, but you have to go to http://lists.qt-project.org for now, it is being moved to a new server so at some point the https address will be back, but until then you need to use the http address." > > What comes to the Qt Project, it is how Qt is developed - all the work done for Qt by The Qt Company is via the Qt Project. The website where this is best visible is: https://codereview.qt-project.org, also the mailing lists are with qt-project.org domain. > > The reasons for not having a separate site for open-source Qt and commercial Qt are described quite well in this blog post from, 2014: http://blog.qt.io/blog/2014/08/06/defragmenting-qt-and-uniting-our-ecosystem/ > > The hosting foundation for Qt Project (a non-profit organization registered in Norway) is currently inoperable, costs of running the web servers, download systems etc of the Qt Project are paid directly by The Qt Company. That blog you link said it would merge the contents of qt-project.org with the contents of digia. In practice, it just removed, or hide, all the contents from qt-project, and replaced it by The Qt Company marketing. At the time, qt-project.org contained useful information for and from developers *of* Qt. The contribution model was explained, the blog links was linking to planet qt, an aggregation of contributors blog. https://web.archive.org/web/20140806181527/http://qt-project.org:80/ Today, qt-project.org redirects to https://www.qt.io/developers/ which is use a page for developer *using* Qt. It contains only Qt Company links, The "Qt" blog is just "The Qt Company" blog. It does not really mention that there are contributors to Qt other than the Qt company. ___ 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] QtConcurrent replacement candidate
> and also sometimes > using the private-ish QFutureInterface to be able to use QFuture to > its full extent, which makes us feel a little dirty :) Good not to feel alone :) Philippe On Thu, 1 Nov 2018 10:42:36 +0100 Elvis Stansvik wrote: > There were some discussions last year on > https://bugreports.qt.io/browse/QTBUG-61928 about the async API future > (pun intended). I'm sure there are a few old mailing list threads too. > > I too would be interested in where Qt is heading in this area going > forward. We're using the current QtConcurrent APIs, and also sometimes > using the private-ish QFutureInterface to be able to use QFuture to > its full extent, which makes us feel a little dirty :) > > Elvis > Den tors 1 nov. 2018 kl 00:57 skrev Denis Kormalev : > > > > Hi, > > > > As part of our work projects we have a framework (named Proof and partly > > open sourced). Most part of it is not really interesting outside of our > > industry, but one of its basic ideas is heavy usage of future/promise > > technology with API similar to one used in Scala. We also have tasks > > scheduling helpers that are based on these futures. > > I would like to ask Qt community if Qt itself needs QFuture/QtConcurrent > > redoing and replacing with something similar to what we do. > > If community will find it interesting I'm more than happy to implement it > > and do everything to make it as part of Qt someday. > > Current API is a bit specific for our projects and of course need to be > > reworked, but main idea can be seen from examples listed at > > https://github.com/opensoft/proofseed#futures-examples . > > Future/Promise API can be seen at > > https://github.com/opensoft/proofseed/blob/develop/include/proofseed/future.h > > . Main idea is that all interaction is done via QSharedPointer wrappers. I > > assume it is not the best way to do it and probably FutureSP should be > > named Future (with protected inheritance from QSharedPointer and having all > > methods from Future) and Future should be named something like FutureData. > > Tasks scheduling is done mostly via run() function specified at > > https://github.com/opensoft/proofseed/blob/develop/include/proofseed/tasks.h#L181 > > . > > Future also has negative class named Failure, which in case of Qt adoption > > probably should be just a QVariant (current implementation is, as I > > mentioned previously, a bit specific for our projects). > > > > Anyway, I would like to start a discussion if Qt community thinks that > > something like that could be useful as part of Qt itself. In this case I > > can work on basic API with having Future inherited from QSharedPointer and > > show it for early API review. > > I never did anything greater than bugfixes for Qt, so I would also need few > > recommendations about where to start (I assume I will need a repo in qt > > playground for stuff like that). > > > > Another question is about legal stuff. This library is BSD-3 licensed and I > > assume I will need some documents from my company if this implementation > > will be heavily similar to existing library. If anyone can advise (again, > > of course if Qt community will find it interesting) I would really > > appreciate it. 2 > > > > -- > > Regards, > > Denis Kormalev > > > > ___ > > 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtConcurrent replacement candidate
There were some discussions last year on https://bugreports.qt.io/browse/QTBUG-61928 about the async API future (pun intended). I'm sure there are a few old mailing list threads too. I too would be interested in where Qt is heading in this area going forward. We're using the current QtConcurrent APIs, and also sometimes using the private-ish QFutureInterface to be able to use QFuture to its full extent, which makes us feel a little dirty :) Elvis Den tors 1 nov. 2018 kl 00:57 skrev Denis Kormalev : > > Hi, > > As part of our work projects we have a framework (named Proof and partly open > sourced). Most part of it is not really interesting outside of our industry, > but one of its basic ideas is heavy usage of future/promise technology with > API similar to one used in Scala. We also have tasks scheduling helpers that > are based on these futures. > I would like to ask Qt community if Qt itself needs QFuture/QtConcurrent > redoing and replacing with something similar to what we do. > If community will find it interesting I'm more than happy to implement it and > do everything to make it as part of Qt someday. > Current API is a bit specific for our projects and of course need to be > reworked, but main idea can be seen from examples listed at > https://github.com/opensoft/proofseed#futures-examples . > Future/Promise API can be seen at > https://github.com/opensoft/proofseed/blob/develop/include/proofseed/future.h > . Main idea is that all interaction is done via QSharedPointer wrappers. I > assume it is not the best way to do it and probably FutureSP should be named > Future (with protected inheritance from QSharedPointer and having all methods > from Future) and Future should be named something like FutureData. > Tasks scheduling is done mostly via run() function specified at > https://github.com/opensoft/proofseed/blob/develop/include/proofseed/tasks.h#L181 > . > Future also has negative class named Failure, which in case of Qt adoption > probably should be just a QVariant (current implementation is, as I mentioned > previously, a bit specific for our projects). > > Anyway, I would like to start a discussion if Qt community thinks that > something like that could be useful as part of Qt itself. In this case I can > work on basic API with having Future inherited from QSharedPointer and show > it for early API review. > I never did anything greater than bugfixes for Qt, so I would also need few > recommendations about where to start (I assume I will need a repo in qt > playground for stuff like that). > > Another question is about legal stuff. This library is BSD-3 licensed and I > assume I will need some documents from my company if this implementation will > be heavily similar to existing library. If anyone can advise (again, of > course if Qt community will find it interesting) I would really appreciate > it. 2 > > -- > Regards, > Denis Kormalev > > ___ > 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] Build system for Qt 6
you mean "hard to work with"? On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote: Hi, GN is the closest build system to QBS, the only problem it has it's controled by Google and these guys are sometime had to work with. Cheers, BogDan. În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris: On 10/29/18 1:17 PM, Lars Knoll wrote: Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. Just some observation: LLVM/Clang is a bigger project using CMake for some longer time and coincidentally, just now, there is a discussion whether they should add GN build files to their repositories as, let me quote: """ cmake is great for many use cases, but in my opinion local day-to-day development isn't one of them. """ Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html Nikolai ___ 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
Hi,I have to apologise for my behaviour. While I still think Christian Gagneraud's attack on the Qt company abilities was unfair and uncalled for, it's not a justification for my actions.Creating an hostile environment is bad for the community and I should not have done it.It won't happen again,Regards,Luca ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
On 01.11.18 08:49, Tuukka Turunen wrote: Hi Christian, What comes to the mistake with the mailing list archive, we of course fix it. Meanwhile, use the workaround described by Andy: " It is there, but you have to go to http://lists.qt-project.org for now, it is being moved to a new server so at some point the https address will be back, but until then you need to use the http address." What comes to the Qt Project, it is how Qt is developed - all the work done for Qt by The Qt Company is via the Qt Project. The website where this is best visible is: https://codereview.qt-project.org, also the mailing lists are with qt-project.org domain. The reasons for not having a separate site for open-source Qt and commercial Qt are described quite well in this blog post from, 2014: http://blog.qt.io/blog/2014/08/06/defragmenting-qt-and-uniting-our-ecosystem/ The hosting foundation for Qt Project (a non-profit organization registered in Norway) is currently inoperable, costs of running the web servers, download systems etc of the Qt Project are paid directly by The Qt Company. That blog you link said it would merge the contents of qt-project.org with the contents of digia. In practice, it just removed, or hide, all the contents from qt-project, and replaced it by The Qt Company marketing. At the time, qt-project.org contained useful information for and from developers *of* Qt. The contribution model was explained, the blog links was linking to planet qt, an aggregation of contributors blog. https://web.archive.org/web/20140806181527/http://qt-project.org:80/ Today, qt-project.org redirects to https://www.qt.io/developers/ which is use a page for developer *using* Qt. It contains only Qt Company links, The "Qt" blog is just "The Qt Company" blog. It does not really mention that there are contributors to Qt other than the Qt company. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Cristián Maureira-Fredes for approver
Congratulations to Cristián. All rights have been set. -- Alex From: Alex Blasche Sent: Thursday, 11 October 2018 11:28:39 AM To: development@qt-project.org Cc: Cristián Maureira-Fredes Subject: Nominating Cristián Maureira-Fredes for approver Hi, I'd like to nominate Cristian Maureira-Fredes for approver rights. Predominately he has worked on the Qt for Python project ensuring that Qt and the Python world can come together. His work: https://codereview.qt-project.org/#/q/owner:%22Cristian+Maureira-Fredes%22,n,z His reviews: https://codereview.qt-project.org/#/q/reviewer:%22Cristian+Maureira-Fredes%22,n,z -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
>From the same email perhaps it's also worth quoting the first paragraph: " first things first: If you're happy with cmake, you can stop reading now. Nobody is proposing that LLVM moves off cmake, and nobody is proposing anything that's causing people using cmake more work. " Simon From: Development on behalf of Nikolai Kosjar Sent: Thursday, November 1, 2018 9:30:01 AM To: Lars Knoll; Qt development mailing list Subject: Re: [Development] Build system for Qt 6 On 10/29/18 1:17 PM, Lars Knoll wrote: > Given that we are confident we can build Qt 6 with cmake, I believe that it > makes most sense to follow down that route. Just some observation: LLVM/Clang is a bigger project using CMake for some longer time and coincidentally, just now, there is a discussion whether they should add GN build files to their repositories as, let me quote: """ cmake is great for many use cases, but in my opinion local day-to-day development isn't one of them. """ Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html Nikolai ___ 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] Build system for Qt 6
Hi, GN is the closest build system to QBS, the only problem it has it's controled by Google and these guys are sometime had to work with. Cheers, BogDan. În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris: > On 10/29/18 1:17 PM, Lars Knoll wrote: > > Given that we are confident we can build Qt 6 with cmake, I believe that > > it makes most sense to follow down that route. > Just some observation: > > LLVM/Clang is a bigger project using CMake for some longer time and > coincidentally, just now, there is a discussion whether they should add > GN build files to their repositories as, let me quote: > > """ > cmake is great for many use cases, but in my opinion local day-to-day > development isn't one of them. > """ > > Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html > LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html > > Nikolai > ___ > 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] Build system for Qt 6
On 10/29/18 1:17 PM, Lars Knoll wrote: > Given that we are confident we can build Qt 6 with cmake, I believe that it > makes most sense to follow down that route. Just some observation: LLVM/Clang is a bigger project using CMake for some longer time and coincidentally, just now, there is a discussion whether they should add GN build files to their repositories as, let me quote: """ cmake is great for many use cases, but in my opinion local day-to-day development isn't one of them. """ Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html Nikolai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
Hi Christian, What comes to the mistake with the mailing list archive, we of course fix it. Meanwhile, use the workaround described by Andy: " It is there, but you have to go to http://lists.qt-project.org for now, it is being moved to a new server so at some point the https address will be back, but until then you need to use the http address." What comes to the Qt Project, it is how Qt is developed - all the work done for Qt by The Qt Company is via the Qt Project. The website where this is best visible is: https://codereview.qt-project.org, also the mailing lists are with qt-project.org domain. The reasons for not having a separate site for open-source Qt and commercial Qt are described quite well in this blog post from, 2014: http://blog.qt.io/blog/2014/08/06/defragmenting-qt-and-uniting-our-ecosystem/ The hosting foundation for Qt Project (a non-profit organization registered in Norway) is currently inoperable, costs of running the web servers, download systems etc of the Qt Project are paid directly by The Qt Company. Yours, Tuukka On 31/10/2018, 23.50, "Development on behalf of Christian Gagneraud" wrote: On Thu, 1 Nov 2018 at 05:28, Kain Vampire via Development wrote: > > WHAT A TWAT! > > P.S. > > Yes, feel free to ban me, it was worth it. Was it? You could have used the word 'idiot', at least it is not an insult to the feminine gender. You could have as well quoted which part of the message you didn't like. I'm taking you didn't like part 2. This was obviously a provocative statement, but it was not an insult. I still stand that the qt-projects.org domain should not be managed (directly or indirectly) by the Qt Company, there is a clear conflict of interest. Something that has been raised several times in the past (Check the mailing list archives about the captive/deceptive portal hat is/was the Qt's download page). lists.qt-projects.org has had issue for more than a month, and (suddenly) got resolved overnight. [Side note: http stopped to redirect to https, but https is still down, which means that https urls returned by search engine are broken. Whoever runs codereview.qt-project.org has access to a wildcard ssl certificate (*.qt-project.org), but it seems that whoever runs lists.qt-project.org doesn't.] As an experience, try to type "download qt" in you favorite search engine, and tell me what you get, here is my top results: https://www.qt.io/download https://www1.qt.io/offline-installers/ https://download.qt.io/archive/qt/ qt-project.org/downloads The interesting bit is that qt-project.org/downloads redirects to https://www.qt.io/download. Basically, qt-projects.org is just a facade to qt.io, I think this is not healthy. There is no public expression of the "Qt Project". Concerning, the "Qt Project Hosting Foundation", i've found: https://wiki.qt.io/Qt-contributors-summit-2014-QtCS2104_Foundation https://investors.qt.io/governance/management/ (where it is mentioned that Tuukka Turunen is a "Chairman of the Board of Directors in the Qt Project Hosting Foundation") http://website.informer.com/Cristina+Hamley+Qt+Project+Hosting+Foundation.html Chris PS: I do not hate the Qt Company, nor do I hate anyone working for them. Without license, without money, there would be no "Qt Company", and without "Qt Company", the "Qt Project" would be substantially different. As a license owner and an OSS enthusiast I am thankful to the Qt Company and to all numerous direct and indirect "Qt Project" contributors. ___ 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
