Hi all,
'5.14' is soft branched from 'dev' now. Final downmerge from 'dev' to '5.14',
Qt 5.14 Feature Freeze ( and most probably also branching '5.15' from '5.14'
[1]) will happen Monday 26th August. So start using '5.14' for new changes
targeted to Qt 5.14 release.
And please fill Qt 5.14. ne
Jason H wrote:
> I also have to point out that there was a statement made by Lars to make
> QML [more] strongly typed. I had expected that from the beginning, that
> Python would be the scripting language of QML, not Javascript[0],
I don't see how Python is inherently more strongly typed than Java
Sze Howe Koh wrote:
> 3) Pick one of the options above, but go one step further and use
> std::optional (C++17) instead of returning null objects. I imagine this
> should apply more broadly to the whole of Qt, not just the functions
> discussed here.
IMHO, std::optional conceptually makes sense on
On Sun, 18 Aug 2019 at 07:37, Mutz, Marc wrote:
>
> On 2019-08-17 07:13, Sze Howe Koh wrote:
> [...]
> > Which should we implement? I personally prefer (2) as it it can be
> > added to Qt 5.x and provides backward compatibility while keeping the
> > nice compact function names. We could enable QT_
On Monday, 19 August 2019 12:34:23 PDT Jason H wrote:
> > > Can Qt set a "no private destructor!" rule?
> >
> > No.
> >
> > Private destructors have a purpose.
>
> Would a workable re-wording be "always provide a public means of
> destruction"?
No, since the purpose is to prevent you from doing
Dear all,
I implemented PDF rendering in Qt application.
My opinion is that Poppler is not the best piece of open source code,
look the code in comparison to MuPDF, it is C but clean C and run on
embedded devices.
Rather Poppler is more like a pile-up of crappy codes. Some years ago,
somebody
Dear all,
I am using PyQt since 10 years now and my points are:
- It is true that missing bindings is a serious issue to use PySide
actually.
- I noticed PyQt has simpler wrapper code, but I don't investigated more.
- I would dream to have Python instead of JS, but we know how to
implement a
> > Can Qt set a "no private destructor!" rule?
>
> No.
>
> Private destructors have a purpose.
Would a workable re-wording be "always provide a public means of destruction"?
To be clear, I am not sure what the actual issue is, why it's private, or why
shiboken can't handle it. In the immediate
In response to
>> To reflect that and help us all understand that the development focus
>> is now towards Qt 6, I would like to propose that dev becomes the Qt
>> 6 branch after we branched away 5.14
Friedemann Kleint (19 August 2019 13:57) asked:
> How long do we keep merging 5.14->dev? At what
On Monday, 19 August 2019 08:55:45 PDT Jason H wrote:
> Can Qt set a "no private destructor!" rule?
No.
Private destructors have a purpose.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
Thanks Cristián! If you thought I was suggesting it was done, I was not. I was
just stating the facts as they appear at the current time feedback is being
given. :-) I am encouraged at PySide continuing development!
I hope that the private destructor issue is avoided for all future classes. I
Hello Jason,
I will comment inline.
On 8/19/19 3:52 PM, Jason H wrote:
> I tried PySide 2, and was extremely disappointed that not all the classes are
> supported. What's worse it PyQt supports the classes that are not supported.
> Having that kind of errata is devastating to the confidence in
I tried PySide 2, and was extremely disappointed that not all the classes are
supported. What's worse it PyQt supports the classes that are not supported.
Having that kind of errata is devastating to the confidence in a project.
Qt6/PySide6 must have parity from day 1.
Next, the biggest flaw is
Hello,
After the general discussion of the vision for Qt6,
we wanted to say a few things regarding Qt for Python.
Even though we are talking about a Python module,
the whole development is C and C++ related, and due to
Python's popularity, we have been getting a lot of attention
on Shiboken, the
Hi,
>To reflect that and help us all understand that the development focus
is now towards Qt 6, I would like to propose that dev becomes the
> Qt 6 branch after we branched away 5.14
How long do we keep merging 5.14->dev? At what point do we go into
cherry-pick mode for 5.14->dev? This shoul
On 19 Aug 2019, at 11:41, coroberti .
mailto:corobe...@gmail.com>> wrote:
Hi,
Could be this issue be given a priority since it's a regression
and strikes deployments of Qt-5.12 LTS on Windows?
https://bugreports.qt.io/browse/QTBUG-44096
Thanks in advance!
Kind regards,
Robert Iakobashvili
He
Hi,
Could be this issue be given a priority since it's a regression
and strikes deployments of Qt-5.12 LTS on Windows?
https://bugreports.qt.io/browse/QTBUG-44096
Thanks in advance!
Kind regards,
Robert Iakobashvili
___
Dev
Il 16/08/19 11:02, Mutz, Marc via Development ha scritto:
It seems that the presence of QWeakPointer::data() in the past has given
many Qt developers the wrong impression and they're now fighting hard to
keep that impression intact when porting away from deprecated data().
Many thanks for deali
Hi,
We have soft branched '5.12.5' from '5.12' today. All new changes targeted to
Qt 5.12.5 release should be done in '5.12.5'. Final downmerge from '5.12' to
'5.12.5' will happen this Friday (23th August) so there should be enough time
to finalize ongoing changes in '5.12'
Target is to releas
Hi,
CI is up and running again.
Br
Heikki
From: Heikki Halmet
Sent: maanantai 19. elokuuta 2019 8.43
To: development@qt-project.org; Qt Development
Subject: CI is in maintenance break
Hi,
CI is in maintenance break and will be down approximately 1 hour. We are
redeploying our hosts.
Ystä
20 matches
Mail list logo
