Re: [Interest] Update widget geometry BEFORE window shown

[coroberti]

Have you tried the suggestion from Henry to move the window first to the
negative coordinates?

Kind regards,
Robert Iakobashvili



On Mon, May 27, 2024 at 9:01 AM David M. Cotter  wrote:

> Does ANY ONE have any ideas on this?? Pretty please??
>
> -dave
>
> On May 24, 2024, at 12:14 PM, David M. Cotter  wrote:
>
> I’ve tried everything I can think of. The ONLY one that works the way I
> NEED is the first one, but that one flashes the window on the screen
>
> #if 1
> qWidgetP->show();
> qWidgetP->hide();
> QtLetTimersFire(0);
> #endif
>
> #if 0
> QLayout* layoutP(qWidgetP->layout());
>
> layoutP->update();
> layoutP->activate();
> QtLetTimersFire(0);
> #endif
>
> #if 0
> for (auto* childP: qWidgetP->findChildren()) {
> childP->updateGeometry();
> }
>
> qWidgetP->updateGeometry();
> QtLetTimersFire(0);
> #endif
>
> #if 0
> qWidgetP->setAttribute(Qt::WA_DontShowOnScreen, true);
> qWidgetP->show();
> // qWidgetP->layout()->invalidate();
> // qWidgetP->layout()->update();
> // qWidgetP->layout()->activate();
> qWidgetP->hide();
> qWidgetP->setAttribute(Qt::WA_DontShowOnScreen, false);
> QtLetTimersFire(0);
> #endif
>
> #if 0
> qWidgetP->setAttribute(Qt::WA_DontShowOnScreen, true);
> qWidgetP->show();
>
> qWidgetP->layout()->invalidate();
> qWidgetP->layout()->update();
> qWidgetP->layout()->activate();
>
> for (auto* childP: qWidgetP->findChildren()) {
> childP->updateGeometry();
> }
>
> qWidgetP->updateGeometry();
>
> qWidgetP->hide();
> qWidgetP->setAttribute(Qt::WA_DontShowOnScreen, false);
> QtLetTimersFire(0);
> #endif
>
>
> On May 24, 2024, at 12:47 AM, coroberti  wrote:
>
> David,
> Try
> yourWidget->layout()->update();
> yourWidget->layout()->activate();
>
> If not,
> let the event loop to run, ie. arranging a short timer.
>
> Kind regards,
> Robert Iakobashvili
> 
>
> On Fri, May 24, 2024 at 1:53 AM David M. Cotter  wrote:
>
>
> I need to do something like this:
>
> windowP->layout()->updateGeometry(); // causes all widget geometry to
> update
> DoSomethingImportant(windowP->GetWidget(“someWidget”).geometry()); // do
> something with the geometry of a widget (which must be up to date)
> windowP->setGeometry(windowP->GetInitialGeometry()); // pos/size now based
> on the fact that we KNOW the geometry of one of the widgets BEFORE the
> window is shown
> windowP->show(); // only NOW show the window, NOT before now
>
> How do I do something like the first line? Cause all widget geometry
> (Recursively), to know / figure out its size AND position? And this BEFORE
> the window or any widget is “shown”  via the windowP->show() command?
>
> Please don’t try to tell me to do it differently. If you don’ know how to
> answer it, please don’t chime in, thanks.
>
> -Dave
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Update widget geometry BEFORE window shown

[coroberti]

David,
Try
yourWidget->layout()->update();
yourWidget->layout()->activate();

If not,
let the event loop to run, ie. arranging a short timer.

Kind regards,
Robert Iakobashvili


On Fri, May 24, 2024 at 1:53 AM David M. Cotter  wrote:
>
> I need to do something like this:
>
> windowP->layout()->updateGeometry(); // causes all widget geometry to update
> DoSomethingImportant(windowP->GetWidget(“someWidget”).geometry()); // do 
> something with the geometry of a widget (which must be up to date)
> windowP->setGeometry(windowP->GetInitialGeometry()); // pos/size now based on 
> the fact that we KNOW the geometry of one of the widgets BEFORE the window is 
> shown
> windowP->show(); // only NOW show the window, NOT before now
>
> How do I do something like the first line? Cause all widget geometry 
> (Recursively), to know / figure out its size AND position? And this BEFORE 
> the window or any widget is “shown”  via the windowP->show() command?
>
> Please don’t try to tell me to do it differently. If you don’ know how to 
> answer it, please don’t chime in, thanks.
>
> -Dave
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Void pointers for Mac ARM

[coroberti]

Sorry, no knowledge about the pragma and how it's handled by clang.

I'd make it all 8-bytes aligned on 64-bit.

Kind regards,
Robert Iakobashvili


On Mon, Jun 19, 2023 at 2:14 PM Turtle Creek Software
 wrote:
>
> Alignment is definitely possible.  There was a similar problem earlier in 
> execution, and that had pointers to 2-byte aligned structs.
> We just rewrote the ugly void* code rather than try to diagnose it further.  
> The debugger showed the correct address but failed to cast a parameter.
>
> Can the ARM compiler handle #pragma pack (2) ?
>
> Thanks,
> Casey McDermott
> TurtleSoft.com
>
> On Mon, Jun 19, 2023 at 2:50 AM coroberti  wrote:
>>
>> On Sat, Jun 17, 2023 at 8:12 PM Turtle Creek Software
>>  wrote:
>> >
>> > Our app contains some old C-ish C++ code from an early 90's database 
>> > called NeoAccess. It often uses function pointers with void pointers as 
>> > parameters.  Their code works OK for Mac & Windows, when built with the 
>> > latest Qt5 on Intel.
>> >
>> > The code also builds OK with the latest Qt6, but running it on an M1 Mac 
>> > gives run-time errors. Void pointers to structs and objects don't cast 
>> > properly and stay null.  We haven't tried Qt6 on Windows yet but will do 
>> > that soon.
>> >
>> > Any ideas on how to fix it?  We've abandoned NeoAccess for our new app but 
>> > still need it to convert data from existing files.  Rewriting their code 
>> > is a nightmare.
>>
>> Casey,
>> Perhaps, checking the alignment of the void* pointers in question
>> could provide you with some clues.
>>
>> Kind regards,
>> Robert Iakobashvili
>> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Void pointers for Mac ARM

[coroberti]

On Sat, Jun 17, 2023 at 8:12 PM Turtle Creek Software
 wrote:
>
> Our app contains some old C-ish C++ code from an early 90's database called 
> NeoAccess. It often uses function pointers with void pointers as parameters.  
> Their code works OK for Mac & Windows, when built with the latest Qt5 on 
> Intel.
>
> The code also builds OK with the latest Qt6, but running it on an M1 Mac 
> gives run-time errors. Void pointers to structs and objects don't cast 
> properly and stay null.  We haven't tried Qt6 on Windows yet but will do that 
> soon.
>
> Any ideas on how to fix it?  We've abandoned NeoAccess for our new app but 
> still need it to convert data from existing files.  Rewriting their code is a 
> nightmare.

Casey,
Perhaps, checking the alignment of the void* pointers in question
could provide you with some clues.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] MSVC not-the-latest: are you using it? why?

[coroberti]

Hi Thiago,
On some update of MSVC-2017 to their next minor release, we got their
optimization bug.
It was a waste of time to understand what happened and to work-around it.

jm2c

Kind regards,
Robert

On Sun, Jan 22, 2023 at 6:19 PM Thiago Macieira
 wrote:
>
> In this case, MSVC 2019, which is still supported.
>
> I'm trying to understand why people don't upgrade their Visual Studios. In the
> past, they used to use different and binary-incompatible VC runtimes, so large
> projects often needed to stick to a single version because of different teams
> needing to otherwise have a flag day.
>
> But that hasn't been the case since MSVC 2015. So, are you still sticking to
> older MSVC releases years after there's a new one? Why?
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Cloud Software Architect - Intel DCAI Cloud Engineering
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What is the right way of creating a static lib that has qml resources with cmake?

[coroberti]

On Mon, Jan 16, 2023 at 10:07 AM Nuno Santos  wrote:
>
> Good morning Ulf,
>
> Ok, so this this the news Qt 6 / CMake approach to things and we can’t avoid 
> it right?
>
> However, as it is, its buggy. I will upload my last week example to 
> https://bugreports.qt.io/browse/QTBUG-110110
>
> Because I’ve been struggling with this for days without having success. I’ve 
> also shared this example with another top level Qt developer who couldn’t 
> figure it out as well. I’ve only tested on Mac so far. At the time being this 
> is a full blocker.
>
> Thanks for your help and insights.
>
> Have an excellent week!
>
> Best regards,
>
> Nuno

Dear Nuno,
On Mac, unlike on Windows, there's a concept of an app bundle.
The Qt shared libraries are copied by macdeployqt to the app bundle as
shared libraries called frameworks.

Thus, shared libraries are coming together with the exe and are easily
accessible.

Perhaps, at least on Mac you do not need static linking and can rather
safely use the dynamic linking
to the libs within the bundle?

Thanks.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Crash on Mac

[coroberti]

Thanks.

It appears, perhaps, be related to simulated keyboard events
sent by: CGCreateKeyboardEvent

Digging into it ...

Kind regards,
Robert Iakobashvili


On Mon, Jan 2, 2023 at 1:21 PM Tor Arne Vestbø  wrote:
>
> There is no way to disable this code path I’m afraid.
>
> Cheers,
> Tor Arne
>
> > On 2 Jan 2023, at 11:57, coroberti  wrote:
> >
> > Dear Tor Arne,
> > Thanks for replying.
> >
> > This is not something that is easily reproducible, sorry.
> > The scenario is also not clear.
> >
> > Therefore, the question was about its origin.
> >
> > What could be the correct way to disable handling of the System
> > Shortcuts or filter them
> > not to propagate them to handling.
> >
> >
> > Kind regards,
> > Robert
> >
> > On Mon, Jan 2, 2023 at 12:44 PM Tor Arne Vestbø  
> > wrote:
> >>
> >> Please file a bug report with a test case and detailed version info, 
> >> thanks!
> >>
> >> Cheers,
> >> Tor Arne
> >>
> >>> On 2 Jan 2023, at 06:59, coroberti  wrote:
> >>>
> >>> Hi,
> >>> There is a rare crash that happens on Mac platforms.
> >>>
> >>> If somebody could advise on what happens and
> >>> whether it could be helpful to filter out the shortcut events.
> >>> What is the way to get rid of it?
> >>>
> >>> Thanks in advance!
> >>> Robert
> >>>
> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> >>> 0   libqcocoa.dylib   0x000107eebe85 0x107ea5000 + 
> >>> 290437
> >>> 1   libqcocoa.dylib   0x000107eaf932 0x107ea5000 + 
> >>> 43314
> >>> 2   org.qt-project.QtGui  0x0001054cb767 0x105474000 + 
> >>> 358247
> >>> 3   org.qt-project.QtGui  0x0001054cb475
> >>> QKeyMapper::possibleKeys(QKeyEvent*) + 53
> >>> 4   org.qt-project.QtGui  0x0001054d6008
> >>> QShortcutMap::createNewSequences(QKeyEvent*, QVector&,
> >>> int) + 40
> >>> 5   org.qt-project.QtGui  0x0001054d5760
> >>> QShortcutMap::find(QKeyEvent*, int) + 64
> >>> 6   org.qt-project.QtGui  0x0001054d54d8
> >>> QShortcutMap::nextState(QKeyEvent*) + 88
> >>> 7   org.qt-project.QtGui  0x0001054d53f4
> >>> QShortcutMap::tryShortcut(QKeyEvent*) + 52
> >>> 8   org.qt-project.QtGui  0x000105485f01
> >>> QWindowSystemInterface::handleShortcutEvent(QWindow*, unsigned long,
> >>> int, QFlags, unsigned int, unsigned int,
> >>> unsigned int, QString const&, bool, unsigned short) + 401
> >>> 9   libqcocoa.dylib   0x000107ec6965 0x107ea5000 + 
> >>> 137573
> >>> 10  libqcocoa.dylib   0x000107ec6a88 0x107ea5000 + 
> >>> 137864
> >>> 11  com.apple.AppKit  0x7fff33f29ffd
> >>> -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6512
> >>> 12  com.apple.AppKit  0x7fff33f28469
> >>> -[NSWindow(NSEventRouting) sendEvent:] + 349
> >>> 13  libqcocoa.dylib   0x000107eb4597 0x107ea5000 + 
> >>> 62871
> >>> 14  libqcocoa.dylib   0x000107eb3e34 0x107ea5000 + 
> >>> 60980
> >>> 15  com.apple.AppKit  0x7fff33f2719e
> >>> -[NSApplication(NSEvent) sendEvent:] + 2826
> >>> 16  libqcocoa.dylib   0x000107ed003a 0x107ea5000 + 
> >>> 176186
> >>> 17  com.apple.AppKit  0x7fff33d7394f
> >>> -[NSApplication run] + 707
> >>> 18  libqcocoa.dylib   0x000107ecc57d 0x107ea5000 + 
> >>> 161149
> >>> 19  org.qt-project.QtCore 0x000105b749ee
> >>> QEventLoop::exec(QFlags) + 398
> >>> 20  org.qt-project.QtCore 0x000105b793a1
> >>> QCoreApplication::exec() + 369
> >>> 21  com.Ghotit.RealWriter-10  0x0001017d6e7f main + 2959
> >>> 22  libdyld.dylib 0x7fff707becc9 start + 1
> >>> ___
> >>> Interest mailing list
> >>> Interest@qt-project.org
> >>> https://lists.qt-project.org/listinfo/interest
> >>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Crash on Mac

[coroberti]

Dear Tor Arne,
Thanks for replying.

This is not something that is easily reproducible, sorry.
The scenario is also not clear.

Therefore, the question was about its origin.

What could be the correct way to disable handling of the System
Shortcuts or filter them
not to propagate them to handling.


Kind regards,
Robert

On Mon, Jan 2, 2023 at 12:44 PM Tor Arne Vestbø  wrote:
>
> Please file a bug report with a test case and detailed version info, thanks!
>
> Cheers,
> Tor Arne
>
> > On 2 Jan 2023, at 06:59, coroberti  wrote:
> >
> > Hi,
> > There is a rare crash that happens on Mac platforms.
> >
> > If somebody could advise on what happens and
> > whether it could be helpful to filter out the shortcut events.
> > What is the way to get rid of it?
> >
> > Thanks in advance!
> > Robert
> >
> > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> > 0   libqcocoa.dylib   0x000107eebe85 0x107ea5000 + 
> > 290437
> > 1   libqcocoa.dylib   0x000107eaf932 0x107ea5000 + 43314
> > 2   org.qt-project.QtGui  0x0001054cb767 0x105474000 + 
> > 358247
> > 3   org.qt-project.QtGui  0x0001054cb475
> > QKeyMapper::possibleKeys(QKeyEvent*) + 53
> > 4   org.qt-project.QtGui  0x0001054d6008
> > QShortcutMap::createNewSequences(QKeyEvent*, QVector&,
> > int) + 40
> > 5   org.qt-project.QtGui  0x0001054d5760
> > QShortcutMap::find(QKeyEvent*, int) + 64
> > 6   org.qt-project.QtGui  0x0001054d54d8
> > QShortcutMap::nextState(QKeyEvent*) + 88
> > 7   org.qt-project.QtGui  0x0001054d53f4
> > QShortcutMap::tryShortcut(QKeyEvent*) + 52
> > 8   org.qt-project.QtGui  0x000105485f01
> > QWindowSystemInterface::handleShortcutEvent(QWindow*, unsigned long,
> > int, QFlags, unsigned int, unsigned int,
> > unsigned int, QString const&, bool, unsigned short) + 401
> > 9   libqcocoa.dylib   0x000107ec6965 0x107ea5000 + 
> > 137573
> > 10  libqcocoa.dylib   0x000107ec6a88 0x107ea5000 + 
> > 137864
> > 11  com.apple.AppKit  0x7fff33f29ffd
> > -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6512
> > 12  com.apple.AppKit  0x7fff33f28469
> > -[NSWindow(NSEventRouting) sendEvent:] + 349
> > 13  libqcocoa.dylib   0x000107eb4597 0x107ea5000 + 62871
> > 14  libqcocoa.dylib   0x000107eb3e34 0x107ea5000 + 60980
> > 15  com.apple.AppKit  0x7fff33f2719e
> > -[NSApplication(NSEvent) sendEvent:] + 2826
> > 16  libqcocoa.dylib   0x000107ed003a 0x107ea5000 + 
> > 176186
> > 17  com.apple.AppKit  0x7fff33d7394f
> > -[NSApplication run] + 707
> > 18  libqcocoa.dylib   0x000107ecc57d 0x107ea5000 + 
> > 161149
> > 19  org.qt-project.QtCore 0x000105b749ee
> > QEventLoop::exec(QFlags) + 398
> > 20  org.qt-project.QtCore 0x000105b793a1
> > QCoreApplication::exec() + 369
> > 21  com.Ghotit.RealWriter-10  0x0001017d6e7f main + 2959
> > 22  libdyld.dylib 0x7fff707becc9 start + 1
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt Crash on Mac

[coroberti]

Hi,
There is a rare crash that happens on Mac platforms.

If somebody could advise on what happens and
whether it could be helpful to filter out the shortcut events.
What is the way to get rid of it?

Thanks in advance!
Robert

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libqcocoa.dylib   0x000107eebe85 0x107ea5000 + 290437
1   libqcocoa.dylib   0x000107eaf932 0x107ea5000 + 43314
2   org.qt-project.QtGui  0x0001054cb767 0x105474000 + 358247
3   org.qt-project.QtGui  0x0001054cb475
QKeyMapper::possibleKeys(QKeyEvent*) + 53
4   org.qt-project.QtGui  0x0001054d6008
QShortcutMap::createNewSequences(QKeyEvent*, QVector&,
int) + 40
5   org.qt-project.QtGui  0x0001054d5760
QShortcutMap::find(QKeyEvent*, int) + 64
6   org.qt-project.QtGui  0x0001054d54d8
QShortcutMap::nextState(QKeyEvent*) + 88
7   org.qt-project.QtGui  0x0001054d53f4
QShortcutMap::tryShortcut(QKeyEvent*) + 52
8   org.qt-project.QtGui  0x000105485f01
QWindowSystemInterface::handleShortcutEvent(QWindow*, unsigned long,
int, QFlags, unsigned int, unsigned int,
unsigned int, QString const&, bool, unsigned short) + 401
9   libqcocoa.dylib   0x000107ec6965 0x107ea5000 + 137573
10  libqcocoa.dylib   0x000107ec6a88 0x107ea5000 + 137864
11  com.apple.AppKit  0x7fff33f29ffd
-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6512
12  com.apple.AppKit  0x7fff33f28469
-[NSWindow(NSEventRouting) sendEvent:] + 349
13  libqcocoa.dylib   0x000107eb4597 0x107ea5000 + 62871
14  libqcocoa.dylib   0x000107eb3e34 0x107ea5000 + 60980
15  com.apple.AppKit  0x7fff33f2719e
-[NSApplication(NSEvent) sendEvent:] + 2826
16  libqcocoa.dylib   0x000107ed003a 0x107ea5000 + 176186
17  com.apple.AppKit  0x7fff33d7394f
-[NSApplication run] + 707
18  libqcocoa.dylib   0x000107ecc57d 0x107ea5000 + 161149
19  org.qt-project.QtCore 0x000105b749ee
QEventLoop::exec(QFlags) + 398
20  org.qt-project.QtCore 0x000105b793a1
QCoreApplication::exec() + 369
21  com.Ghotit.RealWriter-10  0x0001017d6e7f main + 2959
22  libdyld.dylib 0x7fff707becc9 start + 1
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Thread-To-CPU-Core distribution

