Hi,
On 2020-02-13 19:29, Thiago Macieira wrote:
On Thursday, 13 February 2020 09:53:11 PST Thiago Macieira wrote:
I can confirm krdc is affected just the same way that KMail and
VirtualBox
are: it works on screen 1, but fails to repaint on screen 2.
It's a much simpler application than KMail
On Thu, Feb 13, 2020 at 10:01:02AM +, Maurice Kalinowski wrote:
> > From: Development On Behalf Of
> > André Pönitz Sent: Wednesday, February 12, 2020 8:00 PM To: Allan
> > Sandfeld Jensen Cc: development@qt-project.org
> > Subject: Re: [Development] The future of smart pointers in Qt API
> >
On Thu, Feb 13, 2020 at 09:42:23AM +, Karsten Heimrich wrote:
> -Original Message-
> >From: André Pönitz Sent: Mittwoch, 12. Februar
> >2020 19:38 Uhr To: Vitaly Fanaskov Cc:
> >Karsten Heimrich ; development@qt-project.org
> >Subject: Re: [Development] The future of smart pointers in
On Thursday, 13 February 2020 09:53:11 PST Thiago Macieira wrote:
> I can confirm krdc is affected just the same way that KMail and VirtualBox
> are: it works on screen 1, but fails to repaint on screen 2.
>
> It's a much simpler application than KMail to debug. I can reproduce this by
> using it
On Tuesday, 28 January 2020 19:14:50 PST Thiago Macieira wrote:
> I don't know what makes KMail different. I thought it was the use of a
> qtwebengine window, but the qtwebengine examples seem to work fine.
>
> My current theory is embedding of X11 content
> (QWidget::createWindowContainer, use of
On 13 Feb 2020, at 13:53, Maurice Kalinowski
mailto:maurice.kalinow...@qt.io>> wrote:
Hi,
I think moving the implementations into one git repo would be a good move. In
that case you could also move the qml state machine bindings from qtdeclarative
(See src/imports folder).
I don’t think mer
Hi,
I think moving the implementations into one git repo would be a good move. In
that case you could also move the qml state machine bindings from qtdeclarative
(See src/imports folder).
I don’t think merging the implementations is a good idea, I find they serve
different purposes. Just my t
Hi,
I think moving the implementations into one git repo would be a good move. In
that case you could also move the qml state machine bindings from qtdeclarative
(See src/imports folder).
I don’t think merging the implementations is a good idea, I find they serve
different purposes. Just my tw
HI,
maybe I send out the wrong signal, but currently the suggestion is to keep the
implementations, just unify them in a separate module.
-- Karsten
From: Jean-Michaël Celerier
Sent: Donnerstag, 13. Februar 2020 12:03 Uhr
To: Karsten Heimrich
Cc: development@qt-project.org
Subject: Re: [Devel
As far as I know, there are no tasks created so far. I agree that we need to
create a separate task, but not until the final decision.
As it was mentioned in this thread, moving Qt smart pointers to Qt5Compat
module is not discussed so far. What to do with existing public API that uses
smart Qt
Il 13/02/20 10:57, Vitaly Fanaskov ha scritto:
I think that moving Qt smart pointers to Qt5Compat module creates almost
no hassle. For Qt users it should be a one line in the terminal to
replace includes in their code bases (probably also prepend a namespace
to classes' names, but I'm not sure if
What has lead to considering that they could eventually be removed ?
Couldn't they be split off in a separate library put in the marketplace or
github for instance if they're a thorn ?
No reason to throw away code that works, is there ?
On Thu, Feb 13, 2020 at 10:58 AM Karsten Heimrich
wrote:
Hi all,
We have restricted staging in qt5.git repo in '5.14' branch temporarily. This
is done to get few provisioning related changes in; it seems that those cannot
be integrated without increased coordination. Heikki and me will integrate
those changes in and after that we will restore staging
> From: Development On Behalf Of
> André Pönitz
> Sent: Wednesday, February 12, 2020 8:00 PM
> To: Allan Sandfeld Jensen
> Cc: development@qt-project.org
> Subject: Re: [Development] The future of smart pointers in Qt API
>
> On Wed, Feb 12, 2020 at 05:08:33PM +0100, Allan Sandfeld Jensen wrote:
I think that moving Qt smart pointers to Qt5Compat module creates almost
no hassle. For Qt users it should be a one line in the terminal to
replace includes in their code bases (probably also prepend a namespace
to classes' names, but I'm not sure if there is a namespace).
In general, I'd say t
Hi,
we would like to remove the QStatemachine API's from Qt Core. We identified 2
options to do this:
* Move into QtScXML and keep both the implementation
* rename the module to reflect that it contains 2 different state machine
implementations
* Move into Qt5Compat
* in the long
-Original Message-
>From: André Pönitz
>Sent: Mittwoch, 12. Februar 2020 19:38 Uhr
>To: Vitaly Fanaskov
>Cc: Karsten Heimrich ; development@qt-project.org
>Subject: Re: [Development] The future of smart pointers in Qt API
>
>On Wed, Feb 12, 2020 at 11:13:17AM +, Vitaly Fanaskov wrote
Yes, I see your point. The thing is that we need to narrow this
discussion down and make a decision. Creating something like a wiki page
would take a long time, I'm afraid. I think that there is should be a
balance between collecting all possible opinions and trying to
understand what contribut
Another important PSA.
Developers that modify .pro / .pri / .qrc / configure.json files in 5.14 /
5.15, your changes will be merged upwards all the way to dev (this is business
as usual at the moment).
That means that the 5.15 -> dev merge might fail, due to the CMakeLists.txt
files not being
19 matches
Mail list logo
