Hi,
Qt 5.15 Beta1 is released, see https://www.qt.io/blog/qt-5.15-beta1-released
br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
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 appar
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 th
On 26/02/2020 09.10, Oliver Wolff wrote:
> 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 oth
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 thin
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
Hi,
Declarative in 5.15 (5.14?) has public API taking a std::function and that
appears to be okay so far :)
Simon
> Am 27.02.2020 um 18:53 schrieb Thiago Macieira :
>
> On Monday, 24 February 2020 03:07:00 PST Lars Knoll wrote:
>>> On 21 Feb 2020, at 18:49, Thiago Macieira
>>> wrote:
>
On Thursday, 27 February 2020 04:40:34 PST Ville Voutilainen wrote:
> The chance is very good; I talked about this with the maintainer of
> GCC already, and he was amenable to disabling
> an "unknown attribute" warning if the attribute has a namespace. For
> attributes that don't have namespaces,
>
On Wednesday, 26 February 2020 08:26:14 PST Alex Blasche wrote:
> > 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"
On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
> > In any case, I do understand why Qt added emit as a keyword 25 years ago.
> > But today, we do have IDEs which should be able to figure out on the fly
> > whether a function call is a signal emission (as they already do for
> > virtua
On Tuesday, 25 February 2020 23:24:14 PST Lars Knoll wrote:
> The way it works is that in case more than one slot is connected to such a
> signal, the return value of the last slot connected is returned, if nothing
> is connected a default constructed value is returned.
The last DirectConnection s
On Monday, 24 February 2020 03:07:00 PST Lars Knoll wrote:
> > On 21 Feb 2020, at 18:49, Thiago Macieira
> > wrote:
> > On Friday, 21 February 2020 08:39:57 PST Volker Hilsheimer wrote:
> >
> >> I’m fine with that, and as communicated by Jani, deprecations can be
> >> done
> >> even with featur
Kai Köhne (27 February 2020 16:46) wrote:
> Another thing I'm wondering about is the use of QT_DEPRECATED_SINCE in
> Qt's .cpp files. I see the benefit of QT_DEPRECATED_SINCE in the
> headers, because these are compiled into the user code, who in turn
> can use QT_DISABLE_DEPRECATED_BEFORE. Anyhow,
Hi,
After seeing many different ways to deprecate API in Qt 5.15, I thought it
might make sense to assemble some best practices (comments & extensions
welcome):
https://codereview.qt-project.org/c/meta/quips/+/292255
One of the main takeaways is: Please also properly deprecate in the
docume
Hi Pier!
First of all I’d like to strongly echo your thanks to Johan for his amazing
work on QtWayland!
The module is important to us as well, and we’d like to see it continued. As of
now we do not have a dedicated person to take over Johan's work, but this is
something we’re looking to addres
> I may need to write that patch myself.
Would you consider instead a patch introducing a builtin that allows a
library to declare attributes they "support" ?
eg something in the taste of __builtin_declare_valid_attribute("qt::emit");
A far cry from attribute creation abilities of languages such
On Thu, 27 Feb 2020 at 09:15, Alex Blasche wrote:
> >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
> >attri
17 matches
Mail list logo