[coroberti]

On Thu, Dec 29, 2022 at 1:45 AM Alexander Carôt  wrote:
>
> Hej Konrad,
>
> >>I can't hold back my curiosity, so I've got to ask: why? Why would you
> >>do that? Why do you assume you know better than the operating system?
>
> I totally understand the question and agree to anything else you state in 
> your email below, however, I am dealing with a non-standard use case with 
> comparably tough delay restrictions. I do it for R reasons related to 
> remote music performances and the project where this works has been going 
> into:
>
> https://www.soundjack.eu/
> https://www.soundjack.eu/publications/
>
> In this domain we are constantly seeking opportunities to improve audio/video 
> low(est)-latency on x-platform standard hardware.
>
> Especially on cheaper hardware such as the Raspi thread distribution was a 
> benefit in that regard especially when processing audio with 32 samples/block 
> and probably less but I need to compare and evaluate it more intensively now.

Additionally, to decrease the jitter and get more attention to your threads,
you may try running as a root and switch to SCHED_FIFO priority and
assign high priority there.

https://github.com/ianohara/linux-rt-examples/blob/master/src/schedulerTest.c

Kind regards,
Robert Iakobashvili
 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[coroberti]

On Mon, Dec 19, 2022 at 10:09 AM Tuukka Turunen  wrote:
> This mailing list thread is actually already part of the discussion. I am 
> sure the relevant stakeholders will read through the mails. One important 
> thing: the question is whether or not the _latest_ Qt version supports 3 or 4 
> generations of macOS – because we already support the older macOS version 
> with the earlier Qt releases. We are avoiding to the extent possible dropping 
> supported platforms from released versions of Qt, so macOS 10.15 continues to 
> be supported with Qt releases up to Qt 6.4 in any case. This also leads into 
> Qt supporting such macOS versions that Apple no longer supports – like the 
> discussed macOS 10.15 that is supported in Qt 6.4, but no longer supported by 
> Apple.
>
> Yours,
> Tuukka

Thank you, Tukka, for clarifying the points for the decision makers.

Hope to hear from them soon.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[coroberti]

On Sun, Dec 18, 2022 at 3:09 PM Thiago Macieira
 wrote:
>
> That's bad. But we all know who's to blame here, in both arguments: Apple.
>
> > Try to listen to the people that work with the real, live customers
> > like Nuno and me.
>
> We have. The decision is that we need to make a cut and move on, eventually.
> There's only so much resource available for handling different generations. We
> decided to adopt Apple's own end-of-life as ours.
>
> > Please, add one more old Mac OS release to the supported list to be
> > more realistic, so it will be not a thin three releases but at least four.
>
> At this point, since my AVX2 changes have been postponed to 6.6, I don't mind
> restoring 10.15 support in 6.5, as it doesn't impact me and the improvements I
> plan to add. So I won't object.
>
> But I can't speak for Qt Company's resource commitment, with the need to *add*
> 13.x to their test base. I think we all agree that MUST be tested. Given a
> finite resource allocation, something will need to give and they will have to
> make that choice.
>
> Moreover, 6.5 is one of their LTS. They have to make a choice whether they
> want to keep 10.15 in support for the lifetime of that LTS. That would mean
> they'd *end* support 2.5 years after Apple last provided a security update for
> the OS. Their own networking requirements may imply they *can't* have that OS
> in the CI because of its lack of security fixes. I don't know what it takes 
> for
> them to allow that; I can only tell you that if Intel were hosting such
> systems, those would need to be in a special lab with no direct Internet
> access, which means they couldn't be part of a CI.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Cloud Software Architect - Intel DCAI Cloud Engineering
>

Thank you, Thiago, for your understanding and the assistance proposed.

Thus, we need it to be approved by the Qt Company.

Tukka, can we get the people of the Qt Company sitting and at least discussing:

1. The general issue related to the level of Qt support for Mac platforms
considering four (4) versions to support instead of the current three (3).

2. The concrete case of Mac Support for Qt 6.5.

Even if you come back and say - sorry, we considered, but decided to
turn it down,
still the effort will be very much appreciated.

Thanks in advance for considering the options.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[coroberti]

On Sun, Dec 18, 2022 at 3:29 AM Thiago Macieira
 wrote:
>
> On Saturday, 17 December 2022 05:40:48 -03 Tuukka Turunen via Interest wrote:
> > at least between versions 10.15 and 11 there does not seem to be a
> > major drop in what HW is supported.
>
> There is a drop, but we're talking about  CPUs launched in 2013 and older.
> Specifically, 11.0 drops support for Sandy Bridge and Ivy Bridge Macbooks and
> Mac Minis. Whether you count that as "major" or not, I'll leave it up to you.
>
> What matters to me is that those were the last AVX-incapable CPUs, which allow
> us to assume that AVX2 is present.

Dear Thiago and Tuukka,
It seems that you are working under an assumption that if the HW allows it,
users will upgrade their Mac OS.

This is not how it works in reality, sorry.

Many, if not most, Mac users are upgrading only once.
They upgrade, see how their content-editing, multimedia, etc. software
is ruined by their first upgrade;
next, they work with software vendors to restore their applications
back to some working state, get the lesson and ... do not touch it forever.

Try to listen to the people that work with the real, live customers
like Nuno and me.

Please, add one more old Mac OS release to the supported list to be
more realistic, so it will be not a thin three releases but at least four.

Please, consider that.
Thanks in advance!

P.S. Oh, these customers are not security aware? Agree, this is bad.

Sorry, but please get it that these people, not computer fricks and sometimes
technically challenged, need to run smoothly with their daily jobs
rather than work hard on
bringing their apps to the working stage after each upgrade.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[coroberti]

Thanks, Eike.

Kind regards,
Robert Iakobashvili


On Fri, Dec 16, 2022 at 2:43 PM Eike Ziller  wrote:
>
> "Apple are incorrectly reporting Big Sur 11 as Catalin 10.15. You can read 
> more about it here.
> We can't correctly show usage for Big Sur 11 or Catalina 10.15 until Apple 
> fixes this."
>
> Looks like WebKit doesn't report anything larger than 10.15.
> https://bugs.webkit.org/show_bug.cgi?id=216593
>
> and for Mozilla something similar:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1679929
>
> And indeed my latest Firefox reports
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0)
> Running on macOS 12.
>
> So, while these statistics says something about the usage of "10.15 or later",
> it cannot really be used to say anything about 10.15 versus later versions.
>
> Br, Eike
>
> > Am 16/12/2022 um 13:20 schrieb coroberti :
> >
> > Hi,
> > Since Qt 6.5 drops Mac OS 10.15 Catalina,
> > it apparently starts to be irrelevant for at least 95% of Mac Desktops.
> >
> > https://gs.statcounter.com/macos-version-market-share/desktop/worldwide
> >
> > Google Analytics data of visitors for some web-site, where I have access,
> > also supports the above observations.
> >
> > To keep Qt-6 being still relevant for Mac Desktop open-source
> > development, please
> > consider keeping  Mac OS 10.15 as a target.
> > Thanks.
> >
> > Kind regards,
> > Robert Iakobashvili
> > 
> > ___
> > Development mailing list
> > developm...@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
> HRB 144331 B
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[coroberti]

Hi,
Since Qt 6.5 drops Mac OS 10.15 Catalina,
it apparently starts to be irrelevant for at least 95% of Mac Desktops.

https://gs.statcounter.com/macos-version-market-share/desktop/worldwide

Google Analytics data of visitors for some web-site, where I have access,
also supports the above observations.

To keep Qt-6 being still relevant for Mac Desktop open-source
development, please
consider keeping  Mac OS 10.15 as a target.
Thanks.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Individual developer license is too expensive

[coroberti]

Dear Ben,
If you enter the path of a paid license, it appears
that there is no path back to open-source licensing due to the
structure of Qt-paid that forbids it for the same project.

Therefore, don't be in a rush to pay, and
check if you are really getting something for paid.

Kind regards,
Robert Iakobashvili


On Wed, Feb 23, 2022 at 11:34 AM Ben Cottrell  wrote:
>
>
> On 23/02/22 8:22 pm, Maurice Kalinowski wrote:
> > Hey,
> >
> > just checking whether you are aware of the Qt for Small Business license, 
> > where you seem to be eligible for?
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.qt.io%2Fpricing%2Fqt-for-small-businessdata=04%7C01%7C%7C12554cb0645c479f73de08d9f69d5116%7C84df9e7fe9f640afb435%7C1%7C0%7C637811977803264422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qmHanZ6K0cOWRrF0OMYsVqQv7R9C07mQjUvkxPziKT0%3Dreserved=0
> >
> > BR,
> > Maurice
> >
> I still can't afford the yearly cost of 739 NZD, but maybe this will
> change in the future
> when I'm more successful.
>
> Thanks,
> Ben
>
> >> -Original Message-
> >> From: Interest  On Behalf Of Ben Cottrell
> >> Sent: Tuesday, 22 February 2022 22:45
> >> To: interest@qt-project.org
> >> Subject: [Interest] Individual developer license is too expensive
> >>
> >> Hi,
> >>
> >> I would like to use Qt libraries that are statically linked into my 
> >> binaries, but
> >> the monthly license cost is too expensive, as I'm unemployed at the
> >> moment.
> >>
> >> Is the license price negotiable for individual developers?
> >>
> >> Thanks,
> >> Ben Cottrell
> >>
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Finterestdata=04%7C01%7C%7C12554cb0645c479f73de08d9f69d5116%7C84df9e7fe9f640afb435%7C1%7C0%7C637811977803264422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2B9aDjMkb%2FsLvFpNxU3AD%2FcwhZMfaXMb97xIvLzxm9ac%3Dreserved=0
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[coroberti]

Hi Mark,
The initial dev is slower when using Widgets,
but with less bugs and more robustness, it could be worth doing it,
and at the end of the day, it is even time-saving.

The Qt apps on the desktop platforms you mentioned look very native with
Widgets.

There are many tips and ready solutions for Widgets you can find on the web
to cut the time for the initial development.

Kind regards,
Robert Iakobashvili



On Mon, Feb 21, 2022 at 5:44 PM Mark Gaiser  wrote:

> Hi,
>
> I'm facing so many bugs in QML Controls in Qt6 (they used to be Controls
> V2 in the Qt 5.x days) that I don't want to use them at all anymore. They
> are bugged beyond repair and downright unusable for native desktop
> integration purposes.
>
> Is there another good open source component set out there that integrates
> with the desktop. Specifically with Windows but preferably also with Linux
> (kde and gnome) and Mac.
>
> Using QWidgets should not be an alternative as it slows down development a
> lot. But given the crap that QML Controls is makes me consider switching to
> QWidgets instead.
>
>
> Best regards,
> Mark
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] SQLite database: avoid high memory usage?

[coroberti]

On Mon, Jan 24, 2022 at 11:40 AM Hamish Moffatt via Interest
 wrote:
>
> On 24/1/22 19:40, Alexander Dyagilev wrote:
> > Hello,
> >
> > Let's suppose we have a database file of 16GB in size.
> >
> > We open it using this code:
> >
> > m_db = QSqlDatabase::addDatabase(
> >  "QSQLITE",
> >  dbConnectionName());
> > m_db.setConnectOptions("PRAGMA jounal_mode=WAL;");
> > m_db.setDatabaseName(m_dbPath);
> > m_db.open();
> >
> > After this, our process will use 16GB of memory (at least, under
> > Windows OS). I.e. the whole database file is loaded into the memory.
> >
> > Is there a way to avoid this?
>
>
> Did you mean to misspell journal_mode?
>
> Are you sure it's real memory usage and not just address space used by mmap?
>
>
> Hamish
>

Indeed. Doubts if on Windows it will be all really mapped:
https://docs.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases

Besides that, to keep large areas mapped in RAM,
one may need to lock the pages in memory with their own limits.

Consider inspecting the sources of the SQL-db concerned.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] OSX security – allow dialogue

[coroberti]

Nuno,
You can save on EV and order instead 2-3 years regular code-signing
certificate for Windows.

Non-EV code-signing certificate has a cost of 120-140 USD/year and
for a week or two users get warnings till the certificates earns reputation.

Add to your setup instructions:
Note: Windows-10 Users with SmartScreen protection enabled MAY get a
message "Windows Protects Your PC". Click the link "More Info" below and
further click "Run anyway" to run the < SW_NAME > installation.

You may also opt 2-3 weeks in advance
to whitelist the software/certificate with Microsoft via:
https://www.microsoft.com/en-us/wdsi/filesubmission


As a result, you save 300 USD - 120-140 USD = 160-180 USD / per year.

Kind regards,
Robert Iakobashvili


On Sun, Oct 10, 2021 at 3:20 PM Nuno Santos  wrote:
>
> Alex,
>
> You need to code sign with entitlements to get rid of this problems on Mac OS 
> >= 10.14.6
>
> From my point of view is already a good reason to pay 99 EUR a year.
>
> I consider it quite cheap compared with a EV code signing certificate for 
> Windows which is usually >= 250 EUR a year.
>
> Regards,
>
> Nuno
>
> On 10 Oct 2021, at 12:53, Alexander Carôt  wrote:
>
> When the cam is not authorized by the user it will crash upon initialization 
> because it has no entry in the security settings.
>
> Running the app via terminal works out because the terminal always has these 
> permissions.
>
> With audio it’s more tricky: When the mic is not authorized by the user the 
> sound input will still launch (and not crash) but it will not capture any 
> audio data.
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[coroberti]

On Wed, Sep 29, 2021 at 8:49 PM Thiago Macieira
 wrote:
>
> On Wednesday, 29 September 2021 10:22:41 PDT coroberti wrote:
> > Thiago, you know well about the Extended Support Programs, are not you?
> > So, why to skip it?
>
> No, I didn't. I searched for "windows 7 eol" and found two pages at
> microsoft.com mentioning the date I pasted, with no information about extended
> support.
>
> Anyway, the point is that we felt 6.0 was a good time to cut the ties to old
> platforms. You can keep the legacy platforms with the legacy Qt.
>

Thiago, it's a valid argument.

However, we still with 15-20% Windows deployment on Win-7, and it's
still supported.
My knowledge is that some governments are pressing Microsoft to
prolong it even more.

Let's say Win-7 with MSVC-2019 without UWP seen as compatible at the page:
https://docs.microsoft.com/en-us/visualstudio/releases/2019/compatibility

How do you access the scale of the efforts for doing it?
Is it mainly style or there are more areas?

Thanks.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[coroberti]

On Wed, Sep 29, 2021 at 7:53 PM Thiago Macieira
 wrote:
>
> On Wednesday, 29 September 2021 07:40:11 PDT Rui Oliveira wrote:
> > "Both *Windows 7 or 8.x* version support will not be available for Qt 6"
>
> https://support.microsoft.com/en-us/windows/windows-7-support-ended-on-january-14-2020-b75d4580-2cc7-895a-2c9c-1466d9a53962
>
> "Support for Windows 7 ended on January 14, 2020."
>
> https://docs.microsoft.com/en-us/lifecycle/faq/windows#windows-8.1
> "Windows 8.1 reached the end of Mainstream Support on January 9, 2018, and
> will reach end of Extended Support on January 10, 2023."

Thiago, you know well about the Extended Support Programs, are not you?
So, why to skip it?

For example, Windows-7 till January 10, 2023
https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-7-eos-faq/windows-7-extended-security-updates-faq

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For

[coroberti]

Thanks, Tuukka,
for the information.

Kind regards,
Robert Iakobashvili


On Fri, May 7, 2021 at 1:18 PM Tuukka Turunen  wrote:
>
> Hi,
>
>
>
> Supporting Apple silicon is something we are actively working to have in 
> place for Qt 6.2 including full CI coverage etc.
>
>
>
> To some extent things will work also with Qt 5.15 if you build yourself, but 
> there are some rough edges (and Qt 5.15 is not tested for M1).
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> From: Interest  on behalf of Nuno Santos 
> 
> Date: Friday, 7. May 2021 at 13.10
> To: Tor Arne Vestbø 
> Cc: Qt development mailing list , Qt Interest 
> 
> Subject: Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For
>
> Tor,
>
>
>
> What about building Qt 5.15.X for M1 Macs?
>
>
>
> Is there any kind of wiki resource out there?
>
>
>
> Regards,
>
>
>
> Nuno
>
>
>
> On 7 May 2021, at 10:47, Tor Arne Vestbø  wrote:
>
>
>
> Qt 6.0 and above has official support for Big Sur:
>
>
>
> https://doc.qt.io/archives/qt-6.0/macos.html
>
>
>
> 5.15 is not yet officially supported, but should work fine as well, so please 
> report any issues in JIRA, thanks!
>
>
>
> Cheers,
> Tor Arne
>
>
>
> On 7 May 2021, at 11:00, coroberti  wrote:
>
>
>
> Dear Tukka and others,
> Since September Big Sur is a reality.
>
> Which Qt-version supports correctly QWidgets for this platform for
> open-source development.
>
> If there's no such version, when the support is planned if ever.
>
> I'd appreciate not to hijack this question for any discussions beyond the
> very narrow scope of this question.
>
> Thanks,
>
> Kind regards,
> Robert
> ___
> Development mailing list
> developm...@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For

[coroberti]

Dear Tor Arne,
Thank you for your reply.
It's less useful since Qt-6 is a phantom, beta, and it will remain so
for a year or more.

Kind regards,
Robert Iakobashvili


On Fri, May 7, 2021 at 12:47 PM Tor Arne Vestbø  wrote:
>
> Qt 6.0 and above has official support for Big Sur:
>
> https://doc.qt.io/archives/qt-6.0/macos.html
>
> 5.15 is not yet officially supported, but should work fine as well, so please 
> report any issues in JIRA, thanks!
>
> Cheers,
> Tor Arne
>
> On 7 May 2021, at 11:00, coroberti  wrote:
>
> Dear Tukka and others,
> Since September Big Sur is a reality.
>
> Which Qt-version supports correctly QWidgets for this platform for
> open-source development.
>
> If there's no such version, when the support is planned if ever.
>
> I'd appreciate not to hijack this question for any discussions beyond the
> very narrow scope of this question.
>
> Thanks,
>
> Kind regards,
> Robert
> ___
> Development mailing list
> developm...@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For

[coroberti]

Dear Eike,
Thanks for your comprehensive answer.

I will try to build it from open-source 5.15 branch

Where is the link to the branch?
Thanks!

Kind regards,
Robert Iakobashvili


On Fri, May 7, 2021 at 1:12 PM Eike Ziller  wrote:
>
>
>
> > On May 7, 2021, at 11:47, Tor Arne Vestbø  wrote:
> >
> > Qt 6.0 and above has official support for Big Sur:
> >
> > https://doc.qt.io/archives/qt-6.0/macos.html
> >
> > 5.15 is not yet officially supported, but should work fine as well, so 
> > please report any issues in JIRA, thanks!
> >
>
> Except for
> [QTBUG-88495] Text rendering: spaces are rendered incorrectly on macOS Big 
> Sur after commas, dots. - Qt Bug Tracker
> https://bugreports.qt.io/browse/QTBUG-88495
> and
> [QTBUG-88985] Context QMenu without parent blocked by modal dialog on macOS - 
> Qt Bug Tracker
> https://bugreports.qt.io/browse/QTBUG-88985
>
> for which the fixes are available in the opensource 5.15 branch, but not in 
> the 5.15.2 release.
>
> Qt Creator binaries are released based on Qt 5.15.2, so you can check that 
> for reference.
>
> Br, Eike
>
> > Cheers,
> > Tor Arne
> >
> >> On 7 May 2021, at 11:00, coroberti  wrote:
> >>
> >> Dear Tukka and others,
> >> Since September Big Sur is a reality.
> >>
> >> Which Qt-version supports correctly QWidgets for this platform for
> >> open-source development.
> >>
> >> If there's no such version, when the support is planned if ever.
> >>
> >> I'd appreciate not to hijack this question for any discussions beyond the
> >> very narrow scope of this question.
> >>
> >> Thanks,
> >>
> >> Kind regards,
> >> Robert
> >> ___
> >> Development mailing list
> >> developm...@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> >
> > ___
> > Development mailing list
> > developm...@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
> HRB 144331 B
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Mac Big Sur - Qt Open-Source Support For

