Re: [Development] Build system for Qt 6
Honestly I feel very disappointed as well with this decision. I feel similarly
to others, Qbs is now being phased out so fast (half a year of development,
another half a year of maintanance after that it seems). So better get to
porting stuff to CMake right away. Having experience with CMake this is gonna
be very ugly...
What I do not understand is why the decision was qmake + cmake in the first
place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is
perfectly understandable to tap into wide CMake user base but why ditching Qbs
and not qmake? I wouldn't expect people would mourn qmake...
Oh and on the point of CMake. Lets write a simple if statement as per docs:
set(var1 "Hello")
set(var2 "Hello")
if(var1 EQUAL var2)
message("They are equal")
endif()
Guess what, it prints NOTHING despite docs explicitly saying this should work.
Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever.
This will work:
string(COMPARE EQUAL ${var1} ${var2} _cmp)
if (_cmp)
message("They are equal")
endif()
Yeah, fortunately there is a wide knowledge how to work around this kind of stuff. There
are MANY other things like that that will make you cry when writing even simple things in
CMake's "language". Not to mention CMake is not a build system, Qbs is.
Anyway, what's done is done I guess.
Michael
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] HEADS-UP: Branching from '5.12' to '5.12.0' (almost) done
Hi all, Final downmerge from '5.12' to '5.12.0' is mostly done; only qtbase and qtdeclarative is still ongoing. So from now on all changes targeted to Qt 5.12.0 release needs to be done in '5.12.0' and '5.12' is for Qt 5.12.1 release. br, Jani From: Development on behalf of Jani Heikkinen Sent: Monday, October 22, 2018 6:45 PM To: development@qt-project.org Cc: releas...@qt-project.org Subject: [Development] HEADS-UP: Branching from '5.12' to '5.12.0' started Hi, We have soft branched '5.12.0' from '5.12'. Please start using '5.12.0' for new changes targeted to Qt 5.12.0 release. Final downmerge from '5.12' to '5.12.0' will happen Mon 29th October so there should be enough time to finalize ongoing changes in '5.12' and start using '5.12.0'. Target is to release Qt 5.12.0 RC mid November so it is time to fix remaining blockers from blocker list (https://bugreports.qt.io/issues/?filter=19961) BR, Jani ___ 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 Monday, 29 October 2018 18:20:35 PDT NIkolai Marchenko wrote: > Lars, I have to wonder, don't you guys miss an opportunity here? > Qt 5 was not developed with QBS in mind. As such it probably took more > effort than needed to fit QBS to something that was originally QMake based. > > At the same time you will have to fit CMake to suit the needs for Qt6. (or > vice versa) > > Would it really be so much extra investment to have a build system fully > integrated into Qt framework process that you can just make fit on the fly, > over fiddling around the system that is overgeneralized and perhaps doesn't > support everything as much as you'd want? I'm not Lars. But yes. The Qt 6 organisation won't be too different from Qt 5's, aside from the changes that Lars and Tobias have already mentioned and that make a lot of sense to me. So I don't see how any kind of organisation will make it easier. More importantly, the problem is keeping that specific buildsystem working. If the work isn't shared and others don't pitch in, the price to pay to keep a Qt-only buildsystem working is too high: that's what Lars' email says. Finally, I'm sure any reasonable request we may have on something CMake doesn't support yet, upstream will be willing to hear us and implement where necessary. I quite frankly don't expect there to be much, especially since Lars' email says that they made so much progress in so little time. > You've said it yourself that qbs did give good results. Maybe give it a > chance? It's been given a chance. The wip/qbs branch has existed for years in qtbase. The tool has existed for years. Can you name any project of moderate complexity using it? -- 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] Build system for Qt 6
Lars, I have to wonder, don't you guys miss an opportunity here? Qt 5 was not developed with QBS in mind. As such it probably took more effort than needed to fit QBS to something that was originally QMake based. At the same time you will have to fit CMake to suit the needs for Qt6. (or vice versa) Would it really be so much extra investment to have a build system fully integrated into Qt framework process that you can just make fit on the fly, over fiddling around the system that is overgeneralized and perhaps doesn't support everything as much as you'd want? You've said it yourself that qbs did give good results. Maybe give it a chance? On Mon, Oct 29, 2018 at 3:17 PM Lars Knoll wrote: > Hi all, > > As you will probably remember, there have been lively discussions around > what kind of build tool to use for Qt 6 both during Qt Contributor Summits > as well as on this mailing list. > > There has been a strong consent that we should move away from qmake as our > build tool for Qt due to many shortcomings and the burden we have > maintaining the system. > > Thiago wrote a set of relatively strict requirements for such a build tool > in his mail in July. While some of the requirements had a bit of a Linux > specific background, they have been a good basis. > > There have been rather lively discussions around alternatives, but most > focused around two possible choices for us: Qbs and cmake. > > Qbs is something that has been developed almost exclusively by The Qt > Company. As such, TQtC had to also look at it from a business perspective > and how it fits into the larger picture of making Qt successful. To make a > long story short, while Qbs is pretty cool and interesting technology, it > doesn’t really help us expand the Qt ecosystem and usage. > > To make Qbs really successful would require a rather large effort and > investment in promoting it towards the larger C++ ecosystem as a new build > tool. At the same time it has to be an open source product to stand any > chance in the market. Together this makes it challenging for TQtC to see > how to recover that investment. Thus this investment would be at the > expense of other things we’d like to do, like improving our IDE, working on > rearchitecting and cleaning up our core frameworks for Qt 6 or the design > tooling we are currently investing into. The Qt Company believes that those > other investments are more important for the future of Qt than our choice > of build tool. > > As such, we were left with the question on whether we need Qbs as the > build system for Qt 6 or whether cmake (as the other alternative) would be > up to the task. > > Given that background, we’ve done some more research on using both Qbs and > cmake to build Qt. Both projects did give us good results but we were > actually surprised on how far we got with cmake in a rather limited period > of time. > > In addition, cmake has the advantage of being very widely used in the C++ > ecosystem (amongst many others by KDE), has a very wide support in many > IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of > knowledge about the build system available in the ecosystem. Using it with > Qt 6 would also mean that we can focus our support on two build systems for > our users (qmake and cmake) and we would not have to add a third one to the > mix. > > Given that we are confident we can build Qt 6 with cmake, I believe that > it makes most sense to follow down that route. In case you’re interested, > you can have a look at the cmake prototype code for qtbase on Gerrit in the > wip/cmake branch. Please also let us know if you’re interested in helping > with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are committed > to it for some more time. We are planning on another feature release in the > first quarter of next year and will support it in Qt Creator for at least > another year. Qbs is open source and if someone wants to take over and > develop it further let us know as well. I’d also like to use this place to > thank Christian and Jörg for all their great work on Qbs (and of course > also anybody else who contributed to it). > > Cheers, > Lars > ___ > 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] wip/cmake status information
Tomasz Siekierda wrote:
> On Mon, 29 Oct 2018 at 13:31, Tobias Hunger wrote:
>>
>> Hi!
>> [...]
>> # Building
>>
>> The basic way of building with cmake is as follows:
>>
>> ```
>> cd {build directory}
>> cmake {path to source directory}
>> cmake --build .
>> ```
>
> Just a quick question wrt to that snippet: what is the planed way of
> building Qt after the whole transition is done? Will it be cmake &&
> make, or configure && make, or configure && cmake && make?
cmake .. -G Ninja
or
cmake .. -G "Visual Studio 15 2017"
or
cmake-gui
etc
then
cmake --build . --target install
or
cmake --build . --target install --config release
if on Windows.
Thanks,
Stephen.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
I don't understand how can Qt just let QBS die like that. It's absolutely fantastic. I really hope open source development happens becuase ti will be bloody shame if ti doesn't :( On Tue, Oct 30, 2018 at 12:54 AM Ola Røer Thorsen wrote: > >> > >> We have been developing Qbs over the last years, and as such are >> > >> committed to it for some more time. We are planning on another >> feature >> > >> release in the first quarter of next year and will support it in Qt >> > >> Creator for at least another year. >> > > This is _really_ disappointing news. I'd be happy to see qmake go, now > this. > > We (at work, commercial Qt license) recently ported a rather big build > system to Qbs, replacing qmake and scons. We now have good IDE integration > for all our projects in QtCreator, both the Qt-based applications as well > as pure C/C++-based projects for desktop, embedded Linux and "bare metal" > embedded. We spent some time debugging and reporting/fixing bugs in Qbs > too. Now with Qbs 1.12.0 we're having good and stable results. Incremental > builds are _very_ fast. Project files are easy to set up, read and extend, > even with custom code generation rules, things we never were able to do > with (even undocumented) qmake. It's really impressive. > > Well I guess all that was for nothing, let's rewrite the build system next > year again, and make really sure not to embrace new Qt technologies so fast > next time. > > Cheers, > Ola > > > > > > ___ > 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] wip/cmake status information
The idea is to stick to the cmake way. So cmake with a generator of choice,
potential cmake-gui usage to tweak if you’d like and finally the build tool
that corresponds to the generator.
Simon
> On 29. Oct 2018, at 17:58, Tomasz Siekierda wrote:
>
>> On Mon, 29 Oct 2018 at 13:31, Tobias Hunger wrote:
>>
>> Hi!
>> [...]
>> # Building
>>
>> The basic way of building with cmake is as follows:
>>
>> ```
>> cd {build directory}
>> cmake {path to source directory}
>> cmake --build .
>> ```
>
> Just a quick question wrt to that snippet: what is the planed way of
> building Qt after the whole transition is done? Will it be cmake &&
> make, or configure && make, or configure && cmake && make?
> ___
> 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] wip/cmake status information
On Mon, 29 Oct 2018 at 13:31, Tobias Hunger wrote:
>
> Hi!
> [...]
> # Building
>
> The basic way of building with cmake is as follows:
>
> ```
> cd {build directory}
> cmake {path to source directory}
> cmake --build .
> ```
Just a quick question wrt to that snippet: what is the planed way of
building Qt after the whole transition is done? Will it be cmake &&
make, or configure && make, or configure && cmake && make?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
> > > > >> We have been developing Qbs over the last years, and as such are > > >> committed to it for some more time. We are planning on another feature > > >> release in the first quarter of next year and will support it in Qt > > >> Creator for at least another year. > This is _really_ disappointing news. I'd be happy to see qmake go, now this. We (at work, commercial Qt license) recently ported a rather big build system to Qbs, replacing qmake and scons. We now have good IDE integration for all our projects in QtCreator, both the Qt-based applications as well as pure C/C++-based projects for desktop, embedded Linux and "bare metal" embedded. We spent some time debugging and reporting/fixing bugs in Qbs too. Now with Qbs 1.12.0 we're having good and stable results. Incremental builds are _very_ fast. Project files are easy to set up, read and extend, even with custom code generation rules, things we never were able to do with (even undocumented) qmake. It's really impressive. Well I guess all that was for nothing, let's rewrite the build system next year again, and make really sure not to embrace new Qt technologies so fast next time. Cheers, Ola ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Monday, 29 October 2018 13:36:30 PDT Sune Vuorela wrote: > I feel you are using your position as chan op to kick him far too rare. > But I'm not sure where to bring that up. The 15-day ban expired yesterday, so he's back today. Next one will be 45 days. -- 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] QUIP 12: Code of Conduct
On 2018-10-28, Thiago Macieira wrote: > But if it isn't spam, what gives the list moderator the right to intervene in > something that he/she believes is abusive behaviour? Same thing about IRC: we > do have one annoying person who does come along every now and then, but most > of his messages are just that: annoyance. It's only when he uses profanity > that I feel justified in kicking him out of the channel. > > Am I the one abusing my position as channel op to kick him? Am I being > arbitrary? I feel you are using your position as chan op to kick him far too rare. But I'm not sure where to bring that up. /Sune - also these days in favour of a CoC, but has also protested against such things in the past. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Monday, 29 October 2018 13:18:53 PDT André Pönitz wrote: > Currently the Qt Project defines itself as "meritocratic, > consensus-based community interested in Qt". > > After the suggested I fail to see how it can be called either. We'd have to amend to say that unprofessional behaviour (as defined by the CoC) will not be welcome, regardless of how much merit the particular person may have accumulated. -- 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] QUIP 12: Code of Conduct
Hello! I've tried to provide Code of Conduct based on Arch Linux CoC, pasted here: https://paste.kde.org/pzdmvyi3t Will try to send it to codereview later, feel free to do it instead of me if it will be easier for you, I'm going to spend some time to learn how to do it correctly пн, 29 окт. 2018 г. в 22:19, André Pönitz : > On Mon, Oct 29, 2018 at 02:25:20PM +, Ulf Hermann wrote: > > > But then you make a statement in your post script that demonstrates > > > exactly what I'm talking about. You stated "some emails in this > > > thread sadly make me see part of the project in a different light. I > > > fear I'm not the only one."? Would you say the project has created > > > fear in you and this has somehow "harmed" the project in some way? > > > Who were these people that changed your mind? We need to identify > > > these people and ban them because they are not casting the widest > > > inclusive and protective audience and anything less than that is > > > harm... Let the witch hunt begin... right? > > > > All the proposals for codes of conduct that I have seen so far mention > > banning only as a last resort and have several less drastic measures > > that should be applied before. > > That's exactly the way the Project has operated before, without the > suggested burocratic overhead and without giving some committee > super-powers ranking over all other mechanisms in the project. > > Sure, each time when action has to be taken on IRC or by mailing > list moderation, people taking that decision feel somewhat uneasy, > lest they be accused of censorship or similar. But that is *good*, > as it makes people exercise any extra powers very consciously. > > > Also, the point of having a neutral third > > party decide on the issue, rather than people directly involved in the > > conflict should result in that third party deciding on the measurements > > to be taken, not any victims of harassment, harm, or whatever. > > Currently the Qt Project defines itself as "meritocratic, > consensus-based community interested in Qt". > > After the suggested I fail to see how it can be called either. > > 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] QUIP 12: Code of Conduct
On Mon, Oct 29, 2018 at 02:25:20PM +, Ulf Hermann wrote: > > But then you make a statement in your post script that demonstrates > > exactly what I'm talking about. You stated "some emails in this > > thread sadly make me see part of the project in a different light. I > > fear I'm not the only one."? Would you say the project has created > > fear in you and this has somehow "harmed" the project in some way? > > Who were these people that changed your mind? We need to identify > > these people and ban them because they are not casting the widest > > inclusive and protective audience and anything less than that is > > harm... Let the witch hunt begin... right? > > All the proposals for codes of conduct that I have seen so far mention > banning only as a last resort and have several less drastic measures > that should be applied before. That's exactly the way the Project has operated before, without the suggested burocratic overhead and without giving some committee super-powers ranking over all other mechanisms in the project. Sure, each time when action has to be taken on IRC or by mailing list moderation, people taking that decision feel somewhat uneasy, lest they be accused of censorship or similar. But that is *good*, as it makes people exercise any extra powers very consciously. > Also, the point of having a neutral third > party decide on the issue, rather than people directly involved in the > conflict should result in that third party deciding on the measurements > to be taken, not any victims of harassment, harm, or whatever. Currently the Qt Project defines itself as "meritocratic, consensus-based community interested in Qt". After the suggested I fail to see how it can be called either. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] wip/cmake status information
On Mon, Oct 29, 2018 at 6:21 PM Sérgio Martins wrote: > I'm wondering if you have any performance numbers regarding > incremental builds on Windows, and specially "nmake install", which > currently takes *several* minutes for qtbase alone. Through ETW I > noticed it's due to hundreds of qmake processes being created, so I > guess the problem is gone now :) Not yet. So far too much is missing to do a meaningful comparisons. Best Regards, Tobias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString
Mitch Curtis (29 October 2018 17:42) > To solve #2, I first tried simply saving a QVariant containing a > QByteArray (the contents of which were QDataStream's output). This > didn't work because Qt's JSON implementation doesn't support > QByteArray; it only supports QString. That is, calling > QJsonObject::fromVariantMap(map) where "map" contains a QVariant > containing a QByteArray will result in the corresponding JSON value > being invalid/null. I'm not sure where JSON got involved in that, but if you can manage to use CBOR instead, it's just as happy with QByteArray as with QString (and round-trips them to QByteArray, IIRC). For details, see qtbase/src/corelib/serialization/qcborstream.h I've also no idea how well it plays with QSettings; hopefully you know enough to work it out from the QCbor API ... Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
In a context of witch-hunts against even allegations of minimal harm, NIkolai Marchenko (26 October 2018 20:17) wrote >> And we already see the budding sentiments to that exact tune: >> (quote from Edward Welbourne) >>> That sometimes folk have felt so intimidated that they give up on >>> trying to make a contribution; and that, were potential worse >>> conduct to cause distress to a contributor, we have no process in >>> place that could give them confidence that their distress will be >>> respected and honest efforts will be made to relieve it. Various >>> variations and permutations on these themes may also be relevant; >>> see Simon's mail. >> Note: I understand that he means well, but Within the context of >> Contributor Covenant the punishability of the potential harm of >> people not contributing can escalate to stupid proportions. I have >> nothing against KDE's code. It strives to add positivity. I am very >> much against Qt's CoC being drafted from Covenant. Covenant is >> focused on oppression and excluding ppl. Just to be clear: I was speaking of the case for having *a* code of conduct and a publicly-described process around coaxing folk into honouring it. In particular, I'm not particularly attached to the present wording, nor do I know more than the present discussion has (since I wrote the above) told me about the Contributors' Covenant on which it is based. What I asked for was a process that a contributor can turn to, with reasonable hopes of being heard and getting help, if they feel persecuted. If their feelings of persecution are not anchored in any actual conduct by a community member that actually persecutes them I am all for the process (politely and respectfully) teaching them to not feel persecuted when they aren't being persecuted. I am firmly in favour of the code of conduct's associated processes being proportionate, precisely so that they avoid any objection to an alleged or potential harm escalating "to stupid proportions". I do, indeed, find the Covenant-derived wording and process somewhat heavy-handed and hope I shall soon find the time to read the KDE CoC, of which several voices here have spoken favourably. I'm in favour of *a* code of conduct, and associated processes, precisely if it assures folk who deal with this community of reasonable and respectful treatment. It rather sounds as if the Contributors' Covenant (or, at least, the history of how it's been used) undermines your confidence that you'll be treated reasonably and respectfully, if what we adopt is based on it. Please make the case for that, rather than imputing that I am a preparing the way (however unwittingly) for witch-finders ;^> Jason H (29 October 2018 17:42) ended a recent missive with: > I've asked repeatedly for very specific definitions and standards of > things to be considered. This would go along way to getting my > approval. I will always resist an ambiguous judgements on ambiguous > standards. The process should be transparent to those involved in it, > such that you should know how it will turn out before entering into > the process. I don't think ambiguity serves anyone justly. Specifics are exactly what the code review is for. Come join us at: https://codereview.qt-project.org/243623 I assure you, you are not alone in wanting this thing nailed down tidily enough that there aren't loose flaps under which Aliens with Agendas (whether of the left or the right, whether progressive or reactionary) can slip in and work mischief for our community, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Metatype system in Qt6
On 10/29/18 5:39 PM, Jedrzej Nowacki wrote: Hi everyone! While main heat on the mailing list is taken by topic how to encode that we are nice, friendly and respectful to each other, I would like to show some side project that I had. It is a proposal for base of metatype system for Qt6. You can look and comment at it here: https://github.com/nierob/qmetatype. It is quite fresh and it was rather a storage for functionality ideas. I haven't tried to compare performance of it to the current system, but for sure it has more flexibility and I believe, that conceptually it could serve us during Qt6. Anyway before spending too much time on it I would like to get some early feedback and questions. The discussion in that other thread are not finished, so please wait until there is consensus before being nice! But thanks for caring about the QMetaType system. I had a short look. I think it would be usefull if you already used names closer to what they are supposed to be. Namespace N, P, are not so nice names. The idea of using a single function with operation is quite a good idea I like it. As long as the function takes the typeid as a parameter. Indeed, I'm thinking about dynamic types that would come from language bindings: in this situation, while it is easy to allocate memory on the heap, it is not easy to create a new function pointer for every dynamic type that we would register. Regarding the extension, i don't know if it is such a good idea, because you never know what you can rely on. say you have a QVariant with some type that comes from some part of your code, how do you know if you can print it with qDebug, or convert it to string, how do you register that? IMHO, there should not be extensions! All operation that we want to make available for a type should be always available. Using SFINAE to find out if it is available. So what are the operation we want on a QMetaType: - for QVariant, and the queued connections: copy / destruction. Ideally in place. So we also need the size/alignement to be able to allocate the memory - for qDebug, we need the QDebug operator << - for QDataStream, we need the operator << and >>, and an unique identifier that stay the same. Currently, this is the type id for builtin types, and the name for custom type. I suggest we use the name, if we want to keep compatibility with old steam, we will need to keep a mapping from old type id, to new name. As for the name, we can indeed find a way to extract it from parsing it from __PRETTY_FUNC__ as you do. It would work on every compiler we support i guess, but we need spcial code for that as it is not really standard. In Qt5, we also need the name for the string-based connection syntax. However, I believe we can do that without relying on the name "as-seen-by-moc", if the moc generated code always register the types. (this is already almost the case) - What about QSequentialIterable / QAssociativeIterable? We also need something there. In the design document you say: > The whole registry is kept behind a mutex and it is very central, the mutex > usage actually shows on profilers. This used to be the case before Qt 5.7, but since then, QReadWriteMutex was greatly optimized, does it still show in the profiler? You will need that anyway, because relying on a static variable in a function template does not work on MSVC as far as i know. (Last time i tried was a long time ago, and they had different address and value in different libraries) That's why we will probably need to initialize it with a name lookup. It is probably still a good idea to register builtin type at compile time, since we want to save in registering time. There are some data structures out there with compile time hash table that can be extended at runtime. So the early feedback i can give on your code is that it is a bit more complicated than necessary with the extension. and i think it can be simplified. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] wip/cmake status information
On Mon, Oct 29, 2018 at 12:31 PM Tobias Hunger wrote: > > Hi! > > Some technical details on the wip/cmake branch in Gerrit. You can also > find this information in cmake/README.md there. I'm wondering if you have any performance numbers regarding incremental builds on Windows, and specially "nmake install", which currently takes *several* minutes for qtbase alone. Through ETW I noticed it's due to hundreds of qmake processes being created, so I guess the problem is gone now :) Thanks, and nice work everyone! Regards, Sérgio Martins ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Hi all, I would like to thank the people who have started this discussion. For me this is a very positive thing and a step forward for the Qt community. I really enjoy being part of the community. I want it to continue to be the great group of people that it is today. And hopefully bigger, more diverse and inclusive going forward. I am very sure that a big silent majority does support this initiative. Again, thank you! Reading through the mails (an impressive amount), I feel there is consensus towards the KDE CoC. I also appreciate the positive wording. Maybe we don't need many more mails in this thread, I have the feeling we will not discover a whole lot of new information at this point. I'd like us to move on to the next constructive phase of this process. Let's adopt the more positively phrased CoC from KDE. It is under a license that allows us to use it and is clearly meant to be picked up by others. I am happy that so many people have strong opinions on our culture and value it. For me this is about culture, how we treat each other. That is what being a community is all about. We have a common goal - making Qt the best it can be, and nobody is able to do that alone. We will always have some style of communication in the project. I am happy when I see positive reviews. In my opinion that can be a -1 with good comments which problems to address. Let's set ourselves a high standard, on the communication side as well as on the technical one. I hope we use this as an opportunity to remind ourselves that in reviews we should give ideas what to improve (and how). Reviews are important to share knowledge, which is important to us as community. In emails we should be respectful, on the forums sensible and so on. I think we mostly succeed nowadays. Moving on... we should find out how to deal with the occasional problems that might arise. I do think that we want to establish some form of enforcement. I firmly believe that the first means of action in all cases will be an email or two, just to clarify the situation. Maybe a phone call. Often enough conflicts turn out to be small misunderstandings and we want a reasonable small group of people that keeps things confidential and just nudges people to talk to each other and move on. Only when everything goes wrong should stronger measures ever be considered. Thus we want a group we can trust with making sensible decisions in how to uphold the CoC. I would want them to have some diplomatic skills, respect privacy and be sensitive to different cultures - good communicators. Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Hi Volker, I think you ask a very good question. "If someone like Coraline were to direct her energy to the Qt Project, how much in the open would you want their efforts to be? Or would you rather simply trust that there are not enough maintainers in the Qt project that would fall for their chain of arguments and backdoor schemings?" Let's break that down. "If someone like Coraline were to direct her energy to the Qt Project" - 1) If by energy you mean, she wants to contribute, I would not have a problem with her participation despite me not agreeing with her previous behavior. Contributions would be judged on technical merits alone. 2) If by energy you mean a witch hunt, then it should be done publicly as to add to her existing history. 3) If by energy you mean a "legitimate complaint" then I guess it would depend on the nature of her claims. If the items of transgression are Qt community items, then it's already in public. If things were done in private then it would be debatable what influence the Qt community resolution process would have. So I don't have a clear answer for you, but that should set up some kind of framework. The agreement on venue is difficult. I could both see wanting public resolution or private resolution, and I can't even typify that based on scenario. Admittedly, I don't understand the last part of your question. "simply trust that there are not enough maintainers in the Qt project that would fall for their chain of arguments and backdoor schemings". Previously I suggested that the people selected to judge the process be entirely at random to prevent politicisation of the decision makers. And also evidence should only be considered if on a Qt community property. At the same time, these incidents may have confidential information, which should be protected from public disclosure. I think all of that fell on deaf ears? I've asked repeatedly for very specific definitions and standards of things to be considered. This would go along way to getting my approval. I will always resist an ambiguous judgements on ambiguous standards. The process should be transparent to those involved in it, such that you should know how it will turn out before entering into the process. I don't think ambiguity serves anyone justly. > Sent: Monday, October 29, 2018 at 11:33 AM > From: "Volker Hilsheimer" > To: "Jason H" > Cc: "Lydia Pintscher" , "Qt development mailing list" > > Subject: Re: [Development] QUIP 12: Code of Conduct > > Hey Jason, > > > You seem to assume that without a code of conduct there is no way that people > can get banned. That is not the case. In practice, people can be kicked out > of the Qt Project by the folks that control the respective systems. And by > extension by those who have some influence over those people. > > You call that “self-policing”, but in fact it’s about us trusting that the > folks that have those privileges do not abuse their power. That’s great as > long as it works, but if the project somehow does become “more political”, > then I do think this lack of transparency is not in the interest of the > project. > > A CoC tries to formulate what environment we want our behaviors to create, > and it establishes a less opaque process for managing situations where an > individual seems to do more harm than good to the project. > > That doesn’t mean that there won’t be mistakes. It doesn’t take much to cause > someone distress through an email or a quick comment to their code, esp when > we want to include people that are regularly exposed to all sorts of > harassment, and are not quite as thick-skinned and self-assured as you and I > might be. But I think that, by simply establishing a CoC that community > members agree to, we can create an atmosphere where even a rough piece of > language is received in the spirit of collaboration. > > And that also doens’t mean that there won’t be abuse. I’m sure there are > people that have made it a way of life to be offended. However, they do not > need a Code of Conduct (which is not a legal document anyway). I’d rather > have them raise their voice in the open, and direct them towards a > transparent process, than to have them use backdoor tactics to get influence > over the project. > > The question to you is then: If someone like Coraline were to direct her > energy to the Qt Project, how much in the open would you want their efforts > to be? Or would you rather simply trust that there are not enough maintainers > in the Qt project that would fall for their chain of arguments and backdoor > schemings? > > > Volker > > > > On 29 Oct 2018, at 15:10, Jason H wrote: > > > > Lydia, > > > > First, let me say I've stated my support of the KDE CoC. Thank you for your > > effort in it. > > > > But then you make a statement in your post script that demonstrates exactly > > what I'm talking about. You stated "some emails in this thread sadly make > > me
[Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString
Hi.
I'm trying to sort out some way of saving SplitView's (Qt Quick Controls 2)
state. The goals that I have are:
#1 Allow SplitView's state to easily be saved to QSettings. That's covered by
the patch in its current form.
#2 Allow SplitView's state to easily be saved to a custom project file, so that
applications that need to save UI state on a per-project basis can do so.
Both of these should be doable in QML (besides the IO-related details of saving
to a custom project file).
So far, my patch bases its API on that of QMainWindow. Here's the usage
documentation showing how it's currently done in QML:
https://codereview.qt-project.org/gitweb?p=qt/qtquickcontrols2.git;a=blob;f=src/quicktemplates2/qquicksplitview.cpp;h=6c5f72b1952e58f3f9c956ac129fc221a3017cb4;hb=4cdc2942c69a15484a65d7c8a48b1f129d7bd3d0#l194
Here's the implementation:
https://codereview.qt-project.org/gitweb?p=qt/qtquickcontrols2.git;a=blob;f=src/quicktemplates2/qquicksplitview.cpp;h=6c5f72b1952e58f3f9c956ac129fc221a3017cb4;hb=4cdc2942c69a15484a65d7c8a48b1f129d7bd3d0#l1143
Here's what QMainWindow does:
http://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/widgets/qmainwindow.cpp?h=dev=00b2e45a97205975ee91aa43f00e3dbef1a8907b#n1240
To solve #2, I first tried simply saving a QVariant containing a QByteArray
(the contents of which were QDataStream's output). This didn't work because
Qt's JSON implementation doesn't support QByteArray; it only supports QString.
That is, calling QJsonObject::fromVariantMap(map) where "map" contains a
QVariant containing a QByteArray will result in the corresponding JSON value
being invalid/null.
I thought that I could get around this by using Qt.atob() and Qt.btoa() in QML
to convert the byte array into a Base64 QString, but it turns out that those
functions expect a string:
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qqmlbuiltinfunctions.cpp?h=5.12=475c74a9926efcd968572563e678988e53804603#n996
Running the attached project gives the following output:
created QString from SplitView state: QVariant(QByteArray,
"\x00\x00\x00{\x01")
qml: Saved state in QML as QVariant(QByteArray):
qml: Converted state in QML to a Base64 string:
expected base64 string in a QVariant, got: QVariant(QString, "")
qml: Converted state in QML from Base64 string to QVariant(QByteArray):
in C++, state from QML is: QVariant(QString, "")
read i as 0 and b as false
So now I'm considering what I should do. I'm thinking about making SplitView
convert the QByteArray it creates with QDataStream into a Base64 QString and
returning that instead. That can still be saved in QSettings, and can easily be
used by both Qt's JSON implementation and Qt.atob() and Qt.btoa(). However, I
understand that Base64 encoding can result in slightly larger strings when used
on small input (which SplitView's serialisable state will typically be).
With these uncertainties, I thought I'd ask what others think of my proposed
approach, and if there are any better ways to solve this.
Cheers.
<>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
I've got your idea. My personal position for now is probably more like do not promise things you can't keep. I still have no doubts about Qt and KDE people professionalism. I agree discrimination solving is very important idea. But I guess it probably should be solved via some additional international organization. Such organization could be focused specifically on that, while technical communities like KDE and Qt project could follow it. I want to thank Lydia too for sharing details about approximate number of the situations. I could not interpret it as "good or bad" for the community with current details, but I guess it could be helpful for future comparition. пн, 29 окт. 2018 г. в 18:40, Thiago Macieira : > On Monday, 29 October 2018 00:52:49 PDT Alexey Andreyev wrote: > > Talking about CC and KDE's CoC, it's not obvious for me how to perform > > politics, religion, race, etc -- harassment protection correctly at > > international digital community with provided rules. > > I'm not saying we don't need rules. You said KDE's version looks better > > comparing to CC. Archlinux version looks even better for me. > > > > Anyway, I'm not a professional at such social tasks and want to step > back. > > I do not want to look like annoying person, just wanted to help with > > controversial subjects. > > I have no doubts about Qt people professionalism and happy do be a part > of > > the community. > > For me, the fact that it doesn't say we'll try to address those problems > that > are currently extant in many communities (though, hopefully, not ours), > ArchLinux's CoC is inferior to KDE's. I'd like a text that says states the > goals we'll strive for, not just what we can be sure of. > > -- > 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Metatype system in Qt6
Hi everyone! While main heat on the mailing list is taken by topic how to encode that we are nice, friendly and respectful to each other, I would like to show some side project that I had. It is a proposal for base of metatype system for Qt6. You can look and comment at it here: https://github.com/nierob/qmetatype. It is quite fresh and it was rather a storage for functionality ideas. I haven't tried to compare performance of it to the current system, but for sure it has more flexibility and I believe, that conceptually it could serve us during Qt6. Anyway before spending too much time on it I would like to get some early feedback and questions. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
Yup, it's a sad day for people who liked QBS. Personally I'll check GN, which has a nice syntax, not as nice as QBS but ... :) . În ziua de luni, 29 octombrie 2018, la 18:32:11 EET, Ray Donnelly a scris: > Agreed, a brilliant bit of technology, such a shame to see it deprecated. > > On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: > > Having had the pleasure to use QBS quite extensively (and successfully) in > > the past, I would like to thank the QBS team and contributors for showing > > us what a sane, modern build system could look like. So long! > > > > On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: > >> Hi all, > >> > >> As you will probably remember, there have been lively discussions around > >> what kind of build tool to use for Qt 6 both during Qt Contributor > >> Summits as well as on this mailing list. > >> > >> There has been a strong consent that we should move away from qmake as > >> our build tool for Qt due to many shortcomings and the burden we have > >> maintaining the system. > >> > >> Thiago wrote a set of relatively strict requirements for such a build > >> tool in his mail in July. While some of the requirements had a bit of a > >> Linux specific background, they have been a good basis. > >> > >> There have been rather lively discussions around alternatives, but most > >> focused around two possible choices for us: Qbs and cmake. > >> > >> Qbs is something that has been developed almost exclusively by The Qt > >> Company. As such, TQtC had to also look at it from a business > >> perspective and how it fits into the larger picture of making Qt > >> successful. To make a long story short, while Qbs is pretty cool and > >> interesting technology, it doesn’t really help us expand the Qt > >> ecosystem and usage. > >> > >> To make Qbs really successful would require a rather large effort and > >> investment in promoting it towards the larger C++ ecosystem as a new > >> build tool. At the same time it has to be an open source product to > >> stand any chance in the market. Together this makes it challenging for > >> TQtC to see how to recover that investment. Thus this investment would > >> be at the expense of other things we’d like to do, like improving our > >> IDE, working on rearchitecting and cleaning up our core frameworks for > >> Qt 6 or the design tooling we are currently investing into. The Qt > >> Company believes that those other investments are more important for the > >> future of Qt than our choice of build tool. > >> > >> As such, we were left with the question on whether we need Qbs as the > >> build system for Qt 6 or whether cmake (as the other alternative) would > >> be up to the task. > >> > >> Given that background, we’ve done some more research on using both Qbs > >> and cmake to build Qt. Both projects did give us good results but we > >> were actually surprised on how far we got with cmake in a rather limited > >> period of time. > >> > >> In addition, cmake has the advantage of being very widely used in the C++ > >> ecosystem (amongst many others by KDE), has a very wide support in many > >> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of > >> knowledge about the build system available in the ecosystem. Using it > >> with Qt 6 would also mean that we can focus our support on two build > >> systems for our users (qmake and cmake) and we would not have to add a > >> third one to the mix. > >> > >> Given that we are confident we can build Qt 6 with cmake, I believe that > >> it makes most sense to follow down that route. In case you’re > >> interested, you can have a look at the cmake prototype code for qtbase > >> on Gerrit in the wip/cmake branch. Please also let us know if you’re > >> interested in helping with the effort of porting Qt’s build system over > >> to cmake. > >> > >> We have been developing Qbs over the last years, and as such are > >> committed to it for some more time. We are planning on another feature > >> release in the first quarter of next year and will support it in Qt > >> Creator for at least another year. Qbs is open source and if someone > >> wants to take over and develop it further let us know as well. I’d also > >> like to use this place to thank Christian and Jörg for all their great > >> work on Qbs (and of course also anybody else who contributed to it). > >> > >> Cheers, > >> Lars > >> ___ > >> 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
Re: [Development] Build system for Qt 6
RIP Qbs=( Иван Комиссаров > 29 окт. 2018 г., в 17:32, Ray Donnelly написал(а): > > Agreed, a brilliant bit of technology, such a shame to see it deprecated. >> On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: >> >> >> Having had the pleasure to use QBS quite extensively (and successfully) in >> the past, I would like to thank the QBS team and contributors for showing us >> what a sane, modern build system could look like. >> So long! >> >>> On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: >>> >>> Hi all, >>> >>> As you will probably remember, there have been lively discussions around >>> what kind of build tool to use for Qt 6 both during Qt Contributor Summits >>> as well as on this mailing list. >>> >>> There has been a strong consent that we should move away from qmake as our >>> build tool for Qt due to many shortcomings and the burden we have >>> maintaining the system. >>> >>> Thiago wrote a set of relatively strict requirements for such a build tool >>> in his mail in July. While some of the requirements had a bit of a Linux >>> specific background, they have been a good basis. >>> >>> There have been rather lively discussions around alternatives, but most >>> focused around two possible choices for us: Qbs and cmake. >>> >>> Qbs is something that has been developed almost exclusively by The Qt >>> Company. As such, TQtC had to also look at it from a business perspective >>> and how it fits into the larger picture of making Qt successful. To make a >>> long story short, while Qbs is pretty cool and interesting technology, it >>> doesn’t really help us expand the Qt ecosystem and usage. >>> >>> To make Qbs really successful would require a rather large effort and >>> investment in promoting it towards the larger C++ ecosystem as a new build >>> tool. At the same time it has to be an open source product to stand any >>> chance in the market. Together this makes it challenging for TQtC to see >>> how to recover that investment. Thus this investment would be at the >>> expense of other things we’d like to do, like improving our IDE, working on >>> rearchitecting and cleaning up our core frameworks for Qt 6 or the design >>> tooling we are currently investing into. The Qt Company believes that those >>> other investments are more important for the future of Qt than our choice >>> of build tool. >>> >>> As such, we were left with the question on whether we need Qbs as the build >>> system for Qt 6 or whether cmake (as the other alternative) would be up to >>> the task. >>> >>> Given that background, we’ve done some more research on using both Qbs and >>> cmake to build Qt. Both projects did give us good results but we were >>> actually surprised on how far we got with cmake in a rather limited period >>> of time. >>> >>> In addition, cmake has the advantage of being very widely used in the C++ >>> ecosystem (amongst many others by KDE), has a very wide support in many >>> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of >>> knowledge about the build system available in the ecosystem. Using it with >>> Qt 6 would also mean that we can focus our support on two build systems for >>> our users (qmake and cmake) and we would not have to add a third one to the >>> mix. >>> >>> Given that we are confident we can build Qt 6 with cmake, I believe that it >>> makes most sense to follow down that route. In case you’re interested, you >>> can have a look at the cmake prototype code for qtbase on Gerrit in the >>> wip/cmake branch. Please also let us know if you’re interested in helping >>> with the effort of porting Qt’s build system over to cmake. >>> >>> We have been developing Qbs over the last years, and as such are committed >>> to it for some more time. We are planning on another feature release in the >>> first quarter of next year and will support it in Qt Creator for at least >>> another year. Qbs is open source and if someone wants to take over and >>> develop it further let us know as well. I’d also like to use this place to >>> thank Christian and Jörg for all their great work on Qbs (and of course >>> also anybody else who contributed to it). >>> >>> Cheers, >>> Lars >>> ___ >>> 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] Build system for Qt 6
I too feel like thanks are in order to the Qbs team. Hopefully CMake integration with QtCreator will quickly improve and include mobile platforms as well as embedded and desktop. Il giorno lun 29 ott 2018 alle ore 17:24 Corentin ha scritto: > > Having had the pleasure to use QBS quite extensively (and successfully) in > the past, I would like to thank the QBS team and contributors for showing > us what a sane, modern build system could look like. > So long! > > On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: > >> Hi all, >> >> As you will probably remember, there have been lively discussions around >> what kind of build tool to use for Qt 6 both during Qt Contributor Summits >> as well as on this mailing list. >> >> There has been a strong consent that we should move away from qmake as >> our build tool for Qt due to many shortcomings and the burden we have >> maintaining the system. >> >> Thiago wrote a set of relatively strict requirements for such a build >> tool in his mail in July. While some of the requirements had a bit of a >> Linux specific background, they have been a good basis. >> >> There have been rather lively discussions around alternatives, but most >> focused around two possible choices for us: Qbs and cmake. >> >> Qbs is something that has been developed almost exclusively by The Qt >> Company. As such, TQtC had to also look at it from a business perspective >> and how it fits into the larger picture of making Qt successful. To make a >> long story short, while Qbs is pretty cool and interesting technology, it >> doesn’t really help us expand the Qt ecosystem and usage. >> >> To make Qbs really successful would require a rather large effort and >> investment in promoting it towards the larger C++ ecosystem as a new build >> tool. At the same time it has to be an open source product to stand any >> chance in the market. Together this makes it challenging for TQtC to see >> how to recover that investment. Thus this investment would be at the >> expense of other things we’d like to do, like improving our IDE, working on >> rearchitecting and cleaning up our core frameworks for Qt 6 or the design >> tooling we are currently investing into. The Qt Company believes that those >> other investments are more important for the future of Qt than our choice >> of build tool. >> >> As such, we were left with the question on whether we need Qbs as the >> build system for Qt 6 or whether cmake (as the other alternative) would be >> up to the task. >> >> Given that background, we’ve done some more research on using both Qbs >> and cmake to build Qt. Both projects did give us good results but we were >> actually surprised on how far we got with cmake in a rather limited period >> of time. >> >> In addition, cmake has the advantage of being very widely used in the C++ >> ecosystem (amongst many others by KDE), has a very wide support in many >> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of >> knowledge about the build system available in the ecosystem. Using it with >> Qt 6 would also mean that we can focus our support on two build systems for >> our users (qmake and cmake) and we would not have to add a third one to the >> mix. >> >> Given that we are confident we can build Qt 6 with cmake, I believe that >> it makes most sense to follow down that route. In case you’re interested, >> you can have a look at the cmake prototype code for qtbase on Gerrit in the >> wip/cmake branch. Please also let us know if you’re interested in helping >> with the effort of porting Qt’s build system over to cmake. >> >> We have been developing Qbs over the last years, and as such are >> committed to it for some more time. We are planning on another feature >> release in the first quarter of next year and will support it in Qt Creator >> for at least another year. Qbs is open source and if someone wants to take >> over and develop it further let us know as well. I’d also like to use this >> place to thank Christian and Jörg for all their great work on Qbs (and of >> course also anybody else who contributed to it). >> >> Cheers, >> Lars >> ___ >> 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 > -- https://liri.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
Agreed, a brilliant bit of technology, such a shame to see it deprecated. On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: > > > Having had the pleasure to use QBS quite extensively (and successfully) in > the past, I would like to thank the QBS team and contributors for showing us > what a sane, modern build system could look like. > So long! > > On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: >> >> Hi all, >> >> As you will probably remember, there have been lively discussions around >> what kind of build tool to use for Qt 6 both during Qt Contributor Summits >> as well as on this mailing list. >> >> There has been a strong consent that we should move away from qmake as our >> build tool for Qt due to many shortcomings and the burden we have >> maintaining the system. >> >> Thiago wrote a set of relatively strict requirements for such a build tool >> in his mail in July. While some of the requirements had a bit of a Linux >> specific background, they have been a good basis. >> >> There have been rather lively discussions around alternatives, but most >> focused around two possible choices for us: Qbs and cmake. >> >> Qbs is something that has been developed almost exclusively by The Qt >> Company. As such, TQtC had to also look at it from a business perspective >> and how it fits into the larger picture of making Qt successful. To make a >> long story short, while Qbs is pretty cool and interesting technology, it >> doesn’t really help us expand the Qt ecosystem and usage. >> >> To make Qbs really successful would require a rather large effort and >> investment in promoting it towards the larger C++ ecosystem as a new build >> tool. At the same time it has to be an open source product to stand any >> chance in the market. Together this makes it challenging for TQtC to see how >> to recover that investment. Thus this investment would be at the expense of >> other things we’d like to do, like improving our IDE, working on >> rearchitecting and cleaning up our core frameworks for Qt 6 or the design >> tooling we are currently investing into. The Qt Company believes that those >> other investments are more important for the future of Qt than our choice of >> build tool. >> >> As such, we were left with the question on whether we need Qbs as the build >> system for Qt 6 or whether cmake (as the other alternative) would be up to >> the task. >> >> Given that background, we’ve done some more research on using both Qbs and >> cmake to build Qt. Both projects did give us good results but we were >> actually surprised on how far we got with cmake in a rather limited period >> of time. >> >> In addition, cmake has the advantage of being very widely used in the C++ >> ecosystem (amongst many others by KDE), has a very wide support in many IDEs >> and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge >> about the build system available in the ecosystem. Using it with Qt 6 would >> also mean that we can focus our support on two build systems for our users >> (qmake and cmake) and we would not have to add a third one to the mix. >> >> Given that we are confident we can build Qt 6 with cmake, I believe that it >> makes most sense to follow down that route. In case you’re interested, you >> can have a look at the cmake prototype code for qtbase on Gerrit in the >> wip/cmake branch. Please also let us know if you’re interested in helping >> with the effort of porting Qt’s build system over to cmake. >> >> We have been developing Qbs over the last years, and as such are committed >> to it for some more time. We are planning on another feature release in the >> first quarter of next year and will support it in Qt Creator for at least >> another year. Qbs is open source and if someone wants to take over and >> develop it further let us know as well. I’d also like to use this place to >> thank Christian and Jörg for all their great work on Qbs (and of course >> also anybody else who contributed to it). >> >> Cheers, >> Lars >> ___ >> 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] Build system for Qt 6
Having had the pleasure to use QBS quite extensively (and successfully) in the past, I would like to thank the QBS team and contributors for showing us what a sane, modern build system could look like. So long! On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: > Hi all, > > As you will probably remember, there have been lively discussions around > what kind of build tool to use for Qt 6 both during Qt Contributor Summits > as well as on this mailing list. > > There has been a strong consent that we should move away from qmake as our > build tool for Qt due to many shortcomings and the burden we have > maintaining the system. > > Thiago wrote a set of relatively strict requirements for such a build tool > in his mail in July. While some of the requirements had a bit of a Linux > specific background, they have been a good basis. > > There have been rather lively discussions around alternatives, but most > focused around two possible choices for us: Qbs and cmake. > > Qbs is something that has been developed almost exclusively by The Qt > Company. As such, TQtC had to also look at it from a business perspective > and how it fits into the larger picture of making Qt successful. To make a > long story short, while Qbs is pretty cool and interesting technology, it > doesn’t really help us expand the Qt ecosystem and usage. > > To make Qbs really successful would require a rather large effort and > investment in promoting it towards the larger C++ ecosystem as a new build > tool. At the same time it has to be an open source product to stand any > chance in the market. Together this makes it challenging for TQtC to see > how to recover that investment. Thus this investment would be at the > expense of other things we’d like to do, like improving our IDE, working on > rearchitecting and cleaning up our core frameworks for Qt 6 or the design > tooling we are currently investing into. The Qt Company believes that those > other investments are more important for the future of Qt than our choice > of build tool. > > As such, we were left with the question on whether we need Qbs as the > build system for Qt 6 or whether cmake (as the other alternative) would be > up to the task. > > Given that background, we’ve done some more research on using both Qbs and > cmake to build Qt. Both projects did give us good results but we were > actually surprised on how far we got with cmake in a rather limited period > of time. > > In addition, cmake has the advantage of being very widely used in the C++ > ecosystem (amongst many others by KDE), has a very wide support in many > IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of > knowledge about the build system available in the ecosystem. Using it with > Qt 6 would also mean that we can focus our support on two build systems for > our users (qmake and cmake) and we would not have to add a third one to the > mix. > > Given that we are confident we can build Qt 6 with cmake, I believe that > it makes most sense to follow down that route. In case you’re interested, > you can have a look at the cmake prototype code for qtbase on Gerrit in the > wip/cmake branch. Please also let us know if you’re interested in helping > with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are committed > to it for some more time. We are planning on another feature release in the > first quarter of next year and will support it in Qt Creator for at least > another year. Qbs is open source and if someone wants to take over and > develop it further let us know as well. I’d also like to use this place to > thank Christian and Jörg for all their great work on Qbs (and of course > also anybody else who contributed to it). > > Cheers, > Lars > ___ > 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] QUIP 12: Code of Conduct
> I think we have two camps: > We want a CoC as a feel-good statement of inclusion and tolerance (I think everyone is > committed to this) > AND > 1) We want to use existing situation of laws/self-policing OR > 2) We want a CoC that contains a framework that can get people banned or more Hello, Jason! What do you say about Archlinux CoC? [1] For me it's probably an option to explicitly say at new CoC that "witch hunt" questions from your terminology is not a task for a technical project itself. See part 2.3.3 among others. [1]: https://wiki.archlinux.org/index.php/Code_of_conduct пн, 29 окт. 2018 г. в 17:11, Jason H : > Lydia, > > First, let me say I've stated my support of the KDE CoC. Thank you for > your effort in it. > > But then you make a statement in your post script that demonstrates > exactly what I'm talking about. You stated "some emails in this thread > sadly make me see part of the project in a different light. I fear I'm not > the only one."? Would you say the project has created fear in you and this > has somehow "harmed" the project in some way? Who were these people that > changed your mind? We need to identify these people and ban them because > they are not casting the widest inclusive and protective audience and > anything less than that is harm... Let the witch hunt begin... right? > > Everyone, > This is the slippery slope that I'm talking about accusations start in > wide-abstractions like your statement and devolve into direct accusations. > While no one yet here has the motivation to conduct a witch hunt, we cannot > assume that will be the case. So far common sense has prevailed, but common > sense is, well, uncommon. It may be that Cone day oraline et. al. go on a > witch hunt for those the opposed her Covenant. > > I've spent some time thinking about this this weekend. Here's what I don't > get. Coraline authored the CC. She then goes into projects attacking them > with it, but fortunately(?) it hasn't worked. But to put it a different > way, if I design an instrument, publish the plans, and try to use it in a > community, if it doesn't work, is it the instrument or the user that is at > fault? If that instrument is intended to be destructive (say like a bomb), > then can we see how she really means for this to be used? To my knowledge > none of the people singled out in the witch hunts actually did anything > offensive in the projects they were participating in. > > It could be that eventually those who opposed the CoC in some way get > labeled as "intolerant" by the larger community. Lydia's statement has > already given me pause in this regard and I'm not being hyperbolic. > Political views, and things we don't consider as political today, can > eventually become political. > > I think we have two camps: > We want a CoC as a feel-good statement of inclusion and tolerance (I think > everyone is committed to this) > AND > 1) We want to use existing situation of laws/self-policing OR > 2) We want a CoC that contains a framework that can get people banned or > more > > I've always assumed that there was some line that could be crossed that > would get your accounts shut down and removed from the community. If > someone makes it so that the community cannot function, in whole or in > part, then removal is warranted. These Codes of Conducts lower the barrier > to an incredibly low bar and don't say what lower threshold of "harm" is > needed to run afoul. I haven't even had a response as to if it is perceived > or demonstrable harm that is required. > > So far cooler heads and common sense have prevailed, but I don't trust > that will always be the case. This is why if we go with a CoC that can > prescribe punishments, that it be explicit both in determination and > punishment stages. > > > *Not that I have anything against witches. I have several wiccan friends. > Is the term "witch hunt" offensive? Can I get banned for using that term > now or in the future? > > > > Sent: Sunday, October 28, 2018 at 7:53 PM > > From: "Lydia Pintscher" > > To: development@qt-project.org > > Subject: Re: [Development] QUIP 12: Code of Conduct > > > > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > > wrote: > > > And I'm pretty sure the KDE Community WG can easily compile a list of > times > > > that they were maliciously asked to look into situations and how much > time it > > > took them to give it the attention it was due. > > > > I don't have an exact number but less than 10. And we could always > > deal with it very quickly thanks to some common sense and good > > knowledge of the situation and people involved. No big deal. > > > > (For those who don't know me: I'm one of the people who wrote KDE's > > CoC and has been a member of it's community working group since then. > > I'm also the current president of the non-profit behind KDE.) > > If you have further questions about KDE's Code of Conduct please let > > me know. I'm happy to answer them. > > > > > > Cheers > > Lydia > > > >
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On 2018-10-29 15:56, Thiago Macieira wrote: On Monday, 29 October 2018 04:43:09 PDT Olivier Goffart wrote: > 1) it will copy containers. For Qt containers, that's rather cheap (two > atomic refcount operations), but it's not free. And for Standard Library > containers, that is likely very expensive. But using for(:) with a Qt container will cause a detach in the most common case, so I'd say is even worse. Which is why i'm saying using this reason is a bit ironic. True, which is why we didn't deprecate, but did add qAsConst. > 2) it's implemented by way of a for loop inside a for loop, which is known > to throw optimisers out, generating slightly worse code I would consider that the missed optimization is quite small, if not negligible. And it can be solved in C++17: https://codereview.qt-project.org/243984/ I'd solve this the other way around, by making the macro: if (const auto &_container_ = (container); true) \ for (variable : _container_) That's not behaviour-compatible and will introduce bugs where users rely on iterating over a copy. Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On 10/29/18 4:56 PM, Thiago Macieira wrote: 2) it's implemented by way of a for loop inside a for loop, which is known to throw optimisers out, generating slightly worse code I would consider that the missed optimization is quite small, if not negligible. And it can be solved in C++17: https://codereview.qt-project.org/243984/ I'd solve this the other way around, by making the macro: if (const auto &_container_ = (container); true) \ for (variable : _container_) This creates a scope-only const reference to the original container and then uses the ranged for on it. That does not work, because foreach need to support a variable which is already declare: "QString str; foreach (str, list)" (see the documentation http://doc.qt.io/qt-5/containers.html#foreach ), and this construct is not allowed in a ranged-based for. Othewise, we could have that in C++11: for (variable : qMakeForeachContainer(container)) We should be able to depend on this for Qt 6.4 or something. I tought Qt6 would probably require C++17. But even if one does not, it's completely optional. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Monday, 29 October 2018 08:48:53 PDT Lydia Pintscher wrote: > Asking? Maybe 1 or 2 times. (Sorry for not being super specific. There > might be things I'm simply forgetting since it's been 10 years and > there might be things that were not brought up to the whole committee > but simply mentioned in a chat with one member of the group to get > some input and guidance about how to handle a situation that was not > further escalated because the problem was solved with that.) Thank you, Lydia. That's heartening. -- 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] QUIP 12: Code of Conduct
On Mon, Oct 29, 2018 at 3:11 PM Jason H wrote: > Lydia, > > First, let me say I've stated my support of the KDE CoC. Thank you for your > effort in it. > > But then you make a statement in your post script that demonstrates exactly > what I'm talking about. You stated "some emails in this thread sadly make > me see part of the project in a different light. I fear I'm not the only > one."? Would you say the project has created fear in you and this has somehow > "harmed" the project in some way? Who were these people that changed your > mind? We need to identify these people and ban them because they are not > casting the widest inclusive and protective audience and anything less than > that is harm... Let the witch hunt begin... right? Sorry. I seem to have been misunderstood here. As others have said at the core a Code of Conduct should not be about banning anyone. That's a measure of very last resort. A lot of work should be put in before that happens. Talking, making aware of an issue, mediation, bringing in a neutral third party, separating the parties and a lot of other things are possible before that to address a problem. A Code of Conduct should be as much about stating what a community wants to be as about what it doesn't want. I think about it as a statement of intent that broadcasts values to the rest of the world and gets shared understanding in a community. Some communities then decide to add rules and punishments for violations. Other decide to hand that over to a committee or something similar. There are pros and cons to either. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On Monday, 29 October 2018 04:43:09 PDT Olivier Goffart wrote: > > 1) it will copy containers. For Qt containers, that's rather cheap (two > > atomic refcount operations), but it's not free. And for Standard Library > > containers, that is likely very expensive. > > But using for(:) with a Qt container will cause a detach in the most common > case, so I'd say is even worse. > Which is why i'm saying using this reason is a bit ironic. True, which is why we didn't deprecate, but did add qAsConst. > > 2) it's implemented by way of a for loop inside a for loop, which is known > > to throw optimisers out, generating slightly worse code > > I would consider that the missed optimization is quite small, if not > negligible. And it can be solved in C++17: > https://codereview.qt-project.org/243984/ I'd solve this the other way around, by making the macro: if (const auto &_container_ = (container); true) \ for (variable : _container_) This creates a scope-only const reference to the original container and then uses the ranged for on it. We should be able to depend on this for Qt 6.4 or something. > > I disagree. The optimisation problem is not solved. > > I'm ok with discouraging Q_FOREACH, but deprecating such a function need > more thinking. I'm with you. -- 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] QUIP 12: Code of Conduct
On Mon, Oct 29, 2018 at 4:53 AM Thiago Macieira wrote: > Hi Lydia > > Thanks for chiming in. > > Note I asked about malicious request to the CWG, not legitimate ones. I mean > baseless accusations, based on no actual fact, just attempts to smear someone > or generate useless expediture of people's time. Has that happened, at all? If > so, how long did the committee spend addressing it? How much effort was put > into it? Maybe 2 or 3 times by people not part of the broadly construed core community on forums like reddit etc. Nothing that I'm aware of ever ended up in any official channel or took any noteworthy amount of time from anyone. > Maybe we can also expand to accusations that, though not malicious, were found > not to be under the CoC's purview, like asking someone to be removed due to > some action on their personal time. Asking? Maybe 1 or 2 times. (Sorry for not being super specific. There might be things I'm simply forgetting since it's been 10 years and there might be things that were not brought up to the whole committee but simply mentioned in a chat with one member of the group to get some input and guidance about how to handle a situation that was not further escalated because the problem was solved with that.) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Monday, 29 October 2018 00:52:49 PDT Alexey Andreyev wrote: > Talking about CC and KDE's CoC, it's not obvious for me how to perform > politics, religion, race, etc -- harassment protection correctly at > international digital community with provided rules. > I'm not saying we don't need rules. You said KDE's version looks better > comparing to CC. Archlinux version looks even better for me. > > Anyway, I'm not a professional at such social tasks and want to step back. > I do not want to look like annoying person, just wanted to help with > controversial subjects. > I have no doubts about Qt people professionalism and happy do be a part of > the community. For me, the fact that it doesn't say we'll try to address those problems that are currently extant in many communities (though, hopefully, not ours), ArchLinux's CoC is inferior to KDE's. I'd like a text that says states the goals we'll strive for, not just what we can be sure of. -- 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] QUIP 12: Code of Conduct
Hey Jason, You seem to assume that without a code of conduct there is no way that people can get banned. That is not the case. In practice, people can be kicked out of the Qt Project by the folks that control the respective systems. And by extension by those who have some influence over those people. You call that “self-policing”, but in fact it’s about us trusting that the folks that have those privileges do not abuse their power. That’s great as long as it works, but if the project somehow does become “more political”, then I do think this lack of transparency is not in the interest of the project. A CoC tries to formulate what environment we want our behaviors to create, and it establishes a less opaque process for managing situations where an individual seems to do more harm than good to the project. That doesn’t mean that there won’t be mistakes. It doesn’t take much to cause someone distress through an email or a quick comment to their code, esp when we want to include people that are regularly exposed to all sorts of harassment, and are not quite as thick-skinned and self-assured as you and I might be. But I think that, by simply establishing a CoC that community members agree to, we can create an atmosphere where even a rough piece of language is received in the spirit of collaboration. And that also doens’t mean that there won’t be abuse. I’m sure there are people that have made it a way of life to be offended. However, they do not need a Code of Conduct (which is not a legal document anyway). I’d rather have them raise their voice in the open, and direct them towards a transparent process, than to have them use backdoor tactics to get influence over the project. The question to you is then: If someone like Coraline were to direct her energy to the Qt Project, how much in the open would you want their efforts to be? Or would you rather simply trust that there are not enough maintainers in the Qt project that would fall for their chain of arguments and backdoor schemings? Volker > On 29 Oct 2018, at 15:10, Jason H wrote: > > Lydia, > > First, let me say I've stated my support of the KDE CoC. Thank you for your > effort in it. > > But then you make a statement in your post script that demonstrates exactly > what I'm talking about. You stated "some emails in this thread sadly make > me see part of the project in a different light. I fear I'm not the only > one."? Would you say the project has created fear in you and this has somehow > "harmed" the project in some way? Who were these people that changed your > mind? We need to identify these people and ban them because they are not > casting the widest inclusive and protective audience and anything less than > that is harm... Let the witch hunt begin... right? > > Everyone, > This is the slippery slope that I'm talking about accusations start in > wide-abstractions like your statement and devolve into direct accusations. > While no one yet here has the motivation to conduct a witch hunt, we cannot > assume that will be the case. So far common sense has prevailed, but common > sense is, well, uncommon. It may be that Cone day oraline et. al. go on a > witch hunt for those the opposed her Covenant. > > I've spent some time thinking about this this weekend. Here's what I don't > get. Coraline authored the CC. She then goes into projects attacking them > with it, but fortunately(?) it hasn't worked. But to put it a different way, > if I design an instrument, publish the plans, and try to use it in a > community, if it doesn't work, is it the instrument or the user that is at > fault? If that instrument is intended to be destructive (say like a bomb), > then can we see how she really means for this to be used? To my knowledge > none of the people singled out in the witch hunts actually did anything > offensive in the projects they were participating in. > > It could be that eventually those who opposed the CoC in some way get labeled > as "intolerant" by the larger community. Lydia's statement has already given > me pause in this regard and I'm not being hyperbolic. Political views, and > things we don't consider as political today, can eventually become political. > > I think we have two camps: > We want a CoC as a feel-good statement of inclusion and tolerance (I think > everyone is committed to this) > AND > 1) We want to use existing situation of laws/self-policing OR > 2) We want a CoC that contains a framework that can get people banned or more > > I've always assumed that there was some line that could be crossed that would > get your accounts shut down and removed from the community. If someone makes > it so that the community cannot function, in whole or in part, then removal > is warranted. These Codes of Conducts lower the barrier to an incredibly low > bar and don't say what lower threshold of "harm" is needed to run afoul. I > haven't even had a response as to if it
Re: [Development] QUIP 12: Code of Conduct
> But then you make a statement in your post script that demonstrates > exactly what I'm talking about. You stated "some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one."? Would you say the project has created > fear in you and this has somehow "harmed" the project in some way? > Who were these people that changed your mind? We need to identify > these people and ban them because they are not casting the widest > inclusive and protective audience and anything less than that is > harm... Let the witch hunt begin... right? All the proposals for codes of conduct that I have seen so far mention banning only as a last resort and have several less drastic measures that should be applied before. Also, the point of having a neutral third party decide on the issue, rather than people directly involved in the conflict should result in that third party deciding on the measurements to be taken, not any victims of harassment, harm, or whatever. Ulf ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Lydia, First, let me say I've stated my support of the KDE CoC. Thank you for your effort in it. But then you make a statement in your post script that demonstrates exactly what I'm talking about. You stated "some emails in this thread sadly make me see part of the project in a different light. I fear I'm not the only one."? Would you say the project has created fear in you and this has somehow "harmed" the project in some way? Who were these people that changed your mind? We need to identify these people and ban them because they are not casting the widest inclusive and protective audience and anything less than that is harm... Let the witch hunt begin... right? Everyone, This is the slippery slope that I'm talking about accusations start in wide-abstractions like your statement and devolve into direct accusations. While no one yet here has the motivation to conduct a witch hunt, we cannot assume that will be the case. So far common sense has prevailed, but common sense is, well, uncommon. It may be that Cone day oraline et. al. go on a witch hunt for those the opposed her Covenant. I've spent some time thinking about this this weekend. Here's what I don't get. Coraline authored the CC. She then goes into projects attacking them with it, but fortunately(?) it hasn't worked. But to put it a different way, if I design an instrument, publish the plans, and try to use it in a community, if it doesn't work, is it the instrument or the user that is at fault? If that instrument is intended to be destructive (say like a bomb), then can we see how she really means for this to be used? To my knowledge none of the people singled out in the witch hunts actually did anything offensive in the projects they were participating in. It could be that eventually those who opposed the CoC in some way get labeled as "intolerant" by the larger community. Lydia's statement has already given me pause in this regard and I'm not being hyperbolic. Political views, and things we don't consider as political today, can eventually become political. I think we have two camps: We want a CoC as a feel-good statement of inclusion and tolerance (I think everyone is committed to this) AND 1) We want to use existing situation of laws/self-policing OR 2) We want a CoC that contains a framework that can get people banned or more I've always assumed that there was some line that could be crossed that would get your accounts shut down and removed from the community. If someone makes it so that the community cannot function, in whole or in part, then removal is warranted. These Codes of Conducts lower the barrier to an incredibly low bar and don't say what lower threshold of "harm" is needed to run afoul. I haven't even had a response as to if it is perceived or demonstrable harm that is required. So far cooler heads and common sense have prevailed, but I don't trust that will always be the case. This is why if we go with a CoC that can prescribe punishments, that it be explicit both in determination and punishment stages. *Not that I have anything against witches. I have several wiccan friends. Is the term "witch hunt" offensive? Can I get banned for using that term now or in the future? > Sent: Sunday, October 28, 2018 at 7:53 PM > From: "Lydia Pintscher" > To: development@qt-project.org > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > wrote: > > And I'm pretty sure the KDE Community WG can easily compile a list of times > > that they were maliciously asked to look into situations and how much time > > it > > took them to give it the attention it was due. > > I don't have an exact number but less than 10. And we could always > deal with it very quickly thanks to some common sense and good > knowledge of the situation and people involved. No big deal. > > (For those who don't know me: I'm one of the people who wrote KDE's > CoC and has been a member of it's community working group since then. > I'm also the current president of the non-profit behind KDE.) > If you have further questions about KDE's Code of Conduct please let > me know. I'm happy to answer them. > > > Cheers > Lydia > > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one. > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org > ___ > 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] Undeprecating Q_FOREACH
I'm just replying to this email to sumarize my opinion from the other email in the "qMoveToConst helper for rvalue references to movable Qt containers?" thread. I do not think it is time to deprecate foreach. Currently, the documentation says it is discouraged, and that's fine. But the alternative are harder to use with Qt containers and I do not think it is wise to tell everybody to port away from foreach. One problem of foreach is that it does not work well with QVerLenghtArray and standard containers. But in practice, Qt user are not using them so much. But I guess it would be fine to deprecate and warn for this case: https://codereview.qt-project.org/244010 The other problems seems really minors, and not a reason to port away from it, especially when the alternative is much more difficult to use right. On 10/28/18 7:34 PM, Giuseppe D'Angelo via Development wrote: [...] Why should the Qt Project invest any resource whatsoever maintaining a solution to a problem that has also been solved by the C++ language (and in a more efficient and general way than Q_FOREACH)? Historical reason, and for the same reason the Qt project maintains its own containers. I guess it would be good to discourage uses of QVector/QMap/QSet/... But we can't just force everybody to move away from it just like that. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] wip/cmake status information
I just changed it into a review request, so everyone can have a look in gerrit: https://codereview.qt-project.org/#/c/244005/ Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] wip/cmake status information
I just changed it into a review request, so everyone can have a look in gerrit: https://codereview.qt-project.org/#/c/244005/ Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Build system for Qt 6
Hi all, As you will probably remember, there have been lively discussions around what kind of build tool to use for Qt 6 both during Qt Contributor Summits as well as on this mailing list. There has been a strong consent that we should move away from qmake as our build tool for Qt due to many shortcomings and the burden we have maintaining the system. Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis. There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake. Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage. To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. Thus this investment would be at the expense of other things we’d like to do, like improving our IDE, working on rearchitecting and cleaning up our core frameworks for Qt 6 or the design tooling we are currently investing into. The Qt Company believes that those other investments are more important for the future of Qt than our choice of build tool. As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task. Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time. In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix. Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake. We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it). Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Hi all, I fully agree, Olivier. Looking at https://docs.kdab.com/analysis/qtcreator/clazy.html gives currently 223 potential detaching containers within range-based for, and qtbase alone has 46 (https://docs.kdab.com/analysis/qt5/clazy.html). Even if there may be some false positives, who is going to check and fix them all? If we don't manage to use the range-based for correctly (for Qt-containers), why should we force the user to port away from foreach? Just my two cent. Best regards, André Am 29.10.18 um 12:43 schrieb Olivier Goffart: On 10/28/18 8:17 PM, Thiago Macieira wrote: On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote: It is a bit ironic that one reason given to deprecate Q_FOREACH is that it may copy the container in some cases, while the alternative has the same problem in much more common cases. (It is my impression that implicitly shared container such as QList/QVector are by far much more used than the one that are not within a typical Qt code base) There are two problems with Q_FOREACH: 1) it will copy containers. For Qt containers, that's rather cheap (two atomic refcount operations), but it's not free. And for Standard Library containers, that is likely very expensive. But using for(:) with a Qt container will cause a detach in the most common case, so I'd say is even worse. Which is why i'm saying using this reason is a bit ironic. 2) it's implemented by way of a for loop inside a for loop, which is known to throw optimisers out, generating slightly worse code I would consider that the missed optimization is quite small, if not negligible. And it can be solved in C++17: https://codereview.qt-project.org/243984/ Our rule already was: Don't use foreach in Qt code. (it was fine in examples) Using iterators and now using the ranged for may need more typing, but produces optimal code. What could be done is to only deprecate partial specialization of qMakeForeachContainer for QVarLenghtArray and the standard containers. Or for containers that do not have a 'detach' function. That way, users would get a warning for the problematic containers, but would continue to work just fine with with the containers most Qt developer use. I disagree. The optimisation problem is not solved. I'm ok with discouraging Q_FOREACH, but deprecating such a function need more thinking. Deprecating means you will force user to port all their codebase away from it, which is a huge work. If the rationale is just that they will save a couple of atomic operations, i do not think it is worth it. Deprecating it only for non-shared container seems more logical, since we then warn only when there is actually a problem. And for the Qt shared container case, using foreach is less typing, but also less error prone. (do i have to use qAsConst? or make a copy? or even return a const object which even lead to more problems) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On 10/28/18 8:17 PM, Thiago Macieira wrote: On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote: It is a bit ironic that one reason given to deprecate Q_FOREACH is that it may copy the container in some cases, while the alternative has the same problem in much more common cases. (It is my impression that implicitly shared container such as QList/QVector are by far much more used than the one that are not within a typical Qt code base) There are two problems with Q_FOREACH: 1) it will copy containers. For Qt containers, that's rather cheap (two atomic refcount operations), but it's not free. And for Standard Library containers, that is likely very expensive. But using for(:) with a Qt container will cause a detach in the most common case, so I'd say is even worse. Which is why i'm saying using this reason is a bit ironic. 2) it's implemented by way of a for loop inside a for loop, which is known to throw optimisers out, generating slightly worse code I would consider that the missed optimization is quite small, if not negligible. And it can be solved in C++17: https://codereview.qt-project.org/243984/ Our rule already was: Don't use foreach in Qt code. (it was fine in examples) Using iterators and now using the ranged for may need more typing, but produces optimal code. What could be done is to only deprecate partial specialization of qMakeForeachContainer for QVarLenghtArray and the standard containers. Or for containers that do not have a 'detach' function. That way, users would get a warning for the problematic containers, but would continue to work just fine with with the containers most Qt developer use. I disagree. The optimisation problem is not solved. I'm ok with discouraging Q_FOREACH, but deprecating such a function need more thinking. Deprecating means you will force user to port all their codebase away from it, which is a huge work. If the rationale is just that they will save a couple of atomic operations, i do not think it is worth it. Deprecating it only for non-shared container seems more logical, since we then warn only when there is actually a problem. And for the Qt shared container case, using foreach is less typing, but also less error prone. (do i have to use qAsConst? or make a copy? or even return a const object which even lead to more problems) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to create dummy plugins in qtbase?
On Sun, Oct 28, 2018 at 01:59:07PM -0400, Kyle Edwards wrote: >However, I'm not sure how to create a new Qt module that's visible >to the tests without also being installed/visible outside the >tests. > that's an unsolved problem. qtmultimedia/tests/auto/unit/qmediaserviceprovider also just installs them "for real". ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Merge and Integration status report - 2018.10.29
Integrations * qt5 5.9/5.11/5.12/dev integrations are healthy Merges * qtdeclarative 5.11->5.12 merge(10 days) is ongoing, https://codereview.qt-project.org/#/c/243050/ * qtbase 5.11->5.12 merge, need help, https://codereview.qt-project.org/#/c/243826/ * qtbase 5.12->dev merged on Saturday, https://codereview.qt-project.org/#/c/243500/ I will check other 5.11->5.12 merges today before the latest 5.12->5.12.0 final down merge. Provisionings * qt5 5.12: Android NDK(r18b) and SDK updated on all host platforms on Oct. 20 * qt5 dev: Trying to integrate https://codereview.qt-project.org/#/c/240554/ (Docker Provisioning: Install Docker-based test servers on macOS) soon -- Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Mon, 29 Oct 2018 00:53:01 +0100, Lydia Pintscher wrote: > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I'm not too much interested in the topic of an CoC - not even in the discussion about it - but that doesn't mean, that it should not be allowed to have it here. But in this whole thread there is indeed one posting, that annoys me - and this is yours. I will never understand, why someone feels entitled to judge others so easily - and in your case without even giving any indication about what you are referring to. > I fear I'm not the only one. I guess you are. Nothing for ungood, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
> If they want to be malicious, they'll find a way. Opposite extreme is "who cares, let's accept something and sort it out on the go later" > Which promises in other CoCs do you find vulnerable? Talking about CC and KDE's CoC, it's not obvious for me how to perform politics, religion, race, etc -- harassment protection correctly at international digital community with provided rules. I'm not saying we don't need rules. You said KDE's version looks better comparing to CC. Archlinux version looks even better for me. Anyway, I'm not a professional at such social tasks and want to step back. I do not want to look like annoying person, just wanted to help with controversial subjects. I have no doubts about Qt people professionalism and happy do be a part of the community. пн, 29 окт. 2018 г. в 7:08, Thiago Macieira : > On Sunday, 28 October 2018 17:20:04 PDT Alexey Andreyev wrote: > > > Sure, but again that's why we have a committee behind who will evaluate > > the > > > charges and decide what the proper action to be taken is. If the > charges > > are > > > fake, then the accused would of course not be affected in any way. And > if > > the > > > accuser keeps making false accusations, that's the one who could face > > > sanctions. > > > > Sanctions like ban with additional false accusations about harassment > could > > be sent to mass media to create negative image of the community. > > And if the mass media does buy into the fake story, what can we do? The > attacker can seize on any particular point of our community, whether > there's a > CoC or not. They could attack us for *not* having one in the first place > and > having no method to address their fake injutsice. They could attack us for > having a security mailing list that judged a particular issue they > reported > not to be a security problem, etc. > > If they want to be malicious, they'll find a way. > > And if the media sides with them, not giving us a chance to explain, what > are > we going to do? > > > Let's take a look at archlinux CoC for example: > > https://wiki.archlinux.org/index.php/Code_of_conduct > > > > Literally no vulnerable promises about protecting from harassment that > > could be hard to keep. Additional mention at archwiki not to play with > > controvertial non-related subjects at technical place: > > Which promises in other CoCs do you find vulnerable? > > -- > 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
