Il 24/02/20 13:48, Mitch Curtis ha scritto:
In that case, I share the same concerns as Andre in that it requires IDEs to
have knowledge about Qt. I only use Creator, so it won't bother me, but it will
affect others who are e.g. transitioning or are so used to another IDE that
they'd never swit
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, to some of
us. It causes
fair amounts of "wtf is that?".
That
Hi,
On Monday, February 24, 2020 18:19 CET, Ulf Hermann wrote:
> > Is there a better way to determine what modules are provided?
>
> You could scan the plugins.qmltypes files. There you get a detailed
> listing that tells you what components are available under what imports
> and versions.
Hi,
> Is there a better way to determine what modules are provided?
You could scan the plugins.qmltypes files. There you get a detailed
listing that tells you what components are available under what imports
and versions.
best regards,
Ulf
___
Develo
Hi,
I'm adding a Requires:/Provides: autogenerator for QML modules to rpm (so
packages containing a qml file will automatically pull in the right library
dependencies).
I have a more or less working prototype that extracts relevant information from
qmldir files, but given "module" statements in
24.02.2020, 18:19, "Allan Sandfeld Jensen" :
>
> Yeah you would need something like qEmit(&my_signal, Args..) or without &
> using a macro. Or.. qEmit(std::bind(&my_signal, Args...));
FWIW, using lambda expression is almost always a better solution that std::bind.
--
Regards,
Konstantin
_
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 implemente
On Monday, 24 February 2020 15:03:41 CET Ville Voutilainen wrote:
> On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen
>
> wrote:
> > 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.
On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen
wrote:
>
> 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
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_sign
On Mon, 24 Feb 2020 at 14:35, Mitch Curtis wrote:
> > > > > Signals have different semantics than regular functions.
> > > >
> > > > In what way?
> > >
> > > They typically call back into "upper layers", which is worth considering
> > > on
> > the calling side, e.g. due to the danger of inconsist
> -Original Message-
> From: Edward Welbourne
> Sent: Monday, 24 February 2020 1:35 PM
> To: Mitch Curtis
> Cc: Qt development mailing list ; Lars Knoll
> ; Thiago Macieira
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slo
> -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
> keywords (emit, foreach, forever, signals, slots) by default
>
>
On 24 Feb 2020, at 13:22, Mitch Curtis
mailto:mitch.cur...@qt.io>> wrote:
-Original Message-
From: Development
mailto:development-boun...@qt-project.org>>
On Behalf Of
Lars Knoll
Sent: Monday, 24 February 2020 12:25 PM
To: Thiago Macieira
mailto:thiago.macie...@intel.com>>
Cc: Qt devel
> -Original Message-
> From: Development On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 3:02 PM
> To: Christian Kandeler
> Cc: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slot
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 arg);
and throws a wobbly.
Eddy.
___
> -Original Message-
> From: Development On Behalf Of
> Lars Knoll
> Sent: Monday, 24 February 2020 12:25 PM
> To: Thiago Macieira
> Cc: Qt development mailing list
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by d
On 24 Feb 2020, at 12:30, André Somers
mailto:an...@familiesomers.nl>> wrote:
Hi Lars,
Sent from my phone, please excuse my brevity
On 24 Feb 2020, at 12:27, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
On 21 Feb 2020, at 17:39, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
On
Hi Lars,
Sent from my phone, please excuse my brevity
> On 24 Feb 2020, at 12:27, 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 si
> 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, to some of
>> us. It causes
>> fair amounts of "wtf is that?".
>
> That was my reaction when I first saw it, in 199
> 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 feature freeze in effect, with approval from module maintainer
>> (up until Beta1; aft
> On 24 Feb 2020, at 10:54, Ville Voutilainen
> wrote:
>
> On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier
> wrote:
>>
>> A good inspiration for that feature would be the Just My Code feature of
>> recent visual studio :
>> https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-
Hi,
It seems Qt 5.15 API review is still quite badly ongoing, see
https://bugreports.qt.io/browse/QTBUG-81853
* qtbase (https://codereview.qt-project.org/c/qt/qtbase/+/289203): started but
pretty low activity there.
* qtdeclarative
(https://codereview.qt-project.org/c/qt/qtdeclarative/+/289205
Yes, no change yet. The implementation of the cherry-pick automation is
happening here
https://codereview.qt-project.org/c/qt/qtqa/+/291376/4
and in the related changes. Good progress, thanks to Daniel and the various
peeps helping with reviews and feedback! Considering the time it takes to get
On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier
wrote:
>
> A good inspiration for that feature would be the Just My Code feature of
> recent visual studio :
> https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019
That is indeed what I'm gunning for. :) If our probl
A good inspiration for that feature would be the Just My Code feature of
recent visual studio :
https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019
Best,
Jean-Michaël
On Mon, Feb 24, 2020 at 8:51 AM Shawn Rutledge wrote:
>
> > On 22 Feb 2020, at 12:57, Ville Voutila
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?
Any custom QQuickItem subclass can be a FocusScope, it just needs to set
a flag on i
On 2020-02-21 17:31, Thiago Macieira wrote:
On Friday, 21 February 2020 03:21:32 PST Ville Voutilainen wrote:
Yes, and the name change was discussed but rejected.
Do you know why it was such strong against? Was it, "darn it's too
late" or
was it "we don't care"?
Both. I think the argument
28 matches
Mail list logo