[coroberti]

Dear Tukka and others,
Since September Big Sur is a reality.

Which Qt-version supports correctly QWidgets for this platform for
open-source development.

If there's no such version, when the support is planned if ever.

I'd appreciate not to hijack this question for any discussions beyond the
very narrow scope of this question.

Thanks,

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[coroberti]

On Thu, Apr 29, 2021 at 1:05 PM Bernhard Lindner
 wrote:

> What I don't understand is why Roland doesn't just leave the mailing list and 
> forget about
> Qt.

IMHO, it's a business model.

Distribute the links to your books and your web-site,
and hopefully, sell the books and/or find new customers.

BRGS,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[coroberti]

Dear Guiseppe,
You were very helpful for the list members and personally to me.
The list will deteriorate without you.

Sincerely hope that the moderator will start to function and to do something.

Note, that for Roland it's a pure business - spread links and sell
books, support, perhaps projects etc.
This is what is expected to be stopped by moderation.

Hope, you will reconsider dropping the list. Thanks.

Kind regards,
Robert Iakobashvili


On Thu, Apr 29, 2021 at 11:43 AM Filip Piechocki  wrote:
>
> I totally agree with you, Guiseppe.
>
> I am subscribed to this list for a long time as it happened several times in 
> the past that the issues I was facing with Qt were already solved here.
> But the list became more of a Roland's trolling sandbox, where he is throwing 
> sand in others' eyes and having great fun of that, with less and less useful 
> content in this list over time. I think that more and more people get tired 
> of those endless rants and just go somewhere else.
>
> So do I.
>
> F
>
> On Thu, Apr 29, 2021 at 10:27 AM Giuseppe D'Angelo via Interest 
>  wrote:
>>
>> On 29/04/2021 00:42, Giuseppe D'Angelo via Interest wrote:
>> > If the answer is yes, you were lying. If the answer is no, or you don't
>> > answer, then you're trolling the mailing list. You'll get my apology;
>> > I'll even throw in, for free, my personal congratulations for the long
>> > trolling. But, you'll get a nice permanent ban from here.
>>
>> No reply. Yes, you're not the only one who can set arbitrary deadlines
>> for other people, pal.
>>
>>
>> I'll just go with the script then: you DID believe those links to be true.
>>
>> Then, please accept my deepest and most sincere apologies for calling
>> you a liar.
>>
>> I'll state it again, very clearly, all uppercase:
>>
>> YOU NEVER LIED. I WAS WRONG.
>>
>> Please accept the attached fruit basket as a gesture of good will.
>>
>> ===
>>
>> Where does this leave us, then?
>>
>> At BEST, you have been trolling the mailing list, sending inflammatory
>> false content with the purpose of getting a strong reaction from the
>> participants.
>>
>> At WORST, you have demonstrated some abysmal gross incompetence, since
>> in order to win an argument you:
>>
>> * googled some keywords;
>> * got the first couple of links that seemed to match your thesis;
>> * didn't even bother to read the contents;
>> * pasted the links here believing they were true, without questioning
>> the veracity of such explosive statements;
>> * when busted, dug your hole even deeper by keeping arguing in that
>> direction.
>>
>> (...I'm not alone about bringing this possibility forward...)
>>
>> Spoiler alert, the links were April fools' jokes. They have never been
>> true, and it was even written in the articles that they were jokes. With
>> such precedents, why should anyone believe *any* other argument you
>> bring forward?
>>
>> ===
>>
>> In either case, it is abundantly clear who's full of shit around here.
>>
>> It is also clear to me that moderation on this list doesn't exist, or if
>> it exists, it doesn't want to get sides, and/or considers these
>> behaviours acceptable.
>>
>> I don't. And I don't send ultimatums or threats of libel lawsuits
>> (seriously?) around, including to the moderators, in order to force them
>> to make a move.
>>
>> Hence, I'll be removing myself from this list, effective immediately.
>>
>>
>> You win. Audience claps. Curtains.
>>
>> Ad astra per aspera,
>> --
>> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
>> KDAB (France) S.A.S., a KDAB Group company
>> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

[coroberti]

It looks like some business case for Roland.

Sending many emails with the links to the owned/associated
books thru the Qt mail lists
and even openly advertising them - at least two cases just recently.

Is it in line with the list policy?

Kind regards,
Robert Iakobashvili


On Thu, Apr 1, 2021 at 4:27 PM Volker Hilsheimer
 wrote:
>
> > On 1 Apr 2021, at 14:47, Roland Hughes  wrote:
> >> PS: Roland, I was looking at your 
> >> https://www.theminimumyouneedtoknow.com/agile_book.html page, and judging 
> >> by this sentence, I think your review process is broken. You should 
> >> probably ask for your money back from your professional editors, or 
> >> something… :P
> >>
> >> "The author of this title has spent over 30 years in IT working on 
> >> multi-country corporate applications before there was an Interent, to 
> >> stock exchange trading floor systems, desktop applications, and even 
> >> multiple medical devices."
> >>
> > The book was professionally edited. I put the page together with far less 
> > thought than I put into a post on here. You think it is a run-on sentence, 
> > so what?
>
> I assume you mean “Internet” when your page says “interent”.
>
>
> > The book still sells and I've done very little marketing. Other than the 
> > occasional mention when answering a question for free, none really.
>
> Congratulations.
>
>
> > When the justification for letting 12 year old bugs exist in the bug 
> > database is:
> >
> > that the code was too complex or that fixing the old bug would create new 
> > bugs
> >
> > The code had just as much review before check-in as the page that you 
> > looked at.
>
>
> That’s probably true; 12 years ago Qt was GPL/commercial only and not an open 
> source project with contributors outside of Trolltech. The Windows port was 
> commercial only, and we used perforce for version control. We didn’t do any 
> formal code reviews.
>
> Yes, there are bugs in Qt where a fix would break existing code that relies 
> on current behavior. And yes, there is code in Qt that is fragile, for 
> different reasons. The code I wrote 15+ years ago to support Windows XP menu 
> animations in Qt is probably not a shiny example of robustness.
>
> But most of it is pretty good, even some of mine, and it makes me proud to 
> have been able to contribute to Qt and to work with the incredibly talented 
> people in the Qt community for most of my professional career. I’m sorry that 
> you don’t like it.
>
>
> Cheers,
> Volker
>
> PS: yes, the oldest open bug in Qt is 
> https://bugreports.qt.io/browse/QTBUG-255, reported in 2006.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[coroberti]

On Mon, Mar 22, 2021 at 2:51 AM Jason H  wrote:
>
> >
> > > Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> > > Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> > > customers-leaving
> >
> > I wonder if the loss of confidence in the current Qt owners can ever be 
> > compensated.
> >
> > Even if TQC took back their critical decisions, I can't imagine that people 
> > would ever
> > trust them again. This could cause fatal damage to Qt in the long run if 
> > they don't sell
> > it to someone more responsible.
>
> Is there anything we can do to maybe block the release of new Qt versions, so 
> that the BSD poison pill clause is triggered? Then we can start over from a 
> BSD license, and maybe get other custodians of the code base?
>
> Qt is currently catering to automotive companies, and those sales allow them 
> to neglect other markets. I hope they circle back and get there market 
> segments they have been neglecting.
>
> My company abandoned commercial use of Qt as we were in a neglected market 
> segment... Rewrote the app native on each platform. It was painful, but 
> stuffiness routing the band-aid off quickly is the way to go.  I've been 
> lurking hoping to hear good things about QT6 but it looks like The decision 
> to go native was the right one.

Jason, welcome to the club of re-writers.

Are you still using it for mobile platforms?

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will a Qt 5.x release support macOS 11?

[coroberti]

Kind regards,
Robert Iakobashvili


On Thu, Dec 10, 2020 at 7:10 AM coroberti  wrote:
>
> On Thu, Dec 10, 2020 at 12:45 AM Thiago Macieira
>  wrote:
> >
> > On Wednesday, 9 December 2020 03:51:18 PST Hamish Moffatt wrote:
> > > To be useful I think we also need universal binaries for Qt, and support
> > > for making our own universal binaries in qmake, macdeployqt etc. I think
> > > there are also bugs in JIRA for those.
> > >
> > > Unfortunately we can't build separate ARM/Intel packages and expect our
> > > users to know which to install.
> >
> > You can build twice and use lipo to make universal binaries after the builds
> > are done.
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel DPG Cloud Engineering
> >

Once upon a time:
https://doc.qt.io/archives/4.6/developing-on-mac.html#universal-binaries

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will a Qt 5.x release support macOS 11?

[coroberti]

On Thu, Dec 10, 2020 at 12:45 AM Thiago Macieira
 wrote:
>
> On Wednesday, 9 December 2020 03:51:18 PST Hamish Moffatt wrote:
> > To be useful I think we also need universal binaries for Qt, and support
> > for making our own universal binaries in qmake, macdeployqt etc. I think
> > there are also bugs in JIRA for those.
> >
> > Unfortunately we can't build separate ARM/Intel packages and expect our
> > users to know which to install.
>
> You can build twice and use lipo to make universal binaries after the builds
> are done.
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>

It's not enough.

Bundled frameworks and plugins need to come as universal too.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will a Qt 5.x release support macOS 11?

[coroberti]

Dear Hamish,
Yes, this is the case.

Some bugs like in webengine (chromium) have been filed,
but it could be there are others.

After getting the new HW, we'll be more knowledgeable.

Regarding the native compilation, it seems that there are good patches already
made by Tor Arne Vestbo, and the folks are compiling successfully:

https://bugreports.qt.io/browse/QTBUG-85279

Take care and the best.

Kind regards,
Robert Iakobashvili

On Wed, Dec 9, 2020 at 10:55 AM Hamish Moffatt
 wrote:
>
> Interesting. If it doesn't work on the M1, isn't that a Rosetta bug? I assume 
> you haven't compiled for M1 yet given the Qt support is not released.
>
>
> Hamish
>
> Sent from Nine
> ____
> From: coroberti 
> Sent: Wednesday, 9 December 2020 19:28
> To: Qt Interest
> Cc: Hamish Moffatt
> Subject: Re: [Interest] Will a Qt 5.x release support macOS 11?
>
> Gentlemen,
> Make sure it works fine both on the Intel CPU and the new Apple M1.
>
> In our case, there are issues on Intel CPU and crashes on M1.
>
> Kind regards,
> Robert Iakobashvili
> 
>
> On Wed, Dec 9, 2020 at 10:09 AM Hamish Moffatt
>  wrote:
> >
> > On 9/12/20 6:07 pm, Ben Haller via Interest wrote:
> > > Hi all.  Just wondering whether there is any plan for any Qt 5.x release 
> > > to support macOS 11.  At present, Qt 5.15 supports only through macOS 
> > > 10.15 (https://doc.qt.io/qt-5/macos.html#supported-versions), as far as I 
> > > can tell, and my app built on macOS 10.15 apparently does not run 
> > > properly on macOS 11 (so my users inform me).  Since it looks like it 
> > > will be a little while before a Qt 6 release is really solid (I just saw 
> > > on the list that the first LTS release of Qt 6 is expected in September 
> > > 2021, almost a year from now), it would be really nice if macOS 11 were 
> > > added to the list of supported releases for 5.15.  Any chance of that?  I 
> > > have users who are already on macOS 11 now; I’d like to have a better 
> > > story for them.  Thanks for any info!
> >
> > Our app (built with Qt 5.12) is working fine on 11. Why not get OS 11
> > and test yourself?
> >
> >
> > Hamish
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will a Qt 5.x release support macOS 11?

[coroberti]

Gentlemen,
Make sure it works fine both on the Intel CPU and the new Apple M1.

In our case, there are issues on Intel CPU and crashes on M1.

Kind regards,
Robert Iakobashvili


On Wed, Dec 9, 2020 at 10:09 AM Hamish Moffatt
 wrote:
>
> On 9/12/20 6:07 pm, Ben Haller via Interest wrote:
> > Hi all.  Just wondering whether there is any plan for any Qt 5.x release to 
> > support macOS 11.  At present, Qt 5.15 supports only through macOS 10.15 
> > (https://doc.qt.io/qt-5/macos.html#supported-versions), as far as I can 
> > tell, and my app built on macOS 10.15 apparently does not run properly on 
> > macOS 11 (so my users inform me).  Since it looks like it will be a little 
> > while before a Qt 6 release is really solid (I just saw on the list that 
> > the first LTS release of Qt 6 is expected in September 2021, almost a year 
> > from now), it would be really nice if macOS 11 were added to the list of 
> > supported releases for 5.15.  Any chance of that?  I have users who are 
> > already on macOS 11 now; I’d like to have a better story for them.  Thanks 
> > for any info!
>
> Our app (built with Qt 5.12) is working fine on 11. Why not get OS 11
> and test yourself?
>
>
> Hamish
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] question for a blocking background thread call

[coroberti]

Dear Elvis,
It's very nice.
Thanks a lot.

Kind regards,
Robert


On Wed, Oct 21, 2020 at 9:53 PM Elvis Stansvik  wrote:
>
> Den ons 21 okt. 2020 kl 09:08 skrev coroberti :
> >
> > Elvis and Scott,
> > Could you please provide a code sample?
>
> I can't show our actual code since it's proprietary, but here's an example:
>
> example.cpp:
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> class TaskButton : public QPushButton
> {
> Q_OBJECT
>
> public:
> void startTask() {
> auto progressDialog = new QProgressDialog("Exporting...",
> QString(), 0, 10, this);
> progressDialog->setWindowModality(Qt::WindowModal);
> progressDialog->setAttribute(Qt::WA_DeleteOnClose);
> progressDialog->show();
>
> auto future = QtConcurrent::run(this, ::task);
> auto watcher = new QFutureWatcher(this);
>
> connect(this, ::progressChanged,
> progressDialog, ::setValue);
>
> connect(watcher, ::finished,
> watcher, ::deleteLater);
>
> connect(watcher, ::finished,
> progressDialog, ::close);
>
> connect(watcher, ::finished,
> this, ::finished);
>
> watcher->setFuture(future);
> }
>
> void task() {
> for (int progress = 1; progress < 11; ++progress) {
> QThread::sleep(1);  // Heavy task
> emit progressChanged(progress);
> }
> }
>
> signals:
> void progressChanged(int progress);
> void finished();
> };
>
> int main(int argc, char *argv[]) {
> QApplication app(argc, argv);
>
> TaskButton button;
> button.setText("Start Task");
> button.show();
>
> QObject::connect(, ::clicked,
>  , ::startTask);
>
> QObject::connect(, ::finished, [&]() {
> QMessageBox::information(, "Finished!", "We're done!");
> app.quit();
> });
>
> return app.exec();
> }
>
> #include "example.moc"
>
>
> example.pro:
>
> TEMPLATE = app
> QT += widgets concurrent
> TARGET = example
> INCLUDEPATH += .
> DEFINES += QT_DEPRECATED_WARNINGS
> SOURCES += example.cpp
>
>
> HTH,
> Elvis
>
> >
> > Thanks,
> >
> > Kind regards,
> > Robert
> >
> > On Wed, Oct 21, 2020 at 9:51 AM Elvis Stansvik  wrote:
> > >
> > > Den ons 21 okt. 2020 02:39Scott Bloom  skrev:
> > >>
> > >> Well. I 100% totally overthought this... and was able to implement this 
> > >> in about 10 lines of code using a derivation of QProgressDIalog + 
> > >> QtConcurrent
> > >>
> > >> The progress dialog, is run with windowModality set to  Qt::WindowModal,
> > >>
> > >> I overload exec, and launch the function then call QProgressDialog::exec.
> > >>
> > >> Works like charm. Thanks for the advice.
> > >
> > >
> > > Just to chime in: This is also the approach we've taken to some long 
> > > running operations in our application, and it has also worked out fine.
> > >
> > > Elvis
> > >
> > >>
> > >> Scott
> > >> -Original Message-
> > >> From: Interest  On Behalf Of Thiago 
> > >> Macieira
> > >> Sent: Tuesday, October 20, 2020 3:44 PM
> > >> To: interest@qt-project.org
> > >> Subject: Re: [Interest] question for a blocking background thread call
> > >>
> > >> On Tuesday, 20 October 2020 14:26:10 PDT Giuseppe D'Angelo via Interest 
> > >> wrote:
> > >> > Can't you just create a QDialog and exec() it?
> > >>
> > >> Or any other modal window in front. You probably want to display either 
> > >> a progress bar or a distraction, to let your users know that the 
> > >> application isn't frozen.
> > >>
> > >> --
> > >> Thiago Macieira - thiago.macieira (AT) intel.com
> > >>   Software Architect - Intel DPG Cloud Engineering
> > >>
> > >>
> > >>
> > >> ___
> > >> Interest mailing list
> > >> Interest@qt-project.org
> > >> https://lists.qt-project.org/listinfo/interest
> > >> ___
> > >> Interest mailing list
> > >> Interest@qt-project.org
> > >> https://lists.qt-project.org/listinfo/interest
> > >
> > > ___
> > > Interest mailing list
> > > Interest@qt-project.org
> > > https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] question for a blocking background thread call

[coroberti]

Elvis and Scott,
Could you please provide a code sample?

Thanks,

Kind regards,
Robert

On Wed, Oct 21, 2020 at 9:51 AM Elvis Stansvik  wrote:
>
> Den ons 21 okt. 2020 02:39Scott Bloom  skrev:
>>
>> Well. I 100% totally overthought this... and was able to implement this in 
>> about 10 lines of code using a derivation of QProgressDIalog + QtConcurrent
>>
>> The progress dialog, is run with windowModality set to  Qt::WindowModal,
>>
>> I overload exec, and launch the function then call QProgressDialog::exec.
>>
>> Works like charm. Thanks for the advice.
>
>
> Just to chime in: This is also the approach we've taken to some long running 
> operations in our application, and it has also worked out fine.
>
> Elvis
>
>>
>> Scott
>> -Original Message-
>> From: Interest  On Behalf Of Thiago Macieira
>> Sent: Tuesday, October 20, 2020 3:44 PM
>> To: interest@qt-project.org
>> Subject: Re: [Interest] question for a blocking background thread call
>>
>> On Tuesday, 20 October 2020 14:26:10 PDT Giuseppe D'Angelo via Interest 
>> wrote:
>> > Can't you just create a QDialog and exec() it?
>>
>> Or any other modal window in front. You probably want to display either a 
>> progress bar or a distraction, to let your users know that the application 
>> isn't frozen.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel DPG Cloud Engineering
>>
>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QComboBox Signal void activated(const QString )

[coroberti]

Samuel and Andre,
Thank you for your prompt response.

Have a nice day and week!
Kind regards,
Robert

On Mon, Oct 19, 2020 at 11:58 AM André Hartmann
 wrote:
>
> Hi Robert,
>
> It is still there in 5.15, but deprecated. Please see
> https://doc.qt.io/qt-5/qcombobox-obsolete.html#activated-1
>
> The reason to remove overloaded signals is to make functor-based
> connections easier.
>
> Best regards,
> André
>
> Am 19.10.20 um 10:32 schrieb coroberti:
> > Hi,
> > Documentation for Qt-5.12 refers to two "activated" signals:
> > https://doc.qt.io/qt-5.12/qcombobox.htm
> > void activated(int index)
> > void activated(const QString )
> >
> > Documentation for Qt-5.15 refers to only one of them
> > https://doc.qt.io/qt-5/qcombobox.html
> > void activated(int index)
> >
> > Was the signal removed for some reason?
> > Thanks.
> >
> > Kind regards,
> > Robert Iakobashvili
> > 
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] QComboBox Signal void activated(const QString )

