Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess
On Friday, 28 February 2020 10:42:54 PST Thiago Macieira wrote: > 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. Pushed as https://codereview.qt-project.org/c/qt/qtbase/+/292539 The previous four changes in the same line of fixes need to be approved before this gets in, though. -- 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 Fri, 28 Feb 2020 at 22:35, Lars Knoll wrote: > >> 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). Just turning signals into objects seems SC to me. But nothing will be SC if it has the whole-token "emit" in it. So if we want to introduce some sort of a more-structured C++ approach, we need to pick a different name for it to coexist with emit. > 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). Agreed. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Infra problems - CI is down
Hi, We have problems with our infra and for that reason our CI is currently down. Unfortunately no estimation yet when we have system up and running again. Ystävällisin terveisin / Kind regards, Heikki Halmet Software Engineer | CI Lead Release and Test Automation | CI Team The Qt Company | Finland | Oulu ___ 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 16:28:34 CET Matthew Woehlke wrote: > 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, ...); I agree with the latter. We would need another syntax for connecting if the method names all began with emit. The old SIGNAL() macro could easily be adapted, but the modern syntax would be a problem. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
