> On 24 Feb 2020, at 23:29, Marc Mutz wrote:
>
> Hi Lars, others,
>
> On 2020-02-24 12:25, Lars Knoll wrote:
>>> On 21 Feb 2020, at 17:39, Thiago Macieira wrote:
>>> On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
Having a keyword-extension to normal C++ is ugly as sin, t
> On 25 Feb 2020, at 20:17, Matthew Woehlke wrote:
>
> On 21/02/2020 09.02, Ville Voutilainen wrote:
>> Getting back to macro vs. function.. I think using a function wrapper
>> is fine, considering that signals can't
>> meaningfully return, so the prvalue/xvalue issue doesn't arise.
>
> AFAIK, s
On Tue, 25 Feb 2020 at 10:19, Ville Voutilainen
wrote:
> Or perhaps qEmit(this)->my_signal(Args...);
>
> and hide the befriending of qEmit (so that private/protected don't
This doesn't even need friending.
#include
template
struct qEmit
{
T* that;
qEmit(T* it) : that(it) {}
T* ope
On Tue, 25 Feb 2020 at 22:17, Matthew Woehlke wrote:
> Right, and when I realized that, it got me wondering, how many people
> will need to call that specific function that are *also* using Qt *and*
> will be unwilling to use Q_NO_KEYWORDS to work around the issue?
You're getting back to the reas
On 25/02/2020 14.58, Ville Voutilainen wrote:
> On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote:
>> - Until now, `emit` has rarely been used in code that needs to mix with Qt.
>>
>> - C++20 will have modules.
>>
>> - Modules are theoretically immune to the above issue.
>
> Module definitions a
On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote:
>
> On 24/02/2020 07.34, Edward Welbourne wrote:
> > Mitch Curtis (24 February 2020 13:22)
> >> I don't think anyone has explained what that harm is yet.
> >
> > #define emit
> >
> > causes problems when you import a header that declares
> >
> >
On 24/02/2020 07.34, Edward Welbourne wrote:
> Mitch Curtis (24 February 2020 13:22)
>> I don't think anyone has explained what that harm is yet.
>
> #define emit
>
> causes problems when you import a header that declares
>
> void emit(Type arg);
>
> and the compiler sees
>
> void (Type ar
On 21/02/2020 09.02, Ville Voutilainen wrote:
> Getting back to macro vs. function.. I think using a function wrapper
> is fine, considering that signals can't
> meaningfully return, so the prvalue/xvalue issue doesn't arise.
AFAIK, signals *can't* return, period. The signal body is written by
moc
> On 24. Feb 2020, at 13:48, Mitch Curtis wrote:
>
>> -Original Message-
>> From: Lars Knoll
>> Sent: Monday, 24 February 2020 1:40 PM
>> To: Mitch Curtis
>> Cc: Thiago Macieira ; Qt development mailing
>> list
>> Subject: Re: [Development] A modest proposal: disable lower-case
>> ke
Hi,
The QtWayland module contains the Wayland platform abstraction and a nice
library to make compositors using Qt and QtQuick.
QtWayland Compositor is being used by LG, Jolla, embedded projects and Liri.
The client part is an integral part of those projects and of course it's
fundamental for us
On Mon, 24 Feb 2020 at 7:06 pm, Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:
>
>
> So, does anyone know the historical reasoning here, or any good reason
> for not changing FocusScope just a normal property on Item?
>
> I don’t know the reason but if you just change it to
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 priv
Will try to make comments inline... had to change email client.
On 25/2/20, 10:31 am, "Edward Welbourne" wrote:
Mitch Curtis (25 February 2020 10:23) elaborated on what he'd said earlier:
>> For some context and for those who don't know: within the company, we
>> now have weekly bug
> On 24 Feb 2020, at 10:03, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> Something that I've always wondered about (and hopefully whose reasons have
> been lost in the Nokia times) is why FocusScope exists a dedicated item,
> rather than simply being an ordinary property on Item?
Mitch Curtis (25 February 2020 10:23) elaborated on what he'd said earlier:
>> For some context and for those who don't know: within the company, we
>> now have weekly bug triaging where a team of two people prioritise
>> all unprioritised bugs. So new reports rarely go more than a few days
>> with
> For some context and for those who don't know: within the company, we
> now have weekly bug triaging where a team of two people prioritise all
> unprioritised bugs. So new reports rarely go more than a few days without
> having a priority set. We've been doing this for a few years (?) now and it
Hi.
I'm curious about what the reasons were for allowing (non-approver) reporters
of bugs to set the priority field in Jira.
In my experience this often results in priorities being assigned that don't
follow our conventions [1] on what constitutes a certain priority, but instead
a priority tha
On Tue, 25 Feb 2020 at 00:30, Marc Mutz via Development
wrote:
> 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.
Header units can still export macros. Macros don't go into header
units or named
> That was my first thought (before looking at the qmldir files) as well, but
> it doesn't seem to help with the same modules that are problematic with the
> qmldir scanner.
> e.g. QtQuick.tooling:
QtQuick.tooling does not exist. It's only there to have an import
statement in the *.qmltypes fil
On Mon, 24 Feb 2020 at 17:17, Allan Sandfeld Jensen wrote:
> Yeah you would need something like qEmit(&my_signal, Args..) or without &
> using a macro. Or.. qEmit(std::bind(&my_signal, Args...));
Or perhaps qEmit(this)->my_signal(Args...);
and hide the befriending of qEmit (so that private/prot
20 matches
Mail list logo