[coroberti]

Hi,
Documentation for Qt-5.12 refers to two "activated" signals:
https://doc.qt.io/qt-5.12/qcombobox.htm
void activated(int index)
void activated(const QString )

Documentation for Qt-5.15 refers to only one of them
https://doc.qt.io/qt-5/qcombobox.html
void activated(int index)

Was the signal removed for some reason?
Thanks.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] macOS Big Sur ARM Build

[coroberti .]

me2

Kind regards,
Robert

On Wed, Jun 24, 2020 at 2:21 PM Marc Britton  wrote:
>
> I too would like to know about the Qt Company's reactions/plans for this.
>
> Cheers
> --
> Marc
>
> On Wed, 24 Jun 2020 at 17:57, Pascal Henze  wrote:
>>
>> With the announcement from Apple to move from Intel to ARM what are the 
>> impacts for QT ?
>> Will there be another "Kit" for macOS to build an arm version or is it 
>> already possible at the moment?
>>
>> Does anyone have information about that?
>>
>> Thank you.
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Apple Announced Mac Migration from Intel to ARM

[coroberti .]

Hi,
It looks like we get more headaches with two builds to test.
Interesting what could be the Qt-roadmap on Mac?

Thanks.
Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dictation to Qt-Software on Windows-10 Is Broken

[coroberti .]

Dear Oliver and Andre,
What's up?
If you have any patches to test/validate, please let me know.
Thanks.

Kind regards,
Robert

On Wed, May 13, 2020 at 7:36 AM Oliver Wolff  wrote:
>
> Hi Robert,
>
> On 12.05.2020 13:14, coroberti . wrote:
> > Hi,
> > If somebody in charge could consider increasing priority of the below
> > major Accessibility issue, it would be really appreciated.
> >
> > You cannot dictate to Qt text controls on Windows 10, 8 and 7.
> >
> > https://bugreports.qt.io/browse/QTBUG-83671
> >
> > There is no workaround within Qt platform.
> >
> > Thanks in advance!
>
> Sorry for the late reply. Andre had a look at the issue yesterday and
> commented on the bug report. He is currently busy with something else
> but promised to get back to the topic afterwards.
>
> Kind regards,
> Olli
>
> >
> > Kind regards,
> > Robert
> >
> > On Tue, Apr 21, 2020 at 9:54 AM coroberti .  wrote:
> >> You cannot dictate to Qt-software on Windows-10:
> >> https://bugreports.qt.io/browse/QTBUG-83671
> >>
> >> Actually, it was always a broken area at least since 2015:
> >>
> >> https://bugreports.qt.io/browse/QTBUG-45980
> >>
> >> If people on the list have a chance to vote, please vote.
> >>
> >> Thanks,
> >>
> >> Kind regards,
> >> Robert
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[coroberti .]

On Fri, Jun 12, 2020 at 9:48 AM coroberti .  wrote:
>
> On Fri, Jun 12, 2020 at 9:28 AM Thiago Macieira
>  wrote:
> >
> > On Thursday, 11 June 2020 21:40:03 PDT coroberti . wrote:
> > > Most people are using their Mac computers 7-10 years, yes without the
> > > security updates that for some usage patterns is still fine.
> >
> > macOS 10.13 runs on all 64-bit Intel Macs. It's 10.14 that requires
Haswell,
> > which is today only 6½ years old. All macOS updates have been free for
years.
> > Why is anyone running anything older than 10.13? This is an honest
question:
> > what makes people not upgrade their Macs?
> >
>
> Many people (teachers, tutors) in U.S. Educational systems have Mac
computers.
>
> They are not getting their Mac for free - free Chromebook, maybe.
>
> The Mac hardware works correctly for them for years with their school
systems
> and for their professional purposes.
>
> They have modern browsers like Firefox and Chrome well supporting old
> Mac systems,
> and yes there are many of them still on 10.12 and even on 10.10.
>
> Modern browsers help them with Google-Docs and Office-Online and they
> do not need
> Safari patches for that.
>
> They are not earning as high as software/hardware engineering people and
> paying $1500-2000 for teachers is not something you can afford.
>

Why not to upgrade your Mac OS software?


1. Physiology.
People are not technical enough and have a real barrier to deal
with new features or changes of the UI.

*If it ain't broke, don't fix it - *they think (yes, correct - security
issues, but they have a rather low awareness).

2. Mac upgrade breaks your software, particularly true if you are in
multimedia or education.

If you do not have a license with the option to upgrade for N-years, y
ou end up re-purchasing the software.

This is a very common case on Mac, and a rather rare on Windows.


3. Software vendors steadily drop their support for Mac OS.
For example, Dragon Dictation from Nuance last version released was for
10.13 - no more support since that.

The reason for that is high cost of software support with changing API
security enhancements breaking applications on an yearly basis at least.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[coroberti .]

On Fri, Jun 12, 2020 at 9:28 AM Thiago Macieira
 wrote:
>
> On Thursday, 11 June 2020 21:40:03 PDT coroberti . wrote:
> > Most people are using their Mac computers 7-10 years, yes without the
> > security updates that for some usage patterns is still fine.
>
> macOS 10.13 runs on all 64-bit Intel Macs. It's 10.14 that requires Haswell,
> which is today only 6½ years old. All macOS updates have been free for years.
> Why is anyone running anything older than 10.13? This is an honest question:
> what makes people not upgrade their Macs?
>

Many people (teachers, tutors) in U.S. Educational systems have Mac computers.

They are not getting their Mac for free - free Chromebook, maybe.

The Mac hardware works correctly for them for years with their school systems
and for their professional purposes.

They have modern browsers like Firefox and Chrome well supporting old
Mac systems,
and yes there are many of them still on 10.12 and even on 10.10.

Modern browsers help them with Google-Docs and Office-Online and they
do not need
Safari patches for that.

They are not earning as high as software/hardware engineering people and
paying $1500-2000 for teachers is not something you can afford.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[coroberti .]

On Fri, Jun 12, 2020 at 3:45 AM Hamish Moffatt
 wrote:
>
> On 12/6/20 10:17 am, Scott Bloom wrote:
> > Why is Win7 being dropped?  I (my company) has gotten burned pretty hard by 
> > the dropping of CentOS 6, similar reasons listed for win7..
>
> It's funny that there's so much discussion about dropping Windows 7
> which was released 11 years ago.
>
> Yet Qt 5.15 already dropped macOS prior to 10.13, which is not even 3
> years old. And Qt trunk requires 10.14, which is only 2 years old. This
> is really a major PITA.
>
>
> Hamish

Dear Hamish,
I could easily agree with you that treatment of Mac OS by Qt is not correct.

Most people are using their Mac computers 7-10 years, yes without the
security updates that for some usage patterns is still fine.

The real problem for many customers of Win-7 is that they cannot
migrate to Win-10
due to data being sent to Microsoft. (They are even considering Linux
and Mac options
because of that).

And yes these customers would like to have fancy new features within
the nearest 10 years.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dictation to Qt-Software on Windows-10 Is Broken

[coroberti .]

Dear Oliver and Andre,
Thank you for your reply and plans to fix it.

When you have a patch, please let me know.

I can help to test the fix by building Qt from sources
and applying the patch/patches.

Thanks in advance!

Kind regards,
Robert

On Wed, May 13, 2020 at 7:36 AM Oliver Wolff  wrote:
>
> Hi Robert,
>
> On 12.05.2020 13:14, coroberti . wrote:
> > Hi,
> > If somebody in charge could consider increasing priority of the below
> > major Accessibility issue, it would be really appreciated.
> >
> > You cannot dictate to Qt text controls on Windows 10, 8 and 7.
> >
> > https://bugreports.qt.io/browse/QTBUG-83671
> >
> > There is no workaround within Qt platform.
> >
> > Thanks in advance!
>
> Sorry for the late reply. Andre had a look at the issue yesterday and
> commented on the bug report. He is currently busy with something else
> but promised to get back to the topic afterwards.
>
> Kind regards,
> Olli
>
> >
> > Kind regards,
> > Robert
> >
> > On Tue, Apr 21, 2020 at 9:54 AM coroberti .  wrote:
> >> You cannot dictate to Qt-software on Windows-10:
> >> https://bugreports.qt.io/browse/QTBUG-83671
> >>
> >> Actually, it was always a broken area at least since 2015:
> >>
> >> https://bugreports.qt.io/browse/QTBUG-45980
> >>
> >> If people on the list have a chance to vote, please vote.
> >>
> >> Thanks,
> >>
> >> Kind regards,
> >> Robert
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dictation to Qt-Software on Windows-10 Is Broken

[coroberti .]

Hi,
If somebody in charge could consider increasing priority of the below
major Accessibility issue, it would be really appreciated.

You cannot dictate to Qt text controls on Windows 10, 8 and 7.

https://bugreports.qt.io/browse/QTBUG-83671

There is no workaround within Qt platform.

Thanks in advance!

Kind regards,
Robert

On Tue, Apr 21, 2020 at 9:54 AM coroberti .  wrote:
> You cannot dictate to Qt-software on Windows-10:
> https://bugreports.qt.io/browse/QTBUG-83671
>
> Actually, it was always a broken area at least since 2015:
>
> https://bugreports.qt.io/browse/QTBUG-45980
>
> If people on the list have a chance to vote, please vote.
>
> Thanks,
>
> Kind regards,
> Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Application - Disabling AVX/AVX2

[coroberti .]

Kind regards,
Robert Iakobashvili


On Wed, Apr 22, 2020 at 6:40 PM coroberti .  wrote:
>
> On Wed, Apr 22, 2020 at 6:35 PM Allan Sandfeld Jensen  
> wrote:
> >
> > On Mittwoch, 22. April 2020 17:29:56 CEST coroberti . wrote:
> > > On Wed, Apr 22, 2020 at 6:17 PM Thiago Macieira
> > >
> > >  wrote:
> > > > On Tuesday, 21 April 2020 14:26:13 PDT coroberti . wrote:
> > > > > Hi,
> > > > > Is it enough to define:
> > > > >
> > > > > QMAKE_CFLAGS -= -arch:AVX -arch:AVX2
> > > > > QMAKE_CXXFLAGS -=  -arch:AVX -arch:AVX2
> > > > >
> > > > > to ensure that compilation by QtCreator with Qt-5.14-MSVC Windows
> > > > > will not compile with such optimization flags even if avx and avx2
> > > > > instructions have not been disabled in Qt-library itself?
> > > >
> > > > Since those options aren't added to the CFLAGS or CXXFLAGS in the first
> > > > place, by default what you're tryng to do is a no-op.
> > > > Why do you think there are AVX instructions in your binary? And how did
> > > > you
> > > > turn them on in the first place?
> > > > Thiago Macieira - thiago.macieira (AT) intel.com
> > > >
> > > >   Software Architect - Intel System Software Products
> > >
> > > Thank you for your reply.
> > >
> > > Building 5.14.2, I was alerted by report from config that avx
> > > instructions are enabled.
> > >
> > > Clear, I need to investigate it more.
> > >
> > Probably support for them is enabled, but not turned on. That is what we do 
> > in
> > qtbase, build only some files with AVX enabled and switch to them on at
> > runtime.
> >
> > 'Allan
> >
> Thanks, Allan.
>
> Perhaps, like Microsoft, AVX optimized functions will be used only if
> runtime support by CPU detected.
>
> Kind regards,
> Robert

I've seen it.
It's not just a good job, it's a fantastically great job done in qtbase.

It even navigates thru the mess of compiler versions/issues.

Thanks, Thiago and Allan!

Kind regards,
Robert

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Application - Disabling AVX/AVX2

[coroberti .]

On Wed, Apr 22, 2020 at 6:35 PM Allan Sandfeld Jensen  wrote:
>
> On Mittwoch, 22. April 2020 17:29:56 CEST coroberti . wrote:
> > On Wed, Apr 22, 2020 at 6:17 PM Thiago Macieira
> >
> >  wrote:
> > > On Tuesday, 21 April 2020 14:26:13 PDT coroberti . wrote:
> > > > Hi,
> > > > Is it enough to define:
> > > >
> > > > QMAKE_CFLAGS -= -arch:AVX -arch:AVX2
> > > > QMAKE_CXXFLAGS -=  -arch:AVX -arch:AVX2
> > > >
> > > > to ensure that compilation by QtCreator with Qt-5.14-MSVC Windows
> > > > will not compile with such optimization flags even if avx and avx2
> > > > instructions have not been disabled in Qt-library itself?
> > >
> > > Since those options aren't added to the CFLAGS or CXXFLAGS in the first
> > > place, by default what you're tryng to do is a no-op.
> > > Why do you think there are AVX instructions in your binary? And how did
> > > you
> > > turn them on in the first place?
> > > Thiago Macieira - thiago.macieira (AT) intel.com
> > >
> > >   Software Architect - Intel System Software Products
> >
> > Thank you for your reply.
> >
> > Building 5.14.2, I was alerted by report from config that avx
> > instructions are enabled.
> >
> > Clear, I need to investigate it more.
> >
> Probably support for them is enabled, but not turned on. That is what we do in
> qtbase, build only some files with AVX enabled and switch to them on at
> runtime.
>
> 'Allan
>
Thanks, Allan.

Perhaps, like Microsoft, AVX optimized functions will be used only if
runtime support by CPU detected.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Application - Disabling AVX/AVX2

[coroberti .]

On Wed, Apr 22, 2020 at 6:17 PM Thiago Macieira
 wrote:
>
> On Tuesday, 21 April 2020 14:26:13 PDT coroberti . wrote:
> > Hi,
> > Is it enough to define:
> >
> > QMAKE_CFLAGS -= -arch:AVX -arch:AVX2
> > QMAKE_CXXFLAGS -=  -arch:AVX -arch:AVX2
> >
> > to ensure that compilation by QtCreator with Qt-5.14-MSVC Windows
> > will not compile with such optimization flags even if avx and avx2
> > instructions have not been disabled in Qt-library itself?
> Since those options aren't added to the CFLAGS or CXXFLAGS in the first place,
> by default what you're tryng to do is a no-op.
> Why do you think there are AVX instructions in your binary? And how did you
> turn them on in the first place?
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products

Thank you for your reply.

Building 5.14.2, I was alerted by report from config that avx
instructions are enabled.

Clear, I need to investigate it more.

Thanks,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt Application - Disabling AVX/AVX2

[coroberti .]

Hi,
Is it enough to define:

QMAKE_CFLAGS -= -arch:AVX -arch:AVX2
QMAKE_CXXFLAGS -=  -arch:AVX -arch:AVX2

to ensure that compilation by QtCreator with Qt-5.14-MSVC Windows
will not compile with such optimization flags even if avx and avx2 instructions
have not been disabled in Qt-library itself?

Thanks!

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Dictation to Qt-Software on Windows-10 Is Broken

[coroberti .]

Hi,
If by chance Qt-Accessibility has a maintainer,
this is the new and even more severe issue with dictation on Windows-10.

You cannot dictate to Qt-software on Windows-10:

https://bugreports.qt.io/browse/QTBUG-83671

Actually, it was always a broken area at least since 2015:

https://bugreports.qt.io/browse/QTBUG-45980

If people on the list have a chance to vote, please vote.

Thanks,

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt-5.14.2 - iOS - Drag & Drop

[coroberti .]

On Mon, Apr 20, 2020 at 1:04 PM Tor Arne Vestbø  wrote:
>
> This is a missing feature, please file a feature request, thanks!
>
> Tor Arne
>
> > On 20 Apr 2020, at 08:54, coroberti .  wrote:
> >
> > On Sun, Apr 5, 2020 at 1:32 PM coroberti .  wrote:
> >> Trying to allow Drag to my app on iOS (iPad with spitted view)
> >> and working in line with: https://doc.qt.io/qt-5/dnd.html
> >>
> >> I see that dragEnterEvent () and dragMoveEvent () are never called.
> >>
> >> This is in contrast to Mac OS X where it works for the same exactly code 
> >> properly.
> >> (and acceptDrops(true) was set).
> >>
> >> I was using on both platforms QTextEdit widget.
> >>
> >> Is it correct to say that on iOS widgets lack implementation of drap 
> >> events?
> >>
> >> Please, let me know if I'm missing something like configuration missed, 
> >> etc.
> >>
> >> Thanks in advance!
> >>
> >> Kind regards,
> >> Robert Iakobashvili
> >> 
> >
> > Could somebody from iOS of GUI maintainers guide me whether the
> > issue above is a bug or a feature request to open?
> >
> > Thanks in advance!
> >
> > Kind regards,
> > Robert

Thanks, Tor Arne Vestbø.

Here it is:
https://bugreports.qt.io/browse/QTBUG-83665

Please, vote for it. Thanks!

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt-5.14.2 - iOS - Drag & Drop

[coroberti .]

On Sun, Apr 5, 2020 at 1:32 PM coroberti .  wrote:
> Trying to allow Drag to my app on iOS (iPad with spitted view)
> and working in line with: https://doc.qt.io/qt-5/dnd.html
>
> I see that dragEnterEvent () and dragMoveEvent () are never called.
>
> This is in contrast to Mac OS X where it works for the same exactly code 
> properly.
> (and acceptDrops(true) was set).
>
> I was using on both platforms QTextEdit widget.
>
> Is it correct to say that on iOS widgets lack implementation of drap 
> events?
>
> Please, let me know if I'm missing something like configuration missed, etc.
>
> Thanks in advance!
>
> Kind regards,
> Robert Iakobashvili
> 

Could somebody from iOS of GUI maintainers guide me whether the
issue above is a bug or a feature request to open?

Thanks in advance!

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.12.x LTS

[coroberti .]

It will take for 5.15 several months to get major fixes,
and 5.12 is a very stable version.

jm4c

Kind regards,
Robert

On Tue, Apr 14, 2020 at 4:33 PM Jason H  wrote:
>
> If you're goint to change to 5.12, you might want to wait a month or so for 
> 5.15, the next LTS, is targeted around May 15.
> I'm not sure how much work it is for you to switch, but if you're just now 
> switching to 5.12, I assume it is at a substantial cost...
>
>
>
> Sent: Monday, April 13, 2020 at 1:57 AM
> From: "Ramakanth Kesireddy" 
> To: "Qt Interest" 
> Subject: [Interest] Qt 5.12.x LTS
> Hi,
>
> As we are moving to Qt 5.12 LTS commercial release owing to future 
> commercialwith  LTS releases, I have a few questions:
>
> 1) Can we make use of other open source modules like Qt WebKit or tools like 
> Qt creator, Qt linguist along with Qt commercial release?
>
> 2) Does it makes sense to use latest Qt 5.12.8 LTS instead of Qt 5.12.7 wrto 
> stable release?
>
> 3) May I know if the recent security bug fixes added to Qt 5.13 and Qt 5.14 
> are back ported to Qt 5.12 LTS?
>
> Best Regards,
> Ramakanth
>
>
> ___ Interest mailing list 
> Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt-5.14.2 - iOS - Drag & Drop

[coroberti .]

