Re: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator

Of course +1 From: Development on behalf of Tobias Hunger Sent: Wednesday, May 2, 2018 12:14:14 PM To: qt-crea...@qt-project.org; development@qt-project.org Subject: [Development]

Re: [Development] Setters: Clarifying the ownership

"give" may be confused with "get", which is usually an accessor. I may also think "Am I giving (to QCoreApplication)" or "The QCoreApplication is giving (me)". Maybe it is just a matter of the other verb? Absorb, hand over, hand on, suck in, swallow... Jarek

Re: [Development] QtScxml module maintainer change

+1. Ulf did quite a lot of a good maintenance work already for this module. Jarek From: Development on behalf of Simon Hausmann Sent: Tuesday, September 4, 2018 1:49:15 PM To: Erik Verbruggen; Subject: Re: [Development] QtScxml module maintainer change +1

Re: [Development] Building Qt documentation with developer-build

Hi, You may also want to check the https://bugreports.qt.io/browse/QTBUG-65762 - if you think the issue is still not solved, you may reopen / report new bug report. Regards Jarek [QTBUG-65762] Compiling qdoc in dev is a big pain - Qt Bug ...

Re: [Development] Proposal: New branch model

"All(**) changes would go to dev. From which they would be automatically cherry-picked by a bot to other branches. The decision to which branch cherry- pick, would be taken based on a tag in the commit message. We could add a footer that marks the change risk level as in quip-5" No sure I

Re: [Development] qcollectiongenerator merged into qhelpgenerator

The answer to the first question is yes. If you want to generate the qhc file using Qt < 5.12 you need to use qcollectiongenerator, since merging took place in 5.12 branch, not before. So, I may bring it back if it's needed. Could you give an example link to the project which is failing now?

Re: [Development] New linguist maintainer nomination

+1. AFAIRC, Kai's hands were already on this stuff a long time ago, dating Trolltech times :) From: Development on behalf of Alex Blasche Sent: Monday, January 7, 2019 1:51:25 PM To: development Subject: [Development] New linguist maintainer nomination Hi,

Re: [Development] Proposal: New branch model

From: Volker Hilsheimer Sent: Wednesday, January 23, 2019 5:25 PM To: Jaroslaw Kobus Cc: Jedrzej Nowacki; development@qt-project.org Subject: Re: [Development] Proposal: New branch model On 23 Jan 2019, at 17:08, Jaroslaw Kobus mailto:jaroslaw.ko

Re: [Development] Assistant WebKit/WebEngine support

I think the option 2 (enhancements in QTextBrowser) is the best one, since the time investment spent on it will benefit for all users of QTextBrowser, not only those using Qt help system. So big +1 here! However, if we go with the webengine (or webkit) way, I would be very happy that the

Re: [Development] Assistant WebKit/WebEngine support

QTextBrowser promises to render rich text - isn’t it what we want for showing help? If QTextBrowser isn’t able to render properly the static help files - what is the other typical usage of it? Why we claim that QTextBrowser is able to do things, which in fact it can't? This doesn't show a fair

Re: [Development] Assistant WebKit/WebEngine support

From: Development on behalf of Palaraja, Kavindra Sent: Friday, June 28, 2019 10:56 AM To: Qt development mailing list Subject: Re: [Development] Assistant WebKit/WebEngine support On 28.06.19, 10:24, "Eike Ziller" wrote: > On 27. Jun 2019, at

Re: [Development] HEADS-UP: QStringLiteral

I propose the following policy regarding any further new string classes / wrappers in Qt: Whenever anyone propose new string class / wrapper in public API of Qt, he is obligated to deprecate in parallel at least 2 other string classes / wrappers in public API of Qt. Regards Jarek

[Development] Implementing QStateMachine using QtScxml module

Hi All, recently I was investigating the possibility of replacing the internal implementation of QStateMachine with QtScxml module. See https://bugreports.qt.io/browse/QTBUG-70261. Below I have gathered some results and some conclusions. However, at this point it's not clear in which

Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI

> I'm not really convinced of this. Properties that depend on each other > are a symptom of bad design; we shouldn't discourage QFormBuilder > because of this possible marginal issue. I agree in 100%! However, hundreds of QObject / QWidget properties (and those in their subclasses) in fact depend

Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI

> And there you have it: QFormBuilder mustn't save non-STORED properties. > If it does, it's a bug. And if we have some widget with interlinked > properties that are not clearly marked as non-STORED, or refactored to > be grouped together in a proper datatype, that's another bug. Take any of

Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI

y know that there is hidden dependency (if you know, you may influence the order or storing / reading, but still it's not orthogonal). From: Giuseppe D'Angelo Sent: Tuesday, October 29, 2019 12:13 PM To: Jaroslaw Kobus; Volker Hilsheimer Cc: development@qt-project.org S

[Development] QAction in Qt 6 - next step proposal

Dear Qt friends, hackers and freaks, recently I've noticed a refactoring changes regarding QAction and QActionGroup, happening inside "dev" branch of Qt (https://codereview.qt-project.org/c/qt/qtbase/+/265909). I didn't have a chance to review it before it got merged, I just missed it. So I took

Re: [Development] QAction in Qt 6 - next step proposal

> as discussed on the change, there is not much one can do with the newly > introduced QGuiAction; it serves as a base class for QAction and > QQuickAction, The naming follows the Q(Gui)Application pattern. I didn't know that there is going to be one more subclass. Will QQuickAction be a public

Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI

ties will remain non-orthogonal and will continue to cause issues. From: Hugo Slepicka Sent: Tuesday, October 29, 2019 5:48 PM To: Giuseppe D'Angelo Cc: Jaroslaw Kobus; Volker Hilsheimer; development@qt-project.org Subject: Re: [Development] Issues wit

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

Allan Sandfeld Jensen (27 February 2020 23:03) replied: > That is how I see it too. It essentially violates Qt code guidelines. If it > was a normal method we would name it "emitEmptied()", so far we have just > lived with "emit emptied()" instead. The issue is that if you want to emit a signal,

Re: [Development] Moving math3d classes from GUI to CORE

From: Laszlo Agocs Sent: Thursday, January 23, 2020 5:26 PM To: KDAB Mike Krus; Konstantin Tokarev Cc: Konstantin Shegunov; Jaroslaw Kobus; development@qt-project.org Subject: RE: [Development] Moving math3d classes from GUI to CORE > Indeed, gett

Re: [Development] Moving math3d classes from GUI to CORE

From: Lars Knoll Sent: Thursday, January 23, 2020 3:07 PM To: Laszlo Agocs Cc: Konstantin Shegunov; Jaroslaw Kobus; Qt development mailing list Subject: Re: [Development] Moving math3d classes from GUI to CORE > Hi, > After some thinking, I prett

Re: [Development] Moving math3d classes from GUI to CORE

From: Laszlo Agocs Sent: Friday, January 24, 2020 11:17 AM To: Jaroslaw Kobus; KDAB Mike Krus; Konstantin Tokarev Cc: Konstantin Shegunov; development@qt-project.org Subject: RE: [Development] Moving math3d classes from GUI to CORE >> So it look

Re: [Development] Moving math3d classes from GUI to CORE

Resending it to development list, it was the original intention, but it went to another list. BR Jarek From: Jaroslaw Kobus Sent: Tuesday, January 21, 2020 1:33 PM To: Qt Development Subject: Moving math3d classes from GUI to CORE Hi All, one

Re: [Development] Proposal: Deprecate QVector in Qt 6

There are cases, where the name of the function contains the "list", like: QList QMdiArea::subWindowList(QMdiArea::WindowOrder order = CreationOrder) const; QList > QGraphicsItemAnimation::translationList() const; QList QLowEnergyAdvertisingParameters::whiteList() const; etc... So,

Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList. (6) No need to remane QStringList into QStringVector for consistency reasons. Jarek From: Development on behalf of Lars Knoll Sent: Thursday, April 23, 2020 9:53 AM To: Simon Hausmann Cc: Qt development mailing list Subject: Re:

Re: [Development] QString and related changes for Qt 6

> From: Development on behalf of Thiago > Macieira > Sent: Tuesday, May 12, 2020 10:42 PM > To: development@qt-project.org > Subject: Re: [Development] QString and related changes for Qt 6 > > On 2020-05-12 11:31, Jaroslaw Kobus

Re: [Development] QString and related changes for Qt 6

> From: Development on behalf of Lars > Knoll > Sent: Tuesday, May 12, 2020 9:49 AM > To: Qt development mailing list > Subject: [Development] QString and related changes for Qt 6 > > > * QStringView and QByteArrayView need to be completed to implement all const > methods of QString/QByteArray

Re: [Development] QString and related changes for Qt 6

> From: Development on behalf of Thiago > Macieira > Sent: Wednesday, May 13, 2020 6:21 PM > To: development@qt-project.org > Subject: Re: [Development] QString and related changes for Qt 6 > > On terça-feira, 12 de maio de 2020 22:57:31 PDT Jaroslaw Kobus wrote: > >

Re: [Development] QHelpEngineCore::documentsForIdentifier

Hi Martin, sorry for not answering earlier. I've just prepared a patch that should fix it. The assumption before was that at some point the default for using new filter engine will change to true. However, since it didn't happen so far, I'm providing a full fix for old filtering system, too.

Re: [Development] QHelpEngineCore::documentsForIdentifier

Hi Martin, sorry for not answering earlier. I've just prepared a patch that should fix it. The assumption before was that at some point the default for using new filter engine will change to true. However, since it didn't happen so far, I'm providing a full fix for old filtering system, too.

[Development] Fw: Important recent changes in QList/QString/QByteArray

> > From: Development on behalf of Giuseppe > D'Angelo via Development > Sent: Wednesday, September 2, 2020 9:37 PM > To: Andrei Golubev; development@qt-project.org; Ville Voutilainen > Subject: Re: [Development] Important recent changes in >

Re: [Development] QProperty and library coding guide

> From: Development on behalf of Ulf > Hermann >>> However, for Q_GADGET this would fall apart. > > Actually, with a Q_GADGET you usually don't have a private object. > That's the whole point of it. Then you don't need property wrappers, either. Just for clarification: actually you usually do

[Development] The ssh issue after updating to Fedora 33

Hi all, just in case when someone wants to update to Fedora 33 (or already did it): a potential issue with connection to gerrit may appear. It asks you to make sure you have the correct access rights and the repository exists. It mentions also: Permission denied (publickey). The fix is to

Re: [Development] Request to rename module qtscxml to qtstatemachine

+1 The new name reflects the content of the module much better. Regards Jarek From: Development on behalf of Edward Welbourne Sent: Thursday, January 21, 2021 11:14 AM To: Karsten Heimrich Cc: development@qt-project.org Subject: Re: [Development]

Re: [Development] Repository request: qlitehtml

+1 This may be potentially easily reused in e.g. standalone assistant. Jarek From: Development on behalf of Eike Ziller Sent: Tuesday, January 19, 2021 5:01 PM To: development@qt-project.org Subject: Re: [Development] Repository request: qlitehtml >

Re: [Development] Nominating Andreas Buhr as approver

+1 From: Development on behalf of Paul Wicking Sent: Thursday, April 29, 2021 8:20 AM To: development Subject: [Development] Nominating Andreas Buhr as approver Hi all, I’d like to nominate Andreas Buhr as approver for the Qt Project. Andreas has

[Development] Question about the lifetime of references taken from QHash

Hi All, asking it here, as I couldn't find any clear answer in QHash docs. Provided I have only one instance of my QHash (so, no detaches are being done), and the only API of the QHash I'm using is: insert(), remove(), contains() and operator[], how long I may rely on the reference to value

Re: [Development] Nominating Andrei Golubev as Approver

+1 Disclosure: I've only collaborated remotely with Andrei, however it was always a pleasure. From: Development on behalf of Edward Welbourne Sent: Thursday, March 18, 2021 3:00 PM To: development Subject: [Development] Nominating Andrei Golubev as

Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

+1 Sone indeed does a very good job! Best regards Jarek From: Development on behalf of Cristián Maureira-Fredes Sent: Tuesday, January 18, 2022 3:10 PM To: development Subject: [Development] Nominating Sona Kurazyan as maintainer of qt5compat Hello,

Re: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

+1 From: Development on behalf of Richard Gustavsen Sent: Tuesday, January 25, 2022 9:38 AM To: Qt development mailing list Subject: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets Hi all! I would like to propose a change in

Re: [Development] Nominating Ievgenii Meshcheriakov for approver

+1 Disclaimer: nothing to disclaim, +1 fully deserved. From: Development on behalf of Edward Welbourne Sent: Wednesday, April 6, 2022 2:13 PM To: Alex Blasche Cc: development@qt-project.org Subject: Re: [Development] Nominating Ievgenii Meshcheriakov

[Development] Fw: How to do deprecation

"So instead of #if QT_DEPRECATED_SINCE(6, 4) QT_DEPRECATED_VERSION_X_6_4("Use size() or length() instead.") inline qsizetype count() const { return d.size; } #endif You’d have: QT_DEPRECATED_METHOD(qsizetype count(), 6, 4, "Use size() or length() instead.”) " Hi, it would be

Re: [Development] Qt 6.2.6 LTS Commercial released

Wow! This thread already generated 12 messages - this one is the 13th. How many possible future commercial release e-mails could substitute all the posts from this thread? Would we be around 2024 already or later, isn't it? Is there really no bigger problem in the cruel world right now these

Re: [Development] Nominating Marcus Tillmanns as Approver

+1 Good job, Marcus! Jarek From: Development on behalf of Cristian Adam via Development Sent: Tuesday, November 22, 2022 10:39 PM To: A. Pönitz; development@qt-project.org Subject: Re: [Development] Nominating Marcus Tillmanns as Approver +1 Cheers,

Re: [Development] How qAsConst and qExchange lead to qNN

> 1. Use overloads for methods that take views or spans. In new API we can > omit the methods that take owning containers. If the overload set grows > out of hand, don't add the view/span alternative until we can remove > something. By Thiago's argument, that means not to convert existing >

[Development] QTimer question

Hi All, when I start 2 single shot timers synchronously in a row, with exactly the same interval, from the same thread, can I rely on having their handlers called in the same order in which they were started? I.e.: QTimer::singleShot(1000, [] { qDebug() << "1st timer elapsed"; });

Re: [Development] QTimer question

[Re-sending my reply to Thiago to the mailing list, as I think it may be possibly interesting for more people.] [In meantime I've created https://codereview.qt-project.org/c/qt/qtbase/+/480703 and waiting for CI results.] > On Monday, 29 May 2023 11:40:14 PDT Jaroslaw Kobus via Developm

Re: [Development] QTimer question

> On Tuesday, 30 May 2023 12:25:10 PDT Jaroslaw Kobus wrote: > > Hi Thiago, > > > > thank you for your answer. There are 3 main points: > > > > 1. Coarsing is OK and I'm totally fine with having my timers called a bit > > earlier or later (within 5% accuracy)

Re: [Development] API style guide: scoped enum or not?

>> On 4 May 2023, at 17:34, Marc Mutz via Development >> wrote: >> >> On 04.05.23 15:38, Volker Hilsheimer via Development wrote: >>> Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or >>> QSlider::Orientation::Horizontal? >> >> Without looking at the docs, tell me what

Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style

> - drop the requirement for () in lambdas > > Rationale: this was a word-around for older MSVCs. The standard doesn't > require the empty parameter list (except when adorning the lambda with > noexcept etc, and then the compiler complains) and people have voted > with their feet: we now have

Re: [Development] API style guide: scoped enum or not?

"enum class" has one advantage over "enum" inside a "class" : you may forward declare the "enum class", while the other not. That's quite often case that your header must include the other header just because you use the "enum" in "class" in your API and nothing more. Jarek

Re: [Development] Future of java-style iterators?

https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/filesearch.h FileContainer & FileContainerIterator could be an inspiration, too. The SubDirFileContainer enables traversal according to the selected filters and exclusion filters. This all is a part of the Utils lib inside

Re: [Development] Should QObject::event() be protected or public?

Most probably making it protected (temporarily) and trying to build everything else (including QtCreator) may reveal the original reason for being public. Jarek From: Development on behalf of Marc Mutz via Development Sent: Wednesday, March 13, 2024

Re: [Development] Should QObject::event() be protected or public?

ha scritto: >> Il 15/03/24 19:17, Jaroslaw Kobus via Development ha scritto: >>> +1. Typically, the designer of a subclass knows what he is doing. But it >>>also happens that users of this class know better how to use it :) >> I'm not sure what this means. >>

Re: [Development] Should QObject::event() be protected or public?

> From: Development on behalf of Thiago > Macieira > Sent: Friday, March 15, 2024 7:03 PM > To: development@qt-project.org > Subject: Re: [Development] Should QObject::event() be protected or public? > > On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote: >> I like simple