Re: [Development] Qt Project Missing Infrastructure

Qt Project == Do note that the Qt Project consists of more then just the Qt Framework. As such please pay attention in wording and do distinguish those two. * There are no internal docs on how things work to release * Never been written down Because that's simply not true for

Re: [Development] Changes to the Jira roles and workflow

Default Assignee There is call for discussion around default assignee – is it the module maintainer? Which tasks are up for grabs if everything new goes to the maintainer? Unassigned should be the default. When someone picks up the task, they should assign it to themselves. Anything

Re: [Development] Stepping down

On Friday 01 Jun 2012 13:37:48 Paweł Polański wrote: Hi, due to the fact that I have no longer enough time to maintain Symbian in Qt Creator's Project Management Targets I would like to step down from this position. My symbian knowledge is rather limited. I will be looking over any gerrit

Re: [Development] QMake behaviour change

- Means that source code where headers and sources are split into different directories all of a sudden depends on relative paths to all files See VPATH, which Ossi already mentioned in the bug report. - Behaves differently from QtCreator (tested with a rather old version 2.5.2). What

Re: [Development] QMake behaviour change

On Wednesday 28 Nov 2012 13:17:58 Johan Thelin wrote: On Wed, Nov 28, 2012 at 11:24 AM, Daniel Teske daniel.te...@digia.com wrote: - Means that source code where headers and sources are split into different directories all of a sudden depends on relative paths to all files See VPATH

Re: [Development] Nominating Mitch Curtis for approver

On Friday 14 Dec 2012 11:17:14 Jedrzej Nowacki wrote: 14 days passed and there was no objections. Congratulations Mitch! I'm sorry, that is not correct. From http://qt-project.org/wiki/The_Qt_Governance_Model Once seconded, a new Maintainer is appointed unless a community member objects to

Re: [Development] kdelibs coding style

On Tuesday 30 Apr 2013 19:44:45 Thiago Macieira wrote: On terça-feira, 30 de abril de 2013 18.47.33, Oswald Buddenhagen wrote: on a personal note, while i strongly sympathize with the diff minimization philosophy, i also feel quite a dislike for excess braces. adding to that the in this

Re: [Development] kdelibs coding style

On Tuesday 30 Apr 2013 20:45:40 Thiago Macieira wrote: On terça-feira, 30 de abril de 2013 19.51.40, Daniel Teske wrote: So you suggest that KDE adopt the Qt style and Qt doesn't change anything? Why do they need to be the same? That was the request: can they be the same

Re: [Development] [request] Creation a new QtSerialPort component into a Qt bug tracker