Hi,
Thanks to Qt-team for the latest patch release.

Trying to allow Drag to my app on iOS (iPad with spitted view)
and working in line with: https://doc.qt.io/qt-5/dnd.html

I see that dragEnterEvent () and dragMoveEvent () are never called.

This is in contrast to Mac OS X where it works for the same exactly code
properly.
(and acceptDrops(true) was set).

I was using on both platforms QTextEdit widget.

Is it correct to say that on iOS widgets lack implementation of drap
events?

Please, let me know if I'm missing something like configuration missed, etc.

Thanks in advance!

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt3D] Assertion in QAbstractAspect when inserting entity from plugin DLL

[coroberti .]

On Sat, Feb 8, 2020 at 6:07 AM Thiago Macieira
 wrote:
>
> On Friday, 7 February 2020 05:52:37 PST Volker Enderlein wrote:
> > Program: C:\Qt\5.14.1\msvc2017_64\bin\Qt5Cored.dll
> > Module: 5.14.1
> > File: aspects\qabstractaspect.cpp
> > Line: 213
> >
> > ASSERT: "metaObj" in file aspects\qabstractaspect.cpp, line 213
>
> MSVC 2017 has serious bug in static initialisation. Microsoft has already
> fixed it. Please upgrade (to 2019).
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>

Is it correct to say that Microsoft not released the patch for MSVC 2017?
What is the issue number of link?
Thanks.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

[coroberti .]

Have you tried to comment out cleanup of reply objects (QNetworkReply) ?


On Thu, Feb 6, 2020 at 8:49 AM maitai  wrote:
>
> I've checked it already, and anyway a QFileDialog is a QWidget and as such 
> cannot be created before QApplication (that's what it said when I tried).
>
> Philippe
>
>
>
>
> Le 05-02-2020 21:20, Henry Skoglund a écrit :
>
> Hi, maybe you already checked this, but if you have any big wheels like a 
> QFileDialog declared static, their ctors most likely will run before main(), 
> i.e. some COM/networking activity could occur before main() kicks in.
>
> On 2020-02-05 21:10, maitai wrote:
>
> As I said, I now have doubts it comes from COM threading...
>
> I have built a small app with nothing inside, with the same .pro file exactly 
> (qt modules, libs, etc, in the same order). The only difference is HEADERS 
> and SOURCES of course, main.cpp being the same at least until it crashes. No 
> problem in this small app (running in the same directory).
>
> Again for those who missed it:
>
> main.cpp:
>
> QNetworkAccessManager *inet = new QNetworkAccessManager();
>
> delete inet;
>
> QApplication app(argc, argv);
>
> this works.
>
>QApplication app(argc, argv);
>
>QNetworkAccessManager *inet = new QNetworkAccessManager();
>
> delete inet;
>
> this crashes on new in our app, not in a sample without HEADERS and SOURCES.
>
> I cannot understand that, certainly there is something obvious I am missing.
>
> Philippe Lelong.
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

[coroberti .]

On Tue, Feb 4, 2020 at 6:07 PM maitai  wrote:
>
> Thanks Robert and Thiago,
>
> If I create it on the stack instead of on the heap same mystery, i.e if
> I create it before qApp all good, if after it crashes
>
> this works:
>  qWarning()<<"test";
>  QNetworkAccessManager inet;
>  qWarning()<<"after test";
>  QApplication app(argc, argv);
>
> this crashes:
>  QApplication app(argc, argv);
>  qWarning()<<"test";
>
Kind regards,
Robert Iakobashvili
 inet;
>  qWarning()<<"after test";
>
> Interesting is that in that last case I have a new message in the
> console:
>
> Failed to initialize COM library.  Error code = 0x -7ffefefa, before my
> "test" qWarning()...
>
> Googling it tells me it's about using WMI and it's true I do have some
> WMI functions defined statically in an object.
>
> Still that was working fine before 5.14.0 (5.13.2 for instance), and why
> creating/deleting it before qApp fixes it all is beyond my level of
> understanding...
>
> Philippe Lelong.
>
Dear Philippe,
Beyond any doubts,

1. QApplication should be prior to QNetworkAccessManager;
2. There is some memory issue only triggered by update to 5.14;
3. Look at all places in QNetworkAccessManager slots where you are
doing deleteLater(),
kinda for reply objects.
Try to comment them out temporarily and see if you still reproduce the crash.

Take care,

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

[coroberti .]

On Tue, Feb 4, 2020 at 5:43 PM Thiago Macieira
 wrote:
>
> On Tuesday, 4 February 2020 01:45:27 PST coroberti . wrote:
> > Sorry, I meant allocation of QNetworkAccessManager object
> > by new operator (dynamic) versus its allocation on function scope (static).
>
> Instead of static, please use automatic storage (no static, no new). Create it
> in the stack, after QApplication.
>

Yes, "automatic" is the right word.

Philippe, if "automatic" on stack instance resolves your issue
and the crash when you are doing allocation by new remains,
it's a memory issue.

Try to look at the places where you are doing deleteLater(),
perhaps with the reply objects.

Take care,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

[coroberti .]

Sorry, I meant allocation of QNetworkAccessManager object
by new operator (dynamic) versus its allocation on function scope (static).

Kind regards,
Robert

On Tue, Feb 4, 2020 at 11:31 AM maitai  wrote:
>
> Thanks Robert,
>
> What do you mean by dynamic allocation versus static? In our app all our
> libs are linked statically, all qt libs are dynamics, I cannot change
> that easily.
>
> Philippe.
>
> Le 04-02-2020 09:07, coroberti . a écrit :
> > Dear Philippe,
> > Try to change dynamic allocation to static and if the matters come to
> > order,
> > there's some memory corruption as my experience.
> >
> > jm2c
> >
> > Kind regards,
> > Robert Iakobashvili
> > 
> >
> > On Tue, Feb 4, 2020 at 10:02 AM maitai 
> > wrote:
> >>
> >> Hi all,
> >>
> >> While the mail list was broken I did some further experiments:
> >>
> >> If I move the creation of QNetworkAccessManager into main.cpp, it also
> >> crashes, but only if I put it after QApplication app(argc, argv);
> >>
> >> The funny part being that if I create a QneworkAccessManager before
> >> and
> >> just delete it, then my regular QNetworkAccessManager instantiated in
> >> MainWindow does not crash anymore.
> >>
> >> So my workaround is in main.cpp:
> >>
> >>  QNetworkAccessManager *inet = new QNetworkAccessManager();
> >>  QApplication app(argc, argv);
> >>  delete inet;
> >>
> >> And then all is back to OK.
> >>
> >> I have tried to reproduce that in a small sample but failed. I have
> >> build a small app with the same qt modules, the same linked libraries,
> >> running in the same directory, but failed to reproduce it.
> >>
> >> Any idea about what can go wrong here?
> >>
> >> Thanks
> >> Philippe
> >>
> >> Le 01-02-2020 20:11, maitai a écrit :
> >> > Hi all
> >> >
> >> > I am trying to upgrade from qt5.13.2/MSVC2017 to Qt5.14.1/MSVC2017
> >> >
> >> > In 5.14.1 (and 0) app is crashing on "QNetWorkAccessManager
> >> > *inetManager = new QNetWorkAccessManager()", while all is OK in
> >> > previous Qt versions
> >> >
> >> > I cannot debug this on Windows. I have removed all old dlls etc
> >> > (including SSL ones) in the directory where app is running. Obviously
> >> > something is wrong on my side since I cannot believe
> >> > QNetworkAccessManager is broken in Qt5.14.x/Windows..
> >> >
> >> > Any idea?
> >> > ___
> >> > Interest mailing list
> >> > Interest@qt-project.org
> >> > https://lists.qt-project.org/listinfo/interest
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

[coroberti .]

Dear Philippe,
Try to change dynamic allocation to static and if the matters come to order,
there's some memory corruption as my experience.

jm2c

Kind regards,
Robert Iakobashvili


On Tue, Feb 4, 2020 at 10:02 AM maitai  wrote:
>
> Hi all,
>
> While the mail list was broken I did some further experiments:
>
> If I move the creation of QNetworkAccessManager into main.cpp, it also
> crashes, but only if I put it after QApplication app(argc, argv);
>
> The funny part being that if I create a QneworkAccessManager before and
> just delete it, then my regular QNetworkAccessManager instantiated in
> MainWindow does not crash anymore.
>
> So my workaround is in main.cpp:
>
>  QNetworkAccessManager *inet = new QNetworkAccessManager();
>  QApplication app(argc, argv);
>  delete inet;
>
> And then all is back to OK.
>
> I have tried to reproduce that in a small sample but failed. I have
> build a small app with the same qt modules, the same linked libraries,
> running in the same directory, but failed to reproduce it.
>
> Any idea about what can go wrong here?
>
> Thanks
> Philippe
>
> Le 01-02-2020 20:11, maitai a écrit :
> > Hi all
> >
> > I am trying to upgrade from qt5.13.2/MSVC2017 to Qt5.14.1/MSVC2017
> >
> > In 5.14.1 (and 0) app is crashing on "QNetWorkAccessManager
> > *inetManager = new QNetWorkAccessManager()", while all is OK in
> > previous Qt versions
> >
> > I cannot debug this on Windows. I have removed all old dlls etc
> > (including SSL ones) in the directory where app is running. Obviously
> > something is wrong on my side since I cannot believe
> > QNetworkAccessManager is broken in Qt5.14.x/Windows..
> >
> > Any idea?
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Question about correct way to initialize HiDPI support

[coroberti .]

On Mon, Jan 13, 2020 at 11:35 AM Christoph Cullmann
 wrote:
>
> Hi,
>
> after reading https://doc.qt.io/qt-5/highdpi.html it is still a bit
> unclear to me,
> what is the correct sequence of attribute setting to have proper HiDPI
> support on the
> X11/Windows/macOS platforms (including support for scales like 150%).
>
> At the moment, e.g. in Kate, we try (before we init the QApplication):
>
>  /**
>   * enable high dpi support
>   */
>  QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true);
>  QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);
>
>  /**
>   * allow fractional scaling
>   */
> #if QT_VERSION >= QT_VERSION_CHECK(5, 14, 0)
>
> QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
> #endif
>
> Is that actually the right way to do it?
>
> Does one actually need the Qt::AA_EnableHighDpiScaling call?
> We got some reports that we behave strangely (weird sizes) since we
> added Qt::AA_EnableHighDpiScaling.
>
> If I miss some example snippet in the documentation, any pointer is
> welcome ;=)
>
> Greetings
> Christoph

Hi,
I'm joining the question and would appreciate some kind of "Best Practices"
or guidelines for dummies, perhaps, platform-specific.

Thanks,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Mac OS - AVCaptureDevice requestAccessForMediaType:AVMediaTypeVideo crashes application

[coroberti .]

On Fri, Jan 10, 2020 at 11:17 AM Nuno Santos  wrote:
>
> Roland,
>
> After spending more than 4 hours googling and searching for others examples 
> and realising I was not doing anything wrong I have stumbled with a detail 
> that was causing the crash.
>
> I was codesiging it with: codesign BUNDLE.app -s \"Developer ID Application: 
> Acme Inc. (XPTO)\" --options "runtime"
>
> Removing the —options “runtime” did the trick. The documentation says:
>
> runtime  On macOS versions >= 10.14.0, opts signed processes into a hard-
>   ened runtime environment which includes runtime code signing
>   enforcement, library validation, hard, kill, and debugging
>   restrictions.  These restrictions can be selectively relaxed via
>   entitlements. Note: macOS versions older than 10.14.0 ignore the
>   presence of this flag in the code signature.
>
> But I still don’t understand why it was crashing with this option.
>
> The app was not crashing on the computer that was built and signed but as 
> soon it ran on another computer it would crash with the 
> __CRASHING_DUE_TO_PRIVACY_VIOLATION__ reason.
>
> This was a very tricky one!
>
> Thanks for your reply.
>
> Best regards,
>
> Nuno
>

Nuno,
Mac OS 10.15 requires every software to be delivered from iTunes App Store or
to be notarized.

For Mac software (not being distributed via Store) to be notarized,
hardening runtime seems to be a pre-condition.

Signing with hardening runtime (-o runtime), you can pass some escapes
using the entitlements.plist, for example:




com.apple.security.automation.apple-events

com.apple.security.files.user-selected.read-write

com.apple.security.cs.allow-jit

com.apple.security.cs.allow-unsigned-executable-memory

com.apple.security.cs.allow-dyld-environment-variables

com.apple.security.cs.disable-executable-page-protection

com.apple.security.cs.disable-library-validation




and some others.

codesign --deep -o runtime -f -vv --entitlements ./entitlements.plist
--preserve-metadata=identifier,entitlements,requirements,runtime
--timestamp -s
"Developer ID Application: Your.app" ./Your.app

Afterwords you place the app to an archive or package, notarize it
with Apple and staple prior to distribution.

I was getting various strange crashes prior to doing that.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[coroberti .]

On Tue, Jul 9, 2019 at 8:56 PM Adam Light  wrote:

