Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 15.2.2020 16.23, Marc Mutz via Development wrote: > Hi, > > C++20 will contain new classes with emit() member functions > (wg21.link/P0053). While that will only pose problems for users that > include the new header after (almost) any Qt header, this > should serve as a second shot across the bows (after namespace > boost::signals) that we should change something. This serves as proof that our custom keywords cause issues occasionally, but combined use of and Qt won't be that common. > > To that effect, I'd like to propose that we switch the default for > QT_NO_KEYWORDS around. I'd so this in three phases: > > 1. phase > a. Add CONFIG += keywords (or the CMake equivalent) to act as an > antagonist for no_keywords. > b. Change the documentation, examples and Qt implementation to use the > Q_ macros > > In this case, they just cancel each other out. This is just so you can > already express the intent to continue to use lowercase keywords by > saying CONFIG += keywords. It also makes sure that next generation of Qt > programmers grows up with the Q_ macros, so they don't squint their eyes > when they see > > Q_EMIT valueChanged(m_value); > > 2. phase > a. Make no_keywords the default > b. Change the documentation accordingly > c. the QT_NO_KEYWORDS macro is left untouched > > In this phase, projects that use qmake (or by some other means inherit > Qt's default) > > 3. phase > a. Replace QT_NO_KEYWORDS with a new macro QT_USE_KEYWORDS (or somesuch). > b. Change the documentation accordingly > > In this phase, even projects using not using Qt's defaults would switch > defaults. This plan requires everyone to drop the use of our custom keywords in their code or to enable a new define to compile source code that worked previously. As a backward-incompatible change I think it needs a strong justification. A couple of conflicts during 20 years that can be resolved with equivalent effort (QT_NO_EMIT or QT_NO_KEYWORDS) but are only encountered pretty rarely don't seem like a strong enough reasons to me. Isn't the way to cause the least pain for our users to do nothing in this case? The effort seems to be the same, it's just whether we impose it on everyone or just the people encountering conflicts. The rest of the thread has had a lot of discussion on what the possible alternatives to annotating signal emissions could be or whether such a thing is necessary at all. But I think evaluating whether this warrants a move at all should be considered more than it has. Alternatives may not be relevant if we're not going to get rid of `emit` being defined by default. > > We can then stop there, or we use the years to come to decide how we > want to transition off the macro stuff and consult with ISO C++ so they > can work with us to give us the functionality to do so (meta-classes, > qt::emit with overloaded whitespace operator, whatever). > > I think it's clear that, as it is now, where for two years such a > problem exists in the IS and doesn't get detected by "the Qt project", > for a certain definition thereof, and only comes up by chance encounter > at the last day of the last meeting before C++20 is "done", it cannot > continue. Or, if it continues, Qt will be bitten more and more by stuff > ISO C++ does. If ISO C++'s estimate for C++ programmers and TQC's claim > for Qt developers are both correct, we're looking at a size of the > intersection of the two groups of over 20% of all C++ programmers. I > happen to be firmly rooted in both, and I'd be sad to see the two > separate ways even more than they have done in the past. We should co-operate better in the future. We definitely should *not* add any new custom keywords. But is it worth tackling something very common that causes problems relatively rarely? -- Kari ___ 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
From: Development on behalf of Ville Voutilainen On Wed, 26 Feb 2020 at 18:45, Benjamin TERRIER wrote: >> I would like the idea of using attributes for this. However, compilers are >> allowed to warn for unknown attributes, which is useful to detect typos. >> This means that we would get a warning for each usage of [[qt::emit]]. So >> unless there is a way to disable unknown attribute warnings for a specific >> set of custom attributes this will be a pain. >That's debatable. [dcl.attr]/6 says >Any attribute-token that is not recognized by the implementation is ignored. >In general, implementations can still warn about pretty much whatever >they please, especially considering >that their default modes are not strictly conforming. > >The compilers we plan to support in Qt 6 do warn about unknown >attributes, so the allowance point is kinda >theoretical. Ville, please help me understand sth. If the express intention of attributes is that users should be encouraged to have their own, aren't the warning policies exhibited by current compilers counter productive to the intent of their intended purpose? Or do attributes mostly exist for the purposes compilers themselves may face? Also what's the chance that compiler communities might accept Qt specific attributes if for example TQtC were to put relevant patches forward? -- Alex ___ 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 Wed, 26 Feb 2020 at 18:45, Benjamin TERRIER wrote: > I would like the idea of using attributes for this. However, compilers are > allowed to warn for unknown attributes, which is useful to detect typos. > This means that we would get a warning for each usage of [[qt::emit]]. So > unless there is a way to disable unknown attribute warnings for a specific > set of custom attributes this will be a pain. That's debatable. [dcl.attr]/6 says Any attribute-token that is not recognized by the implementation is ignored. In general, implementations can still warn about pretty much whatever they please, especially considering that their default modes are not strictly conforming. The compilers we plan to support in Qt 6 do warn about unknown attributes, so the allowance point is kinda theoretical. ___ 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
26.02.2020, 19:28, "Alex Blasche" : >> Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >> > We don’t need one rule to rule them all either. Many signals are named >> fooChanged(), and can perfectly well stand on their own, without >> annotations. >> Corner cases like "emit pressed();” can be annotated with Q_EMIT or a >> comment >> to make it clearer what’s going on. > > Some end with "Changed". The overwhelming amount does not follow this rule > and we won't change the naming for Qt 6 either. The naming convention merely > states that there is a verb at the end. For example, let's consider QAbstractButton::clicked() signal. There is no sense in renaming it to anything ending with "Changed". -- 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 Fri, 21 Feb 2020 at 09:24, Kai Köhne wrote: > Hi, > > Another alternative is to actually use C++ attributes for this: > > [[qt::emit]] somethingChanged(); > > C++ attributes are required since C++11, and since C++17 the compiler is > also required to just ignore one's it doesn't know [1]. Because it is part > of the core language, It is also something every C++ IDE and tool does > accept (and could even check for) ... > I would like the idea of using attributes for this. However, compilers are allowed to warn for unknown attributes, which is useful to detect typos. This means that we would get a warning for each usage of [[qt::emit]]. So unless there is a way to disable unknown attribute warnings for a specific set of custom attributes this will be a pain. My 2 cents Benjamin ___ 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
> -Original Message- > From: Lars Knoll > >> -Original Message- > >> From: Lars Knoll > I’m not trying to make this only about emit. But it’s the concrete > problem we’re facing now, and emit is IMO the one keyword where we > simply don’t need a replacement because it has no real semantic > meaning in > >> C++. > >>> > >>> I don't think semantics matter here. It is all about annotation and > readability. > >> With the same arguments we design APIs. While Kai's survey is > >> inconclusive about the actual solution, it is conclusive in one > >> aspect. There is a clear majority to have sth in place for > annotation/readability purposes. > >> > >> As Kai said, in this case a comment would do the trick just as well, > >> no need for a keyword or macro: > >> > >> /*emit*/ mySignal(); or > >> mySignal(); // emit > > > > Can you see us adopting a coding style that enforces the use of such > comments? Otherwise this will quickly change to comments being forgotten > which makes the above suggestion less valuable. Although the alternatives have > no semantics either they impress a stronger coding style than comments IMO. > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find most > of > the alternatives to be worse than no annotation at all. Lars, I did not talk about enforcing. It is a fact that we overwhelmingly use it today. That's a convention hammered into each of our heads by years of adherence. Your comment suggestion would not have that unspoken benefit and therefore extremely quickly disappear. Please let me ask again, can you consider a coding convention to use such comments? Normally the usage of systematic comments for annotation is extremely rare. Therefore, I cannot see that your suggestion to adopt a comment style annotation would be anything else but a lip service without such a convention. -- Alex ___ 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
> -Original Message- > From: Development On Behalf Of > Simon Hausmann Please don't generalise where there is no general or even majority count (see below). > Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: > > We don’t need one rule to rule them all either. Many signals are named > fooChanged(), and can perfectly well stand on their own, without annotations. > Corner cases like "emit pressed();” can be annotated with Q_EMIT or a comment > to make it clearer what’s going on. Some end with "Changed". The overwhelming amount does not follow this rule and we won't change the naming for Qt 6 either. The naming convention merely states that there is a verb at the end. > This is also what tipped me over. We have stronger conventions nowadays with > property based APIs and the Changed suffix for the corresponding signals. > We'll > be fine without "emit" :-) Another case of generalisation where there is none. QML may have that notation but C++ doesn't. Now I don't know whether you plan to enforce such a rule for the new object property system but I would argue forcing every object property signal to end with "Changed" might be a bit too much. Last but not least, not every signal is associated to a property either. -- Alex > ___ > 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 2/15/20 3:23 PM, Marc Mutz via Development wrote: > Hi, > > C++20 will contain new classes with emit() member functions > (wg21.link/P0053). > Hello, I know this discussion is about C++, but I just wanted to mention that Signals in Python are objects, and we rely on the emit method to emit signals (duh!). As a C++ programmer, renaming the emit macro for something else doesn't affect me, even if we decide to remove it, because I think we can do fine, so I have no strong feelings. As a Python programmer, removing the macro will cause headaches when trying to figure out how to make Signals work, since looking at some random Qt/C++ code I will not know what's the proper way of emitting one. (In case I'm not aware of these conventions) As a PySide developer, if we agree to change the name, we can just rename the function we expose, to qEmit or whatever, but in case the macro gets removed, we will need to keep the emit() method, and explain to users that in C++ land this doesn't exists, which will maybe cause some headaches. My 3 cents, Cheers PS: More info about signals and slots in PySide: https://wiki.qt.io/Qt_for_Python_Signals_and_Slots -- Dr. Cristian Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ 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
Oliver Wolff (26 February 2020 15:10) wrote [snip] > it serves a purpose to me. "Look here a signal is emitted, so that other > parts who are interested in this information might react". For me that's > important information when reading code (be it while coding or in code > reviews). Indeed. As a reviewer, the awareness that "this" may have been destroyed at the emit makes these lines a significant pause for thought. Admittedly, when the emit happens inside some method I'm calling, that may be hidden; but then that method's name should reflect the possibly drastic changes to context that are credible responses to its signalling. We can say the same of the signal name, of course, but the signal itself is somewhat "atomic" where the methods that exercise them are (ipso facto) composites whose names need to reflect what they're expected to do over-all, where the signal's name properly just says what event has happened, that someone might want to connect to. I'd consider a naming convention adequate for signals, all the same. 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
Hi, On 21/02/2020 13:57, Mitch Curtis wrote: >> -Original Message- >> From: Eike Ziller >> Sent: Friday, 21 February 2020 1:55 PM >> To: Mitch Curtis >> Cc: Ville Voutilainen ; Alex Blasche >> ; development@qt-project.org >> Subject: Re: [Development] A modest proposal: disable lower-case >> keywords (emit, foreach, forever, signals, slots) by default >> >> >> >>> On 21. Feb 2020, at 13:30, Mitch Curtis wrote: >>> -Original Message- From: Development On Behalf >> Of Ville Voutilainen Sent: Friday, 21 February 2020 12:16 PM To: Alex Blasche Cc: development@qt-project.org Subject: Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default On Fri, 21 Feb 2020 at 10:42, Alex Blasche >> wrote: > I think a fallback to > > somethingChanged() > > without any annotation is not what we want. We'd miss vital > information and reduce readability. Can you please explain what that vital information is? >>> >>> How can you tell if it's a signal being emitted or just a function call >>> without >> the emit syntax? With the emit syntax before the signal emission, it's >> immediately obvious that it's a signal. >> >> It isn’t because you can put “emit” anywhere in your code because it has no >> semantics for the compiler. > > I never said it had any semantic purpose, I'm purely arguing that it has > implications for readability. I agree with Mitch here. For me the emit has value. It's just an annotation, but for me it serves a purpose. I can see that this is a signal emission and even if people keep arguing that this is pointless it serves a purpose to me. "Look here a signal is emitted, so that other parts who are interested in this information might react". For me that's important information when reading code (be it while coding or in code reviews). Now everyone can tell me, that I am stupid and that is not necessary, but to me it looks, like people are jumping the "I agree" train and people who disagree are somewhat "intimidated" and do no longer dare to voice that. My 5 cents, Olli > >> It’s not beter than any code comment that you could also put there, like >> >> /*emit*/ something(); >> >> or >> >> something(); // emit > > I disagree; I think those are ugly. > >>> Not all signals follow the *Changed() naming convention, nor should they, >> so it becomes even less obvious in those cases. >>> ___ 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 >> >> -- >> Eike Ziller >> Principal Software Engineer >> >> The Qt Company GmbH >> Erich-Thilo-Straße 10 >> D-12489 Berlin >> eike.zil...@qt.io >> http://qt.io >> Geschäftsführer: Mika Pälsi, >> Juha Varelius, Mika Harjuaho >> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, >> HRB 144331 B > > ___ > 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
26.02.2020, 16:34, "Simon Hausmann" : > Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >>> We’re neither enforcing the use of ‘emit’ currently. And I honestly find >>> most of the alternatives to be worse than no annotation at all. >> I agree. >> >> 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. >> >> We don’t need one rule to rule them all either. Many signals are named >> fooChanged(), and can perfectly well stand on their own, without >> annotations. Corner cases like "emit pressed();” can be annotated with >> Q_EMIT or a comment to make it clearer what’s going on. > > This is also what tipped me over. We have stronger conventions nowadays > with property based APIs and the Changed suffix for the corresponding > signals. We'll be fine without "emit" :-) FWIW, not all signals in world have corresponding properties. -- 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
Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >> We’re neither enforcing the use of ‘emit’ currently. And I honestly find >> most of the alternatives to be worse than no annotation at all. > I agree. > > 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. > > We don’t need one rule to rule them all either. Many signals are named > fooChanged(), and can perfectly well stand on their own, without annotations. > Corner cases like "emit pressed();” can be annotated with Q_EMIT or a comment > to make it clearer what’s going on. This is also what tipped me over. We have stronger conventions nowadays with property based APIs and the Changed suffix for the corresponding signals. We'll be fine without "emit" :-) Simon ___ 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 Wed, 26 Feb 2020 at 14:44, Tor Arne Vestbø wrote: > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find > > most of the alternatives to be worse than no annotation at all. > > I agree. > > 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. Yep, this part of it destroys the "annotate the yield operations" for me; if I call another function that then signals, I don't see the annotation, so the warm and fuzzy feeling of safety requires a very particular programming style. ___ 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
>>Were neither enforcing the use of emit currently. And I honestly >> find most of the alternatives to be worse than no annotation at all. As an illustration, for many years, I have the naming convention to start all my signals with... "signal" eg. signalChange(); This notation is so intuitive that I often forget to write "emit" before the call. Philippe On Wed, 26 Feb 2020 12:30:09 + Lars Knoll wrote: > > > > On 26 Feb 2020, at 10:38, Alex Blasche wrote: > > > > > > > >> -Original Message- > >> From: Lars Knoll > Im not trying to make this only about emit. But its the concrete > problem were facing now, and emit is IMO the one keyword where we > simply dont need a replacement because it has no real semantic meaning > in > >> C++. > >>> > >>> I don't think semantics matter here. It is all about annotation and > >>> readability. > >> With the same arguments we design APIs. While Kai's survey is inconclusive > >> about the actual solution, it is conclusive in one aspect. There is a > >> clear majority > >> to have sth in place for annotation/readability purposes. > >> > >> As Kai said, in this case a comment would do the trick just as well, no > >> need for a > >> keyword or macro: > >> > >> /*emit*/ mySignal(); or > >> mySignal(); // emit > > > > Can you see us adopting a coding style that enforces the use of such > > comments? Otherwise this will quickly change to comments being forgotten > > which makes the above suggestion less valuable. Although the alternatives > > have no semantics either they impress a stronger coding style than comments > > IMO. > > Were neither enforcing the use of emit currently. And I honestly find most > of the alternatives to be worse than no annotation at all. > > Cheers, > Lars > > > > > -- > > Alex > > ___ > 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 26 Feb 2020, at 13:30, Lars Knoll wrote: > > > >> On 26 Feb 2020, at 10:38, Alex Blasche wrote: >> >> >> >>> -Original Message- >>> From: Lars Knoll > I’m not trying to make this only about emit. But it’s the concrete > problem we’re facing now, and emit is IMO the one keyword where we > simply don’t need a replacement because it has no real semantic meaning in >>> C++. I don't think semantics matter here. It is all about annotation and readability. >>> With the same arguments we design APIs. While Kai's survey is inconclusive >>> about the actual solution, it is conclusive in one aspect. There is a clear >>> majority >>> to have sth in place for annotation/readability purposes. >>> >>> As Kai said, in this case a comment would do the trick just as well, no >>> need for a >>> keyword or macro: >>> >>> /*emit*/ mySignal(); or >>> mySignal(); // emit >> >> Can you see us adopting a coding style that enforces the use of such >> comments? Otherwise this will quickly change to comments being forgotten >> which makes the above suggestion less valuable. Although the alternatives >> have no semantics either they impress a stronger coding style than comments >> IMO. > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find most > of the alternatives to be worse than no annotation at all. I agree. 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. We don’t need one rule to rule them all either. Many signals are named fooChanged(), and can perfectly well stand on their own, without annotations. Corner cases like "emit pressed();” can be annotated with Q_EMIT or a comment to make it clearer what’s going on. Tor Arne ___ 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 Feb 2020, at 10:38, Alex Blasche wrote: > > > >> -Original Message- >> From: Lars Knoll I’m not trying to make this only about emit. But it’s the concrete problem we’re facing now, and emit is IMO the one keyword where we simply don’t need a replacement because it has no real semantic meaning in >> C++. >>> >>> I don't think semantics matter here. It is all about annotation and >>> readability. >> With the same arguments we design APIs. While Kai's survey is inconclusive >> about the actual solution, it is conclusive in one aspect. There is a clear >> majority >> to have sth in place for annotation/readability purposes. >> >> As Kai said, in this case a comment would do the trick just as well, no need >> for a >> keyword or macro: >> >> /*emit*/ mySignal(); or >> mySignal(); // emit > > Can you see us adopting a coding style that enforces the use of such > comments? Otherwise this will quickly change to comments being forgotten > which makes the above suggestion less valuable. Although the alternatives > have no semantics either they impress a stronger coding style than comments > IMO. We’re neither enforcing the use of ‘emit’ currently. And I honestly find most of the alternatives to be worse than no annotation at all. Cheers, Lars > > -- > Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Priority field in Jira
>From: Volker Hilsheimer > > The priority field changes it’s meaning during the lifetime of the bug report: > > * in the beginning, it tells us how important it is for the reporter of the > bug. This is useful. This is news to me; I've not once heard of it being used this way. I also question the usefulness of a field that has two meanings over time. Why not have two fields with distinct meanings that can't be confused and that result in no extra work? However little that work may be, it's still unnecessary. This solution is even more "inclusive" [1], as well. I would argue that a good bug report should explain what the consequences of a bug are and how this affects the user's application. I have asked for this exact information in several instances in the past and it greatly helped me come up with a suitable priority. If this information is not initially present in the report, this question has to be asked eventually anyway. When you ask what the consequences of a bug are and how it affects the end user, you can quite easily come up with an objective assessment of the priority of that bug, and of course any +1 comments, votes and watchers can naturally increase that priority over time to some extent. > * after triaging (which we do regularly, at least in The Qt Company), it > tells us how important it is for the Qt Company (and perhaps the Qt > community/project at large) But if the initial priority as reported by the customer is important, then you've just lost it by overriding during triage (not many people are going to check the "All" tab to see the history). This might solve the issue of being "inclusive", but then becomes a lack of transparency. > Anything that is still a P0 after triaging should be treated as such: > unplanned work that needs to be fixed so urgently that it preempts any > planned work. > > For everything else: if you are in a team that plans their work weeks based > on JIRA tickets, then the priority of a ticket is one piece of information > for that planning process. > > Not allowing reporters to set priority removes a piece of information, but > shouldn’t change anything else, so I’m not convinced that we should limit > things by default. Most reports are created with priorities left as unevaluated, so by now we should be used to coming to a conclusion about the priority without an initial assessment from the reporter. This is something I think the bug triaging duties are great for getting better at, and I think pretty much everyone in the company does a good job at assessing priorities. > If reporters consistently abuse their privilege, in spite of dialogue and > feedback, then we might need to find more effective ways to deal with those > particular reporters. To be clear: I've probably ever only had a ping-pong issue once, so I'm not claiming that that is a problem. I'm just questioning whether our process could be more efficient. [1] Though if you look another popular open source project with a public bug tracker with lots of bugs, you'll see that reporters have even less freedom in managing a report and somehow it works fine: https://github.com/godotengine/godot/issues ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Priority field in Jira
> On 26 Feb 2020, at 11:45, Mitch Curtis wrote: > >> >> From: Development on behalf of Lorn >> Potter >> Sent: Wednesday, 26 February 2020 11:15 AM >> To: development@qt-project.org >> Subject: Re: [Development] Priority field in Jira >> >> On 25/2/20 8:11 PM, Joerg Bornemann wrote: >>> On 2/25/20 10:31, Edward Welbourne wrote: >>> How about: because we can always over-ride them if we really disagree; and their prioritising of the bug is an opening for discussion of why it's so important to them - which, after all, we might have missed. I'd rather have a dialog than a privilege, >>> >>> This is about expertise, not privilege. For reporters, the priority is >>> usually muuch higher than for us or even other users of Qt, because >>> the priority is assessed from the viewpoint of their project. >>> >>> Let's say I've written this audio player app and found some quirk in >>> QtMultimedia that makes skipping impossible every once in a while. Users >>> give one star ratings and complain loudly. >>> What priority is this bug for me? Well, P0 of course. >>> For us? Not so much... >> >> That's when one uses the privilege of being the assignee to change the >> priority to what you think it is, with an explanation to the reporter >> why it isn't a P0. > > How is this different in the end? I can probably count the number of times a > priority set by a reporter didn't need to be changed on one hand. So in the > end it's simply extra work that has be done on top of an already massive > backlog of bugs. > >> Removing the ability for a reporter to change priority does not seem all >> that inclusive to me. >> my 2c... > > I must have missed something here, because I'm not aware of any issues with > "exclusion" in our bug tracker, and don't know how this can be construed as > being exclusive. There are processes that we follow to ensure that we have an > accurate overview of which bugs need the most attention. This is (or should > be) standard practice at every company that develops software, most of which > don't have public trackers in the first place. I fail to see how preventing > people who are unfamiliar with our prioritisation process from changing the > priority is excluding anyone, _especially_ when the means for disputing a > priority is already present and is the same regardless of whether or not the > priority field is open to everyone. The priority field changes it’s meaning during the lifetime of the bug report: * in the beginning, it tells us how important it is for the reporter of the bug. This is useful. * after triaging (which we do regularly, at least in The Qt Company), it tells us how important it is for the Qt Company (and perhaps the Qt community/project at large) Anything that is still a P0 after triaging should be treated as such: unplanned work that needs to be fixed so urgently that it preempts any planned work. For everything else: if you are in a team that plans their work weeks based on JIRA tickets, then the priority of a ticket is one piece of information for that planning process. Not allowing reporters to set priority removes a piece of information, but shouldn’t change anything else, so I’m not convinced that we should limit things by default. If reporters consistently abuse their privilege, in spite of dialogue and feedback, then we might need to find more effective ways to deal with those particular reporters. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Priority field in Jira
Actually, priority field is not that useful. Anything except P0 and P1 can hang indefinitely in unsolved state, and I agree that assigning P0 or P1 should be restricted. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Priority field in Jira
> >From: Development on behalf of Lorn >Potter >Sent: Wednesday, 26 February 2020 11:15 AM >To: development@qt-project.org >Subject: Re: [Development] Priority field in Jira > >On 25/2/20 8:11 PM, Joerg Bornemann wrote: >> On 2/25/20 10:31, Edward Welbourne wrote: >> >>> How about: because we can always over-ride them if we really disagree; >>> and their prioritising of the bug is an opening for discussion of why >>> it's so important to them - which, after all, we might have missed. >>> >>> I'd rather have a dialog than a privilege, >> >> This is about expertise, not privilege. For reporters, the priority is >> usually muuch higher than for us or even other users of Qt, because >> the priority is assessed from the viewpoint of their project. >> >> Let's say I've written this audio player app and found some quirk in >> QtMultimedia that makes skipping impossible every once in a while. Users >> give one star ratings and complain loudly. >> What priority is this bug for me? Well, P0 of course. >> For us? Not so much... > >That's when one uses the privilege of being the assignee to change the >priority to what you think it is, with an explanation to the reporter >why it isn't a P0. How is this different in the end? I can probably count the number of times a priority set by a reporter didn't need to be changed on one hand. So in the end it's simply extra work that has be done on top of an already massive backlog of bugs. >Removing the ability for a reporter to change priority does not seem all >that inclusive to me. >my 2c... I must have missed something here, because I'm not aware of any issues with "exclusion" in our bug tracker, and don't know how this can be construed as being exclusive. There are processes that we follow to ensure that we have an accurate overview of which bugs need the most attention. This is (or should be) standard practice at every company that develops software, most of which don't have public trackers in the first place. I fail to see how preventing people who are unfamiliar with our prioritisation process from changing the priority is excluding anyone, _especially_ when the means for disputing a priority is already present and is the same regardless of whether or not the priority field is open to everyone. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Priority field in Jira
On 25/2/20 8:11 PM, Joerg Bornemann wrote: On 2/25/20 10:31, Edward Welbourne wrote: How about: because we can always over-ride them if we really disagree; and their prioritising of the bug is an opening for discussion of why it's so important to them - which, after all, we might have missed. I'd rather have a dialog than a privilege, This is about expertise, not privilege. For reporters, the priority is usually muuch higher than for us or even other users of Qt, because the priority is assessed from the viewpoint of their project. Let's say I've written this audio player app and found some quirk in QtMultimedia that makes skipping impossible every once in a while. Users give one star ratings and complain loudly. What priority is this bug for me? Well, P0 of course. For us? Not so much... That's when one uses the privilege of being the assignee to change the priority to what you think it is, with an explanation to the reporter why it isn't a P0. Removing the ability for a reporter to change priority does not seem all that inclusive to me. my 2c... Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Lorn Potter Freelance Qt Developer. Platform Maintainer Qt WebAssembly, Maintainer QtSensors Author, Hands-on Mobile and Embedded Development with Qt 5 ___ 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
> -Original Message- > From: Lars Knoll > >> I’m not trying to make this only about emit. But it’s the concrete > >> problem we’re facing now, and emit is IMO the one keyword where we > >> simply don’t need a replacement because it has no real semantic meaning in > C++. > > > > I don't think semantics matter here. It is all about annotation and > > readability. > With the same arguments we design APIs. While Kai's survey is inconclusive > about the actual solution, it is conclusive in one aspect. There is a clear > majority > to have sth in place for annotation/readability purposes. > > As Kai said, in this case a comment would do the trick just as well, no need > for a > keyword or macro: > > /*emit*/ mySignal(); or > mySignal(); // emit Can you see us adopting a coding style that enforces the use of such comments? Otherwise this will quickly change to comments being forgotten which makes the above suggestion less valuable. Although the alternatives have no semantics either they impress a stronger coding style than comments IMO. -- Alex ___ 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
> I don't think semantics matter here. It is all about annotation and readability. With the same arguments we design APIs. While Kai's survey is inconclusive about the actual solution, it is conclusive in one aspect. There is a clear majority to have sth in place for annotation/readability purposes. You should I think take into account that the whole C++ community manages to do just fine without annotating calls to std::function (or $any_other_signal_slot_library_in_the_universe) in the same way - even though all of the "dangers" can still apply. On Wed, Feb 26, 2020 at 9:18 AM Alex Blasche wrote: > > > > -Original Message- > > From: Development On Behalf Of Lars > > Knoll > > > > I’m not trying to make this only about emit. But it’s the concrete > problem we’re > > facing now, and emit is IMO the one keyword where we simply don’t need a > > replacement because it has no real semantic meaning in C++. > > I don't think semantics matter here. It is all about annotation and > readability. With the same arguments we design APIs. While Kai's survey is > inconclusive about the actual solution, it is conclusive in one aspect. > There is a clear majority to have sth in place for annotation/readability > purposes. > > > > Qt relies on macros a lot, and while I have not followed the latest > Modules > > development, I'm sure macros pose a problem for a modularized Qt, too > > > > > > So while emit is the latest in the line of macro clashes, it's not the > first and it > > likely won't be the last. So, please, just removing 'emit' because it's > easy doesn't > > solve the problem for `signals` and `slots`. > > > > > > Can access specifiers have attributes? > > > public [[qt::slots]]: > > > > > > > Why do we need it, if functions can already have attributes? > > Because it is in the wrong spot. I want to spot the signal call in a cpp > file and not a header. I must assume that the reason why we had emit in the > first place (besides "slots" and "signals") is the same. > > > public: > > [[qt::slot]] void mySlot(); > > > > protected: > > [[qt::signal] void mySignal(); > > I’d love to have this too (in addition to [[qt::emit]]) > > -- > Alex > > ___ > 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 26 Feb 2020, at 09:16, Alex Blasche wrote: > > > >> -Original Message- >> From: Development On Behalf Of Lars >> Knoll > > >> I’m not trying to make this only about emit. But it’s the concrete problem >> we’re >> facing now, and emit is IMO the one keyword where we simply don’t need a >> replacement because it has no real semantic meaning in C++. > > I don't think semantics matter here. It is all about annotation and > readability. With the same arguments we design APIs. While Kai's survey is > inconclusive about the actual solution, it is conclusive in one aspect. There > is a clear majority to have sth in place for annotation/readability purposes. As Kai said, in this case a comment would do the trick just as well, no need for a keyword or macro: /*emit*/ mySignal(); or mySignal(); // emit Both of those are IMO more readable than most of the other proposals we had. > >>> Qt relies on macros a lot, and while I have not followed the latest Modules >> development, I'm sure macros pose a problem for a modularized Qt, too >>> >>> So while emit is the latest in the line of macro clashes, it's not the >>> first and it >> likely won't be the last. So, please, just removing 'emit' because it's easy >> doesn't >> solve the problem for `signals` and `slots`. >>> >>> Can access specifiers have attributes? >>> public [[qt::slots]]: >>> >> >> Why do we need it, if functions can already have attributes? > > Because it is in the wrong spot. I want to spot the signal call in a cpp file > and not a header. I must assume that the reason why we had emit in the first > place (besides "slots" and "signals") is the same. Marc was asking about the declarations in the headers where we have signals/Q_SIGNALS and slots/Q_SLOTS. Those could be replaced by adding an attribute to the method declaration. Cheers, Lars > >> public: >> [[qt::slot]] void mySlot(); >> >> protected: >> [[qt::signal] void mySignal(); > > I’d love to have this too (in addition to [[qt::emit]]) > > -- > Alex > ___ 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
> -Original Message- > From: Development On Behalf Of Lars > Knoll > I’m not trying to make this only about emit. But it’s the concrete problem > we’re > facing now, and emit is IMO the one keyword where we simply don’t need a > replacement because it has no real semantic meaning in C++. I don't think semantics matter here. It is all about annotation and readability. With the same arguments we design APIs. While Kai's survey is inconclusive about the actual solution, it is conclusive in one aspect. There is a clear majority to have sth in place for annotation/readability purposes. > > Qt relies on macros a lot, and while I have not followed the latest Modules > development, I'm sure macros pose a problem for a modularized Qt, too > > > > So while emit is the latest in the line of macro clashes, it's not the > > first and it > likely won't be the last. So, please, just removing 'emit' because it's easy > doesn't > solve the problem for `signals` and `slots`. > > > > Can access specifiers have attributes? > > public [[qt::slots]]: > > > > Why do we need it, if functions can already have attributes? Because it is in the wrong spot. I want to spot the signal call in a cpp file and not a header. I must assume that the reason why we had emit in the first place (besides "slots" and "signals") is the same. > public: > [[qt::slot]] void mySlot(); > > protected: > [[qt::signal] void mySignal(); I’d love to have this too (in addition to [[qt::emit]]) -- Alex ___ 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
Hi, There are now 73 results to the survey, current results are at https://bugreports.qt.io/secure/attachment/92413/survey_result.pdf I tried to aggregate also the other suggestions, and ordering by absolute votes: mySignal() - 21 votes Q_EMIT mySignal() - 13 votes [[qt::emit]] mySignal() - 12 votes qemit mySignal() - 5 votes emit mySignal() - 3 votes qEmit(mySignal) - 1 vote keep the \"ugly\" q_emit but don\`t require it. - 1 vote method call with naming convention - 1 vote mySignal() // emit, let a comment look lik a comment - 1 vote [[emit]] - 1 vote emitmysignal() - 1 vote Thanks for participating! Kai > -Original Message- > From: Development On Behalf Of Kai > Köhne > Sent: Monday, February 24, 2020 4:31 PM > To: Ville Voutilainen ; Lars Knoll > > Cc: Thiago Macieira ; Qt development mailing > list > Subject: Re: [Development] A modest proposal: disable lower-case keywords > (emit, foreach, forever, signals, slots) by default > > Hi, > > Since this is arguably as much about taste as it is about technicalities, I > thought it might be interesting to do a quick poll in the form of a survey: > > https://www.1ka.si/a/255723 > > Disclaimer: Qt Project is not a democracy, so let's not pretend that whatever > gets most clicks gets implemented in the end. Still, I'm curious ... > > Kai > > > -Original Message- > > From: Development On Behalf Of > > Ville Voutilainen > > Sent: Monday, February 24, 2020 2:53 PM > > To: Lars Knoll > > Cc: Thiago Macieira ; Qt development > > mailing list > > Subject: Re: [Development] A modest proposal: disable lower-case > > keywords (emit, foreach, forever, signals, slots) by default > > > > On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote: > > > But we could convey the information that this is a signal you’re > > > calling > > *reliably* through other means. This implies that the keyword is not > required. > > > > Was the keyword ever required? Seems like it's just a taste difference > > from a > > > > qEmit(my_signal()); > > > > to write > > > > emit my_signal(); > > > > The first one can be namespaced, and thus its name lookup controlled. > > It also never clashes with a member name. > > Its worse aesthetics aside, if we'd had that since the beginning, we > > wouldn't be talking about the current clashes with std::osyncstream. > > ___ > > 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 mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