On Wednesday 26 Jun 2013 13:05:01 Knoll Lars wrote: On 26.06.13 12:59, Daniel Teske daniel.te...@digia.com wrote: On Wednesday 26 Jun 2013 09:04:26 Knoll Lars wrote: I can do that, but I can unfortunately not migrate the open bugs to the new component (as I can't migrate across Jira

Re: [Development] Making QScopedPointer scoped (again)

Again, this is what std::unique_ptr is for. We should not try to turn QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a need for a std::unique_ptr, they should use it. We should not adapt QScopedPointer to fit the need instead. Adding a move contructor to

Re: [Development] Making QScopedPointer scoped (again)

On Wednesday 04 Sep 2013 22:15:48 Stephen Kelly wrote: On Wednesday, September 04, 2013 19:48:53 Knoll Lars wrote: Given that we have less then 3 weeks until feature freeze (1) or (3) sound more attractive for 5.2. That's not relevant. QScopedPointer is not moved anywhere in Qt 5.2. No

[Development] Convenient script for contributors: git gpush

Hi, a long time ago Marius Storm-Olsen wrote a nice convenience tool to ease pushing to gerrit. As probably most are unaware of that tool, I'll just resend his original annoucement. -- Hi, I've just pushed a convenience script to the qtrepotools repository, which makes it easier to push

[Development] Qt Creator 3.2 dropping support for Mac OS X 10.6

Hi, Let's make this: Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there

Re: [Development] Converting types in Qt

Anyway. To summarize my position in the original context: QVariant is as it is. It is convenient at times, and it is already too convenient at times. Easy type conversion is a different use case than Type agnostic storage. QVariant does a bit of both, only the second one has ever been useful

Re: [Development] Converting types in Qt

On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote: On Thursday 17 of July 2014 10:51:03 you wrote: QVariant::operator== is not symmetric QDateTime dateTime = QDateTime::currentDateTime(); QTime time = dateTime.time(); qDebug() (QVariant(dateTime) ==

Re: [Development] crash when activating timers

On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote: On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote: So my question: Does anyone have any idea how this could possibly happen, how we could reproduce and/or debug and fix it? I also got a bug report that is similar:

Re: [Development] Platform maintainers

To make it explicit, I’d like to propose the following people as Maintainers for different platforms: Android: Bogdan +1 daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why can't QString use UTF-8 internally?

On Wednesday 11 Feb 2015 17:20:04 Guido Seifert wrote: Minor OT, but I am too curious... do you have an example? Are there really cases were turning lower case into upper case or vice versa changes the length of a string? What is uppercase ß? daniel

[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Hi, Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and C++14 added a lot of new good features. C++17 is planned to be a big step again. Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in a C++98 world. As an example, Qt's container

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

On Thursday 19 Feb 2015 15:41:42 Matthew Woehlke wrote: On 2015-02-19 15:21, Marc Mutz wrote: On Thursday 19 February 2015 13:29:48 Daniel Teske wrote: more than 400 lambdas in Creator's source Sounds like lambdas are overused (as any new language feature is overused before it's fully

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

On Friday 20 Feb 2015 00:17:00 Mathias Hasselmann wrote: [...] [...] [...] [...] I guess my point that the ranged based for loop and qt containers don't mix too well is now very much proven by the depth of this particular discussion. The upcoming Ranges TS has also uses std::begin and

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote: On Thursday 19 February 2015 13:29:48 Daniel Teske wrote: [1] ranged based for uses std::begin(container), which if not overloaded calls container.begin(), which detaches. So using range-based can be used: - If the container

Re: [Development] Qt LTS C++11 plans

On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote: On 25/06/15 11:43, Teske Daniel daniel.te...@theqtcompany.com wrote: * WEC7 not supported anymore, WEC2013 supported So what is the time frame for dropping WEC2013? Because that's the time Qt will be stuck with MSVC2012. WEC2013

Re: [Development] Qt LTS C++11 plans

* WEC7 not supported anymore, WEC2013 supported So what is the time frame for dropping WEC2013? Because that's the time Qt will be stuck with MSVC2012. daniel ___ Development mailing list Development@qt-project.org

Re: [Development] Move ctors for q_declare_shared types

On Friday 26 Jun 2015 16:45:18 Marc Mutz wrote: On Friday 26 June 2015 12:34:31 Daniel Teske wrote: Most of our implicitly shared types already had a move-assignment operator, because it's just QFoo operator=(QForr other) { swap(other); return *this; } And that's indeed how

Re: [Development] Some Qt3D feedback

Curiously, you didn't list any pro-namespace arguments. Actually: We couldn’t make things work in a source compatible way. * connect statements are hard with namespaces. * metatype registration is problematic with namespaced types * One of our coding guidelines is that you write code

[Development] FileRe: Move ctors for q_declare_shared types

- QVector should give the same guarantee as the standard containers. I disagree with that. QVector is not std::vector. At first, it is implicitly shared, so that's already a big difference. And therefore we can allow ourselfs many more differences. But this point still stands.

Re: [Development] Move ctors for q_declare_shared types

Most of our implicitly shared types already had a move-assignment operator, because it's just QFoo operator=(QForr other) { swap(other); return *this; } And that's indeed how QVector's move assignment is implemented. It's also broken. Just because other is a rvalue reference does not

Re: [Development] Move ctors for q_declare_shared types

For standard containers, this is specified in *container.requirements* To quote, with: a being a container and rv a non-const rvalue of the same type: a = rv All existing elements of a are either move assigned to or destroyed, I do not see any reason why our containers

Re: [Development] FileRe: Move ctors for q_declare_shared types

Hi, https://codereview.qt-project.org/#/c/120804/ and https://codereview.qt-project.org/#/c/120771 do fix the move assignment operators in Qt, just like I wanted. I wonder why Marc Mutz didn't fell the need to update the mailing list on his changed opinion and this fix. Anyway, for those

Re: [Development] FileRe: Move ctors for q_declare_shared types

Are we going to announce every API change on the ML now? No, that is obviously stupid. But, could you please stop trying to divert a discussion by raising unrelated questions? If a change is related to a discussion on the mailing list, I expect that the change is posted to the discussion.

Re: [Development] FileRe: Move ctors for q_declare_shared types

If a change is related to a discussion on the mailing list, I expect that the change is posted to the discussion. I already quoted you the mail where I ... Because not doing that, circumvents the discussion on the mailing list and goes against the spirit of The Qt Governance Model.

Re: [Development] unique_ptr and Qt

Thanks for doing this. Here is what i suggest to make the change less intrusive: For the constructors themself in every classes.   // Removed the '=nullptr' default parent, and added QT_UNSAFE_API   QT_UNSAFE_API explicit QLineEdit(QWidget *parent);   QT_UNSAFE_API explicit QLineEdit(const

[Development] unique_ptr and Qt

Hi, I've done some research into how supporting unique_ptr in Qt might look like. I have a patch which adds apis using unique_ptr for ownership transfer to almost all of QtBase and a patch for Qt Creator to show how using those apis looks like. Qt: https://codereview.qt-project.org/231543

Re: [Development] unique_ptr and Qt, Take 2

Hi, I was happly ignoring the other threads, since I didn't like the temperature of some the responses. But I guess you force me to write a response not just to you, but something that is a bit more general. Or... just don't do that? I can't recall that I've *ever* had problems with

Re: [Development] unique_ptr and Qt, Take 2

The minor problem being that to not so small audiences, new Whoosh(something); just looks like a bug, and then you need to look three times to realize that something is a parent. Sure... but `something.createChild()` can help with that. OTOH, I just realized a problem with that... when the

Re: [Development] unique_ptr and Qt, Take 2

Am 06.05.2019 um 12:04 schrieb Lars Knoll: On 6 May 2019, at 10:27, Konstantin Shegunov > wrote: On Mon, May 6, 2019 at 10:42 AM Lars Knoll > wrote: Not sure whether it’s most projects, but there certainly are users doing it. And

Re: [Development] unique_ptr and Qt, Take 2

The patch I propose does not take that into account and is indeed almost entirely source compatible. Scratch the "not". And while I'd encourage someone to try it out, I'm of the firm opinion that Qt should try to get over its NIH attitude. One of the issues with Qt in the real world is

Re: [Development] unique_ptr and Qt, Take 2

hat nice to me Maybe I’m asking too much, but it would be nice get rid of raw pointers completely switching to pair std::unique_ptr/std::observer_ptr I don't think observer_ptr has only miniscule benefit over a raw pointer and I think it's ugly. Thiago Macieira: On Friday, 3 May 2019 10:22:20 P

[Development] unique_ptr and Qt, Take 2

Hi, a year back I wrote a patch that added unique_ptr apis to most of qtbase. I still think that would be a good addition to Qt, and thus I've updated the patch with the feedback gained at the Contributor Summit last year and taking into account that with Qt6, binary compatibility is not

Re: [Development] The future of smart pointers in Qt API

Am 04.02.2020 um 07:53 schrieb Shawn Rutledge: On 1 Feb 2020, at 19:20, Daniel Teske <mailto:q...@squorn.de>> wrote: Now to take your next example: setParent is not fine. setParent can be used in 4 different ways: child->setParent(child->parent()): Invariant holds c

Re: [Development] The future of smart pointers in Qt API

Am 04.02.2020 um 13:22 schrieb Konstantin Shegunov: On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov > wrote: I think, if we decide to re-implement parent-child model using smart pointers, we would not use unique pointers at all. Even in a methods like

Re: [Development] The future of smart pointers in Qt API

Am 04.02.2020 um 17:47 schrieb Volker Hilsheimer: On 4 Feb 2020, at 16:12, Ville Voutilainen wrote: On Tue, 4 Feb 2020 at 15:40, Volker Hilsheimer wrote: This works, but now you are encoding the visual hierarchy of the widgets in two places: when asking the presumed parent to create the

Re: [Development] The future of smart pointers in Qt API

Parent-child relationship is not going to go away, it has purpose beyond object lifetime: the visual hierarchy is encoded in the parent/child relationship of widgets, for example. Making ownership of objects, and assumptions regarding their life-cycle, explicit in code is a good thing

Re: [Development] The future of smart pointers in Qt API

Hi, I'm confused that there's zero discussion of the work I have done in showing how adding unique_ptr apis would look like. Surely, you have internally discussed that approach. Also I'm sad to see that instead of using public mailing lists, you seem to have discussed this extensively

Re: [Development] The future of smart pointers in Qt API

Pros I can see: 1) Qt style STL has different naming convention that looks alien to Qt API. It leads to inconsistency. The "Qt projects not using the standard library" era is over and the sooner that is understood the better. That inconsistency is just something to get used too Qt does

Re: [Development] The future of smart pointers in Qt API

Hi Daniel, I like many things in this proposal, especially the principles; thanks for that! Where I’m on the fence is the replacing of setParent with “adoptChild”. I think of “parent” as a property of an object, so setParent/parent accessors are the API that fits into my mental model. I

Re: [Development] The future of smart pointers in Qt API

Am 02.02.2020 um 18:17 schrieb Иван Комиссаров: Can we please return to the discussion about QObject parent/child with smart pointers rather than discussing Qt/stl naming? No one answered my question about QObject::deleteLater: And what about the QObject::deleteLater() method? Any ideas how