>
>
> On Fri, Jun 21, 2019 at 12:13 AM Kai Köhne  wrote:
>
>>
>> I understand that the "hardened runtime" enabling happens at codesign
>> time,
>> so this should arguably be a feature of macdeployqt. It's not there yet
>> though,
>> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If
>> you're
>> right that this will become mandatory for macOS 10.15, it arguably get a
>> higher
>> priority; feel free to comment, including a link to the source of this
>> statement.
>>
>> For the time being, it seems you've to execute the codesign call yourself.
>>
>>
> Notarization is a requirement for macOS 10.15 (Catalina, currently in
> beta). See https://developer.apple.com/news/?id=06032019i for an official
> source of this requirement. In one of the WWDC 2019  talks about security
> and code signing/notarization, they mentioned that this was true for
> applications built (or maybe it's signed) after some date in early June.
> For example, Qt 4.9.2, released June 26, 2019, will not run on Catalina
> beta 3 without knowing how to work around the notarization requirement.
>
> Note also that notarization is separate from hardened runtime. An
> application built with the 10.14 SDK or later must enable hardened runtime
> in order for it to be possible to notarize the application, but it is
> possible to notarize applications built with previous SDK versions for
> which hardened runtime did not exist.
>
> See my comment at
> https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
>  for
> some links that are particularly helpful in describing all of the
> complexities involved in notarization and hardened runtime.
>
> Adam
>
>
Adam,
Could you please provide more details about notarization without runtime
hardening by using SDK 10.13?
Specifically, which Xcode version was used and at which Mac OS?
Thanks,

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[coroberti .]

On Fri, Jun 21, 2019 at 9:42 AM Hamish Moffatt
 wrote:
>
> Apple says that all apps will need to be notarized (viewed) by them to
> be run on macOS 10.15 once released.
> Apps must have the hardened runtime enabled in Xcode before they can be
> notarized.
> Is there any way to get qmake to enable that project option?
> Hamish
>
Hi Hamish,
Good catch. Thanks for the reminder of notarization - a one more
headache from Apple.
Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Android - tgkill - libQt5Purchasing.so

[coroberti .]

Dear Nuno,
Here's the JNI issue that could be your case:

https://bugreports.qt.io/browse/QTBUG-68813

It looks like it's fixed (thanks to BogDan) in 5.12.2.

Kind regards,
Robert Iakobashvili



On Thu, May 9, 2019 at 9:35 AM coroberti .  wrote:

> Dear Nuno,
> Yes, JNI in QtPurchasing.
>
> The issue with the known bug of supposed to be fixed by BogDan recently is
> that
> Qt-5.9 worked perfect. Qt-5.10 and 5.11 are broken and it's supposed to be
> fixed very recently somewhere in Qt-5.12,
> but it might be that the fix is not covering all scenario.
>
> I'd look for all classes in QtPurchasing called by JNI and, if you have a
> scenario to reproduce the badness,
> make a log prior to every JNI call to see where it breaks.
>
> Take care.
>
> Kind regards,
> Robert Iakobashvili
> 
>
>
> On Thu, May 9, 2019 at 8:25 AM Nuno Santos 
> wrote:
>
>> Robert,
>>
>> Thanks for your input.
>>
>> I don’t use JNI for purchasing a long time. I rely solely on the C++ API
>> of QtPurchasing. That’s even more wicked.
>>
>> Maybe the problems resides solely inside the QtPurchasing module… I’m the
>> dark!
>>
>> Best,
>>
>> Nuno
>>
>> On 9 May 2019, at 06:47, coroberti .  wrote:
>>
>> Dear Nuno,
>> No knowledge, but as a direction, it's kinda JNI of QPurchasing is
>> looking in some scenario
>> for a Java class that is not existing or not installed.
>>
>> I'd look into all JNI calls that QPurchasing is doing and its Java
>> dependencies.
>>
>> We had recently a major issue with JNI done not via Qt API that BogDan
>> supposed to get fixed
>> and this issue appeared in Qt-5.10. Therefore, it could be another
>> direction to explore.
>>
>> Sorry, but jm2c to add.
>>
>> Kind regards,
>> Robert Iakobashvili
>> 
>>
>>
>> On Thu, May 9, 2019 at 12:08 AM Nuno Santos 
>> wrote:
>>
>>> Thiago,
>>>
>>> Thanks for your reply.
>>>
>>> Unfortunately no, this is all I can see in Google Play developer
>>> console... :(
>>>
>>> Unless I’m missing some detail on how to get more information.
>>>
>>> All I know it that it is very regular. Before I was using 5.10 and there
>>> was no issues. Since I have upgraded to Qt 5.12 this crash started to
>>> happen and happens quite often. So often that in some devices the cannot
>>> even be open and I don’t have a clue why it happens.
>>>
>>> The biggest problem is that in this cases, people usually slam the app
>>> with one star.
>>>
>>> Regards,
>>>
>>> Nuno
>>>
>>> > On 8 May 2019, at 20:47, Thiago Macieira 
>>> wrote:
>>> >
>>> > On Wednesday, 8 May 2019 07:21:09 PDT Nuno Santos wrote:
>>> >>  #06  pc 000ac2bb  /system/lib/libart.so
>>> >> (art::LogMessage::~LogMessage()+1322) #07  pc 00239e37
>>> >> /system/lib/libart.so (art::Thread::AssertNoPendingException()
>>> const+358)
>>> >> #08  pc 000de40b  /system/lib/libart.so
>>> >> (art::ClassLinker::FindClass(art::Thread*, char const*,
>>> >> art::Handle)+14) #09  pc 001df82b
>>> >> /system/lib/libart.so (art::JNI::FindClass(_JNIEnv*, char
>>> const*)+806) #10
>>> >> pc 5813
>>> >> /data/app/com.imaginando.drc-1/lib/arm/libQt5Purchasing.so
>>> >
>>> > All of these are logging a fatal message and then abort()ing the
>>> application.
>>> > Can you get that message?
>>> >
>>> > --
>>> > Thiago Macieira - thiago.macieira (AT) intel.com
>>> >  Software Architect - Intel System Software Products
>>> >
>>> >
>>> >
>>> > ___
>>> > Interest mailing list
>>> > Interest@qt-project.org
>>> > https://lists.qt-project.org/listinfo/interest
>>>
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> https://lists.qt-project.org/listinfo/interest
>>>
>>
>>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Android - tgkill - libQt5Purchasing.so

[coroberti .]

Dear Nuno,
Yes, JNI in QtPurchasing.

The issue with the known bug of supposed to be fixed by BogDan recently is
that
Qt-5.9 worked perfect. Qt-5.10 and 5.11 are broken and it's supposed to be
fixed very recently somewhere in Qt-5.12,
but it might be that the fix is not covering all scenario.

I'd look for all classes in QtPurchasing called by JNI and, if you have a
scenario to reproduce the badness,
make a log prior to every JNI call to see where it breaks.

Take care.

Kind regards,
Robert Iakobashvili



On Thu, May 9, 2019 at 8:25 AM Nuno Santos  wrote:

> Robert,
>
> Thanks for your input.
>
> I don’t use JNI for purchasing a long time. I rely solely on the C++ API
> of QtPurchasing. That’s even more wicked.
>
> Maybe the problems resides solely inside the QtPurchasing module… I’m the
> dark!
>
> Best,
>
> Nuno
>
> On 9 May 2019, at 06:47, coroberti .  wrote:
>
> Dear Nuno,
> No knowledge, but as a direction, it's kinda JNI of QPurchasing is looking
> in some scenario
> for a Java class that is not existing or not installed.
>
> I'd look into all JNI calls that QPurchasing is doing and its Java
> dependencies.
>
> We had recently a major issue with JNI done not via Qt API that BogDan
> supposed to get fixed
> and this issue appeared in Qt-5.10. Therefore, it could be another
> direction to explore.
>
> Sorry, but jm2c to add.
>
> Kind regards,
> Robert Iakobashvili
> 
>
>
> On Thu, May 9, 2019 at 12:08 AM Nuno Santos 
> wrote:
>
>> Thiago,
>>
>> Thanks for your reply.
>>
>> Unfortunately no, this is all I can see in Google Play developer
>> console... :(
>>
>> Unless I’m missing some detail on how to get more information.
>>
>> All I know it that it is very regular. Before I was using 5.10 and there
>> was no issues. Since I have upgraded to Qt 5.12 this crash started to
>> happen and happens quite often. So often that in some devices the cannot
>> even be open and I don’t have a clue why it happens.
>>
>> The biggest problem is that in this cases, people usually slam the app
>> with one star.
>>
>> Regards,
>>
>> Nuno
>>
>> > On 8 May 2019, at 20:47, Thiago Macieira 
>> wrote:
>> >
>> > On Wednesday, 8 May 2019 07:21:09 PDT Nuno Santos wrote:
>> >>  #06  pc 000ac2bb  /system/lib/libart.so
>> >> (art::LogMessage::~LogMessage()+1322) #07  pc 00239e37
>> >> /system/lib/libart.so (art::Thread::AssertNoPendingException()
>> const+358)
>> >> #08  pc 000de40b  /system/lib/libart.so
>> >> (art::ClassLinker::FindClass(art::Thread*, char const*,
>> >> art::Handle)+14) #09  pc 001df82b
>> >> /system/lib/libart.so (art::JNI::FindClass(_JNIEnv*, char const*)+806)
>> #10
>> >> pc 5813
>> >> /data/app/com.imaginando.drc-1/lib/arm/libQt5Purchasing.so
>> >
>> > All of these are logging a fatal message and then abort()ing the
>> application.
>> > Can you get that message?
>> >
>> > --
>> > Thiago Macieira - thiago.macieira (AT) intel.com
>> >  Software Architect - Intel System Software Products
>> >
>> >
>> >
>> > ___
>> > Interest mailing list
>> > Interest@qt-project.org
>> > https://lists.qt-project.org/listinfo/interest
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Android - tgkill - libQt5Purchasing.so

[coroberti .]

Dear Nuno,
No knowledge, but as a direction, it's kinda JNI of QPurchasing is looking
in some scenario
for a Java class that is not existing or not installed.

I'd look into all JNI calls that QPurchasing is doing and its Java
dependencies.

We had recently a major issue with JNI done not via Qt API that BogDan
supposed to get fixed
and this issue appeared in Qt-5.10. Therefore, it could be another
direction to explore.

Sorry, but jm2c to add.

Kind regards,
Robert Iakobashvili



On Thu, May 9, 2019 at 12:08 AM Nuno Santos 
wrote:

> Thiago,
>
> Thanks for your reply.
>
> Unfortunately no, this is all I can see in Google Play developer
> console... :(
>
> Unless I’m missing some detail on how to get more information.
>
> All I know it that it is very regular. Before I was using 5.10 and there
> was no issues. Since I have upgraded to Qt 5.12 this crash started to
> happen and happens quite often. So often that in some devices the cannot
> even be open and I don’t have a clue why it happens.
>
> The biggest problem is that in this cases, people usually slam the app
> with one star.
>
> Regards,
>
> Nuno
>
> > On 8 May 2019, at 20:47, Thiago Macieira 
> wrote:
> >
> > On Wednesday, 8 May 2019 07:21:09 PDT Nuno Santos wrote:
> >>  #06  pc 000ac2bb  /system/lib/libart.so
> >> (art::LogMessage::~LogMessage()+1322) #07  pc 00239e37
> >> /system/lib/libart.so (art::Thread::AssertNoPendingException()
> const+358)
> >> #08  pc 000de40b  /system/lib/libart.so
> >> (art::ClassLinker::FindClass(art::Thread*, char const*,
> >> art::Handle)+14) #09  pc 001df82b
> >> /system/lib/libart.so (art::JNI::FindClass(_JNIEnv*, char const*)+806)
> #10
> >> pc 5813
> >> /data/app/com.imaginando.drc-1/lib/arm/libQt5Purchasing.so
> >
> > All of these are logging a fatal message and then abort()ing the
> application.
> > Can you get that message?
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >  Software Architect - Intel System Software Products
> >
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.12 for Windows (Static)

[coroberti .]

On Thu, Jan 17, 2019 at 12:27 PM Nuno Santos 
wrote:

> Robert,
>
> Yes, I know. I have tried both.
>
> When I click the .exe it doesn’t happen nothing. Nothing! :/
>
> Is there any kind of debug flags that I can set?
>
> Nuno
>
>
Nuno,
1.What about trying some log to file at the beginning of your main()?

2. What about compiling some console test and running it from console?

3. QT_DEBUG_PLUGINS
http://doc.qt.io/qt-5/deployment-plugins.html
http://doc.qt.io/qt-5/plugins-howto.html#static-plugins

j2mc
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.12 for Windows (Static)

[coroberti .]

On Thu, Jan 17, 2019 at 11:13 AM Nuno Santos 
wrote:

> Hi,
> I have just compiled a fresh Qt 5.12.1 from the source statically on
> Windows but I’m having a basic problem.
> Any application that I run, crashes immediately, even the Qt Creator
> project templates, like que Qt Quick application template.
> I don’t have a clue of what is going on. Any ideas on how to get more
> information to eventually fill a bug report?
>
> Thanks!
> Nuno
>

Nuno,
Are you running from QtCreator or by clicking the exe file?
Clicking the exe could provide a Windows message if any dlls required are
not linked.

Running in debugger interesting if you are coming to main.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt-12 with Dark Theme on MacOS Mojave

[coroberti .]

On Thu, Dec 20, 2018 at 9:33 PM Mike Krus  wrote:

> Hi
>
> I’ve been tracking QEvent::PaletteChange events, like this:
>
> bool MainWindow::event(QEvent *event)
> {
> if (event->type() == QEvent::PaletteChange) {
> QPalette p = palette();
> m_clearColor = p.color(QPalette::Base);
> emit clearColorChanged(m_clearColor);
> }
>
> return QMainWindow::event(event);
> }
>
> Event gets sent when switching between themes…
>
> Of course, I’m just using the base colour as is, not trying to figure out
> if it’s light or dark…
>
> Hope this helps,
>
> Mike
>
> > On 20 Dec 2018, at 18:48, coroberti .  wrote:
> >
> > Hi,
> > Qt-12 well manages the colors of QWidgets - great job of Qt-developers.
> Thank you!
> >
> > When some background colors are managed by the application,
> > how to figure out whether it's Light or Dark theme currently in use?
> >
> > Another question is how to get notification about the switch between the
> themes?
>
>
Hi Mike,
Thank you for your reply and the proposed direction.

It looks like what's left for me is to explore how to figure out from
QPalette mapping to the standard themes.

BRGS,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt-12 with Dark Theme on MacOS Mojave

[coroberti .]

Hi,
Qt-12 well manages the colors of QWidgets - great job of Qt-developers.
Thank you!

When some background colors are managed by the application,
how to figure out whether it's Light or Dark theme currently in use?

Another question is how to get notification about the switch between the
themes?

Thanks in advance!

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[coroberti .]

> > Il 11/11/18 17:15, coroberti . ha scritto:
> > > Following Allan's advise, here's something that is starting to work
> > > (checks omitted)
> > >
> > > QTextDocument* doc = this->text_edit_->document();
> > > QTextBlock currentBlock = doc->firstBlock();
> > >
> > >  while (currentBlock.isValid()) {
> > >
> > >  QTextCursor cursor(currentBlock);
> > >  QTextBlockFormat blockFormat = currentBlock.blockFormat();
> > >  blockFormat.setLineHeight(200, 
> > > QTextBlockFormat::ProportionalHeight);
> > >  cursor.setBlockFormat(blockFormat);
> > >
> > >  currentBlock = currentBlock.next();
> > >  }
> > >
> > > Thank you very much!
> >
> > Isn't it simpler to use a selection approach instead?
> >
> > QTextBlockFormat format;
> > format.setLineHeight(...);
> >
> > QTextCursor cursor(textDocument);
> > cursor.select(QTextCursor::Document);
> > cursor.mergeBlockFormat(format);
> > My 2 c,
> > --
> > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer

Thanks, Guiseppe. It also works properly.

Thanks, Allan.
So, there are two good ways from the API point of view.

When HTML from QTextEdit is retrieved by toHtml(), it generates HTML
with the correct line-height, i.e. 200% as in the example below:



It's properly treated by browsers, etc.

However, when saved to an html file and next loaded to QTextEdit,
line-height attribute inside  tag is ignored.
This page doesn't refer to line-height as to the supported attributes:
http://doc.qt.io/qt-5/richtext-html-subset.html#block-attributes

Is it correct to say that this is not a bug but rather an expected behavior,
and bug report is not required for this case?
Thanks.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[coroberti .]

On Mon, Nov 12, 2018 at 12:41 PM Giuseppe D'Angelo via Interest
 wrote:
>
> Il 11/11/18 17:15, coroberti . ha scritto:
> > Following Allan's advise, here's something that is starting to work
> > (checks omitted)
> >
> > QTextDocument* doc = this->text_edit_->document();
> > QTextBlock currentBlock = doc->firstBlock();
> >
> >  while (currentBlock.isValid()) {
> >
> >  QTextCursor cursor(currentBlock);
> >  QTextBlockFormat blockFormat = currentBlock.blockFormat();
> >  blockFormat.setLineHeight(200, 
> > QTextBlockFormat::ProportionalHeight);
> >  cursor.setBlockFormat(blockFormat);
> >
> >  currentBlock = currentBlock.next();
> >  }
> >
> > Thank you very much!
>
> Isn't it simpler to use a selection approach instead?
>
> QTextBlockFormat format;
> format.setLineHeight(...);
>
> QTextCursor cursor(textDocument);
> cursor.select(QTextCursor::Document);
> cursor.mergeBlockFormat(format);
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer

Dear Giuseppe,
Thank you for your suggestion.

I'll test it and let you and the list to know.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[coroberti .]

Kind regards,
Robert Iakobashvili


On Sun, Nov 11, 2018 at 5:29 PM coroberti .  wrote:
>
> On Sun, Nov 11, 2018 at 5:21 PM Allan Sandfeld Jensen  
> wrote:
> >
> > On Sonntag, 11. November 2018 16:13:12 CET coroberti . wrote:
> > > On Sun, Nov 11, 2018 at 5:06 PM Allan Sandfeld Jensen 
> > wrote:
> > > > On Sonntag, 11. November 2018 14:11:52 CET coroberti . wrote:
> > > > > Hi,
> > > > > It seems that arranging line spacing for text in QTextEdit (like 1.5,
> > > > > 2, 3 lines) is not an easy coding.
> > > > >
> > > > > Any code samples, directions, howtos would be very much appreciated.
> > > >
> > > > There is probably a way to get to the default or root QTextBlockFormat 
> > > > and
> > > > set lineHeight on it, but I couldn't spot the logical way from QTextEdit
> > > > either; but you can always just do it in CSS and set the CSS as the
> > > > default style- sheet on the document the QTextEdit is showing. Remember 
> > > > a
> > > > QTextEdit is basically showing HTML, so you can do it like you would in
> > > > HTML.
> > > >
> > > > 'Allan
> > >
> > > Hi Allan,
> > > Thanks, but It seems that only this HTML/CSS subset is supported:
> > >
> > > http://doc.qt.io/qt-5/richtext-html-subset.html
> > >
> > Right, line-height isn't mentioned there, but considering the C++ side of 
> > the
> > CSS implementation (QTextBlockFormat) has it, it might just have left out. I
> > would give it a shot.
> >
> > 'Allan
>
> Right. You mean to work with:
> http://doc.qt.io/qt-5/qtextblockformat.html#setLineHeight
> http://doc.qt.io/qt-5/qtextblockformat.html#LineHeightTypes-enum ->
> QTextBlockFormat::ProportionalHeight1This sets the spacing
> proportional to the line (in percentage). For example, set to 200 for
> double spacing.
> Thank you.
> Kind regards,
> Robert

Following Allan's advise, here's something that is starting to work
(checks omitted)

QTextDocument* doc = this->text_edit_->document();
QTextBlock currentBlock = doc->firstBlock();

while (currentBlock.isValid()) {

QTextCursor cursor(currentBlock);
QTextBlockFormat blockFormat = currentBlock.blockFormat();
blockFormat.setLineHeight(200, QTextBlockFormat::ProportionalHeight);
cursor.setBlockFormat(blockFormat);

currentBlock = currentBlock.next();
}

Thank you very much!
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[coroberti .]

On Sun, Nov 11, 2018 at 5:21 PM Allan Sandfeld Jensen  wrote:
>
> On Sonntag, 11. November 2018 16:13:12 CET coroberti . wrote:
> > On Sun, Nov 11, 2018 at 5:06 PM Allan Sandfeld Jensen 
> wrote:
> > > On Sonntag, 11. November 2018 14:11:52 CET coroberti . wrote:
> > > > Hi,
> > > > It seems that arranging line spacing for text in QTextEdit (like 1.5,
> > > > 2, 3 lines) is not an easy coding.
> > > >
> > > > Any code samples, directions, howtos would be very much appreciated.
> > >
> > > There is probably a way to get to the default or root QTextBlockFormat and
> > > set lineHeight on it, but I couldn't spot the logical way from QTextEdit
> > > either; but you can always just do it in CSS and set the CSS as the
> > > default style- sheet on the document the QTextEdit is showing. Remember a
> > > QTextEdit is basically showing HTML, so you can do it like you would in
> > > HTML.
> > >
> > > 'Allan
> >
> > Hi Allan,
> > Thanks, but It seems that only this HTML/CSS subset is supported:
> >
> > http://doc.qt.io/qt-5/richtext-html-subset.html
> >
> Right, line-height isn't mentioned there, but considering the C++ side of the
> CSS implementation (QTextBlockFormat) has it, it might just have left out. I
> would give it a shot.
>
> 'Allan

Right. You mean to work with:
http://doc.qt.io/qt-5/qtextblockformat.html#setLineHeight
http://doc.qt.io/qt-5/qtextblockformat.html#LineHeightTypes-enum ->
QTextBlockFormat::ProportionalHeight1This sets the spacing
proportional to the line (in percentage). For example, set to 200 for
double spacing.

Thank you.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[coroberti .]

On Sun, Nov 11, 2018 at 5:06 PM Allan Sandfeld Jensen  wrote:
>
> On Sonntag, 11. November 2018 14:11:52 CET coroberti . wrote:
> > Hi,
> > It seems that arranging line spacing for text in QTextEdit (like 1.5,
> > 2, 3 lines) is not an easy coding.
> >
> > Any code samples, directions, howtos would be very much appreciated.
> >
> There is probably a way to get to the default or root QTextBlockFormat and set
> lineHeight on it, but I couldn't spot the logical way from QTextEdit either;
> but you can always just do it in CSS and set the CSS as the default style-
> sheet on the document the QTextEdit is showing. Remember a QTextEdit is
> basically showing HTML, so you can do it like you would in HTML.
>
> 'Allan

Hi Allan,
Thanks, but It seems that only this HTML/CSS subset is supported:

http://doc.qt.io/qt-5/richtext-html-subset.html

Best regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QTextEdit - Line Spacing

[coroberti .]

Hi,
It seems that arranging line spacing for text in QTextEdit (like 1.5,
2, 3 lines) is not an easy coding.

Any code samples, directions, howtos would be very much appreciated.

Thanks in advance!

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.11.2 for Android Prebuilt- Crash in the First Non-Qt JNI

[coroberti .]

Dear Marcus,
Thank you very much!

Kind regards,
Robert Iakobashvili

On Mon, Nov 5, 2018 at 10:50 AM Markus Maier  wrote:
>
> Hi,
>
> I didn't look through your logs in detail, but the issue sounds like it might 
> be related to https://bugreports.qt.io/browse/QTBUG-68813 - I needed the 
> workaround from the end of the bug's description in order to get my JNI calls 
> working again. My code also works with Qt 5.9 and doesn't work with 5.11.2, 
> just like in this report.
>
> The workaround might however have some bad side effects, as mentioned by 
> Bogdan Vatra (the Qt for Android maintainer) in one of the comments - the 
> issue is unresolved ...
>
> Best regards
> Markus
>
>
> Am Do., 1. Nov. 2018 um 20:31 Uhr schrieb coroberti . :
>>
>> Hi,
>> I was trying to build my Qt widget app that is working on Android
>> since Qt 5.3, later 5.7 and 5.9
>> using downloaded offline Qt 5.11.2.
>>
>> Using Qt JNI seems to be working properly, like:
>> RequestPermissions =
>>
>> QAndroidJniObject("com/domain/myapp/permissions/RequestPermissions",
>>   "(Landroid/app/Activity;)V",
>>   
>> QtAndroid::androidActivity().object()
>>   );
>>
>> // Checking for errors in the JNI
>> QAndroidJniEnvironment env;
>> if (env->ExceptionCheck()) {
>> // Handle exception here.
>> env->ExceptionClear();
>> }
>>
>> Unfortunately, the very first non-Qt JNI in my app crashes it.
>> JNIEnv* env;
>> if (g_javaVM->AttachCurrentThread(, NULL)<0)
>> {
>> return false;
>> }
>> jboolean res = env->CallStaticBooleanMethod(s_sharingClassID,
>> s_sharingMyFuncMethodID);
>> g_javaVM->DetachCurrentThread();
>>
>> This is not something specific JNI, but really the first one non-Qt
>> JNI crashes it.
>>
>>
>> Is there any initialization or some magic in the new Qt JNI that could impact
>> non-Qt JNI?
>>
>> Should I detach thread manually after Qt JNI?
>>
>>
>> rt : art/runtime/runtime.cc:1537]
>> Thread[11,tid=6741,Native,Thread*=0xe4ab5f00,peer=0x12c11ee0,"qtMainLoopThread"]
>> attempting to detach while still running code
>> F art : art/runtime/runtime.cc:424] Runtime aborting...
>> F art : art/runtime/runtime.cc:424] Aborting thread:
>> F art : art/runtime/runtime.cc:424] "qtMainLoopThread" prio=5 tid=11 Native
>> F art : art/runtime/runtime.cc:424] | group="" sCount=0 dsCount=0
>> obj=0x12c11ee0 self=0xe4ab5f00
>> F art : art/runtime/runtime.cc:424] | sysTid=6741 nice=0 cgrp=default
>> sched=0/0 handle=0xf07bc920
>> F art : art/runtime/runtime.cc:424] | state=R schedstat=( 78120491
>> 95764296 62 ) utm=6 stm=1 core=0 HZ=100
>> F art : art/runtime/runtime.cc:424] | stack=0xf06ba000-0xf06bc000
>> stackSize=1038KB
>> F art : art/runtime/runtime.cc:424] | held mutexes= "abort lock"
>>
>> F art : art/runtime/runtime.cc:424] native: #00 pc 0058848e
>> /system/lib/libart.so
>> (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIciP12BacktraceMapPKcPNS_9ArtMethodEPv+238)
>> F art : art/runtime/runtime.cc:424] native: #01 pc 00553ebe
>> /system/lib/libart.so
>> (_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcbP12BacktraceMap+526)
>> F art : art/runtime/runtime.cc:424] native: #02 pc 00550ebb
>> /system/lib/libart.so
>> (_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcbP12BacktraceMap+75)
>> F art : art/runtime/runtime.cc:424] native: #03 pc 0053c8d3
>> /system/lib/libart.so
>> (_ZNK3art10AbortState10DumpThreadERNSt3__113basic_ostreamIcNS1_11char_traitsIcPNS_6ThreadE+67)
>> F art : art/runtime/runtime.cc:424] native: #04 pc 0053c6a7
>> /system/lib/libart.so
>> (_ZNK3art10AbortState4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIc+615)
>> F art : art/runtime/runtime.cc:424] native: #05 pc 0052cc0b
>> /system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+155)
>> F art : art/runtime/runtime.cc:424] native: #06 pc 0011def3
>> /system/lib/libart.so (_ZN3art10LogMessageD1Ev+1939)
>> F art : art/runtime/runtime.cc:424] native: #07 pc 0052c679
>> /system/lib/libart.so (_ZN3art7Runtime19DetachCurrentThreadEv+377)
>> F art : art/runtime/runtime.cc:424] native: #08 pc 003a1d85
>> /system/lib/libart.so (_ZN3art3JII19DetachCurrentThreadEP7_JavaVM+69)
>> F art : art/runti

