On Thu, Jun 9, 2022 at 4:20 PM Volker Hilsheimer
wrote:
> > I am not asking for a fake release event myself, just the usual one. If
> someone manages the state restore manually, that would not be broken by the
> usual release happening as far as I can see.
>
> You are asking for a release event
On Thu, Jun 9, 2022 at 4:20 PM Volker Hilsheimer
wrote:
> > I was thinking of drag and drop setting an internal state for the
> QWidget which then the QWidget can use to decide whether to emit clicked()
> or not to address Volker's concern?
>
> Which in the case of QAbstractButton means a change
This case is very complicated. In actual we often expect to get an
app_compile_version with the smallest version number. In the above case, it
should be 6.3, but the existing code cannot do it. If we have a better way then
we can rewrite it, but the current implementation should be removed
This is a good idea, we need a similar approach also in our projects, but
QCoreApplicationPrivate::app_compile_version is not perfect, it is only valid
after constructing QCoreApplication, I think we should change a better way to
get a valid one at any time app_compile_version. I have an idea:
On Thursday, 9 June 2022 12:36:25 PDT Alexander Akulich wrote:
> On Thu, Jun 9, 2022 at 10:14 PM Thiago Macieira
>
> wrote:
> > Doesn't work for libraries.
>
> Can you explain please?
Libraries don't call QCoreApplication's constructor.
The application may have been recompiled and thus will
On Thu, Jun 9, 2022 at 10:14 PM Thiago Macieira
wrote:
>
> Doesn't work for libraries.
>
Can you explain please? I see this correspond to 5.0.0 until
QCoreApplication constructor called but I thought it would be 'better
than a leak'.
QCoreApplicationPrivate::app_compile_version is a part of
On Thursday, 9 June 2022 10:16:19 PDT Alexander Akulich wrote:
> Hi everyone,
>
> On Wed, Jun 8, 2022 at 5:18 PM Fabian Kosmale wrote:
> > What remains to be done:
> > - There are concerns that mixing Qt versions might lead to an unbounded
> > memory leak with the current implementation.
> I
> On 9 Jun 2022, at 19:16, Alexander Akulich wrote:
>
> Hi everyone,
>
> On Wed, Jun 8, 2022 at 5:18 PM Fabian Kosmale wrote:
>>
>> What remains to be done:
>> - There are concerns that mixing Qt versions might lead to an unbounded
>> memory leak with the current implementation.
>
> I
I think that’s ok given that its self contained, and something users really
need on mobile. But as with the other exception, please try to finish it as
soon as possible.
Cheers,
Lars
On 9 Jun 2022, at 15:01, Tor Arne Vestbø
mailto:tor.arne.ves...@qt.io>> wrote:
Hi,
The permission API
Hi everyone,
On Wed, Jun 8, 2022 at 5:18 PM Fabian Kosmale wrote:
>
> What remains to be done:
> - There are concerns that mixing Qt versions might lead to an unbounded
> memory leak with the current implementation.
I can't find any precedent but if we *really* want then probably we
can get
Hi,
On 09/06/2022 17:20, Volker Hilsheimer wrote:
Let’s put things into a perspective here. You are proposing a flag that we
perhaps flip on by default within Qt 6, and that might break a whole ton of
widgets out there that today correctly implement drag’n’drop and that will
start failing in
On Thursday, 9 June 2022 11:36:21 CEST Giuseppe D'Angelo via Development
wrote:
> Il 09/06/22 01:48, Thiago Macieira ha scritto:
> > d) Because if this, code using QStringConverter with non-builtin encodings
> > will leak resources unless it's recompiled for 6.4. No source changes are
> >
>> On 8 Jun 2022, at 19:52, Laszlo Papp wrote:
>>
>>
>>
>> On Tue, Jun 7, 2022 at 8:26 PM Giuseppe D'Angelo
>> wrote:
>> Il 07/06/22 20:57, Laszlo Papp ha scritto:
>> > Just checked the Qt wiki, but it does not seem to speak about this rule.
>> > Only binary and source compatibility. No
Hi,
The permission API (https://bugreports.qt.io/browse/QTBUG-90498 /
https://codereview.qt-project.org/c/qt/qtbase/+/409324) was planned for Qt 6.4,
but unfortunately did not stabilize enough in time for the freeze.
To avoid pushing the API to 6.5, and to get some user feedback on the both
Hi,
qt5.git CI dev branch integrations now use the configure / qt-configure-module
scripts instead of calling cmake / qt-cmake-private to configure qt repos.
This is now inline with our documentation which also says to use configure /
qt-configure-module. Underneath it's of course all CMake.
В Fri, 20 May 2022 10:31:03 +
Morten Sørvig пишет:
> Continuing on the more pragmatic track, I’ve pushed a change to add
> rounding support, along with some additional testing:
> https://codereview.qt-project.org/c/qt/qtbase/+/412296
>
> Morten
Has the work stalled? Would be really nice to
Hi,
On 09/06/2022 11:57, Fabian Kosmale wrote:
QSettings doesn't have a way to change the codec at all as far as I can tell,
and is UTF-8 only, so I'm not sure how
relevant that is for the discussion.
Just replying to this point: it's another API that used to accept an
encoding in Qt 5
Hi,
with the naive approach, old code that used to fail would leak one ICU
converter per constructed QStringConverter.
I've outlined an approach in the patch which would however avoid that issue
(old code would keep failing to
create a converter).
Only adding support in the XML classes would
Il 09/06/22 01:48, Thiago Macieira ha scritto:
d) Because if this, code using QStringConverter with non-builtin encodings
will leak resources unless it's recompiled for 6.4. No source changes are
necessary.
I am saying that (d) is an acceptable situation because of (a) and (b), and in
spite of
19 matches
Mail list logo
