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
_
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
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 Feb
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,
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
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 choic
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
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 th
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(...);
>
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 "regu
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-insi
> > 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 mai
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 lastl
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(...);
>
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 wou
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
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-styl
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 pr
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 c
> 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
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 ma
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 moveToTra
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.
-
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 w
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 ev
25 matches
Mail list logo