[Interest] Qt 5.11.2 for Android Prebuilt- Crash in the First Non-Qt JNI

[coroberti .]

Hi,
I was trying to build my Qt widget app that is working on Android
since Qt 5.3, later 5.7 and 5.9
using downloaded offline Qt 5.11.2.

Using Qt JNI seems to be working properly, like:
RequestPermissions =

QAndroidJniObject("com/domain/myapp/permissions/RequestPermissions",
  "(Landroid/app/Activity;)V",
  QtAndroid::androidActivity().object()
  );

// Checking for errors in the JNI
QAndroidJniEnvironment env;
if (env->ExceptionCheck()) {
// Handle exception here.
env->ExceptionClear();
}

Unfortunately, the very first non-Qt JNI in my app crashes it.
JNIEnv* env;
if (g_javaVM->AttachCurrentThread(, NULL)<0)
{
return false;
}
jboolean res = env->CallStaticBooleanMethod(s_sharingClassID,
s_sharingMyFuncMethodID);
g_javaVM->DetachCurrentThread();

This is not something specific JNI, but really the first one non-Qt
JNI crashes it.


Is there any initialization or some magic in the new Qt JNI that could impact
non-Qt JNI?

Should I detach thread manually after Qt JNI?


rt : art/runtime/runtime.cc:1537]
Thread[11,tid=6741,Native,Thread*=0xe4ab5f00,peer=0x12c11ee0,"qtMainLoopThread"]
attempting to detach while still running code
F art : art/runtime/runtime.cc:424] Runtime aborting...
F art : art/runtime/runtime.cc:424] Aborting thread:
F art : art/runtime/runtime.cc:424] "qtMainLoopThread" prio=5 tid=11 Native
F art : art/runtime/runtime.cc:424] | group="" sCount=0 dsCount=0
obj=0x12c11ee0 self=0xe4ab5f00
F art : art/runtime/runtime.cc:424] | sysTid=6741 nice=0 cgrp=default
sched=0/0 handle=0xf07bc920
F art : art/runtime/runtime.cc:424] | state=R schedstat=( 78120491
95764296 62 ) utm=6 stm=1 core=0 HZ=100
F art : art/runtime/runtime.cc:424] | stack=0xf06ba000-0xf06bc000
stackSize=1038KB
F art : art/runtime/runtime.cc:424] | held mutexes= "abort lock"

F art : art/runtime/runtime.cc:424] native: #00 pc 0058848e
/system/lib/libart.so
(_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIciP12BacktraceMapPKcPNS_9ArtMethodEPv+238)
F art : art/runtime/runtime.cc:424] native: #01 pc 00553ebe
/system/lib/libart.so
(_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcbP12BacktraceMap+526)
F art : art/runtime/runtime.cc:424] native: #02 pc 00550ebb
/system/lib/libart.so
(_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcbP12BacktraceMap+75)
F art : art/runtime/runtime.cc:424] native: #03 pc 0053c8d3
/system/lib/libart.so
(_ZNK3art10AbortState10DumpThreadERNSt3__113basic_ostreamIcNS1_11char_traitsIcPNS_6ThreadE+67)
F art : art/runtime/runtime.cc:424] native: #04 pc 0053c6a7
/system/lib/libart.so
(_ZNK3art10AbortState4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIc+615)
F art : art/runtime/runtime.cc:424] native: #05 pc 0052cc0b
/system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+155)
F art : art/runtime/runtime.cc:424] native: #06 pc 0011def3
/system/lib/libart.so (_ZN3art10LogMessageD1Ev+1939)
F art : art/runtime/runtime.cc:424] native: #07 pc 0052c679
/system/lib/libart.so (_ZN3art7Runtime19DetachCurrentThreadEv+377)
F art : art/runtime/runtime.cc:424] native: #08 pc 003a1d85
/system/lib/libart.so (_ZN3art3JII19DetachCurrentThreadEP7_JavaVM+69)
F art : art/runtime/runtime.cc:424] native: #09 pc 0013572d
/data/app/com.domain.myapplication-2/lib/x86/libMyapplication.so
(_ZN14AndroidSharing12isMyFuncEv+109)
F art : art/runtime/runtime.cc:424] native: #10 pc 00099f30
/data/app/com.domain.myapplication-2/lib/x86/libMyapplication.so
(_ZN12GPreferences19check_if_myfuncEv+48)
F art : art/runtime/runtime.cc:424] native: #11 pc 00074d09
/data/app/com.domain.myapplication-2/lib/x86/libMyapplication.so
(_ZN8TextEditC1EP7QWidget+2377)
F art : art/runtime/runtime.cc:424] native: #12 pc 00051b7b
/data/app/com.domain.myapplication-2/lib/x86/libMyapplication.so
(main+747)
F art : art/runtime/runtime.cc:424] at
org.qtproject.qt5.android.QtNative$6.run(QtNative.java:359)
F art : art/runtime/runtime.cc:424] at
org.qtproject.qt5.android.QtThread$1.run(QtThread.java:61)
F art : art/runtime/runtime.cc:424] at java.lang.Thread.run(Thread.java:761)
F art : art/runtime/runtime.cc:424] Dumping all threads without
appropriate locks held: thread list lock mutator lock
F art : art/runtime/runtime.cc:424] All threads:

F art : art/runtime/runtime.cc:424] DALVIK THREADS (14):

F art : art/runtime/runtime.cc:424] "qtMainLoopThread" prio=5 tid=11 Runnable
F art : art/runtime/runtime.cc:424] | sysTid=6741 nice=0 cgrp=default
sched=0/0 handle=0xf07bc920
F art : art/runtime/runtime.cc:424] | state=R schedstat=( 92273427
100558772 70 ) utm=6 stm=2 core=0 HZ=100
F art : art/runtime/runtime.cc:424] | stack=0xf06ba000-0xf06bc000
stackSize=1038KB
F art : art/runtime/runtime.cc:424] | held mutexes= "abort lock"
"mutator lock"(shared held)

F art : art/runtime/runtime.cc:424] native: #00 pc 0058848e

Re: [Interest] Crash in iOS 12 when Accessibility is ON

[coroberti .]

Hi Philippe,
On windows, I've made a custom menu based on QWidgets.

On iOS, I've integrated native Popovers with UITableViewController
inside to serve as menus.
It adds more native look and feel.

Take care.

Kind regards,
Robert Iakobashvili

On Fri, Oct 26, 2018 at 4:47 PM maitai  wrote:
>
> Hi,
> Tried to put all I could think (tooltip, statustip, etc), no luck.
> I will go the hard way, using a custom class derived from both QAction
> and QAccessible...
>
> Philippe.
>
> Le 26-10-2018 10:34, coroberti . a écrit :
> > Hi Philippe,
> > What I've seen recently on Windows,
> > QAction is not supporting platform accessibility unlike QWidget
> > derivatives.
> >
> > There are two paths to go there:
> > 1. To make some derivative of QAction and implement QAccessible;
> > 2. To make a custom menu from QWidget derivatives.
> >
> > Prior to going there, try to set whatever text options in QAction you
> > have
> > like text, toolTip, etc.
> >
> > Kind regards,
> > Robert Iakobashvili
> > 
> > On Fri, Oct 26, 2018 at 11:09 AM maitai 
> > wrote:
> >>
> >> Hi Robert,
> >> Thanks for the support.
> >> Backtrace is joined, as seen from xcode.
> >>
> >> Philippe.
> >>
> >> Le 26-10-2018 09:27, coroberti . a écrit :
> >> > Hi Philippe,
> >> > Just voted for it.
> >> >
> >> > If you run the app from debugger and trigger the menu's action to
> >> > reproduce,
> >> > which backtrace stack of functions you see there?
> >> >
> >> > Kind regards,
> >> > Robert Iakobashvili
> >> > 
> >> > On Fri, Oct 26, 2018 at 10:01 AM maitai 
> >> > wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >> There has been already 2 bug reports for that (QTBUG-70909 and
> >> >> QTBUG-70683), but it is not yet fixed and I am looking for a
> >> >> workaround,
> >> >> since lot of my users are complaining.
> >> >>
> >> >> To make a long story short, iOS 12 is crashing in UIAccessibility
> >> >> _axuiElementForNotificationData when for instance Speak Screen is ON.
> >> >> This is because Qt doesn't check that the list of Accessibility items
> >> >> is
> >> >> empty, as I understood.
> >> >>
> >> >> A workaround has been proposed, which consists in putting a non empty
> >> >> title to the main window. That is indeed OK for a QML application, but
> >> >> our app is still pure QWidget-based. Putting a title in MainWindow
> >> >> duly
> >> >> fixed the crash at startup, but now it only crashes later, whenever
> >> >> the
> >> >> user triggers a QAction from a QMenu. It crashes at the same place in
> >> >> UIAccessibility.
> >> >>
> >> >> I have tried many things with no success, including:
> >> >> - Add some setAccessibilityName etc in some relevant objects,
> >> >> - In qappdelegate settings some flags supposed to ignore
> >> >> Accessibility,
> >> >> such as [aView setIsAccessibilityElement:NO]; and [aView
> >> >> accessibilityElementsHidden:YES];
> >> >> - I even tried to override some QIOS functions but did not succeed.
> >> >>
> >> >> Someone suggested to just add a dummy Accessibility item, so the list
> >> >> won't be empty. I have no idea how to do that.
> >> >>
> >> >> I have of course tried 5.9.7 and 5.11.2, no luck.
> >> >>
> >> >> If someone has some advices or ideas...
> >> >>
> >> >> Thanks
> >> >> Philippe Lelong
> >> >> ___
> >> >> Interest mailing list
> >> >> Interest@qt-project.org
> >> >> http://lists.qt-project.org/mailman/listinfo/interest___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Crash in iOS 12 when Accessibility is ON

[coroberti .]

Hi Philippe,
What I've seen recently on Windows,
QAction is not supporting platform accessibility unlike QWidget derivatives.

There are two paths to go there:
1. To make some derivative of QAction and implement QAccessible;
2. To make a custom menu from QWidget derivatives.

Prior to going there, try to set whatever text options in QAction you have
like text, toolTip, etc.

Kind regards,
Robert Iakobashvili

On Fri, Oct 26, 2018 at 11:09 AM maitai  wrote:
>
> Hi Robert,
> Thanks for the support.
> Backtrace is joined, as seen from xcode.
>
> Philippe.
>
> Le 26-10-2018 09:27, coroberti . a écrit :
> > Hi Philippe,
> > Just voted for it.
> >
> > If you run the app from debugger and trigger the menu's action to
> > reproduce,
> > which backtrace stack of functions you see there?
> >
> > Kind regards,
> > Robert Iakobashvili
> > 
> > On Fri, Oct 26, 2018 at 10:01 AM maitai 
> > wrote:
> >>
> >> Hello,
> >>
> >> There has been already 2 bug reports for that (QTBUG-70909 and
> >> QTBUG-70683), but it is not yet fixed and I am looking for a
> >> workaround,
> >> since lot of my users are complaining.
> >>
> >> To make a long story short, iOS 12 is crashing in UIAccessibility
> >> _axuiElementForNotificationData when for instance Speak Screen is ON.
> >> This is because Qt doesn't check that the list of Accessibility items
> >> is
> >> empty, as I understood.
> >>
> >> A workaround has been proposed, which consists in putting a non empty
> >> title to the main window. That is indeed OK for a QML application, but
> >> our app is still pure QWidget-based. Putting a title in MainWindow
> >> duly
> >> fixed the crash at startup, but now it only crashes later, whenever
> >> the
> >> user triggers a QAction from a QMenu. It crashes at the same place in
> >> UIAccessibility.
> >>
> >> I have tried many things with no success, including:
> >> - Add some setAccessibilityName etc in some relevant objects,
> >> - In qappdelegate settings some flags supposed to ignore
> >> Accessibility,
> >> such as [aView setIsAccessibilityElement:NO]; and [aView
> >> accessibilityElementsHidden:YES];
> >> - I even tried to override some QIOS functions but did not succeed.
> >>
> >> Someone suggested to just add a dummy Accessibility item, so the list
> >> won't be empty. I have no idea how to do that.
> >>
> >> I have of course tried 5.9.7 and 5.11.2, no luck.
> >>
> >> If someone has some advices or ideas...
> >>
> >> Thanks
> >> Philippe Lelong
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Crash in iOS 12 when Accessibility is ON

[coroberti .]

Hi Philippe,
Just voted for it.

If you run the app from debugger and trigger the menu's action to reproduce,
which backtrace stack of functions you see there?

Kind regards,
Robert Iakobashvili

On Fri, Oct 26, 2018 at 10:01 AM maitai  wrote:
>
> Hello,
>
> There has been already 2 bug reports for that (QTBUG-70909 and
> QTBUG-70683), but it is not yet fixed and I am looking for a workaround,
> since lot of my users are complaining.
>
> To make a long story short, iOS 12 is crashing in UIAccessibility
> _axuiElementForNotificationData when for instance Speak Screen is ON.
> This is because Qt doesn't check that the list of Accessibility items is
> empty, as I understood.
>
> A workaround has been proposed, which consists in putting a non empty
> title to the main window. That is indeed OK for a QML application, but
> our app is still pure QWidget-based. Putting a title in MainWindow duly
> fixed the crash at startup, but now it only crashes later, whenever the
> user triggers a QAction from a QMenu. It crashes at the same place in
> UIAccessibility.
>
> I have tried many things with no success, including:
> - Add some setAccessibilityName etc in some relevant objects,
> - In qappdelegate settings some flags supposed to ignore Accessibility,
> such as [aView setIsAccessibilityElement:NO]; and [aView
> accessibilityElementsHidden:YES];
> - I even tried to override some QIOS functions but did not succeed.
>
> Someone suggested to just add a dummy Accessibility item, so the list
> won't be empty. I have no idea how to do that.
>
> I have of course tried 5.9.7 and 5.11.2, no luck.
>
> If someone has some advices or ideas...
>
> Thanks
> Philippe Lelong
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt Commits - Where to Find the Patches by Commit-Id

[coroberti .]

On Sun, Oct 21, 2018 at 1:06 AM Thiago Macieira
 wrote:
>
> On Saturday, 20 October 2018 10:16:56 PDT coroberti . wrote:
> > 5be48d4238465b4efd36ed4bbb96ec407be9f217
> >
> > Where I can find the patch by the commit-id.
> >
> > Qt Codereview seems to be the place but without search by commit-id.
> > https://codereview.qt-project.org/#/q/status:open,n,z
>
> That's what that big search field on the top left is for. Just paste the
> commit SHA1 there and press enter.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center

Thanks, it works.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt Commits - Where to Find the Patches by Commit-Id

[coroberti .]

Thanks, people.

Kind regards,
Robert Iakobashvili


On Sat, Oct 20, 2018 at 9:32 PM Elvis Stansvik  wrote:
>
> Den lör 20 okt. 2018 kl 20:29 skrev Elvis Stansvik :
> >
> > Den lör 20 okt. 2018 kl 19:19 skrev coroberti . :
> > >
> > > Hi,
> > > The bug report https://bugreports.qt.io/browse/QTBUG-69281
> > > refers to commit:
> > >
> > > 5be48d4238465b4efd36ed4bbb96ec407be9f217
> > >
> > > Where I can find the patch by the commit-id.
> >
> > git show 5be48d4238465b4efd36ed4bbb96ec407be9f217 ?
> >
> > Just kidding :) If you don't have a Git clone of the repo locally, you
> > can use code.qt.io:
> >
> > 
> > http://code.qt.io/cgit/qt/qtwebengine.git/commit/?id=5be48d4238465b4efd36ed4bbb96ec407be9f217
> >
> > >
> > > Qt Codereview seems to be the place but without search by commit-id.
> > > https://codereview.qt-project.org/#/q/status:open,n,z
> > >
> > > Another question is whether Qt-5.11.3 branch exists?
> >
> > The 5.11 branch is at:
> >
> > http://code.qt.io/cgit/qt/qtbase.git/log/?h=5.11
> >
> > There's no v5.11.3 tag yet, if that's what you mean (see
> > http://code.qt.io/cgit/qt/qtbase.git/refs/tags).
>
> (Those two links were for qtbase, but there are similar ones for
> qtwebengine.git.)
>
> >
> > Cheers,
> > Elvis
> >
> > >
> > > Thanks in advance.
> > >
> > > Kind regards,
> > > Robert Iakobashvili
> > > 
> > > ___
> > > Interest mailing list
> > > Interest@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Qt Commits - Where to Find the Patches by Commit-Id

[coroberti .]

Hi,
The bug report https://bugreports.qt.io/browse/QTBUG-69281
refers to commit:

5be48d4238465b4efd36ed4bbb96ec407be9f217

Where I can find the patch by the commit-id.

Qt Codereview seems to be the place but without search by commit-id.
https://codereview.qt-project.org/#/q/status:open,n,z

Another question is whether Qt-5.11.3 branch exists?

Thanks in advance.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Android] Qt machine unique id

[coroberti .]

On Wed, Oct 10, 2018 at 10:53 PM Thiago Macieira
 wrote:
>
> On Wednesday, 10 October 2018 07:00:13 PDT Igor Mironchik wrote:
> > Maybe MAC address of the network interface is good enough for you?
>
> There are some RFCs and internet drafts that recommend creating random or
> pseudo-random MAC addresses, for privacy. In other words, the MAC address
> would change depending on which network you're connected to and often which
> day it is.
>
> I do that for my Linux system for WiFi. Windows 10 has this feature too, but I
> don't remember if it's enabled by default.
>
> https://www.ietf.org/blog/mac-privacy/
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center

