Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 12:12:35 PST Matthew Woehlke wrote: > On 28/02/2020 13.39, Thiago Macieira wrote: > > That's my point: it's a reasonable feature to ask that any good IDE > > implement. > It may be reasonable to ask *an IDE* to implement such a feature. It is > *not* reasonable to ask every place that developers look at code — some > of which don't even do basic syntax highlighting, much less have the > project parsing capability necessary to build a code model — to > implement such a feature. That being the case, you are never going to > achieve the same level of annotation as `emit` provides. We lived for 7 years with Gerrit not highlighting anything at all in qstring.cpp. That's not the end of the world. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 12:06:06 PST Matthew Woehlke wrote:
> ...this might actually be better, since it would mean we still have MOC
> generating the code for the signal. (I was trying to figure out how MOC
> would generate the object initialization logic, and failing. I suspect
> this would work better. I wonder if we could even introduce this new
> style without breaking existing code source compatibility?)
>
> ...but I think connections would still look like either:
>
> connect(foo, ::emptied, ...);
>
> ...or:
>
> connect(foo->emptied(), ...);
Yes, this can be added BC break for new signals and is also SC forwards-
compatible ifor Qt 7:
template
class QSignal
{
...
};
static QSignal bytesWritten() const;
connect(foo, ::bytesWritten, receiver, ...);
Some magic in QObject::connect() can detect whether the return type is a
QSignal and so match the QSignal's template parameter to the slot, instead of
the PMF. It'll also call the static function to get the ID and this static
function is generated by moc. We could also design QSignal so it's a C++20
structural type, so it could eventually be used as a non-type template
parameter.
But it can't be retrofitted without BC break to existing signals, since the
function name is already used.
The signal emission would be different:
qEmit(::bytesWritten, count);
or
qEmit(q->bytesWritten(), count);
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Abandoning fix for QTBUG-67970 - QString & std::u16string_view support
Task filed by Herb Sutter. https://bugreports.qt.io/browse/QTBUG-67970 https://codereview.qt-project.org/c/qt/qtbase/+/227684 There are conflicts in my rebase to 5.15 and I don't want to give the impression I'll have time to continue work. So just abandoning. Someone else pick it up, please. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Abandoning low-level I/O unreviewed patches
About two and a half years old without much of a review, and I don't have time to fix the rebase conflicts with 5.15, so I'm just abandoning. Maybe in 4 years we can just rip everything out and use std::filesystem. Until then, it's not worth my time to fix further, especially after the moveToTrash addition refactored the Windows code. There are a number of bugfixes applied because of the unit testing for tst_qfilesystemengine. Unfortunately, it also finds a number of defects in Windows itself that I never managed to work around. If anyone wants to take a look: https://codereview.qt-project.org/211240 Long live QSystemResult https://codereview.qt-project.org/211398 https://codereview.qt-project.org/212254 https://codereview.qt-project.org/212255 https://codereview.qt-project.org/212256 https://codereview.qt-project.org/212257 https://codereview.qt-project.org/254546 - fixes QTBUG-74102 https://codereview.qt-project.org/212258 https://codereview.qt-project.org/212259 https://codereview.qt-project.org/212260 https://codereview.qt-project.org/212261 https://codereview.qt-project.org/212262 https://codereview.qt-project.org/212263 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Signal naming convention (was: A modest proposal: disable lower-case keywords...)
Honestly, a naming convention may solve the issue within the Qt
code-base, but I don't think it would necessarily be adopted by all
users of Qt.
Personally, I in my Qt projects I just use the Q_EMIT macro, and I do
find that helpful.
The downside of the naming convention aspect is that Lambdas may be
involved so it might not be clear based on the name either, at least
when looking under a debugger.
Overall, the conversation has been interesting, and while my opinion may
not matter much (being I haven't been involved much in the last few
years given work constraints) - I'd lean towards moving away from `emit`
and back to using `Q_EMIT` and then allowing `Q_EMIT` to generate the
compiler annotation for supported compilers or being an empty macro in
other cases.
Any how... $0.02 FWIW.
Ben
On 2/28/20 3:13 PM, Vasily Pupkin wrote:
> Prefixing identifiers is a slippery slope. In a fit of unifying coding
> style everything will get prefixed. There will be slot_, m_, property_,
> setter_/getter_ and so on.
> Type name prefixing worth mentioning - unbelieably ugly
> convention
> https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions .
>
>
> If you do this in your code base, consider postfixing, rather than
> prefixing. It enables better readability.
> Given a module, that implements a feature with several aspects.
> class Feature
> {
> void aspect1_signal();
> void apscet1_slot();
> }
>
> пт, 28 февр. 2020 г. в 22:38, Max Paperno >:
>
>
> I humbly suggest, in general, that a signal name could be prefixed with
> "sig", "sig_", "signal" or "signal_". "sigEmptied()" doesn't look
> horrible IMHO, and should work semantically with any verb. Using
> prefixes to signify meaning already has some precedence in C/C++ world
> as well. And lastly even "dumb" syntax highlighters could pick up on
> that pretty easily (even w/out access to, or needing to parse, any
> header files to determine what is a signal), though of course there
> could be "false positives" for any other words starting with "sig"
> (like
> "significantElements()" :) ).
>
> As a Qt user and frequent reader of other people's code (like on
> StackOverflow for instance to answer questions, git repos, code
> reviews,
> e-mails, etc, etc), it's clearly useful to know that a method call is a
> signal vs. anything else. I'd rather not have to remember that "hot
> pink
> color on SO highlighter" means it's a signal (and in many cases there's
> no way for a highlighter or basic text editor to even determine that).
>
> Cheers,
> -Max (returning to lurk mode)
>
> (This is not a reply to anyone in particular, just quoting the most
> recent relevant bits below.)
>
> On 2/28/2020 4:34 AM, Edward Welbourne wrote:
> > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
> >>> Taking a step back... I think some of the reason for the current
> >>> situation has to do with API design. Which of these is easier to
> understand?
> >>>
> >>> if (map.empty())
> >>> emptied();
> >>>
> >>> - vs. -
> >>>
> >>> if (map.isEmpty())
> >>> emit emptied();
> >>>
> >>> One reads like plain English. The other is missing words in a
> way that
> >>> can confuse readers.
> >
> > 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.
> >
> > Indeed; most of the case for "emit" can be answered by a sensible
> naming
> > convention. Even the case of "functions that trigger signals" can be
> > handled by that, when it really matters.
> ___
> 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
>
--
Ben Meyer
Software Engineer
(703)901-2797
bm_witn...@yahoo.com
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> On 28 Feb 2020, at 21:18, Sérgio Martins via Development > wrote: > > On 2020-02-28 18:32, Thiago Macieira wrote: >> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >>> If we had to do it over again, it might make sense to follow Python and >>> make signals *objects* instead of *methods*. Then the code would look like: >>> this->emptied.emit(...); >> Binary compatibility issue: if it's a member of the class, it can't be added >> or removed without changing the class's size and layout, so it would tie our >> hands for future improvements. >> You'd see instead: >>this->emptied().emit(...); >>connect(foo, foo->emptied(), ...); > > > I like this, then we could finally (and without hacks) have protected and > private signals like in Qt 4. > > Would also solve the need for qOverload ? This is all nice and fun to bike shed about, but I don’t think those proposed solutions match the scope of the original problem (which was relatively small). I don’t think a massive source compatibility breakage is what we want, just because there is one std header using emit as a method name. And most of Qt’s signals are named in a way that makes it rather obvious it’s a signal we’re looking at (e.g. fooChanged() or clicked()), so there’s no need for an ‘emit’ in front to be clear. Some names are less obvious and the ‘emit’ does help readability of our source code. So to shortcut this discussion a bit: I am completely opposed to a massive SIC changes/efforts for our signals (like giving them ugly names like emitClicked(), or signal objects). If people feel strongly, I am open to trying to find a way to keep some sort of ‘emit’ prefix (whether that’s Q_EMIT or a [[qt::emit]] attribute), but I do agree with Marc that we should in the long term try to get away from having emit/signals/slots defined as macros (at least by default). Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 2020-02-28 18:32, Thiago Macieira wrote: On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: If we had to do it over again, it might make sense to follow Python and make signals *objects* instead of *methods*. Then the code would look like: this->emptied.emit(...); Binary compatibility issue: if it's a member of the class, it can't be added or removed without changing the class's size and layout, so it would tie our hands for future improvements. You'd see instead: this->emptied().emit(...); connect(foo, foo->emptied(), ...); I like this, then we could finally (and without hacks) have protected and private signals like in Qt 4. Would also solve the need for qOverload ? 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 https://lists.qt-project.org/listinfo/development
Re: [Development] Signal naming convention
On 2/28/2020 2:37 PM, Max Paperno wrote: I humbly suggest, in general, that a signal name could be prefixed with "sig", "sig_", "signal" or "signal_". "sigEmptied()" doesn't look horrible IMHO, and should work semantically with any verb. Using prefixes to signify meaning already has some precedence in C/C++ world as well. And lastly even "dumb" syntax highlighters could pick up on that pretty easily (even w/out access to, or needing to parse, any header files to determine what is a signal), though of course there could be *"false positives"* for any other words starting with "sig" (like "significantElements()" :) ). Sorry, "significantElements()" is a bad example of course. The "sig" would need to be followed by upper case (or "[nal][_]") and be called w/out a return value (on a new line or at least "standalone" within an [implied] block like "if (foo) sigEmptied();"). So actually false positives are probably not very likely. -Max ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Signal naming convention (was: A modest proposal: disable lower-case keywords...)
Prefixing identifiers is a slippery slope. In a fit of unifying coding
style everything will get prefixed. There will be slot_, m_, property_,
setter_/getter_ and so on.
Type name prefixing worth mentioning - unbelieably ugly convention
https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions
.
If you do this in your code base, consider postfixing, rather than
prefixing. It enables better readability.
Given a module, that implements a feature with several aspects.
class Feature
{
void aspect1_signal();
void apscet1_slot();
}
пт, 28 февр. 2020 г. в 22:38, Max Paperno :
>
> I humbly suggest, in general, that a signal name could be prefixed with
> "sig", "sig_", "signal" or "signal_". "sigEmptied()" doesn't look
> horrible IMHO, and should work semantically with any verb. Using
> prefixes to signify meaning already has some precedence in C/C++ world
> as well. And lastly even "dumb" syntax highlighters could pick up on
> that pretty easily (even w/out access to, or needing to parse, any
> header files to determine what is a signal), though of course there
> could be "false positives" for any other words starting with "sig" (like
> "significantElements()" :) ).
>
> As a Qt user and frequent reader of other people's code (like on
> StackOverflow for instance to answer questions, git repos, code reviews,
> e-mails, etc, etc), it's clearly useful to know that a method call is a
> signal vs. anything else. I'd rather not have to remember that "hot pink
> color on SO highlighter" means it's a signal (and in many cases there's
> no way for a highlighter or basic text editor to even determine that).
>
> Cheers,
> -Max (returning to lurk mode)
>
> (This is not a reply to anyone in particular, just quoting the most
> recent relevant bits below.)
>
> On 2/28/2020 4:34 AM, Edward Welbourne wrote:
> > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
> >>> Taking a step back... I think some of the reason for the current
> >>> situation has to do with API design. Which of these is easier to
> understand?
> >>>
> >>>if (map.empty())
> >>> emptied();
> >>>
> >>> - vs. -
> >>>
> >>>if (map.isEmpty())
> >>> emit emptied();
> >>>
> >>> One reads like plain English. The other is missing words in a way that
> >>> can confuse readers.
> >
> > 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.
> >
> > Indeed; most of the case for "emit" can be answered by a sensible naming
> > convention. Even the case of "functions that trigger signals" can be
> > handled by that, when it really matters.
> ___
> 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
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28/02/2020 13.39, Thiago Macieira wrote: > That's my point: it's a reasonable feature to ask that any good IDE implement. It may be reasonable to ask *an IDE* to implement such a feature. It is *not* reasonable to ask every place that developers look at code — some of which don't even do basic syntax highlighting, much less have the project parsing capability necessary to build a code model — to implement such a feature. That being the case, you are never going to achieve the same level of annotation as `emit` provides. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28/02/2020 13.37, Konstantin Tokarev wrote: > 28.02.2020, 21:34, "Thiago Macieira" : >> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >>> If we had to do it over again, it might make sense to follow Python and >>> make signals *objects* instead of *methods*. Then the code would look like: >>> >>> this->emptied.emit(...); >> >> Binary compatibility issue: if it's a member of the class, it can't be added >> or removed without changing the class's size and layout, so it would tie our >> hands for future improvements. >> >> You'd see instead: >> >> this->emptied().emit(...); >> connect(foo, foo->emptied(), ...); > > I think it could be a static member as well - there is no real reason for > such member > to be per-instance in the first place. If it was static, you'd have to pass the instance to `emit(...)`. Otherwise you don't know what instance sent the signal. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 28/02/2020 13.32, Thiago Macieira wrote: > On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >> If we had to do it over again, it might make sense to follow Python and >> make signals *objects* instead of *methods*. Then the code would look like: >> >> this->emptied.emit(...); > > Binary compatibility issue: if it's a member of the class, it can't be added > or removed without changing the class's size and layout, so it would tie our > hands for future improvements. Good point. Although... > You'd see instead: > > this->emptied().emit(...); > connect(foo, foo->emptied(), ...); ...this might actually be better, since it would mean we still have MOC generating the code for the signal. (I was trying to figure out how MOC would generate the object initialization logic, and failing. I suspect this would work better. I wonder if we could even introduce this new style without breaking existing code source compatibility?) ...but I think connections would still look like either: connect(foo, ::emptied, ...); ...or: connect(foo->emptied(), ...); -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Signal naming convention (was: A modest proposal: disable lower-case keywords...)
I humbly suggest, in general, that a signal name could be prefixed with "sig", "sig_", "signal" or "signal_". "sigEmptied()" doesn't look horrible IMHO, and should work semantically with any verb. Using prefixes to signify meaning already has some precedence in C/C++ world as well. And lastly even "dumb" syntax highlighters could pick up on that pretty easily (even w/out access to, or needing to parse, any header files to determine what is a signal), though of course there could be "false positives" for any other words starting with "sig" (like "significantElements()" :) ). As a Qt user and frequent reader of other people's code (like on StackOverflow for instance to answer questions, git repos, code reviews, e-mails, etc, etc), it's clearly useful to know that a method call is a signal vs. anything else. I'd rather not have to remember that "hot pink color on SO highlighter" means it's a signal (and in many cases there's no way for a highlighter or basic text editor to even determine that). Cheers, -Max (returning to lurk mode) (This is not a reply to anyone in particular, just quoting the most recent relevant bits below.) On 2/28/2020 4:34 AM, Edward Welbourne wrote: On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: Taking a step back... I think some of the reason for the current situation has to do with API design. Which of these is easier to understand? if (map.empty()) emptied(); - vs. - if (map.isEmpty()) emit emptied(); One reads like plain English. The other is missing words in a way that can confuse readers. 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. Indeed; most of the case for "emit" can be answered by a sensible naming convention. Even the case of "functions that trigger signals" can be handled by that, when it really matters. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtWayland future
> > Unfortunately Johan Helsing is leaving The Qt Company. > > > > He has done an amazing work and I want to thank him. > Good news for Johan I suppose but definitely bad news for Qt as one of the brightest minds leaves. Good luck! > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess
On Thursday, 27 February 2020 11:50:02 PST Simon Hausmann wrote: > Hi, > > Declarative in 5.15 (5.14?) has public API taking a std::function and that > appears to be okay so far :) Good to know. I see it in two public headers in 5.14. We've just found out that std::mutex is missing on a non-insignificant platform: MinGW (at least some builds of it). I just hope that people using those platforms simply hadn't skipped qtdeclarative in 5.14. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 07:24:32 PST Matthew Woehlke wrote:
> We aren't talking about recognizing `emit`. We're talking about being
> able to inspect the following code:
>
> if (...)
> {
> this->update();
> this->changed();
> }
>
> ...and recognizing that the former is a "regular" method call, while the
> latter is a signal emission. Which requires a code model that correctly
> identifies the corresponding header *and* understands MOC's
> meta-language. TTBOMK, *no* IDE's (or perhaps only QtC) currently do the
> latter.
That's my point: it's a reasonable feature to ask that any good IDE implement.
Qt is not an irrelevant chunk of C++, so understanding what a signal is and
helping developers is very much in an IDE's scope. At the very least, they
should have a feature to detect whether the function being called is code in
this project, another project, or is generated during the build.
Whether the feature will be implemented is a whole other story. But it's
reasonable to ask.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
28.02.2020, 21:34, "Thiago Macieira" : > On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >> If we had to do it over again, it might make sense to follow Python and >> make signals *objects* instead of *methods*. Then the code would look like: >> >> this->emptied.emit(...); > > Binary compatibility issue: if it's a member of the class, it can't be added > or removed without changing the class's size and layout, so it would tie our > hands for future improvements. > > You'd see instead: > > this->emptied().emit(...); > connect(foo, foo->emptied(), ...); I think it could be a static member as well - there is no real reason for such member to be per-instance in the first place. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: > If we had to do it over again, it might make sense to follow Python and > make signals *objects* instead of *methods*. Then the code would look like: > > this->emptied.emit(...); Binary compatibility issue: if it's a member of the class, it can't be added or removed without changing the class's size and layout, so it would tie our hands for future improvements. You'd see instead: this->emptied().emit(...); connect(foo, foo->emptied(), ...); -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 27/02/2020 17.03, Allan Sandfeld Jensen wrote: > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: >> On 26/02/2020 07.42, Tor Arne Vestbø wrote: >>> As others have argued, a signal is not special, in the sense that any >>> function can do anything, including emitting signals, so annotating it >>> doesn’t seem critical, as we apparently are fine without in all other >>> cases. >> Taking a step back... I think some of the reason for the current >> situation has to do with API design. Which of these is easier to understand? >> >> if (map.empty()) >> emptied(); >> >> - vs. - >> >> if (map.isEmpty()) >> emit emptied(); >> >> One reads like plain English. The other is missing words in a way that >> can confuse readers. > > 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. I still have to disagree. *The signal* is "emptied". It is *not* "emitEmptied". If we had to do it over again, it might make sense to follow Python and make signals *objects* instead of *methods*. Then the code would look like: this->emptied.emit(...); But I *equally do not* want to write: connect(foo, ::emitEmptied, ...); -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 27/02/2020 17.01, Allan Sandfeld Jensen wrote:
> On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote:
>> On 27/02/2020 13.57, Thiago Macieira wrote:
>>> On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
You seem to assume everyone used QtCreator as their IDE of choice. That
is
not a reasonable assumption I think.
>>>
>>> It is a reasonable feature request for ALL IDEs to understand what a Qt
>>> signal is.
>>
>> Really? You include github/gitlab/phabricator in that list? Vim? Notepad++?
>
> I would be surprised if any of those didn't.
Really? Because only one of those *might* include code parsing abilities.
We aren't talking about recognizing `emit`. We're talking about being
able to inspect the following code:
if (...)
{
this->update();
this->changed();
}
...and recognizing that the former is a "regular" method call, while the
latter is a signal emission. Which requires a code model that correctly
identifies the corresponding header *and* understands MOC's
meta-language. TTBOMK, *no* IDE's (or perhaps only QtC) currently do the
latter.
Conversely, `emit` works *even in non-IDE's*; notepad, cat, grep,
(github), etc Claiming that "the IDE can do just as good a job
marking signals as using `emit`" is just plain wrong, or at least,
missing the point.
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Fixing network-related warnings in modules other than qtbase (5.15)
To all, please, don't do this now. The original patches with error->networkError and similar were reverted, since the decision was made in favour of changing/deprecation signal name instead. Thanks. Best regards, Timur. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, 28 Feb 2020 at 10:35, Edward Welbourne wrote: > > > Indeed; most of the case for "emit" can be answered by a sensible naming > convention. > One case where it does not work is in connections. emit somethingWasDone() and emitSomethingWasDone() look similar. But the emit in connect(obj, ::emitSomethingWasDone, ...) looks a bit superfluous to me. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 26/02/2020 07.42, Tor Arne Vestbø wrote: >>> As others have argued, a signal is not special, in the sense that any >>> function can do anything, including emitting signals, so annotating it >>> doesn’t seem critical, as we apparently are fine without in all other >>> cases. On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote: >> Taking a step back... I think some of the reason for the current >> situation has to do with API design. Which of these is easier to understand? >> >> if (map.empty()) >> emptied(); >> >> - vs. - >> >> if (map.isEmpty()) >> emit emptied(); >> >> One reads like plain English. The other is missing words in a way that >> can confuse readers. 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. Indeed; most of the case for "emit" can be answered by a sensible naming convention. Even the case of "functions that trigger signals" can be handled by that, when it really matters. The only problem is that (as a legacy of having had a "keyword" for so long) we have a bunch of signals whose names don't conform to that convention. No-one has suggested we abolish "emit" overnight; so there shall be time to change the names of things during the course of the transition to retiring it. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Monday, 24 February 2020 03:30:25 PST André Somers wrote: You seem to assume everyone used QtCreator as their IDE of choice. That is not a reasonable assumption I think. On 27/02/2020 13.57, Thiago Macieira wrote: >>> It is a reasonable feature request for ALL IDEs to understand what a >>> Qt signal is. On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote: >> Really? You include github/gitlab/phabricator in that list? Vim? >> Notepad++? Allan Sandfeld Jensen (27 February 2020 23:01) replied > I would be surprised if any of those didn't. I see that emacs in fact colours emit green and the next word yellow (I think it's mistaking it for a declaration, as it colours types green and identifiers yellow in those), but if I remove emit it doesn't do anything special with the signal invocation. So I think that counts as emacs not knowing what signals are, although it does do something, albeit probably bogus, with the "keyword" when used. Whether one counts emacs, vim or notepad++ as an IDE is, however, another story ! I read Thiago as talking about things that *call themselves* IDEs, rather than text editors. Even so, asking MSVS to support Qt-specific features ... sounds ambitious - good luck ;^> Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] HEADS-UP: Branching from '5.14' to '5.14.2' started
Hi, We have soft branched '5.14.2' from '5.14'. So please start using '5.14.2' for all new changes targeted to Qt 5.14.2 release. Final downmerge from '5.14' to '5.14.2' will happen Monday 9th March. We are targeting to release Qt 5.14.2 Tue 17th March br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
