Re: [Development] 6.7 FF vs. C++20 comparisons
Il 13/12/23 18:36, Thiago Macieira ha scritto: On Wednesday, 13 December 2023 08:46:57 -03 Marc Mutz via Development wrote: The question I have, therefore, is the following: is converting more classes to the new framework considered a feature as in "affected by FF"? I'd say simple changes should be fine. There should be no behaviour change at all, anywhere. If that turns out to be a large change, we may want to postpone; if it breaks something, then we've likely found a bug. I'm also +1 on the same grounds. I'm very mildly concerned about "breaks something", not in the sense that a rewrite of the operators using the new facilities will not work, but that it might have semantic changes that will break BC (e.g. for inline code). It was quite hard to spot it on QModelIndex... Thank you, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Update What's new in Qt 6.7 (Was: Re: HEADS-UP: Qt 6.7 Feature Freeze)
Hi, There is quite a lot of things missing still from https://codereview.qt-project.org/c/qt/qtdoc/+/524057 Qt 6.7 Beta 1 release is somewhere early next week and we should publish the first iteration of the What’s new page along with it. Yours, Tuukka From: Development on behalf of Volker Hilsheimer via Development Date: Saturday, December 9, 2023 at 16:07 To: Jani Heikkinen , development@qt-project.org Subject: Re: [Development] HEADS-UP: Qt 6.7 Feature Freeze > On 8 Dec 2023, at 15:06, Jani Heikkinen via Development > wrote: > > Hi! > Qt 6.7 Feature Freeze will be in effect today. If your changes are ready and > approved by the end of today, you can still continue staging those in 'dev' > over the weekend. The plan is to branch from "6.7" to "dev" on Monday morning > next week. Perhaps we should wait with branching off until we have a successful dependency round completed in dev. Otherwise the CI system will do twice the work to test the same set of changes in different branches. > If your feature isn't ready by the end of today, you'll either need to > postpone it to Qt 6.8 or request an exception. If your feature is ready and merged, please remember to update the whatsnew67.qdoc file in the qtdoc repository as well. To limit conflicts, use gerrit’s inline editing feature to add your bits to this change: https://codereview.qt-project.org/c/qt/qtdoc/+/524057 Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Request for early MOC support for C++20 Modules
Hi Devs, I'd like to ask about a possible roadmap update regarding C++20 modules support in moc. There was a discussion a while ago about C++20/23 support for Qt (https://lists.qt-project.org/pipermail/development/2023-May/043823.html), and I would like to know if there has been any internal update. The corresponding bug report is https://bugreports.qt.io/browse/QTBUG-86697, but it seems that even more bump comments will not help. This is about ensuring moc can handle modules, not about converting Qt itself into a module. Getting moc ready for C++20 modules is something that could be done now, well in advance of Qt 6.9. For me, this is the only, and biggest, roadblock to adding modules support in my apps. Also, we shouldn't forget about tools like the QtRemoteObjects compiler that translates .rep files into .cpp/.h files (and possibly others?) that need updating too. On a related note, when moving a class to modules, it would be handy to have a way to skip the 'Generate Missing Q_PROPERTY Members' boilerplate code. My current classes are mostly 50% getter/setter boilerplate, and in my opinion, this is only manageable because we split our code into header and source files. This will be gone when using modules. So, I would like to see something like *Q_PROP(QString text)*, that generates default get/set/notify code, and if needed, one could still use the old *Q_PROPERTY(QString text READ text WRITE setText NOTIFY textChanged FINAL)* if they need to add additional logic into the get/set functions. Cheers, Elias Steurer -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
Hi, > On a related note, when moving a class to modules, it would be handy to > have a way to skip the 'Generate Missing Q_PROPERTY Members' boilerplate > code. My current classes are mostly 50% getter/setter boilerplate, and > in my opinion, this is only manageable because we split our code into > header and source files. This will be gone when using modules. So, I > would like to see something like *Q_PROP(QString text)*, that generates > default get/set/notify code, and if needed, one could still use the old > *Q_PROPERTY(QString text READ text WRITE setText NOTIFY textChanged > FINAL)* if they need to add additional logic into the get/set functions. Sounds like a job for a Q_SYNTHESIZE (modeled after Objective C’s @synthesize). Cheers Kai Uwe -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
Hi Elias, let's get your second question out of the way: Doesn't Q_PROPERTY(Qstring text MEMBER m_text) cover that already? Now, for the actual question, moc supporting modules: That certainly wasn't a priority before CMake had official support for modules, but granted, they do now support them, and the three big compilers have at least some amount support for them. Still, I haven't seen much (Qt Company) customer demand there, though as the ticket shows, there is quite a bit of community interest. What would be needed to actually get module support into moc? 1. moc's parsing logic needs to learn about the relevant new keywords. moc needs to know at the very least the module (partition)'s name. 2. The generator needs to be adjusted to actually create valid code (basically what's described in the referenced bug). I expect some challenges there (e.g. what if your custom Q_OBJECT is only in an internal partition, but not in the primary module interface, can moc then find all necessary imports?), but I guess the most trivial cases could be supported without too much work. But I suspect your more interested in timelines, not the details of what the work entails. The ship has already sailed for Qt 6.7. If we want this feature in Qt 6.8, I see two ways forward: - Someone contributes patches. As moc's maintainer, I can promise to review them timely - There is enough interest (e.g. voiced here on the mailing list here, or by customers via support) that I can justify working on that feature myself. If neither of the two happen, I expect this to slip to 6.9 (but then to be picked up for 6.9 due to the expected general push for mandatory C++20 support in Qt) Lastly, as mentioned on this year's Qt contributor summit, moc's current architecture as a glorified preprocessor comes with its own challenges. I totally expect that to bite us when it comes to more interesting module use cases, but it's not a blocker for getting support for the "easy" parts in. Fabian Von: Development im Auftrag von Elias Steurer via Development Gesendet: Freitag, 15. Dezember 2023 14:36 An: development@qt-project.org Betreff: [Development] Request for early MOC support for C++20 Modules Hi Devs, I'd like to ask about a possible roadmap update regarding C++20 modules support in moc. There was a discussion a while ago about C++20/23 support for Qt (https://lists.qt-project.org/pipermail/development/2023-May/043823.html), and I would like to know if there has been any internal update. The corresponding bug report is https://bugreports.qt.io/browse/QTBUG-86697, but it seems that even more bump comments will not help. This is about ensuring moc can handle modules, not about converting Qt itself into a module. Getting moc ready for C++20 modules is something that could be done now, well in advance of Qt 6.9. For me, this is the only, and biggest, roadblock to adding modules support in my apps. Also, we shouldn't forget about tools like the QtRemoteObjects compiler that translates .rep files into .cpp/.h files (and possibly others?) that need updating too. On a related note, when moving a class to modules, it would be handy to have a way to skip the 'Generate Missing Q_PROPERTY Members' boilerplate code. My current classes are mostly 50% getter/setter boilerplate, and in my opinion, this is only manageable because we split our code into header and source files. This will be gone when using modules. So, I would like to see something like Q_PROP(QString text), that generates default get/set/notify code, and if needed, one could still use the old Q_PROPERTY(QString text READ text WRITE setText NOTIFY textChanged FINAL) if they need to add additional logic into the get/set functions. Cheers, Elias Steurer -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
Hi Fabian, >let's get your second question out of the way: Doesn't Q_PROPERTY(QString text MEMBER m_text) cover that already? No, I still need all the get/set/notify functions to change/get the variables from the outside. There is currently no way to do that, or am I missing something? Something like this https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52 but as a standardized Qt macro. Thanks for the insight regarding moc timeline and challenges. Let's hope some customers voice their support 😊 Cheers, Eli On 12/15/2023 3:07 PM, Fabian Kosmale wrote: Hi Elias, let's get your second question out of the way: Doesn't Q_PROPERTY(Qstring text MEMBER m_text) cover that already? Now, for the actual question, moc supporting modules: That certainly wasn't a priority before CMake had official support for modules, but granted, they do now support them, and the three big compilers have at least some amount support for them. Still, I haven't seen much (Qt Company) customer demand there, though as the ticket shows, there is quite a bit of community interest. What would be needed to actually get module support into moc? 1. moc's parsing logic needs to learn about the relevant new keywords. moc needs to know at the very least the module (partition)'s name. 2. The generator needs to be adjusted to actually create valid code (basically what's described in the referenced bug). I expect some challenges there (e.g. what if your custom Q_OBJECT is only in an internal partition, but not in the primary module interface, can moc then find all necessary imports?), but I guess the most trivial cases could be supported without too much work. But I suspect your more interested in timelines, not the details of what the work entails. The ship has already sailed for Qt 6.7. If we want this feature in Qt 6.8, I see two ways forward: - Someone contributes patches. As moc's maintainer, I can promise to review them timely - There is enough interest (e.g. voiced here on the mailing list here, or by customers via support) that I can justify working on that feature myself. If neither of the two happen, I expect this to slip to 6.9 (but then to be picked up for 6.9 due to the expected general push for mandatory C++20 support in Qt) Lastly, as mentioned on this year's Qt contributor summit, moc's current architecture as a glorified preprocessor comes with its own challenges. I totally expect that to bite us when it comes to more interesting module use cases, but it's not a blocker for getting support for the "easy" parts in. Fabian Von: Development im Auftrag von Elias Steurer via Development Gesendet: Freitag, 15. Dezember 2023 14:36 An:development@qt-project.org Betreff: [Development] Request for early MOC support for C++20 Modules Hi Devs, I'd like to ask about a possible roadmap update regarding C++20 modules support in moc. There was a discussion a while ago about C++20/23 support for Qt (https://lists.qt-project.org/pipermail/development/2023-May/043823.html), and I would like to know if there has been any internal update. The corresponding bug report ishttps://bugreports.qt.io/browse/QTBUG-86697, but it seems that even more bump comments will not help. This is about ensuring moc can handle modules, not about converting Qt itself into a module. Getting moc ready for C++20 modules is something that could be done now, well in advance of Qt 6.9. For me, this is the only, and biggest, roadblock to adding modules support in my apps. Also, we shouldn't forget about tools like the QtRemoteObjects compiler that translates .rep files into .cpp/.h files (and possibly others?) that need updating too. On a related note, when moving a class to modules, it would be handy to have a way to skip the 'Generate Missing Q_PROPERTY Members' boilerplate code. My current classes are mostly 50% getter/setter boilerplate, and in my opinion, this is only manageable because we split our code into header and source files. This will be gone when using modules. So, I would like to see something like Q_PROP(QString text), that generates default get/set/notify code, and if needed, one could still use the old Q_PROPERTY(QString text READ text WRITE setText NOTIFY textChanged FINAL) if they need to add additional logic into the get/set functions. Cheers, Elias Steurer-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
On 2023-12-15, Elias Steurer via Development wrote: > No, I still need all the get/set/notify functions to change/get the > variables from the outside. There is currently no way to do that, or am > I missing something? Something like this > https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52 > > but as a standardized Qt macro. My experience, after having written a few macros like that out of projects, is that it is a bad idea, unless it is really thought thru. What I have seen is that it encourages all properties to be read/write/notify where at least many of them was only supposed to be read/notify or read/constant. /Sune -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
> On 15 Dec 2023, at 16:19, Sune Vuorela wrote:
>
> On 2023-12-15, Elias Steurer via Development
> wrote:
>> No, I still need all the get/set/notify functions to change/get the
>> variables from the outside. There is currently no way to do that, or am
>> I missing something? Something like this
>> https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52
>> but as a standardized Qt macro.
>
> My experience, after having written a few macros like that out of
> projects, is that it is a bad idea, unless it is really thought thru.
>
> What I have seen is that it encourages all properties to be
> read/write/notify where at least many of them was only supposed to be
> read/notify or read/constant.
>
> /Sune
Would it help/be a bad idea if moc would identify member functions that match
the Qt naming convention so that you can reduce the boiler plate, e.g.
class Thing
{
Q_PROPERTY(QString text)
public:
void setText(const QString &text); // obviously the setter
QString text() const; // evidently the getter
signals:
textChanged(const QString &text); // there’s a notification signal
};
Doesn’t help you if you use snake case, but *could* perhaps be configurable
with a command line option.
Volker
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
On Friday, 15 December 2023 11:07:44 -03 Fabian Kosmale via Development wrote: > 1. moc's parsing logic needs to learn about the relevant new keywords. moc > needs to know at the very least the module (partition)'s name. Please forgive my lack of knowledge on this and asking of very basic questions. That's why I asked Ville during QtCS two weeks ago for someone to investigate module support and explain to the rest of us what it would mean to support them. Is the file format for the imported modules already standardised? Is it in the C++ standard? I don't remember seeing it there. If it's not a standard (ISO C++ standard or otherwise), we'd need to write format parsers for each compiler, which raises the cost for supporting modules considerably, especially if the compilers aren't committing to a stable format in the first place. Qt should make the commitment that will support at most one module format. Any compiler that doesn't operate on those will not have their modules supported. I don't know if this is the same content that CMake had to support. It's possible it isn't because CMake doesn't need to know about the classes, enums, variables, functions, and all other entities declared, which are part of the translation unit. Moc does need that. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