MAC-randomization commonly means that per network (SSID) a MAC address
to be generated and used based on the machine's interface MAC (HW MAC) for
a certain connection and next changed not to be recognized by this network.

However, that doesn't mean that the implementation with overwrite the HW MAC
seen by commands and API. There's no need for that.

This links tells about one such linux distribution, but it seems that
there are no more such cases:
http://papers.mathyvanhoef.com/asiaccs2016.pdf

Are you familiar with any other cases?

There are cases when user with enough privileges can overwrite HW MAC,
and so Qt's way seems to be doing a great job by using other
parameters, not MACs.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Simple device discovery using UDP

[coroberti .]

On Tue, Oct 2, 2018 at 5:02 PM Murphy, Sean  wrote:
>
> > I have an app (Desktop) that I want it to know about other running instances
> > on the local network. I figured UDP broadcast was a natural choice. I tried 
> > it,
> > but I never saw anything but my own (local) packets. There's quite a few
> > stackoverflow questions, but none used Qt. I'm wondering if it's a 
> > wifi/router
> > thing?
>
> A couple of first questions:
> - do you have any sort of firewalls running anywhere?
> - have you tried the Qt Networks examples, and do those work?
>   http://doc.qt.io/qt-5/qtexamples.html#qt-network, maybe the Broadcast
>   Sender & Receiver examples
>
> Sean
>
Hi,
1. As Sean has mentioned, firewall settings that do not allow broadcasts
could be the case.

2. Yet another case could be: QHostAddress::Broadcast.
It's so-called All-Networks-Broadcast (255.255.255.255)
and normally requires alleviated privileges to send to (UNIX root, suid)
and could be guarded.

There's another broadcast address - so-called LAN-broadcast
which is less sensitive and more appropriate for broadcasting.

For example, at network 10.31.4.0/24, it will be 10.31.4.255,
and you can find various rules to calculate it.

3. Instead of using a broadcast address, you can figure our all
addresses on this network
and send unicast requests except to the subnet broadcast address .
At most networks, it will be sending to up to 253 address, whereas
rarely it could come to higher numbers.

Take care,

Kind regards,
Robert

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Vote for Windows 32-Bit Binaries for MSVC-2017

[coroberti .]

Hi,
Please, consider voting for:

https://bugreports.qt.io/browse/QTBUG-63708

Note, that if somebody wants to build Qt for 32-bit MSVC-2017 by
himself/herself,
cross compiler to be used since Qt-5.11 and up in line with the tips in:

https://bugreports.qt.io/browse/QTBUG-68462

Note, that since Qt-5.11, there's no option to build WebEngine with
any other compiler below  MSVC-2017.

IMHO, 32-bit Windows at Win-7 is still a mainstream, at least for the
nearest 4 years
till MS provides Windows 7 Extended Security Updates (ESU) through January 2023:

https://www.microsoft.com/en-us/microsoft-365/blog/2018/09/06/helping-customers-shift-to-a-modern-desktop/

Thanks.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] IFW issue: HTTP request returns a Not Acceptable

[coroberti .]

On Tue, Sep 18, 2018 at 5:28 PM, Kevin  wrote:
>
> Thanks for all the responses
>
> My guess is the "?-915259074 " part of the url is what makes the server fail.
>
> To prevent caching, you may wish instead to add header:
> Cache-Control: no-store
>
> For the above suggestions, how do I do that through the IFW? Are there 
> config.xml parameters that I missed?

Hi, Kevin,

It should be fixed by the tool maintainers.
Remove "?-915259074"  and
add instead HTTP headers:
Cache-Control: no-store
Cache-Control: no-cache, private

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] IFW issue: HTTP request returns a Not Acceptable

[coroberti .]

On Tue, Sep 18, 2018 at 9:59 AM, Kai Koehne  wrote:
>
>
>> -Original Message-
>> From: Interest  On
>> Behalf Of Kevin Wang
>> Sent: Tuesday, September 18, 2018 1:33 AM
>> To: Qt Project 
>> Subject: [Interest] IFW issue: HTTP request returns a Not Acceptable
>>
>> Hi All,
>>
>>
>> I am attempting to utilize the Qt Installer Framework for our company's
>> software. I am just starting out and am running into some issues.
>>
>> I uploaded the generated repo to our website, and linked the repo in the
>> installer. When I run the installer and attempt to fetch the remote repo 
>> tree,
>> it returns this:
>>
>>
>>   "Cannot retrieve remote tree. "
>> [...]
>> I sniffed out the HTTP request and it showed that the IFW sent this:
>>   GET /downloads/onlinesoftwarerepo/Updates.xml?-915259074
>> HTTP/1.1
>>   Connection: Keep-Alive
>>   Accept-Encoding: gzip, deflate
>>   Accept-Language: en-US,*
>>   User-Agent: Mozilla/5.0
>>   Host: www.spikegadgets.com 
>>
>> So I have absolutely no experience in web servers and HTTP requests and
>> such. The website and FTP was set up for us, which I used to upload the repo.
>> To me, the issue seems to be that the Installer framework is sending a HTTP
>> request for an encoding that doesn't make sense ("Accept-Encoding: gzip,
>> deflate" for a .xml file?).
>
> An xml file can be compressed , too  Accept-Encoding is just a hint
> to the server which compression the client accepts, and the server is free to
> ignore it. So I doubt that's the issue.
>
> My guess is the "?-915259074 " part of the url is what makes the server fail.
> IIRC this was added to the request in IRC to work around some caching issues,
>  but should be ignored by the server. Maybe that doesn't work for yours.
>
> Regards
>
> Kai

Hi,
To prevent caching, you may wish instead to add header:
Cache-Control: no-store

It should be enough, but you can add also:
Cache-Control: no-cache, private

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Linux openssl 1.1.0 versus 1.0.X

[coroberti .]

On Sun, Sep 16, 2018 at 7:45 AM, maitai  wrote:
> Thanks all for your replies
>
> Another idea:
>
> Do you know if it is enough to change Qt5Network librarie, which I
> distribute together with the app?
>
> And if yes any chance to find it built against ssl 1.1.0 without having to
> recompile the whole qt once more?
>
> Philippe.
>

Hi Philippe,
On Linux you can deliver openssl-1.0 just by yourself by linking it statically.
The cons of that are that from time-to-time you may wish to deliver
security updates.

Take care.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Standardizing Qt Kit Names

[coroberti .]

On Thu, Aug 30, 2018 at 10:14 AM, Tomasz Siekierda  wrote:
> On Wed, 29 Aug 2018 at 20:17, André Pönitz  wrote:
>>
>> On Wed, Aug 29, 2018 at 06:27:57PM +0200, Jason H wrote:
>> > It might be a minor point, but I think it would be good to have more 
>> > uniform kit name structure.
>>
>
> +1
>
> I'd also suggest keeping these names as consise as possible. For
> example, I don't see a need to keep "Qt" in kit name... I know it is
> Qt, no need to mention that. So "5.10.1 Desktop MinGW" should be
> enough.

Jason, it's a very good idea.
Tomacz, this is a helpful as well.

+2

Thanks.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QTreeWidget displays blank widget

[coroberti .]

Hi,
Try for your widgets to call

setAutoFillBackground(true);


Kind regards,
Robert


On Thu, Aug 9, 2018 at 5:58 PM, Nicolas Krieger
 wrote:
> Hello
>
> I would like to display colored widgets in a QTreeWidget.
>
> Screenshots of what I really have are in attached files.
>
> My wigdet is colored, but when in the QTreeWidget, it is all white. How can
> I resolve it?
>
> --
> Nicolas Krieger
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 5.11.1 link error with OpenSSL (Windows)

[coroberti .]

On Fri, Jul 27, 2018 at 12:56 AM, Bob Hood  wrote:
> I'm trying three different versions of OpenSSL -- 1.0.2l, 1.0.2o, 1.1.0h --
> and none of them will link correctly with Qt 5.11.1.  The "known issues"
> wiki page[1] indicates something with Linux that suggests installing an
> older version of OpenSSL (specifically, 1.0 is mentioned).  Would this also
> apply to Windows as well?  It's not explicitly mentioned in these issues.
>

Dear Bob,
I can confirm that successfully configured and built 5.11.1 on Windows
for both 32 and 64 bit builds.
It was configured against opensssl-1.1.0h as a shared linking
and requires the dlls to be either placed to the same folder as exe
or to be in the PATH in run-time.

Nothing that I can tell about linux, but it seems that only openssl
1.1 is supposed
to be supported.

Take care.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt-5.11.0 - QtWebEngine Compilation Broken for Windows 32-bit Builds

[coroberti .]

On Thu, Jul 5, 2018 at 12:01 PM, Alexandru Croitor
 wrote:
>> On 4. Jul 2018, at 18:59, coroberti .  wrote:
>> 1. Using the cross compiler and running in MSVC prompt:
>>
>> "C:\Program Files (x86)\Microsoft Visual
>> Studio\2017\Community\VC\Auxiliary\Build\vcvarsamd64_x86.bat"
>>
>> 2. Configuring qt-5.11.1 as:
>>
>> configure -prefix C:\\Users\\robert\\dev\\qt-5.11.1-webeng-build
>> -shared -opensource -platform win32-msvc -nomake tests -nomake
>> examples -skip qt3d -skip qtactiveqt -skip qtcanvas3d -skip
>> qtconnectivity -skip qtdatavis3d -skip qtlocation -skip qtmultimedia
>> -skip qtscript -skip qtsensors -skip qtserialport -skip qttranslations
>> -no-opengl -no-openvg -qt-zlib -qt-libpng -qt-libjpeg -no-avx -no-avx2
>> -openssl -I C:\Users\robert\dev\OpenSSLShared\include -L
>> C:\Users\robert\dev\OpenSSLShared\lib
>>
>>
>> 3. Running nmake.
>>
>> All compilation of qt including qtwebengine passes properly (with nmake /I)
>>
>> but with compilation error at one module that seems to be dependent on 
>> openGL?
>>
>> See the below:
>>
>> C:/Users/robert/dev/qt-src-5.11.1/qtwebengine/src/core/web_engine_context.cpp(190):
>> error C2027: use of undefined type 'QOpenGLCon
>> text'
>> c:\users\robert\dev\qt-src-5.11.1\qtbase\include\qtgui\5.11.1\qtgui\qpa\../../../../../src/gui/kernel/qplatformnativeinterface.h(6
>> 0): note: see declaration of 'QOpenGLContext'
>> C:/Users/robert/dev/qt-src-5.11.1/qtwebengine/src/core/web_engine_context.cpp(190):
>> error C3861: 'openGLModuleHandle': identifier not found
>>
>>
>> Is it correct to say that qtwebengine cannot be compiled without
>> openGL or this is some additional bug in Qt?
>>
>> Thanks in advance!
>>
>> Kind regards,
>> Robert
>>
>>


> I believe that building webengine without opengl has regressed a few times, 
> so it's plausible that it could happen.

Dear Alexandru,
Thank you for your reply.

Yes, correct.

The procedure of Kai using cross-compilation 64-for-32 works when adding
opengl -dynamic.

It was also mentioned by Thiago in the bug-report as a suggestion.

And yes, building of Qt-5.11.1 with -no-opengl is once more broken on
windows in webengine.

Thanks once more to you and Thiago.

Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt Network Authorization example redirect URI

[coroberti .]

Hi Tom,
The example was not working with me as well.
Sorry, I had no time to dig in.
Kind regards,
Robert


On Sun, Jun 3, 2018 at 6:37 AM, Tom Isaacson via Interest
 wrote:
> I'm still trying to get this to work. I've added some debugging to try and 
> figure out what's happening:
> RedditWrapper::grant()+
> setModifyParametersFunction(): stage = RequestingAuthorization
> RedditWrapper::grant()-
> statusChanged(): status = TemporaryCredentialsReceived
> setModifyParametersFunction(): stage = RequestingAccessToken
> qt.networkauth.oauth2: Unexpected call
>
> Has anyone got this to work? I'm wondering if Reddit have changed something 
> since this example was published.
>
> Tom Isaacson
>
> -Original Message-
> From: Interest  On 
> Behalf Of Tom Isaacson via Interest
> Sent: Sunday, 27 May 2018 20:23
> To: Michael Corcoran ; Interest@qt-project.org
> Subject: Re: [Interest] Qt Network Authorization example redirect URI
>
> Ah, that was it! But the app still isn't displaying any data and I get the 
> error:
> qt.networkauth.oauth2: Unexpected call
>
> Tom Isaacson
>
> From: Michael Corcoran 
> Sent: Sunday, 27 May 2018 15:11
> To: Tom Isaacson via Interest ; Tom Isaacson 
> 
> Subject: Re: Qt Network Authorization example redirect URI
>
> I believe you need OpenSSL 1.0.x. 1.1 API is not compatible with 1.0 at all 
> [1].
>
> Mike
>
> [1] https://www.mail-archive.com/tech@openbsd.org/msg36437.html
> https://www.mail-archive.com/tech@openbsd.org/msg36437.html
> As many of you will already be aware, the OpenSSL 1.1.0 release intentionally 
> introduced significant API changes from the previous release[0][1]. In 
> summary, a large number of data structures that were previously publically 
> visible have been made opaque, with accessor functions being added in order 
> ...
> http://www.mail-archive.com
>
> 
> From: Interest 
>  on 
> behalf of Tom Isaacson via Interest 
> Sent: Sunday, 27 May 2018 2:03 p.m.
> To: mailto:Interest@qt-project.org
> Subject: Re: [Interest] Qt Network Authorization example redirect URI
>
> Finally realised it's http://localhost:1337/ so Reddit is accepting the 
> request now, but the app is printing SSL errors:
> qt.networkauth.oauth2: Unexpected call
> qt.network.ssl: QSslSocket: cannot call unresolved function 
> SSLv23_client_method
> qt.network.ssl: QSslSocket: cannot call unresolved function SSL_CTX_new
> qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init
> qt.network.ssl: QSslSocket: cannot call unresolved function ERR_get_error
> qt.network.ssl: QSslSocket: cannot call unresolved function ERR_get_error
> qt.networkauth.replyhandler: Error creating SSL context ()
>
> I'm using Qt 5.10.1 MSVC2017 64bit so I downloaded Win64 OpenSSL v1.1.0h from:
> https://slproweb.com/products/Win32OpenSSL.html
> and added C:\OpenSSL-Win64\bin to PATH but it's still not working. Is there a 
> particular version of OpenSSL I need or does Qt Creator need to be told where 
> it is?
>
>
> Tom Isaacson
>
> -Original Message-
> From: Interest 
>  On Behalf Of 
> Tom Isaacson via Interest
> Sent: Sunday, 27 May 2018 12:21
> To: mailto:Interest@qt-project.org
> Subject: [Interest] Qt Network Authorization example redirect URI
>
> I've installed Qt 5.10.1 and I'm trying to get the Reddit example for Qt 
> Network Authorization to work:
> https://doc.qt.io/archives/qt-5.10/qtnetworkauth-redditclient-example.html
>
> The instructions tell you to go to https://www.reddit.com/prefs/apps and get 
> a consumer key. I created an app called QtNetworkAuthProject and set the 
> redirect URI to http://localhost:8080/cb as suggested here:
> http://blog.qt.io/blog/2017/01/25/connecting-qt-application-google-services-using-oauth-2-0/
>
> But when I run the app Reddit says "invalid redirect_uri parameter". 
> Apparently this can also be because the redirect URI is wrong:
> https://stackoverflow.com/questions/18472733/invalid-redirect-uri-parameter-for-reddit-api
>
> This answer suggests the blog post is out of date and it should be 
> http://localhost:8080/ but that fails as well:
> https://stackoverflow.com/a/48498861/264822
>
> Does anyone know what the correct setting is? Also, someone should really 
> update the example to explain this better!
>
> Thanks.
>
> Tom Isaacson
>
> ___
> Interest mailing list
> mailto:Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> mailto:Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
> 

[Interest] Qt-5.11.0 - QtWebEngine Compilation Broken for Windows 32-bit Builds

[coroberti .]

Hi,
Trying to compile the recently released Qt-5.11.0 for 32-bit Windows (x86),
everything compiles fine except QtWebEngine where build is broken.

It seems that MSVC-2017 is the only compiler for QtWebEngine sing 5.11,
and theoretically 32-builds are supposed to be supported.

The bug report is here:
https://bugreports.qt.io/browse/QTBUG-68462

Please, vote there and/or provide your solutions/workarounds.

Thanks.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Code contributions via bug reports and forum posts

[coroberti .]

Hi,
This is a very positive and long anticipated development.

Excellent!

Kind regards,
Robert


On Wed, May 16, 2018 at 12:20 PM, Tuukka Turunen  wrote:
>
>
> Hi,
>
>
>
> Contribution of source code is now allowed via Qt systems such as bug
> reports and forums. Traditionally all source code contributions to the Qt
> Project are governed via Contribution License Agreement (CLA), except
> possibility given to the commercial license holders to provide bug fixes and
> similar small modifications that The Qt Company has pushed into Qt. We have
> now updated the Qt Account service terms to more clearly state that source
> code can be contributed via the Qt systems. The preferred way to contribute
> source code to the Qt Project is still via the CLA, according to the
> contribution guidelines. But sometimes a user who has not accepted the CLA
> has a patch that would, for example, fix a bug in Qt. Providing such a patch
> is now also possible via the Qt systems, for example via the bug reports or
> forum posts.
>
>
>
> Please check a blog post for more information:
> http://blog.qt.io/blog/2018/05/16/code-contributions-via-bug-reports-forum-posts/
>
>
>
> Note that any existing source code in the systems is not covered, only items
> pushed from now on.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to debug QNetworkReply? It never finishes!

[coroberti .]

Hi Tomek,
It was a similar case in my setup.

It appeared, though, that I was 2 connections and deleting the first
conn before getting reply.

If you are using the same connection, check that your server supports
pipe-lining.
You need somehow to manage QNetworkReply/s - perhaps 2 different objects.

Kind regards,
Robert


On Tue, Feb 27, 2018 at 10:44 AM, Tomasz Olszak  wrote:
> Hello,
>
> I faced strange issue.Probably important information"
> 1. I send 2 GET request in short delay between them (a few ms). Request have
> the same URL (including GET variables). They are connecting to remote HTTPS
> nginx server
> 2. I save both replies from QNAM in internal cache and when the latter reply
> is finished I print information about first one. First one is running, not
> finished, no error. There is no signal emitted from first reply (like
> encrypted, metadataChanged etc), those signal are emitted from second reply
> though.
>
> Anyone has an idea what could happen and how to debug it?
>
> Thanks in Advance,
> Tomek
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [iOS][macOS] Application Extension support to Qt

[coroberti .]

On Mon, Feb 26, 2018 at 3:47 PM, ekke  wrote:
>
> +1 to add support for App Extensions
>
> need this in some Apps for "Share Extensions" to share Text etc from
> other Apps
> this is a common feature since iOS 8 and customers expect to have this
> also in mobile Apps build with Qt
>
> ekke
>
>
> Am 26.02.18 um 13:49 schrieb Nuno Santos:
> > Hi,
> >
> > Does anyone knows if this will be something on Qt Roadmap for a near
> > future?
> >
> > [iOS][macOS] Application Extension support to Qt
> > -> https://bugreports.qt.io/browse/QTBUG-40101
> >
> > I’m building music apps with Qt and right now I can’t have AUv3
> > support (the ability to use the same app as a another app plugin). Not
> > being able to do this leaves me with the hands tied.
> >
> > Thx
> > Regards,
> > Nuno

Hi,

Indeed, I made an extension two years ago and had no choice
but to re-write all GUI in Swift instead of Qt-GUI.

+1

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest