Re: [Interest] SVG is loaded with invalid dimensions on some machines

[Elvis Stansvik]

Den tors 18 apr. 2024 17:11Alexander Dyagilev  skrev:

> Well, I was able to reproduce the issue.
> 1. Launch app.
> 2. Change system zoom settings from 100% to 125%.
> 3. Done. The issue is here. After restarting app - issue is not
> reproduced.
> So, just a guess, on 2-monitor system this zoom settings changes at
> runtime (maybe app is started initially on some monitor and then moves to
> another one with different zoom setting).
> *Question is*: is it possible to disable this auto-zoom thing for a
> particular image or at least globally?
>

I dont think so. You need to query the device pixel ratio of the screen
your widget is currently displayed on and re-rasterize your SVG to the
appropriate pixel dimensions. You also need to listen for events indicating
a change in device pixel ratio (i.e. user changing their system
preferences) and indicating your widget was moved to another monitor where
the ratio is different, and do the same if that happens. At least that's my
understanding.

We do the same in our app in places where we paint in physical pixels and i
think this is par for the course for DPI-aware Qt applications.

I could be wrong.

Elvis


> On Thu, Apr 18, 2024 at 9:52 PM Alexander Dyagilev 
> wrote:
>
>> Hello,
>>
>> The user with the issue has two monitors connected to his PC. *Weird
>> thing* is that SVG is loaded properly on one monitor (2K) and improperly
>> on another one (FullHD). How can this be? Only Qt authors can probably shed
>> some light on this issue :)
>>
>>
>> On Thu, Apr 18, 2024 at 11:24 AM Alexander Dyagilev 
>> wrote:
>>
>>> Image as it's displayed on the user's machine:
>>>
>>> [image: image.png]
>>>
>>>
>>> On Thu, Apr 18, 2024 at 11:21 AM Alexander Dyagilev 
>>> wrote:
>>>
 I forgot to mention that this happens at least with Qt 6.4.3 and 6.6.2
 (or 6.6.3 I don't remember exactly). We use this code to load the image:

 import QtQuick 2.12

 Image
 {
 property double zoom: 1.0

 readonly property int preferredWidth: sameHiddenImg.implicitWidth *
 zoom
 readonly property int preferredHeight: sameHiddenImg.implicitHeight
 * zoom

 // it works buggy under e.g. Retina displays without this
 width: preferredWidth
 height: preferredHeight

 // it works buggy under e.g. Retina displays without this
 sourceSize: Qt.size(width, height)

 Image
 {
 id: sameHiddenImg
 visible: false
 source: parent.source
 }
 }

 So, valid values for preferredWidth and preferredHeight are 93 and 456.
 But for some rare users they are 116 and 570 accordingly.

 On Thu, Apr 18, 2024 at 11:16 AM Alexander Dyagilev <
 alervd...@gmail.com> wrote:

> Hello,
>
> A few of our users have issues with UI rendering. We SVG sprite to
> display some elements of our UI. This SVG has a size specified in it
> (93x456). And of course we rely on it. The issue is that sometimes it's
> loaded with 116x570 size due to some unknown reason. So it's like a
> different image and we can't use such a sprite properly anymore.
>
> What can be the cause of that? I've attached this sprite image.
>
 ___
> 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] SVG is loaded with invalid dimensions on some machines

[Elvis Stansvik]

Den tors 18 apr. 2024 06:17Alexander Dyagilev  skrev:

> Hello,
>
> A few of our users have issues with UI rendering. We SVG sprite to display
> some elements of our UI. This SVG has a size specified in it (93x456). And
> of course we rely on it. The issue is that sometimes it's loaded with
> 116x570 size due to some unknown reason. So it's like a different image and
> we can't use such a sprite properly anymore.
>
> What can be the cause of that? I've attached this sprite image.
>

570/456 = 1.25 which is a common screen scaling factor, so possibly you
need to take that into account when rasterizing the SVG for display on
screen? Just a guess..

Elvis

___
> 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] App release

[Elvis Stansvik]

Den tors 21 mars 2024 01:29Turtle Creek Software 
skrev:

> We are ready to release a free alpha version of our accounting app for Mac
> & Windows. The plan is to use LGPL while still in beta, then switch to a
> commercial license and static Qt when it's ready to sell.
>
> Will the switch cause licensing problems?
>
> How do people usually distribute QT for dynamic linking?  Our
> users/testers are not very tech savvy.
>

We bundle the Qt libraries inside our installer which we generate with
CPack. The installer contents is prepared with CMake install directives,
macdeployqt/windeployqt tools from Qt as well as the fixup_bundle helper in
CMake.

Elvis


> Thanks,
> Casey McDermott
> TurtleSoft.com
>
>
> ___
> 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] App release

[Elvis Stansvik]

Den tors 21 mars 2024 01:44Thiago Macieira 
skrev:

> On Wednesday, 20 March 2024 17:27:26 PDT Turtle Creek Software wrote:
> > We are ready to release a free alpha version of our accounting app for
> Mac
> > & Windows. The plan is to use LGPL while still in beta, then switch to a
> > commercial license and static Qt when it's ready to sell.
> >
> > Will the switch cause licensing problems?
>
> The LGPL will not cause you legal problems. But you must remember that the
> licence you gave to those recipients is irrevocable: they can continue
> using
> it, distributing it and even developing it after you've made your
> production
> release. You may want to think more about your business case here, because
> some potential paying customers may decide they don't want to pay you if a
> nearly as good version is open source.
>

I'll let Casey confirm, but the way understood it, the license switch
question was regarding the license under which they use Qt.

I.e. they were planning on

- Freeware but closed sourced/proprietary license for app + Qt under LGPL
during beta phase

- Commercial/proprietary licemse for app + Qt under commercial license when
they're out of beta and ready to make money

So the app would never be open source.

Please confirm Casey.

Elvis


> You should also check with Qt Company sales what terms they'll sell you a
> licence under. In the past, they usually required that you retroactively
> buy
> for the time you spent developing the application.
>
> > How do people usually distribute QT for dynamic linking?  Our
> users/testers
> > are not very tech savvy.
>
> For Mac, it's easy:  use macdeployqt and everything is inside your
> application's bundle.
>
> For Windows, you'll need to make an installer to deploy your .exe and all
> the
> Qt libraries and plugins. windeployqt can prepare the installation target,
> but
> the installer itself is up to you. You can use the Qt Installer Framework
> if
> you wish, or something else.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Principal Engineer - 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] QJsonObject memory leak?

[Elvis Stansvik]

Can you create a standalone example? (I see no calls to your
create/uncreate)

How are you measuring memory consumption?

Elvis

Den tors 2 nov. 2023 16:52Nuno Santos  skrev:

> Hi,
>
> I have realised that I cannot release all the memory allocated by a huge
> QJsonObject when I don’t need it any more. To ensure that nothing else was
> in between I have created a simple program that does what is below.
> Conclusion:
>
> - Running on a Mac, compiled in release with Qt 6.5.3
>
> - Starts with 31.7 MB
>
> [image: Screenshot 2023-11-02 at 15.48.29.png]
>
> - Goes up to 412.5 MB
>
> [image: Screenshot 2023-11-02 at 15.48.43.png]
>
> - After calling uncreate drops to 42.7
>
> [image: Screenshot 2023-11-02 at 15.48.50.png]
>
>
> If I repeat this procedure, it always increases the process memory size
> although it is not linear.
>
> In iOS the problem is even worse.
>
> Any ideas of what is happening here?
>
> Thank you!
>
> Best regards,
>
> Nuno
>
>
> QString GetRandomString()
> {
> const QString
> possibleCharacters("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789");
> const int randomStringLength = 4096; // assuming you want random
> strings of 12 characters
>
> QString randomString;
> for(int i=0; i {
> int index = QRandomGenerator::global()->generate() %
> possibleCharacters.length();
> QChar nextChar = possibleCharacters.at(index);
> randomString.append(nextChar);
> }
>
> return randomString;
> }
>
> void Controller::create()
> {
> qDebug() << Q_FUNC_INFO;
>
> for (int i=0; i<10; i++)
> _data[QString::number(i)] = GetRandomString();
> }
>
> void Controller::uncreate()
> {
> qDebug() << Q_FUNC_INFO;
>
> _data = QJsonObject();
> }
>
>
> ___
> 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] Per-language lupdate options not possible with qt_add_lupdate CMake helper?

[Elvis Stansvik]

Filed another suggestion about these macros relating to applications
with sources spread across multiple CMake targets:
https://bugreports.qt.io/browse/QTBUG-115846

Den mån 7 aug. 2023 kl 19:55 skrev Elvis Stansvik :
>
> Thanks Alexandru,
>
> => https://bugreports.qt.io/browse/QTBUG-115845
>
> Den mån 7 aug. 2023 kl 09:42 skrev Alexandru Croitor 
> :
> >
> > Hi,
> >
> > Unless i'm misreading the code, i don't think it's currently possible to 
> > pass per-file / per-lang
> > separate options for a single target with qt_add_lupdate.
> >
> > You could try to work around it by having separate targets per language, 
> > but that's clearly sub-optimal.
> >
> > You should be fine with using qt_create_translation as long as it meets 
> > your needs, we likely won't remove
> > any deprecated api until there is a good enough replacement.
> >
> > Having said that, I suggest you file a suggestion on the bug tracker, so we 
> > can keep track of the use case.
> >
> >
> > > On 6. Aug 2023, at 15:21, Elvis Stansvik  wrote:
> > >
> > > Hi all,
> > >
> > > Porting our application to Qt 6 and I'm a little confused by the new
> > > qt_add_lupdate CMake helper.
> > >
> > > When we run lupdate to generate/update our English translation .ts
> > > files, since our source strings are in English, we want to pass
> > > -pluralonly to lupdate, to only have plural forms for translators to
> > > "translate". We don't want to do this for other languages.
> > >
> > > It seems this is not possible with qt_add_lupdate which takes a target
> > > argument and adds a ${target}_lupdate target, since I assume that with
> > > two successive calls to qt_add_lupdate for the same target (first with
> > > our English .ts files and second with the others), the second call
> > > would trample of what the first one did?
> > >
> > > How should this be done in Qt 6? Surely someone else must be in the same 
> > > boat?
> > >
> > > I know that the non-target based qt_create_translation still exists,
> > > but it's deprecated so not something we want to use.
> > >
> > > Thanks in advance,
> > > Elvis
> > > ___
> > > 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] Per-language lupdate options not possible with qt_add_lupdate CMake helper?

[Elvis Stansvik]

Thanks Alexandru,

=> https://bugreports.qt.io/browse/QTBUG-115845

Den mån 7 aug. 2023 kl 09:42 skrev Alexandru Croitor :
>
> Hi,
>
> Unless i'm misreading the code, i don't think it's currently possible to pass 
> per-file / per-lang
> separate options for a single target with qt_add_lupdate.
>
> You could try to work around it by having separate targets per language, but 
> that's clearly sub-optimal.
>
> You should be fine with using qt_create_translation as long as it meets your 
> needs, we likely won't remove
> any deprecated api until there is a good enough replacement.
>
> Having said that, I suggest you file a suggestion on the bug tracker, so we 
> can keep track of the use case.
>
>
> > On 6. Aug 2023, at 15:21, Elvis Stansvik  wrote:
> >
> > Hi all,
> >
> > Porting our application to Qt 6 and I'm a little confused by the new
> > qt_add_lupdate CMake helper.
> >
> > When we run lupdate to generate/update our English translation .ts
> > files, since our source strings are in English, we want to pass
> > -pluralonly to lupdate, to only have plural forms for translators to
> > "translate". We don't want to do this for other languages.
> >
> > It seems this is not possible with qt_add_lupdate which takes a target
> > argument and adds a ${target}_lupdate target, since I assume that with
> > two successive calls to qt_add_lupdate for the same target (first with
> > our English .ts files and second with the others), the second call
> > would trample of what the first one did?
> >
> > How should this be done in Qt 6? Surely someone else must be in the same 
> > boat?
> >
> > I know that the non-target based qt_create_translation still exists,
> > but it's deprecated so not something we want to use.
> >
> > Thanks in advance,
> > Elvis
> > ___
> > 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] Per-language lupdate options not possible with qt_add_lupdate CMake helper?

[Elvis Stansvik]

Hi all,

Porting our application to Qt 6 and I'm a little confused by the new
qt_add_lupdate CMake helper.

When we run lupdate to generate/update our English translation .ts
files, since our source strings are in English, we want to pass
-pluralonly to lupdate, to only have plural forms for translators to
"translate". We don't want to do this for other languages.

It seems this is not possible with qt_add_lupdate which takes a target
argument and adds a ${target}_lupdate target, since I assume that with
two successive calls to qt_add_lupdate for the same target (first with
our English .ts files and second with the others), the second call
would trample of what the first one did?

How should this be done in Qt 6? Surely someone else must be in the same boat?

I know that the non-target based qt_create_translation still exists,
but it's deprecated so not something we want to use.

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

Re: [Interest] QSslCertificate issues on FreeBSD

[Elvis Stansvik]

Den mån 20 mars 2023 kl 01:45 skrev Alexey Rochev :
>
> Hi,
>
> I'm currently trying to add FreeBSD to my app's CI configuration and for some 
> reason my tests fail due to QSslCertificate::operator==() returning false. 
> More specifically, I compare a QSslCertificate loaded from PEM file and one 
> returned from server (as extracted from QSslError). They are supposed to be 
> the same, but their comparison returns false. Even more mysteriously, despite 
>  operator==() returning false, QSslCertificate::toPem() and 
> QSslCertificate::toText() return exactly the same strings for both of them. 
> This happens both with Qt 5.15.7 and 6.4.2.

What about toDer()? The same?

Elvis

>
> I don't know whether there is an issue with my FreeBSD install (I haven't 
> used it before) or somewhere else and would appreciate any help with this.
> ___
> 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] QProcess unbuffered

[Elvis Stansvik]

Den mån 6 mars 2023 kl 21:21 skrev Scott Bloom :
>
>
>
> From: Björn Schäpers 
> Sent: Monday, March 6, 2023 12:18 PM
> To: Scott Bloom ; interest@qt-project.org
> Subject: Re: [Interest] QProcess unbuffered
>
>
>
> Am 06.03.2023 um 02:11 schrieb Scott Bloom:
>
> I have an external executable (mkvalidator from 
> https://www.matroska.org/downloads/mkvalidator.html
>
>
>
> It never flushes the output, and it uses linefeed without carriage returns to 
> overwrite existing text on the output.
>
>
> The problem is, when I run it via QProcess (on windows, Qt 5.15.10), I get 
> zero output until the process ends.  As if it was buffered, and the output 
> was finally flushed
>
> When running from the command line, I do get output continuously during the 
> processing.
>
>
>
> I setup a timer to waitForRead, didn’t do anything. I cant seem to force the 
> QProcess to read all stdout or stderror info.
>
> Any thoughts?
>
>
> TIA
>
> Scott
>
>
>
> ___
>
> Interest mailing list
>
> Interest@qt-project.org
>
> https://lists.qt-project.org/listinfo/interest
>
> Hi,
>
> I had the exact same problem (but without QProcess). You have to use a trick 
> to disable the buffering, I don't know if its possible with QProcess, you 
> will have to use QProcess::CreateProcessArgumentModifier or most likely 
> CreateProcess directly.
>
> If there is interest I can copy some of my data, but currently I can't access 
> it.
>
> Kind regards,
> Björn.
>
> I would love any info/data you can provide.  Feel free to email me privately 
> if you want.

If possible, keep it on the list, to not leave us hanging. I think
it's valuable for both Qt devs and users to see other people's
laundry, even if it's a bit dirty :)

Elvis

>
> Thanks
>
> Scott
>
> ___
> 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] MSVC not-the-latest: are you using it? why?

[Elvis Stansvik]

Den sön 22 jan. 2023 kl 23:08 skrev Elvis Stansvik :
>
> > MSVC not-the-latest: are you using it? why?
>
> Yes, using VS 2019.
>
> I can only speak for us, but we simply haven't had any really
> compelling reason to upgrade our compiler.
>
> Turning the question around: If you have no need for the
> features/improvements that a newer compiler would bring, why would you
> upgrade it? It's a non-zero amount of work to switch.
>
> In many places, if you can't make a (somewhat) direct connection to
> something revenue-generating, such as a client case, it's not going to
> get done unless there's unexpected extra time available.
>
> That said, we would have no problem with Qt dropping support for VS
> 2019. We are using a somewhat old 5.12 version of Qt anyway, mostly
> for same reason as we are not using latest compiler.
>
> So perhaps better wait for someone that is staying on top of the
> latest Qt to give their view. I can imagine that there that do that to

*that there are those that do that

> get improvements/bug fixes, but which rarely update their compiler.
> It's quite rare to be affected by a compiler bug after all.
>
> Elvis
>
> Den sön 22 jan. 2023 kl 17:19 skrev Thiago Macieira 
> :
> >
> > 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] MSVC not-the-latest: are you using it? why?

[Elvis Stansvik]

> MSVC not-the-latest: are you using it? why?

Yes, using VS 2019.

I can only speak for us, but we simply haven't had any really
compelling reason to upgrade our compiler.

Turning the question around: If you have no need for the
features/improvements that a newer compiler would bring, why would you
upgrade it? It's a non-zero amount of work to switch.

In many places, if you can't make a (somewhat) direct connection to
something revenue-generating, such as a client case, it's not going to
get done unless there's unexpected extra time available.

That said, we would have no problem with Qt dropping support for VS
2019. We are using a somewhat old 5.12 version of Qt anyway, mostly
for same reason as we are not using latest compiler.

So perhaps better wait for someone that is staying on top of the
latest Qt to give their view. I can imagine that there that do that to
get improvements/bug fixes, but which rarely update their compiler.
It's quite rare to be affected by a compiler bug after all.

Elvis

Den sön 22 jan. 2023 kl 17:19 skrev Thiago Macieira :
>
> 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] QRegularExpression for replace

[Elvis Stansvik]

Maybe I'm dumb, but I'm still not sure what is being asked for.

If it's regular expression replacement with back-references in the
replacement string, I think that's possible with QString::replace like
I showed.

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

Re: [Interest] QRegularExpression for replace

[Elvis Stansvik]

Den tors 1 dec. 2022 kl 20:44 skrev Scott Bloom :
>
> Im looking for a way using QRE to do something like the following
>
>
>
> auto regEx = QRegularExpression( “(?.*)” );
>
> if ( regEx.match( string ) )
>
> auto newString = regEx.replace( string, “${name}” );

It's a bit hard to know exactly what you want given the example above,
since the .* would match the entire input string.

But like Tony said, you can make references to the capturing groups in
the replacement string, so e.g.

#include 
#include 
#include 

int main(void) {
   QString s = "Hello Jane and Joe";
   qDebug() << s.replace(QRegularExpression("(Jane|Joe)"), "little \\1");
   return 0;
}

will print

"Hello little Jane and little Joe"

I don't think you can reference capturing groups by name, but that's
just a minor inconvenience.

Elvis

>
>
>
>
>
> Using the standard set of regex subsitutions
>
>
>
> Is this something anyone is looking at? Or is there a solution outthere?
>
> Scott
>
> ___
> 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 Creator consistency

[Elvis Stansvik]

Den lör 3 dec. 2022 kl 23:02 skrev Turtle Creek Software
:
>
> It's good to have multiple ways to do common things.
>
> F2 is not great because I'm often leaned way back with right hand on mouse, 
> and with
> left hand holding drink, snack, scratching or whatever. An extra click is 
> faster then reaching to the keyboard.

I hear you man. Slowly slipping further down the chair, to the point I
cannot even reach the keyboard, is the absolute highlight of my work
day afternoon.

It's downright outrageous that the Qt Creator team dare move a menu
entry by several pixels, and then have the audacity to suggest using
the keyboard.

Frankly, that they don't include a free set of physical foot pedals
for the most common actions is just inexplicable.

Elvis

>
> BTW Follow Symbol Under Cursor does *not* go from source to header if you 
> double-clicked on the function first.
> That changed a few updates ago.  It works properly if the text is not 
> selected.  Odd.
> I probably do the double-click by habit left over from Xcode, Visual Studio 
> and/or CodeWarrior.
>
> Actually, aside from temporal consistency, there's a lot to be said for 
> consistency between development apps also.
> Casey McD
>
>
>
> On Sat, Dec 3, 2022 at 3:56 PM A. Pönitz  wrote:
>>
>> On Fri, Dec 02, 2022 at 07:24:56PM -0500, Turtle Creek Software wrote:
>> > The last few updates to QT Creator have made small changes to the user
>> > interface, annoyingly.
>> >
>> > Using the latest, I weirdly kept seeing preprocessor output. Huh?  Turns
>> > out Follow Symbol Under Cursor moved from #2 to #3 in the right-click
>> > menu.  When using a command 50 times a day, one clicks by position not by
>> > reading text.
>> > [...]
>>
>> You could press  instead of positioning the mouse over the symbol,
>> right-click, move the mouse to entry #2 or #3, and click again to
>> trigger the action/.
>>
>>
>> > Minor changes have big impact.
>>
>> Indeed.
>>
>> Andre'
>>
> ___
> 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] ASAN (Qt 6.4 + Glib) build shows stackoverflow in trivial Qt program

[Elvis Stansvik]

Den lör 12 nov. 2022 kl 18:08 skrev Thiago Macieira :
>
> On Friday, 11 November 2022 23:54:24 PST Dennis Luehring wrote:
> >../qt6/qtbase/configure -debug -opensource [...]
> ># ==> https://pastebin.com/JDm0p80b  qt6_configure.txt
>
> You've only built qtbase. That means you have no Wayland client plugin.
>
> The configure output is confusing. It says "yes" for a bunch of X11 things, 
> but
> the "XCB" section only has "no":
> >   XCB:
> > Using system-provided xcb-xinput . no
> > GL integrations:
> >   GLX Plugin . no
> > XCB GLX .. no
> >   EGL-X11 Plugin . no
>
> Though none of them are about XCB itself, one would conclude it is enabled.
> The hint here that GLX wasn't enabled.
>
> In any case, the XCB plugin didn't get built:
>
> > linux@linux-virtual-machine:~/qt6_dev/qt6-build/plugins/platforms$ ls
> > libqeglfs.so  libqlinuxfb.so  libqminimalegl.so  libqminimal.so
> > libqoffscreen.so  libqvkkhrdisplay.so  libqvnc.so
>
> So this build has no XCB or Wayland, that's why you can't start applications.
> If you just want to test an application that starts and ends, you can use the
> offscreen one.

And just to chime in, you would do that by running with
QT_QPA_PLATFORM=offscreen.

Elvis

>
>
> --
> 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] Medical device companies using Qt

[Elvis Stansvik]

Den lör 29 okt. 2022 kl 19:26 skrev Stan Morris :
>
> A poster (troll?) writes that few medical device companies use Qt. That is 
> simply incorrect.

I'm sorry to say it, but I see a reply from the same in your near future...

Elvis

>
> I know developers at 4 medical device companies of which 3 use Qt: Qt 5, Qt 
> 6, and don't know if  the 3rd transitioned to Qt 6 yet.
>
> Look at job postings. A "Qt" search on indeed.com for job postings in Newport 
> Beach, CA showed 3 of the first 10 postings are at medical device companies: 
> Massimo, Johnson & Johnson, and Nihon Kohden are medical device companies 
> that are hiring Qt developers.
>
> Lack of interest in Qt by medical device companies is misinformation. I 
> apologize for not contributing to the technical tone of this list.
> ___
> 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] Small survey on necessary Qt Container size

[Elvis Stansvik]

Den mån 5 sep. 2022 kl 22:30 skrev Thiago Macieira :
>
> On Monday, 5 September 2022 10:25:59 PDT A. Pönitz wrote:
> >   How often do people /need/ /Qt/ containers with /more than
> >   1 billion elements/ ?
>
> Or foresee needing them in the next 10 years.

0 times and 0 times.

I've used Qt (non)professionally on and off for 15 years.

That said, don't want my disclosure of these numbers to construed as
me taking a side in a Qt + size_t discussion - I just don't feel like
I'm read up enough on the matter. But there you go :)

Elvis

>
> --
> 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] [External] Re: How to properly terminate QtConcurrent run

[Elvis Stansvik]

Den tors 18 aug. 2022 16:44Sean Murphy via Interest 
skrev:

> > > I'll look into this idea, but some of what my processChunk() does are
> > > calls into an external library that I can't control so my options are
> > > limited there. As far as I can tell, this is an issue for any code
> that just takes
> > a long time.
> >
> > Yes, if this it's a call into an external API that provides no mechanism
> to cancel
> > the call prematurely, you have no option for graceful shutdown and have
> to
> > kill the threads forcefully.
> >
> > I guess in the code handling your application exit, you can wait a
> little bit for
> > all threads in the pool, and after an "unreasonable"
> > amount of time has passed (half a second?), kill them all forcefully.
> > Bit of a big hammer, but I don't know of any way to query for the threads
> > currently used by a specific ::map call (maybe someone else does though).
>
> Yeah, and that seems to be the rub with the QtConcurrent functions, I don't
> get any sort of handle to the threads it is spawning off, unless maybe I
> can get
> at them via the global thread pool?


Yes, it uses the global threadpool by default I think.

I guess the problem with eg an API to get the list of threads used by a
::map call is that it would be inherently racy - by the time you kill a
thread it could have been put back into and out of the pool already and be
running something you don't want to kill?

So maybe better with a custom pool.

Elvis

I'm just starting to look at that. Other than
> trying to call cancel() on the associated QFutureWatcher, which does work
> eventually as long as your function called by map() actually returns,
> there doesn't
> seem to be a way to stop those concurrent threads.
>
> With the way my code exists at the moment, I've got the main application
> running
> in the UI thread. I intentionally spawn off Thread A and move my
> processingManager
> object over to that thread, and when that object gets a processing
> request, it  calls
> QtConcurrent::map() which spawns off Threads B, C, D, etc... and I don't
> seem to have
> any control over those threads. I know when I had the infinite loop bug in
> my
> processChunk() call, killing off Thread A (the processingManager's thread)
> and deleting
> the processingManager itself didn't seem to forcefully terminate Threads B
> through
> whatever - they just kept on running forever. I'm going to try writing up
> a small test app to
> double check this. I was doing all this in the main application, which has
> a whole lot of
> other stuff going on, so maybe my issue was somewhere else...
>
> Sean
> This e-mail, including any attached files, may contain confidential
> information, privileged information and/or trade secrets for the sole use
> of the intended recipient. Any review, use, distribution, or disclosure by
> others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive information for the intended recipient), please
> contact the sender by reply e-mail and delete all copies of this message.
> ___
> 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] [External] Re: How to properly terminate QtConcurrent run

[Elvis Stansvik]

Den ons 17 aug. 2022 kl 17:12 skrev Sean Murphy via Interest
:
>
> Thanks for the response!
>
> > You should signal processChunk to stop processing early. You can for
> > example do this through an atomic variable which is periodically checked, 
> > e.g.
> > as part of the stop condition in that loop you mentioned.
>
> I'll look into this idea, but some of what my processChunk() does are calls 
> into an
> external library that I can't control so my options are limited there. As far 
> as I can
> tell, this is an issue for any code that just takes a long time.

Yes, if this it's a call into an external API that provides no
mechanism to cancel the call prematurely, you have no option for
graceful shutdown and have to kill the threads forcefully.

I guess in the code handling your application exit, you can wait a
little bit for all threads in the pool, and after an "unreasonable"
amount of time has passed (half a second?), kill them all forcefully.
Bit of a big hammer, but I don't know of any way to query for the
threads currently used by a specific ::map call (maybe someone else
does though).

Elvis

>
> Take this hypothetical scenario for example:
>  - we have some processing task that would take hours to run if run in a 
> single thread,
> but it can be broken down into chunks
>  - once broken into chunks, each chunk takes maybe a minute to run, but most 
> of
> that minute is consumed in an external library that I can't do anything 
> about
>  - user starts one of these tasks, but before it finishes they decide they 
> don't care
> about the results and want to completely quit the application
>  - I warn the user there's a job in progress, are they sure they want to 
> quit? They say Yes
>
> So at this point, the user really wants to quit the application. From what 
> I've gleaned so
> far, and I could be wrong so feel free to correct me, I can tell the 
> QFutureWatcher to
> cancel the job. But this only prevents any chunks that hadn't been started 
> from getting
> started, it doesn't immediately terminate the chunks that are currently in 
> progress,
> those continue until they all finish, at which point the QFutureWatcher 
> signals both
> canceled() and finished(), and now I can safely quit the application. But if 
> it were me as
> the user, I'd be annoyed that I have to wait up to a minute for the 
> application to quit
> after I asked it to quit.
>
> > I may be wrong, but I think terminating a thread forcefully is considered a
> > poor design.
>
> In general I agree, but I'm not sure I do in the special case of the user 
> quitting the application
> under the conditions I've described above. At that point to me (this is me 
> wearing my user hat
> now, not my developer hat), I would want the application to quit immediately 
> and I don't really
> care what happens under the hood - as long as it doesn't crash.
>
> (Developer hat back on) I don't see a way to easily accomplish this under the 
> QtConcurrent
> API. Most of the examples I can find online show how to do the set up part, 
> but they rarely
> give any time to showing how to cleanly abort a run in progress. The only 
> actual solution I
> see that can do this cleanly is to ditch QtConcurrent, and write my own 
> chunkProcessor
> objects that spawn and manage their own worker threads, which when signaled, 
> can forcefully
> terminate regardless of what is being done at the time.
>
> I'm open to suggestions/corrections/etc. Also, if anyone has any references 
> they like that talk
> more about quitting/cleaning up threads under all sorts of different 
> scenarios, I'd love to read
> more about it - I seem to be struggling to find those.
>
> Sean
> This e-mail, including any attached files, may contain confidential 
> information, privileged information and/or trade secrets for the sole use of 
> the intended recipient. Any review, use, distribution, or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive information for the intended recipient), please contact 
> the sender by reply e-mail and delete all copies of this message.
> ___
> 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] How to properly terminate QtConcurrent run

[Elvis Stansvik]

Den tis 16 aug. 2022 kl 18:23 skrev Sean Murphy via Interest
:
>
> I've encountered a bug of mine, that is leading me to ask how to properly fix 
> some behavior...
>
> The setup: I've got a worker task that runs in a separate thread, waiting for 
> jobs to come over from MainWindow. When that worker task gets a job, it 
> splits the jobs into smaller chunks, and then uses QtConcurrent::map() to 
> process those chunks in parallel. Currently I've got a bug in my 
> processChunk() function which is causing an infinite loop (I'm fixing that as 
> we speak), but what I noticed is that because of those infinite loops running 
> inside of QtConcurrent calls, I was unable to quit my application. Since all 
> the infinite loop is happening in a non-UI thread, the UI is responsive and I 
> can choose to quit the application from either the File menu or the 'X' 
> button. The UI goes away, but the application is still running, and there's 
> no way to do anything about it other than killing it out at the OS task 
> manager level. What I want to have happen is any processing that is in 
> process when the user quits is immediately aborted/terminated and the 
> application exits cleanly.
>
> So basically I have:
>  - a thread, workerThread
>  - an object, workerObject, that lives in workerThread
>  - a function, workerObject::processChunk()
> - this function is the one that currently has an infinite loop bug
>  - a future watcher, chunkWatcher
>
> And then when workerObject receives a new request signal from MainWindow, it 
> calls
>   chunkWatcher->setFuture(QtConcurrent::map(chunks, processChunk));
>
> In MainWindow, I've got this:
> ~MainWindow()
> {
>   mWorkerThread->terminate();
>   mWorkerThread ->wait();
> }
>
> But that code only kills the thread the worker task itself is in, not the 
> threads that QtConcurrent has spawned off to run processChunk() that will 
> never return. I'm poking through the QFutureWatcher, but I don't see a way to 
> forcefully terminate stuff that's in progress. All I see is cancel() and 
> pause(), but if I understand what I'm seeing, those don't seem to stop 
> processChunk() calls that are already in progress, they just prevent 
> processChunk() from being called on the remaining chunks after each chunk in 
> progress finished.
>
> So is there any way I can terminate QtConcurrent::map()?

You should signal processChunk to stop processing early. You can for
example do this through an atomic variable which is periodically
checked, e.g. as part of the stop condition in that loop you
mentioned.

I may be wrong, but I think terminating a thread forcefully is
considered a poor design.

Elvis

>
> Sean
>
>
>
>
>
>
> This e-mail, including any attached files, may contain confidential 
> information, privileged information and/or trade secrets for the sole use of 
> the intended recipient. Any review, use, distribution, or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive information for the intended recipient), please contact 
> the sender by reply e-mail and delete all copies of this message.
> ___
> 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] spurious breakpoints in Qt Creator

[Elvis Stansvik]

Den sön 15 maj 2022 21:45Matej Košík  skrev:

> Hi,
>
> While using Qt Creator, I noticed that it generates "spurious breakpoints".
>
> How to reproduce:
> - I start Qt Creator
> - I generate a new project
>   (Qt Widgets Application with QMainWindow as a base class)
> - from the menu I choose
>   - Debug
> - Start Debugging
>   - Start debugging of startup project
>
> then the debugged project first stops in "gtk3/main.cpp" and then stops
> in other places.
>
> When I let the program continue, it then stops again in the file
> "ico/main.cpp".
>
> When I let the program continue, it then stops again in the file
> "pdf/main.cpp".
>
> I guess that I am doing something wrong, but I am unable to figure out
> what. Any help is welcome. I would like the program to stop only in
> breakpoints defined by me.
>
> I am using:
> - Linux (version 5.10.0-14-amd64)
> - GNOME (version 3.38.5)
> - Qt Creator (4.14.1)
>

Not related to your problem, but would highly recommend using latest
version of Qt Creator.

Elvis

- Qt (version 6.3 compiled from source)
> ___
> 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] Qthread from QFuture?

[Elvis Stansvik]

I don't think QFuture/QFutureWatcher would have such an API. I guess
you could query what thread it is at the start of the function you run
with QtConcurrent::run and communicate that to your main thread.

Elvis

Den tis 4 jan. 2022 kl 20:08 skrev Scott Bloom :
>
> Is there anyway to get (if it even exists) a QThread from a 
> QFuture/QFutureWatcher?
>
> The main issue, and I know this going to sound horrible, I would like to 
> kill/terminate the thread, I know its safe  (famous last words)..
>
>
>
> Here is what im doing, maybe someone has a better solution (Im sure of it).
>
>
>
> I have a Qlineedit entry that takes a path.  Often, this path is network 
> based, and very often over VPN, meaning its NOT always connected.
>
>
>
> On the text changing, the window determines if the path is valid 
> (QFileInfo::exists, isDir, isExecutable for directories, some are files).  
> Unfortunately, if the VPN is not connected, it can take up to 30 seconds for 
> the OS to return “no it doesn’t exist”.  (Windows is the primary OS, but I 
> have seen the same on Linux)
>
> I have created a “Delayed Line Edit” class, that derives from QLineEdit, that 
> delays the “the text is edited” by a set amount of time, to minimize the 
> check (ie when typing the path by hand).
>
>
>
> However, at some point this 30 second delay hits, freezes the gui and is an 
> overall miserable experience.
>
>
>
> What I have done, is created a simple Object “Background File Check” that has 
> all the File Info queries.  You set the path, set what you want checked, and 
> call “checkPath”.  This calls QtConcurrent::run on the checkPath internal 
> function.  There is a QResultWatcher, that emits the check has finished or 
> timed out (with a single shot timer called when checkPath is set).
>
> 99% of the time time, if its not there in 5 seconds, its dead.  So a 5000 ms 
> timer is used.  This works great.  Except there is one problem.
>
>
>
> If the user tries to exit the tool before all the threads have finished, the 
> tool waits for them to close.
>
>
>
> There is no way to interrupt the single class to the OS, its frozen in the 
> thread (better than also freezing the GUI).  But If I could ask the watcher, 
> give me your QThread and let me terminate it, it would fix the issue.
>
>
>
> Any ideas?
>
> Scott
>
>
>
>
>
> ___
> 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] Can QML compiler optimize switch into array indexing?

[Elvis Stansvik]

Den fre 15 okt. 2021 kl 09:29 skrev Ulf Hermann :
>
> > I now saw your nice blog post about this at [1], saying "You should
> > not call qmlRegisterType() and friends procedurally anymore.".
> >
> > I then saw that there's no pointer in the docs for qmlRegisterType and
> > friends [2] to QML_ELEMENT.
>
> There are quite a few links from the qmlRegisterType() family of
> functions to their macro counter parts. For each one there is a "See
> also" below it and the macros are documented on the same page.

It's decided: I've gone blind. Thanks.

>
> The general documentation on how to define QML types from C++ can be
> found at [1]. It only mentions the macros.
>
> [1] https://doc.qt.io/qt-6/qtqml-cppintegration-definetypes.html

Ah thanks. I also missed that overview somehow.

Elvis

>
> best regards,
> Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Can QML compiler optimize switch into array indexing?

[Elvis Stansvik]

Den tors 14 okt. 2021 kl 09:49 skrev Ulf Hermann :
>
> Hi,
>
> Let's look at the QML snippet again:
>
> > enabledBorders: {
>
> > switch (control.edge) {
>
> > case Qt.BottomEdge:
>
> > return PlasmaCore.FrameSvgItem.TopBorder;
>
> > case Qt.RightEdge:
>
> > return PlasmaCore.FrameSvgItem.LeftBorder;
>
> > case Qt.TopEdge:
>
> > return PlasmaCore.FrameSvgItem.BottomBorder;
>
> > case Qt.LeftEdge:
>
> > default:
>
> > return PlasmaCore.FrameSvgItem.RightBorder;
>
> > }
>
> > }
>
> What the QML interpreter and JIT do on such a thing is quite sad:
>
> 1. Lookup "Qt" and figure out it's a singleton.
> 2. Lookup "BottomEdge" on "Qt" and figure out it's an enum
> 3. Resolve enum to number
> 4. Compare
>
> ... and so on for all the cases. Once the right case is found, it does:
>
> 1. Lookup "PlasmaCore" and figure out it's a type namespace (probably?)
> 2. Lookup "FrameSvgItem" on "PlasmaCore" and figure out it's a type
> 3. Lookup "TopBorder" on "FrameSvgItem" and figure out it's an enum
> 4. Resolve enum to number
>
> The lookups are cached, so the second and any following executions of
> the same piece of code are faster. Yet, it's still quite far from what
> it could be. The problem here is that the QML engine initially doesn't
> know what all the names mean and has to figure it out at run time.
>
> This is a case where the QML-to-C++ compilation will truly shine because
> we can do all of the lookup at compile time if we know all your types.
> Then the generated code collapses into a few comparisons on plain integers.
>
> This is why you have to declare your types in your header files using
> QML_ELEMENT and friends, and use qt_add_qml_module to declare QML
> modules in CMake.

I now saw your nice blog post about this at [1], saying "You should
not call qmlRegisterType() and friends procedurally anymore.".

I then saw that there's no pointer in the docs for qmlRegisterType and
friends [2] to QML_ELEMENT.

If the recommended way nowadays is the declarative approach, would
probably be good with a pointer there since not everyone finds the
blog posts.

Maybe I should just make a suggestion on Gerrit, but it was such a
long time since I had it set up, so I'll take the lazy way out :)

Cheers,
Elvis

[1] https://www.qt.io/blog/qml-type-registration-in-qt-5.15
[2] https://doc.qt.io/QT-5/qqmlengine.html#qmlRegisterType

>
> best regards,
> Ulf
> ___
> 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] [External] Proxied view not updating live when source model does

[Elvis Stansvik]

Den tis 21 sep. 2021 16:00Murphy, Sean  skrev:

> > I'm having an issue where my proxy model and its associated view aren't
> > updating live when changes are made in the source model.
> >
> > My proxy model simply is attempting to invert the rows of the source
> model. So
> > it inherits from a QSortFilterProxyModel and implements mapFromSource()
> and
> > mapToSource() as follows:
> >
> > QModelIndex invertRowsModel::mapFromSource(const QModelIndex
> > ) const
> > {
> > if(sourceIndex.isValid() && rowCount() > 0)
> > {
> > return this->index(rowCount() - sourceIndex.row() - 1,
> > sourceIndex.column());
> > }
> >
> > return QModelIndex();
> > }
> >
>
> Small update here, but I'm not sure what it actually means... I added a
> debug
> statement at the top of my mapFromSource() function, so now that function
> reads like so:
>
> QModelIndex invertRowsModel::mapFromSource(const QModelIndex
> ) const
> {
> if(sourceIndex.isValid() && rowCount() > 0)
> {
> qDebug() << __FUNCTION__ << "valid index" << sourceIndex;
> return this->index(rowCount() - sourceIndex.row() - 1,
> sourceIndex.column());
> } else {
> qDebug() << __FUNCTION__ << "invalid index" << sourceIndex;
> }
>
> return QModelIndex();
> }
>
> With this in place, while modifying the data in the source view, I NEVER
> see the
> mapFromSource() "valid index" debug message from the proxy model. Right
> after
> setData() is called in the source model, I see a couple of these messages
> come out
> and that's it:
>
>   invertRowsModel::mapFromSource invalid index
> QModelIndex(-1,-1,0x0,QObject(0x0))
>
> I'm not sure exactly what that means or how to address it, but it is a new
> data point...
>

I added the same kind of printout and concluded the same yesterday, when I
thought I'd help you debug as a challenge.. (then ran out of time).

Curious to see how this progresses..

Code in QSFPM for handling source model dataChanged is a bit hard to
follow..

Elvis


> Sean
>
> ___
> 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] Configuring Qt's built-in freetype ?

[Elvis Stansvik]

Den tors 26 aug. 2021 kl 13:39 skrev Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com>:

> Hi,
>
> for consistency, I am shipping my app with freetype on all platforms.
> This looks "correct", definitely better than using macOS or Win32's font
> rendering, but ! Qt's built-in freetype does not look as good than my Linux
> system's finely-tuned freetype configuration which prompted some
> investigation.
>
> It's very visible for instance in the menu bar:
> * Top one is my system freetype, notice how the fonts are crispy and
> beautiful.
> * Below one is using Qt's -qt-freetype: notice how the straight lines,
> like for the "t" in settings or the vertical bars in H are blurry.
> [image: here.png]
>
> If you zoom you'll notice that the one below is missing sub-pixel AA:
>
> [image: here-small.png]
> Thus my question: is there a way (even if that implies rebuilding Qt) to
> pass configuration options to freetype ? Surely that must be possible as
> it's able to do the correct thing with my distro (arch btw)'s Qt / freetype
> / fontconfig combo.
>

Maybe set FONTCONFIG_FILE envvar to point to a custom config file that you
ship, or FONTCONFIG_PATH to point to a conf.d directory with a custom
config snippet.

Elvis


> Kind regards,
> Jean-Michaël
>
>
> --
> Jean-Michaël Celerier
> *cto* ossia.io | *consulting inquiries* celtera.dev | *personal*
> jcelerier.name
> t: +336 81 31 53 08
> ___
> 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] Faster way of rendering QOpenGLFramebufferObject to image

[Elvis Stansvik]

Den tors 15 juli 2021 kl 10:30 skrev Nuno Santos :
>
> Elvis,
>
> Using your quick example (attached as a project below) I’ve run some tests 
> and realised that window rendering it not happening at the same frame rate in 
> all machines and the maximum differs:
>
> - no more than 30 fps in on a 2017 iMac with Radeon graphics card
> - no more than 30 fps on 2019 Intel Mac Book with Intel Graphics
> - up to 144 fps on a Windows machine with an RTX 2060
> - 115 fps on a 2018 12.9” iPad Pro
>
> Changing the width and height of the scene doesn’t seem to impact the frame 
> rate.
>
> I was expecting to have more than 60 fps on the iMac and Macbook. I don’t 
> think this simple scene would be limited to 30 fps

It does sound like a bug to me, unless somehow those Mac systems are
running at a 30 Hz monitor refresh rate and Quick is trying to match
that, but it seems very unlikely.

Unless someone here knows, I'd file a bug with a minimal example.

I did try adding some basic timing to my earlier example, and on my
Linux laptop afterRendering is called at a rate of 60 Hz.

Elvis

>
> At this point, I’m not taking into consideration that time it takes to obtain 
> the pixel data from the fbo/texture.
>
> Since in order to have v-sync with window when painting the context of the 
> texture rendered on the offscreen renderer I need to drive the paint via main 
> window paint, this means that I will be limited by main window painting frame 
> rate.
>
> Is anyone aware of frame rate limitations of a qquickwindow painting?
>
> Project attached.
>
> Thanks,
>
> Best regards,
>
> Nuno
>
>
>
> > On 14 Jul 2021, at 23:48, Elvis Stansvik  wrote:
> >
> > My idea would be something like (sketch):
> >
> > main.cpp:
> >
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > int main(int argc, char *argv[])
> > {
> >   QGuiApplication app(argc, argv);
> >
> >   auto view = new QQuickView;
> >   view->setSource(QUrl::fromLocalFile("test.qml"));
> >   view->show();
> >
> >   // I use a QVector here, but you would have your AVFrame and
> >   // its allocated memory buffer..
> >   QVector buffer;
> >   QMutex mutex;
> >
> >   QObject::connect(view, ::afterRendering, view, [&]() {
> >   mutex.lock();
> >   buffer.resize(4 * view->width() * view->height());
> >   glReadPixels(0, 0, view->width(), view->height(), GL_RGBA,
> > GL_UNSIGNED_BYTE, buffer.data());
> >   mutex.unlock();
> >   }, Qt::DirectConnection);
> >
> >   return app.exec();
> > }
> >
> > test.qml:
> >
> > import QtQuick 2.2
> >
> > Rectangle {
> >   width: 1920
> >   height: 1080
> >
> >   Rectangle {
> >   width: 500
> >   height: 500
> >   color: "green"
> >   anchors.centerIn: parent
> >   RotationAnimation on rotation {
> >   from: 0
> >   to: 360
> >   duration: 2000
> >   loops: Animation.Infinite
> >   }
> >   }
> > }
> >
> > I don't know whether this would work for you.
> >
> > Elvis
> >
> > Den tis 13 juli 2021 kl 15:31 skrev Nuno Santos :
> >>
> >> Elvis,
> >>
> >> Thanks for sharing your thoughts. It makes sense.
> >>
> >> I need to dive into the toImage function, try to read directly the bytes 
> >> from the FBO and see if that has any performance impact.
> >>
> >> Best regards,
> >>
> >> Nuno
> >>
> >>> On 13 Jul 2021, at 14:10, Elvis Stansvik  wrote:
> >>>
> >>> Hi Nuno,
> >>>
> >>> I'm really out of my waters here, but, provided you don't need to hold
> >>> on to each AVFrame after you are "done with it", you could perhaps
> >>> avoid having to allocate a QImage for each frame (which toImage forces
> >>> you to do) by just allocating a a single AVFrame and a single memory
> >>> buffer for it, and then do what toImage does, which is make sure the
> >>> FBO is bound and read the pixels off of it with glReadPixels. Then you
> >>> could read the pixels straight into the memory buffer used by your
> >>> AVFrame.
> >>>
> >>> That way you would save the overhead of a new QImage being allocated
> >>> each time, which might speed things up..?
> >>>
> >>> Just ideas here. Have not worked with GL or ffmpeg before.
> >

Re: [Interest] Faster way of rendering QOpenGLFramebufferObject to image

[Elvis Stansvik]

My idea would be something like (sketch):

main.cpp:

#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
   QGuiApplication app(argc, argv);

   auto view = new QQuickView;
   view->setSource(QUrl::fromLocalFile("test.qml"));
   view->show();

   // I use a QVector here, but you would have your AVFrame and
   // its allocated memory buffer..
   QVector buffer;
   QMutex mutex;

   QObject::connect(view, ::afterRendering, view, [&]() {
   mutex.lock();
   buffer.resize(4 * view->width() * view->height());
   glReadPixels(0, 0, view->width(), view->height(), GL_RGBA,
GL_UNSIGNED_BYTE, buffer.data());
   mutex.unlock();
   }, Qt::DirectConnection);

   return app.exec();
}

test.qml:

import QtQuick 2.2

Rectangle {
   width: 1920
   height: 1080

   Rectangle {
   width: 500
   height: 500
   color: "green"
   anchors.centerIn: parent
   RotationAnimation on rotation {
   from: 0
   to: 360
   duration: 2000
   loops: Animation.Infinite
   }
   }
}

I don't know whether this would work for you.

Elvis

Den tis 13 juli 2021 kl 15:31 skrev Nuno Santos :
>
> Elvis,
>
> Thanks for sharing your thoughts. It makes sense.
>
> I need to dive into the toImage function, try to read directly the bytes from 
> the FBO and see if that has any performance impact.
>
> Best regards,
>
> Nuno
>
> > On 13 Jul 2021, at 14:10, Elvis Stansvik  wrote:
> >
> > Hi Nuno,
> >
> > I'm really out of my waters here, but, provided you don't need to hold
> > on to each AVFrame after you are "done with it", you could perhaps
> > avoid having to allocate a QImage for each frame (which toImage forces
> > you to do) by just allocating a a single AVFrame and a single memory
> > buffer for it, and then do what toImage does, which is make sure the
> > FBO is bound and read the pixels off of it with glReadPixels. Then you
> > could read the pixels straight into the memory buffer used by your
> > AVFrame.
> >
> > That way you would save the overhead of a new QImage being allocated
> > each time, which might speed things up..?
> >
> > Just ideas here. Have not worked with GL or ffmpeg before.
> >
> > Elvis
> >
> > Den tis 13 juli 2021 kl 11:22 skrev Nuno Santos :
> >>
> >> Hi,
> >>
> >> I’m trying to capture the content of an FBO to a video file. This video 
> >> file should contain the animations generated by a qml scene.
> >>
> >> To do this, I’m recurring to QOpenGLFramebufferObject class toImage() 
> >> method.
> >>
> >> My scene is being drawn at 1920x1080. Each call to toImage takes 30 ms! :(
> >>
> >> If I want to render to file at 60 fps, ideally, this call would need to 
> >> take less than 16 ms to give me room to do other operations, such as video 
> >> encoding and the actual render.
> >>
> >> As anyone been here before? What other strategies are available to copy 
> >> the FBO data to an image?
> >>
> >> I’m using libav to encode the video file, therefor I need to fill an 
> >> AVFrame. Right now I’m filling the AVFrame from the QImage generated by 
> >> the FBO toImage method.
> >>
> >> Does any one knows a method of filling an AVFrame directly from texture 
> >> data?
> >>
> >> Thanks
> >>
> >> Best regards,
> >>
> >> Nuno
> >> ___
> >> 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] Faster way of rendering QOpenGLFramebufferObject to image

[Elvis Stansvik]

Hi Nuno,

I'm really out of my waters here, but, provided you don't need to hold
on to each AVFrame after you are "done with it", you could perhaps
avoid having to allocate a QImage for each frame (which toImage forces
you to do) by just allocating a a single AVFrame and a single memory
buffer for it, and then do what toImage does, which is make sure the
FBO is bound and read the pixels off of it with glReadPixels. Then you
could read the pixels straight into the memory buffer used by your
AVFrame.

That way you would save the overhead of a new QImage being allocated
each time, which might speed things up..?

Just ideas here. Have not worked with GL or ffmpeg before.

Elvis

Den tis 13 juli 2021 kl 11:22 skrev Nuno Santos :
>
> Hi,
>
> I’m trying to capture the content of an FBO to a video file. This video file 
> should contain the animations generated by a qml scene.
>
> To do this, I’m recurring to QOpenGLFramebufferObject class toImage() method.
>
> My scene is being drawn at 1920x1080. Each call to toImage takes 30 ms! :(
>
> If I want to render to file at 60 fps, ideally, this call would need to take 
> less than 16 ms to give me room to do other operations, such as video 
> encoding and the actual render.
>
> As anyone been here before? What other strategies are available to copy the 
> FBO data to an image?
>
> I’m using libav to encode the video file, therefor I need to fill an AVFrame. 
> Right now I’m filling the AVFrame from the QImage generated by the FBO 
> toImage method.
>
> Does any one knows a method of filling an AVFrame directly from texture data?
>
> Thanks
>
> Best regards,
>
> Nuno
> ___
> 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] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Elvis Stansvik]

Nice work Volker!

Elvis

Den fre 11 juni 2021 16:18Volker Hilsheimer  skrev:

> To close this thread, a bunch of changes that fix this in the least
> intrusive way have been merged for Qt 6.2.
>
> In ExtendedSelection, Ctrl+Press does not deselect items that could also
> be dragged, Ctrl+Release does; Ctrl+Press on an unselected item selects the
> item, then you can drag it as part of a previous selection. An equivalent
> change n MultiSelection (minus the Ctrl):
>
> * https://codereview.qt-project.org/c/qt/qtbase/+/351595/8
> * https://codereview.qt-project.org/c/qt/qtbase/+/352401
>
> Thanks for the comments and reviews. Qt 6.2 should be available as
> snapshot packages already, and the Alpha is around the corner as well.
> Early feedback to those (and several other changes and fixes to Qt Widgets
> from the last couple of weeks [1]) would be most welcome.
>
>
> Cheers,
> Volker
>
> [1]
> https://codereview.qt-project.org/q/is:merged+branch:dev+path:%255Esrc/widgets/.*+after:2021-05-31
>
>
> > On 1 Jun 2021, at 21:43, Volker Hilsheimer 
> wrote:
> >
> > But git history will remember the fool that broke all the things :P
> >
> > Anyway, a bunch of patches in the chain currently ending at
> >
> > https://codereview.qt-project.org/c/qt/qtbase/+/351595/3
> >
> > in case anyone wants to give it a swing. MultiSelection is not changed
> yet, and it looks like we might get away with a minimal change for
> ExtendedSelection.
> >
> > There’s no intention to bring those changes to Qt 5.
> >
> > Volker
> >
> >
> >> On 28 May 2021, at 19:01, Elvis Stansvik  wrote:
> >>
> >> Yea man, just change it. No one remembers a coward! :)
> >>
> >> Den fre 28 maj 2021 kl 17:07 skrev David M. Cotter :
> >>>
> >>> assuming your change "does the right thing in all cases" then i think
> it should be the default.
> >>>
> >>> nobody WANTS the currently-bad behavior.
> >>>
> >>> -dave
> >>>
> >>>> On May 28, 2021, at 5:55 AM, Volker Hilsheimer <
> volker.hilshei...@qt.io> wrote:
> >>>>
> >>>> Cross-posting from the development mailing list in case any of you
> have a strong opinion about this.
> >>>>
> >>>> Volker
> >>>>
> >>>>
> >>>>> On 28 May 2021, at 13:10, Volker Hilsheimer 
> wrote:
> >>>>>
> >>>>> Hey Widget fans,
> >>>>>
> >>>>> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
> >>>>>
> >>>>> The UX resulting from our (strange) choice to trigger selection
> changes on mouse press rather than mouse release is indeed quite horrible,
> as explained in the ticket.
> >>>>>
> >>>>> The options to fix that seem to be:
> >>>>>
> >>>>> 1) change the default behavior - always change selection on mouse
> release
> >>>>> 2) change the default behavior if drag (as per dragDropMode)
> >>>>> 3) make the "selection trigger" a property
> >>>>>
> >>>>> None of those options would IMHO result in a change that qualifies
> for stable branches. I’ve for now implemented option 3. This introduces new
> API, so if we agree that this is the way to go then it would ideally be
> merged before 6.2 feature freeze next Friday.
> >>>>>
> >>>>> https://codereview.qt-project.org/c/qt/qtbase/+/351595
> >>>>>
> >>>>> However, the possible property values seem oddly specific to this
> problem, and give that this is a 6.2 only change anyway, perhaps it would
> be best to simply change the default, which would then also make Qt
> matching native UIs better (ie Windows Explorer or macOS Finder)?
> >>>>>
> >>>>> Cheers,
> >>>>> Volker
> >>>>>
> >>>>> ___
> >>>>> 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
> >
> > ___
> > 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] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Elvis Stansvik]

Yea man, just change it. No one remembers a coward! :)

Den fre 28 maj 2021 kl 17:07 skrev David M. Cotter :
>
> assuming your change "does the right thing in all cases" then i think it 
> should be the default.
>
> nobody WANTS the currently-bad behavior.
>
> -dave
>
> > On May 28, 2021, at 5:55 AM, Volker Hilsheimer  
> > wrote:
> >
> > Cross-posting from the development mailing list in case any of you have a 
> > strong opinion about this.
> >
> > Volker
> >
> >
> >> On 28 May 2021, at 13:10, Volker Hilsheimer  
> >> wrote:
> >>
> >> Hey Widget fans,
> >>
> >> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
> >>
> >> The UX resulting from our (strange) choice to trigger selection changes on 
> >> mouse press rather than mouse release is indeed quite horrible, as 
> >> explained in the ticket.
> >>
> >> The options to fix that seem to be:
> >>
> >> 1) change the default behavior - always change selection on mouse release
> >> 2) change the default behavior if drag (as per dragDropMode)
> >> 3) make the "selection trigger" a property
> >>
> >> None of those options would IMHO result in a change that qualifies for 
> >> stable branches. I’ve for now implemented option 3. This introduces new 
> >> API, so if we agree that this is the way to go then it would ideally be 
> >> merged before 6.2 feature freeze next Friday.
> >>
> >> https://codereview.qt-project.org/c/qt/qtbase/+/351595
> >>
> >> However, the possible property values seem oddly specific to this problem, 
> >> and give that this is a 6.2 only change anyway, perhaps it would be best 
> >> to simply change the default, which would then also make Qt matching 
> >> native UIs better (ie Windows Explorer or macOS Finder)?
> >>
> >> Cheers,
> >> Volker
> >>
> >> ___
> >> 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] Locale detection of Qt application hosted via WASM

[Elvis Stansvik]

Den ons 28 apr. 2021 kl 22:05 skrev Thorsten Glaser :
>
> On Wed, 28 Apr 2021, Elvis Stansvik wrote:
>
> > Agree to put in an option to change language, but surely it should be
> > possible to have the default be based on the language the user has set
> > in the OS/browser, just like many web applications do? (not
>
> Sure, as last resort, if the user has not yet set a cookie or so,
> or connected a language with their account profile, this could
> determine the default language. You’re going to need a default
> anyway.

The language of the browser is going to be the desired one in the vast
majority of cases, so I would rather think of the unusual cases, such
as using someone elses computer or wanting a different language for
some other reason, where the user needs to actively change the
language, as the last resort.

>
> This is why I said make the language selection very discoverable
> (use icons, not just names; don’t place it too small in the
> bottom of the page, etc).

Agreed.

Elvis

>
> bye,
> //mirabilos
> --
> Infrastrukturexperte • tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
> Telephon +49 228 54881-393 • Fax: +49 228 54881-235
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> *
>
> Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter
>
> *
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Locale detection of Qt application hosted via WASM

[Elvis Stansvik]

Den ons 28 apr. 2021 kl 18:57 skrev Thorsten Glaser :
>
> On Wed, 28 Apr 2021, Nicholas Yue wrote:
>
> > I am new to locale handling in general and definitely new to locale on the
> > web browser.
>
> If you’re targetting a webbrowser, make the language selectable in
> the software itself. Anything else is an affront: both geolocation
> and browser language preferences fail, e.g. when in an Internet
> Café in a foreign country. Make it easily enough reachable and
> discoverable so it’ll be of use to all kinds of users. Then set
> the language of the application based on it and, perhaps, even
> store the chosen language in a cookie. DO NOT rely on either of the
> other possible language sources.

Agree to put in an option to change language, but surely it should be
possible to have the default be based on the language the user has set
in the OS/browser, just like many web applications do? (not
geolocation though, agree that is a bad basis for default language).

Elvis

>
> bye,
> //mirabilos
> --
> Infrastrukturexperte • tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
> Telephon +49 228 54881-393 • Fax: +49 228 54881-235
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> *
>
> Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter
>
> *
> ___
> 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] Help a unix guy on windows qmake

[Elvis Stansvik]

Den ons 21 apr. 2021 kl 20:43 skrev Elvis Stansvik :
>
> Den ons 21 apr. 2021 kl 19:49 skrev Jason H :
> >
> >
> >
> > > Sent: Wednesday, April 21, 2021 at 1:14 PM
> > > From: "Thiago Macieira" 
> > > To: interest@qt-project.org
> > > Subject: Re: [Interest] Help a unix guy on windows qmake
> > >
> > > On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > > > Now, when compiling, regardless of shadow build or not, refer to the 
> > > > libs by
> > > > adding to the project: +++ project.pro
> > > > + mingw {
> > > > + INCLUDEPATH += $PROJ/libraries/win/include
> > > > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > > > + }
> > > >
> > > > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build 
> > > > dir, be
> > > > it shadow or not. I don't want to copy the libraries to the shadow dir 
> > > > in
> > > > QMAKE_PRE_LINK because they *never* change.
> > >
> > > You're mixing environment variables and qmake variables. Qmake variables
> > > always start with a double dollar sign and are expanded by qmake when it
> > > writes the Makefile output. You can see their value with message().
> > >
> > > qmake does not expand environment variables at all.
> > >
> > > $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> > > Project MESSAGE: r = $X b
> > >
> > > The environment variables are written as-is to your Makefile. It's up to 
> > > you
> > > to write something that make will understand.
> > >
> > > $PROJ is not a valid environment variable expansion in Make.
> >
> >
> > Right. I used $PROJ for illustrative purposes. I guess the flaw in my 
> > thinking
> > is that when the shadow build is made, that there is some way to reference 
> > the
> > original location( other than ../project_name
> >
> > Maybe all I need is:
> > PROJ=../project
>
> I think you'd need to use $$_PRO_FILE_PWD_ for it to work in a shadow build 
> (?)
>
> E.g. assuming
>
> $PROJ/project.pro
> $PROJ/libraries/win/include/mylib.h
> $PROJ/libraries/win/x64/mylib.lib
>
> Something like
>
> mingw {
> INCLUDEPATH += $$_PRO_FILE_PWD_/libraries/win/include
> LIBS += $$_PRO_FILE_PWD_/libraries/win/x64
> }

Scratch my suggestion and just use $$PWD. I had misunderstood that variable.

The docs for it says it all: "Specifies the full path leading to the
directory containing the current file being parsed. This can be useful
to refer to files within the source tree when writing project files to
support shadow builds.", which sounds like what you need (and as
suggested by Jérôme in his mail.

Elvis

>
> Elvis
>
> >
> > Thank you for example. Very enlightening.
> > ___
> > 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] Help a unix guy on windows qmake

[Elvis Stansvik]

Den ons 21 apr. 2021 kl 20:43 skrev Elvis Stansvik :
>
> Den ons 21 apr. 2021 kl 19:49 skrev Jason H :
> >
> >
> >
> > > Sent: Wednesday, April 21, 2021 at 1:14 PM
> > > From: "Thiago Macieira" 
> > > To: interest@qt-project.org
> > > Subject: Re: [Interest] Help a unix guy on windows qmake
> > >
> > > On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > > > Now, when compiling, regardless of shadow build or not, refer to the 
> > > > libs by
> > > > adding to the project: +++ project.pro
> > > > + mingw {
> > > > + INCLUDEPATH += $PROJ/libraries/win/include
> > > > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > > > + }
> > > >
> > > > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build 
> > > > dir, be
> > > > it shadow or not. I don't want to copy the libraries to the shadow dir 
> > > > in
> > > > QMAKE_PRE_LINK because they *never* change.
> > >
> > > You're mixing environment variables and qmake variables. Qmake variables
> > > always start with a double dollar sign and are expanded by qmake when it
> > > writes the Makefile output. You can see their value with message().
> > >
> > > qmake does not expand environment variables at all.
> > >
> > > $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> > > Project MESSAGE: r = $X b
> > >
> > > The environment variables are written as-is to your Makefile. It's up to 
> > > you
> > > to write something that make will understand.
> > >
> > > $PROJ is not a valid environment variable expansion in Make.
> >
> >
> > Right. I used $PROJ for illustrative purposes. I guess the flaw in my 
> > thinking
> > is that when the shadow build is made, that there is some way to reference 
> > the
> > original location( other than ../project_name
> >
> > Maybe all I need is:
> > PROJ=../project
>
> I think you'd need to use $$_PRO_FILE_PWD_ for it to work in a shadow build 
> (?)
>
> E.g. assuming
>
> $PROJ/project.pro
> $PROJ/libraries/win/include/mylib.h
> $PROJ/libraries/win/x64/mylib.lib
>
> Something like
>
> mingw {
> INCLUDEPATH += $$_PRO_FILE_PWD_/libraries/win/include
> LIBS += $$_PRO_FILE_PWD_/libraries/win/x64

Should have been LIBS += $$_PRO_FILE_PWD_/libraries/win/x64/mylib.lib

Elvis

> }
>
> Elvis
>
> >
> > Thank you for example. Very enlightening.
> > ___
> > 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] Help a unix guy on windows qmake

[Elvis Stansvik]

Den ons 21 apr. 2021 kl 19:49 skrev Jason H :
>
>
>
> > Sent: Wednesday, April 21, 2021 at 1:14 PM
> > From: "Thiago Macieira" 
> > To: interest@qt-project.org
> > Subject: Re: [Interest] Help a unix guy on windows qmake
> >
> > On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > > Now, when compiling, regardless of shadow build or not, refer to the libs 
> > > by
> > > adding to the project: +++ project.pro
> > > + mingw {
> > > + INCLUDEPATH += $PROJ/libraries/win/include
> > > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > > + }
> > >
> > > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, 
> > > be
> > > it shadow or not. I don't want to copy the libraries to the shadow dir in
> > > QMAKE_PRE_LINK because they *never* change.
> >
> > You're mixing environment variables and qmake variables. Qmake variables
> > always start with a double dollar sign and are expanded by qmake when it
> > writes the Makefile output. You can see their value with message().
> >
> > qmake does not expand environment variables at all.
> >
> > $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> > Project MESSAGE: r = $X b
> >
> > The environment variables are written as-is to your Makefile. It's up to you
> > to write something that make will understand.
> >
> > $PROJ is not a valid environment variable expansion in Make.
>
>
> Right. I used $PROJ for illustrative purposes. I guess the flaw in my thinking
> is that when the shadow build is made, that there is some way to reference the
> original location( other than ../project_name
>
> Maybe all I need is:
> PROJ=../project

I think you'd need to use $$_PRO_FILE_PWD_ for it to work in a shadow build (?)

E.g. assuming

$PROJ/project.pro
$PROJ/libraries/win/include/mylib.h
$PROJ/libraries/win/x64/mylib.lib

Something like

mingw {
INCLUDEPATH += $$_PRO_FILE_PWD_/libraries/win/include
LIBS += $$_PRO_FILE_PWD_/libraries/win/x64
}

Elvis

>
> Thank you for example. Very enlightening.
> ___
> 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

[Elvis Stansvik]

Den tors 1 apr. 2021 kl 15:31 skrev Nuno Santos :
>
> I don’t see Roland's emails anymore because I’ve blocked him. He is a kind of 
> hater and lover of Qt at the same time. He loves when someone gives him a 
> spark to set this email list on fire and then write long emails full of 
> bullshit that only someone that has nothing to do has time to read.
>
> I use Qt for more than 10 years now. I’ve started my company alone in 2014. 
> Since then I’ve been building 7 products with Qt that I deploy for Windows, 
> Mac, iOS and Android.
>
> I’ve had issues, bugs, but most of them were not show stoppers. When a show 
> stopper bug appears I report it and it usually gets fixed. Some faster, some 
> slower, but every single one had a fix. The last one was fixed in less than a 
> month.
>
> My experience with Qt is very good. It has been keeping stability over all 
> this years and I’ve only mostly focused in building products.
>
> Has issues? Has! But Apple has issues, Microsoft has issues as every single 
> software company has issues, because software is constantly evolving.
>
> If it wasn’t Qt, I would be here giving this testimonial. It really helped me 
> to do more with less.
>
> Big shout to the Qt Team, keep the awesome work!!!

+1

I've also had a Roland-filter in place since early 2019. Should
frankly have added it much earlier. There are more productive things
to do than read his tantrums.

Elvis

>
> Best regards,
>
> Nuno Santos
> Founder / CEO / CTO
> www.imaginando.pt
>
> On 1 Apr 2021, at 12:05, Turtle Creek Software  wrote:
>
> In general, I agree with Roland about the need for stability.  The past 20 
> years we've spent most of our programming time just keeping up with Mac OS 
> changes. Meanwhile the Windows competition has been adding features.
>
> We want a platform that lets our C++ code be a cash cow, without all the 
> current upkeep. Stability for even longer than 15 years would be nice. Our 
> sales are about half Mac and half Windows, so cross-platform is the dream. We 
> want someone else to make the port to M1, and whatever Apple charges into 
> next. Then we can focus on solving problems for construction companies, 
> rather than rewriting GUI code just to stay in the same place.
>
> Qt promises that, but the Qt team responses on this thread make me nervous 
> about it being delivered. When folks get defensive, that's often a bad sign.
>
> I'm new to the Qt world, but the mix of an open-source project and a 
> profit-making company sounds extremely complicated.  Targeting everything 
> from medical devices to desktops sounds very complicated.
>
> I hope this forum isn't muzzled. Critical comments on a list like this are 
> not libel. They provide useful information amongst the noise. Netiquette is 
> about courtesy between humans. Corporations and projects don't have feelings 
> to hurt, so they probably need less protection.
>
> Casey McDermott
> TurtleSoft.com
>>
>>
> ___
> 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] QSqlQuery bind value

[Elvis Stansvik]

Yea, you can always use db.driver()->escapeIdentifier(x,
QSqlDriver::TableName) if you want to sleep a little better anyway.

Elvis


Den tis 16 mars 2021 kl 21:52 skrev Jérôme Godbout :
>
> Thanks, that was the problems, this is annoying, but I do create the query 
> prepare with a String with arg (I known this is bad, but the tablename is 
> provided by inner code only, this is not user inputs of any sort).
>
> On Mar 16, 2021, at 4:23 PM, Elvis Stansvik  wrote:
>
> Den tis 16 mars 2021 kl 21:21 skrev Elvis Stansvik :
>
>
> Den tis 16 mars 2021 kl 20:19 skrev Jérôme Godbout :
>
>
> Hi,
>
> I’m trying to use the Sql with Sqlite with Qt. The database seem to be 
> working just fine, but I run into troubles with the bind value. The named 
> bind doesn’t seem to work (Qt 5.15.2, Mac OS):
>
> m_sql->m_create_table(m_database);
>
> m_sql->m_create_table.prepare(R"raw(CREATE TABLE IF NOT EXISTS :table name 
> (idkey TEXT PRIMARY KEY, data TEXT) WITHOUT ROWID)raw”);
>
>
> You can't use a bound parameter value for the table name. This would
> be the case even if you used the SQLite C library. I imagine this is
> the case in other database engines as well.
>
>
> Some good answers here:
> https://stackoverflow.com/questions/11312737/can-i-parameterize-the-table-name-in-a-prepared-statement
>
> Elvis
>
>
> Elvis
>
>
>
> Note: I did try to add the ending ; it make no difference. Is it required? I 
> do not see it in any example.
>
>
> The prepare return false for some reason, I did try with quotes this solve 
> the prepare but I thing the escaping should be done automatically?! Is the 
> value escape character automatically for named and positional args? What is 
> wrong with this query, the query work just fine into sqlite3.
>
> CREATE TABLE IF NOT EXISTS ':tablename’ (idkey TEXT PRIMARY KEY, data TEXT) 
> WITHOUT ROWID;
>
>
> It doesn’t complain, but create a table name :table name instead! The replace 
> doesn’t occur into the quote ‘ '
>
> This query work just fine into sqlite command line.
>
> CREATE TABLE IF NOT EXISTS toto (idkey TEXT PRIMARY KEY, data TEXT) WITHOUT 
> ROWID;
>
>
> What is wrong with this?! This seem to be just like the examples, is SQLite 
> any special in that regards (I known only a single statement is required for 
> sqlite).
>
> Thanks,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
> Jerome Godbout
> Software/Firmare Lead Amotus
>
> C: (581) 777-0050
> O: (418) 800-1073 ext.: 114
> godbo...@amotus.ca
>
>
>
> dimonoff.com   |amotus.ca
>
> We have moved!
> 1015 Avenue Wilfrid-Pelletier, Québec, QC G1W 0C4, 4e étage
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QSqlQuery bind value

[Elvis Stansvik]

Den tis 16 mars 2021 kl 21:21 skrev Elvis Stansvik :
>
> Den tis 16 mars 2021 kl 20:19 skrev Jérôme Godbout :
> >
> > Hi,
> >
> > I’m trying to use the Sql with Sqlite with Qt. The database seem to be 
> > working just fine, but I run into troubles with the bind value. The named 
> > bind doesn’t seem to work (Qt 5.15.2, Mac OS):
> >
> > m_sql->m_create_table(m_database);
> >
> > m_sql->m_create_table.prepare(R"raw(CREATE TABLE IF NOT EXISTS :table name 
> > (idkey TEXT PRIMARY KEY, data TEXT) WITHOUT ROWID)raw”);
>
> You can't use a bound parameter value for the table name. This would
> be the case even if you used the SQLite C library. I imagine this is
> the case in other database engines as well.

Some good answers here:
https://stackoverflow.com/questions/11312737/can-i-parameterize-the-table-name-in-a-prepared-statement

Elvis

>
> Elvis
>
> >
> >
> > Note: I did try to add the ending ; it make no difference. Is it required? 
> > I do not see it in any example.
> >
> >
> > The prepare return false for some reason, I did try with quotes this solve 
> > the prepare but I thing the escaping should be done automatically?! Is the 
> > value escape character automatically for named and positional args? What is 
> > wrong with this query, the query work just fine into sqlite3.
> >
> > CREATE TABLE IF NOT EXISTS ':tablename’ (idkey TEXT PRIMARY KEY, data TEXT) 
> > WITHOUT ROWID;
> >
> >
> > It doesn’t complain, but create a table name :table name instead! The 
> > replace doesn’t occur into the quote ‘ '
> >
> > This query work just fine into sqlite command line.
> >
> > CREATE TABLE IF NOT EXISTS toto (idkey TEXT PRIMARY KEY, data TEXT) WITHOUT 
> > ROWID;
> >
> >
> > What is wrong with this?! This seem to be just like the examples, is SQLite 
> > any special in that regards (I known only a single statement is required 
> > for sqlite).
> >
> > Thanks,
> >
> > ___
> > 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] QSqlQuery bind value

[Elvis Stansvik]

Den tis 16 mars 2021 kl 20:19 skrev Jérôme Godbout :
>
> Hi,
>
> I’m trying to use the Sql with Sqlite with Qt. The database seem to be 
> working just fine, but I run into troubles with the bind value. The named 
> bind doesn’t seem to work (Qt 5.15.2, Mac OS):
>
> m_sql->m_create_table(m_database);
>
> m_sql->m_create_table.prepare(R"raw(CREATE TABLE IF NOT EXISTS :table name 
> (idkey TEXT PRIMARY KEY, data TEXT) WITHOUT ROWID)raw”);

You can't use a bound parameter value for the table name. This would
be the case even if you used the SQLite C library. I imagine this is
the case in other database engines as well.

Elvis

>
>
> Note: I did try to add the ending ; it make no difference. Is it required? I 
> do not see it in any example.
>
>
> The prepare return false for some reason, I did try with quotes this solve 
> the prepare but I thing the escaping should be done automatically?! Is the 
> value escape character automatically for named and positional args? What is 
> wrong with this query, the query work just fine into sqlite3.
>
> CREATE TABLE IF NOT EXISTS ':tablename’ (idkey TEXT PRIMARY KEY, data TEXT) 
> WITHOUT ROWID;
>
>
> It doesn’t complain, but create a table name :table name instead! The replace 
> doesn’t occur into the quote ‘ '
>
> This query work just fine into sqlite command line.
>
> CREATE TABLE IF NOT EXISTS toto (idkey TEXT PRIMARY KEY, data TEXT) WITHOUT 
> ROWID;
>
>
> What is wrong with this?! This seem to be just like the examples, is SQLite 
> any special in that regards (I known only a single statement is required for 
> sqlite).
>
> Thanks,
>
> ___
> 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] QML MouseArea containsMouse is set to true even if it's not actually

[Elvis Stansvik]

Den ons 24 feb. 2021 17:09Alexander Dyagilev  skrev:

> It seems that HoverHandler is not affected by this bug:
> https://doc.qt.io/qt-5.12/qml-qtquick-hoverhandler.html
>
> I've switched to it - the problem is not happening anymore.
>

Glad it worked out, but if you think there is a bug in MouseArea, please
report it on the bugtracker with a minimal testcase included.

Elvis

On 2/15/2021 8:14 PM, Alexander Dyagilev wrote:
>
> Hello,
>
> In our code we have one MouseArea which fills entire parent:
> MouseArea {
>
> id: mouseAreaRow
>
> hoverEnabled: true
>
> anchors.fill: parent
>
> propagateComposedEvents: true
>
> onPressed: { mouse.accepted = false }
>
> }
>
> And we have another MouseArea which fills a small part of the same area
> which the first MouseArea fills:
>
> MouseArea {
>
> id: mouseAreaUp
>
> hoverEnabled: true
>
> anchors.fill: parent
>
> cursorShape: Qt.PointingHandCursor
>
> }
>
> The problem is that sometimes mouseAreaUp.containsMouse continues to be
> set to true even after the mouse left its area. Most of the time it happens
> when the mouse pointer is moved very fast.
>
> Is this a known issue or maybe some misunderstanding on our side?
>
> Is there any workaround? Is it possible to at least force MouseArea to
> recheck if it really contains the mouse pointer?
>
> ___
> 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?

[Elvis Stansvik]

I am also interested in this. We may not be able to move our application to
Qt 6 in quite a while, but would be nice if we didn't have to leave macOS
users who upgrade their OS in the dust.

Elvis

Den ons 9 dec. 2020 08:09Ben Haller via Interest 
skrev:

> 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!
>
> Cheers,
> -B.
>
> Benjamin C. Haller
> Messer Lab
> Cornell University
>
> ___
> 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

[Elvis Stansvik]

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

[Elvis Stansvik]

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

Re: [Interest] how to get 3 pixel focus ring?

[Elvis Stansvik]

If you really want this, how about a proxy style? (QProxyStyle). I think
that's the only way for you to get what you want.

You could try to wrangle it using a QFocusFrame subclass with custom
paintEvent, but you'd have to manually track widget resizes using an event
filter, and I'm not sure you're guaranteed that all styles will respect the
focus frame and stand off on painting their own focus visualization. When I
tried it here with the Breeze style I'd get both my own QFocusFrame and
Breeze's own focus visualization, which stuck out a little underneath since
it's rounded.

I know you didn't want any judgement but in general it's bad to disregard
the user's choice of widget style and do these kind of customizations. I as
a Breeze user wish to see Breeze's focus visualization, not that
applications override them.

Even if you have had that look for 10 years without users complaining, it
does not mean they like it - they could just see it as a minor oddity and
shrug at it.

Elvis

Den sön 7 juni 2020 23:21David M. Cotter  skrev:

> i have an example project (see below), that tries 6 different
> implementations, attempts to make the focus ring 3 pix wide. None of them
> work on windows, and only one of them PARTIALLY works on mac. What i want
> is the style you get around a text edit on mac, but i want that style on
> ALL widgets, and i want it on windows too.
>
> anyone have any idea how i can accomplish this?
>
> Please see the example project .
> I've set it up so the same code can be run on both mac and windows (use
> file sharing to run both at once).
>
> 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] Crash due to missing symbol

[Elvis Stansvik]

Den lör 6 juni 2020 kl 12:33 skrev Elvis Stansvik :
>
> Den lör 6 juni 2020 kl 08:54 skrev Alexander Carôt :
> >
> > Hi Ben and all,
> >
> > thanks for the quick reply. In fact I am using two Qt versions - one for 
> > recent and one for older OSX. For the older ones I am using Qt5.9.2 and so 
> > far this had been working until now. Furthermore, I am compiling my app via 
> > qmake / make on the terminal and don't use XCode. In case you have further 
> > ideas please let me know.
>
> When building using QMake from command line, you can use e.g.
>
> qmake QMAKE_MACOSX_DEPLOYMENT_TARGET=10.12
>
> to set the deployment target version.

Judging by the documentation though, the default value for
QMAKE_MACOSX_DEPLOYMENT_TARGET should be the earliest version
supported by Qt. So it's a bit strange you mentioned it won't run on
macOS 10.13 (assuming you're using Qt 5.15).

Elvis

[1] https://doc.qt.io/qt-5/macos.html#target-platforms

>
> Remember to check the supported target versions for the Qt you're using:
>
> - Qt 5.12: https://doc.qt.io/qt-5.12/macos.html#supported-versions
> - Qt 5.14: https://doc.qt.io/qt-5.14/macos.html#supported-versions
> - Qt 5.15: https://doc.qt.io/qt-5.15/macos.html#supported-versions
>
> In short: The minimum for Qt 5.12 is macOS 10.12, while for Qt 5.14
> and Qt 5.15 it's macOS 10.13.
>
> I'm not sure what the minimum for Qt 5.9 was, but I believe it may
> have been macOS 10.10.
>
> Cheers,
> Elvis
>
> >
> > Best
> >
> > Alex
> >
> >
> > --
> > http://www.carot.de
> > Email : alexan...@carot.de
> > Tel.: +49 (0)177 5719797
> >
> >
> > > Gesendet: Freitag, 05. Juni 2020 um 22:03 Uhr
> > > Von: "Ben Haller" 
> > > An: "Alexander Carôt" 
> > > Cc: "qt qt" 
> > > Betreff: Re: [Interest] Crash due to missing symbol
> > >
> > > Hi Alex.  Do you have the “deployment target” set to 10.10, not 10.14, in 
> > > your project?  In Xcode this is in the project settings; in Qt Creator 
> > > it’s a setting in the .pro file.  You can’t set it to be any earlier than 
> > > the Qt version you are running against, however, or precisely this sort 
> > > of thing will happen.  If you need to run on older OS X versions, you 
> > > need to make sure the Qt version you’re using is compatible with those 
> > > older versions.  (I forget where this information is, but Google always 
> > > finds it for me.  :->)
> > >
> > > Cheers,
> > > -B.
> > >
> > > Benjamin C. Haller
> > > Messer Lab
> > > Cornell University
> > >
> > >
> > > > On Jun 5, 2020, at 3:55 PM, Alexander Carôt  
> > > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > when running my Qt app (compiled on Catalona with SDK10.15) on older 
> > > > OSX < 10.14 down to 10.10 I get the following crash when initializing 
> > > > the audio interface:
> > > >
> > > > Termination Reason: DYLD, [0x4] Symbol missing
> > > >
> > > > Dyld Error Message:
> > > > Symbol not found: chkstk_darwin
> > > > Referenced from: /Applications/soundjack.app/Contents/MacOS/soundjack
> > > > Expected in: /usr/lib/libSystem.B.dylib
> > > >
> > > > Does anyone know how to debug this ?
> > > >
> > > > Thanks in advance,
> > > > best
> > > >
> > > > Alex
> > > >
> > > > --
> > > > http://www.carot.de
> > > > Email : alexan...@carot.de
> > > > Tel.: +49 (0)177 5719797
> > > >
> > > > ___
> > > > 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 due to missing symbol

[Elvis Stansvik]

Den lör 6 juni 2020 kl 08:54 skrev Alexander Carôt :
>
> Hi Ben and all,
>
> thanks for the quick reply. In fact I am using two Qt versions - one for 
> recent and one for older OSX. For the older ones I am using Qt5.9.2 and so 
> far this had been working until now. Furthermore, I am compiling my app via 
> qmake / make on the terminal and don't use XCode. In case you have further 
> ideas please let me know.

When building using QMake from command line, you can use e.g.

qmake QMAKE_MACOSX_DEPLOYMENT_TARGET=10.12

to set the deployment target version.

Remember to check the supported target versions for the Qt you're using:

- Qt 5.12: https://doc.qt.io/qt-5.12/macos.html#supported-versions
- Qt 5.14: https://doc.qt.io/qt-5.14/macos.html#supported-versions
- Qt 5.15: https://doc.qt.io/qt-5.15/macos.html#supported-versions

In short: The minimum for Qt 5.12 is macOS 10.12, while for Qt 5.14
and Qt 5.15 it's macOS 10.13.

I'm not sure what the minimum for Qt 5.9 was, but I believe it may
have been macOS 10.10.

Cheers,
Elvis

>
> Best
>
> Alex
>
>
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
>
>
> > Gesendet: Freitag, 05. Juni 2020 um 22:03 Uhr
> > Von: "Ben Haller" 
> > An: "Alexander Carôt" 
> > Cc: "qt qt" 
> > Betreff: Re: [Interest] Crash due to missing symbol
> >
> > Hi Alex.  Do you have the “deployment target” set to 10.10, not 10.14, in 
> > your project?  In Xcode this is in the project settings; in Qt Creator it’s 
> > a setting in the .pro file.  You can’t set it to be any earlier than the Qt 
> > version you are running against, however, or precisely this sort of thing 
> > will happen.  If you need to run on older OS X versions, you need to make 
> > sure the Qt version you’re using is compatible with those older versions.  
> > (I forget where this information is, but Google always finds it for me.  
> > :->)
> >
> > Cheers,
> > -B.
> >
> > Benjamin C. Haller
> > Messer Lab
> > Cornell University
> >
> >
> > > On Jun 5, 2020, at 3:55 PM, Alexander Carôt  
> > > wrote:
> > >
> > > Hi all,
> > >
> > > when running my Qt app (compiled on Catalona with SDK10.15) on older OSX 
> > > < 10.14 down to 10.10 I get the following crash when initializing the 
> > > audio interface:
> > >
> > > Termination Reason: DYLD, [0x4] Symbol missing
> > >
> > > Dyld Error Message:
> > > Symbol not found: chkstk_darwin
> > > Referenced from: /Applications/soundjack.app/Contents/MacOS/soundjack
> > > Expected in: /usr/lib/libSystem.B.dylib
> > >
> > > Does anyone know how to debug this ?
> > >
> > > Thanks in advance,
> > > best
> > >
> > > Alex
> > >
> > > --
> > > http://www.carot.de
> > > Email : alexan...@carot.de
> > > Tel.: +49 (0)177 5719797
> > >
> > > ___
> > > 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] Models and aborting structural changes

[Elvis Stansvik]

Den tors 4 juni 2020 kl 09:00 skrev Elvis Stansvik :
>
> Den ons 3 juni 2020 10:38Jonathan Purol  skrev:
>>
>> Hello everyone,
>>
>> I've been in a bit of a tough spot recently with `QAbstractItemModel`.
>> I'll try to delineate my situation, then my problem, and then the
>> potential solutions and why I think they're all inferior to what I wish
>> to have.
>>
>> We have a desktop applications using QtWidgets, however instead of a
>> data model we obtain our data from an "external source" (this is a
>> little complicated in our use case, but you can think of it as a remote
>> server for all intents and purposes).
>> Now the server emits events for changes in the underlying data model.
>> For example there is an event for `itemAdded` with all appropriate data
>> points being passed to us via a web socket.
>> This is all fine and dandy.
>>
>> The problem arises when I try to now connect this to the model
>> representing all `Item` objects.
>> Qt requires both `beginInsertRows` and `endInsertRows` to be called when
>> these changes are made. Furthermore it requires the underlying data to
>> really only be changed in-between those calls. I.e. `rowCount` should
>> return something different at the time `beginInsertRows` is called than
>> at the time `endInsertRows` is called. So far so good. But we don't
>> really have that in-between point. We only get notified when the change
>> has already happened.
>>
>> There are a few solutions I could see here:
>> 1. Keep a local cache of all of the data, update it incrementally when
>> changes come through with this pattern:
>> - change events arrives
>> - emit "begin change"
>> - update internal data
>> - emit "end change"
>>
>> 2. Keep a local cache of all the data on a per-model basis then repeat
>> as can be seen above
>>
>> I dislike both of these changes, even if they do solve the issue
>> flawlessly. The reason for that is that it is quite a bit of overhead.
>> Both regarding code complexity as well as regarding memory usage and
>> performance. Don't get me wrong, having a cache is important, and we
>> will have one as well. What doesn't stick right with me is a cache that
>> in turn keeps track of all the data all the time.
>>
>> Now you might say "why not just have the server emit both a "before" and
>> a "after" change event for whatever happens.
>> Yeah, I would love to do that - but with Qt's current setup it just
>> isn't possible.
>> What Qt is missing is an `abortInsertRows` function to reset the model's
>> internal state.
>> There are many, many things that can go wrong in our setup, even IF the
>> data was successfully updated. And if we cannot tell Qt to revert the
>> changes in case such an error occurs we cannot possible use this approach.
>> The only solution I would see here would be to call
>> `begin/endResetModel` in case an error occurs, but that sounds like
>> trying to put a nail into a coffin with a wrecking ball.
>
>
> I understand your problem. I've not been in your situation, but how about
>
> - Change server to emit before and after events, plus a cancel event.
>
> - Upon receiving a before event, call beginInsertRows,
>
> - Upon receiving an after event, call endInsertRows,
>
> - Upon receiving a cancel event, call endInsertRows, then call 
> beginRemoveRows, remove the cancelled rows, then call endRemoveRows.
>
> Could that work? I don't think the models would ever show the cancelled data, 
> as control never returned to the event loop during the dance in the last step.

Thinking a bit more (and I'm no expert), if I understand your setup
correctly, I still think there's a race that could confuse your views.

If I understand you right, your model always reports "live" data from
the server, which I presume means your data(..) returns data fetched
from the server.

If so, then I think this scenario could happen (?):

1. View requests some data at index X, and gets back data Y.
2. Something happens on the server so the data changes.
3. The server sends out a change event.
4. View again requests some data at index X, but gets back data Z (!).
5. The change event arrives at your application.
...

This is a situation in which the data returned at some index changes
from the POV of the view, with no beginInsertRows/endInsertRows in
between, which I think is a breach of the Qt model/view contract.

I may be wrong though, so maybe someone more knowledgeable can step in
an confirm/deny.

Cheers,
Elvis


>
> Cheers,
> Elvis
>
>>
>> My questions now are as follows:
>>

Re: [Interest] Models and aborting structural changes

[Elvis Stansvik]

Den ons 3 juni 2020 10:38Jonathan Purol  skrev:

> Hello everyone,
>
> I've been in a bit of a tough spot recently with `QAbstractItemModel`.
> I'll try to delineate my situation, then my problem, and then the
> potential solutions and why I think they're all inferior to what I wish
> to have.
>
> We have a desktop applications using QtWidgets, however instead of a
> data model we obtain our data from an "external source" (this is a
> little complicated in our use case, but you can think of it as a remote
> server for all intents and purposes).
> Now the server emits events for changes in the underlying data model.
> For example there is an event for `itemAdded` with all appropriate data
> points being passed to us via a web socket.
> This is all fine and dandy.
>
> The problem arises when I try to now connect this to the model
> representing all `Item` objects.
> Qt requires both `beginInsertRows` and `endInsertRows` to be called when
> these changes are made. Furthermore it requires the underlying data to
> really only be changed in-between those calls. I.e. `rowCount` should
> return something different at the time `beginInsertRows` is called than
> at the time `endInsertRows` is called. So far so good. But we don't
> really have that in-between point. We only get notified when the change
> has already happened.
>
> There are a few solutions I could see here:
> 1. Keep a local cache of all of the data, update it incrementally when
> changes come through with this pattern:
> - change events arrives
> - emit "begin change"
> - update internal data
> - emit "end change"
>
> 2. Keep a local cache of all the data on a per-model basis then repeat
> as can be seen above
>
> I dislike both of these changes, even if they do solve the issue
> flawlessly. The reason for that is that it is quite a bit of overhead.
> Both regarding code complexity as well as regarding memory usage and
> performance. Don't get me wrong, having a cache is important, and we
> will have one as well. What doesn't stick right with me is a cache that
> in turn keeps track of all the data all the time.
>
> Now you might say "why not just have the server emit both a "before" and
> a "after" change event for whatever happens.
> Yeah, I would love to do that - but with Qt's current setup it just
> isn't possible.
> What Qt is missing is an `abortInsertRows` function to reset the model's
> internal state.
> There are many, many things that can go wrong in our setup, even IF the
> data was successfully updated. And if we cannot tell Qt to revert the
> changes in case such an error occurs we cannot possible use this approach.
> The only solution I would see here would be to call
> `begin/endResetModel` in case an error occurs, but that sounds like
> trying to put a nail into a coffin with a wrecking ball.
>

I understand your problem. I've not been in your situation, but how about

- Change server to emit before and after events, plus a cancel event.

- Upon receiving a before event, call beginInsertRows,

- Upon receiving an after event, call endInsertRows,

- Upon receiving a cancel event, call endInsertRows, then call
beginRemoveRows, remove the cancelled rows, then call endRemoveRows.

Could that work? I don't think the models would ever show the cancelled
data, as control never returned to the event loop during the dance in the
last step.

Cheers,
Elvis


> My questions now are as follows:
> Is there any chance `abort*` methods would be added in the future?
> Could I perhaps add such a method myself?
> Is it safe to just call `endInsertRows` when no changes were made?
> Is there a simple solution I overlooked?
>
> Sincerely,
> Jonathan Purol
>
> ___
> 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] Windows installer for Qt programs

[Elvis Stansvik]

Den tis 21 apr. 2020 kl 09:21 skrev "Alexander Carôt" :
>
> Hello all,
>
> I consider shipping my Qt built software with a conventional installer on 
> Windows.
>
> Can anyone give me a recommendation of a solid freeware for this purpose ?

Just to chime in to what others have said: Our project uses CMake and
we use CPack which in turn uses WiX to create an installer for us.

I did not have to learn too much WiX wizardry, just a basic
customization to make it associate certain files with out application.
It has worked well so far.

We also use

set(CMAKE_INSTALL_UCRT_LIBRARIES ON)
include(InstallRequiredSystemLibraries)

to get the C runtime DLLs (including Universal CRT) installed
alongside our application, and then use windeployqt + CMake's
fixup_bundle to get the rest of our dependencies installed alongside
the application.

Cheers,
Elvis

>
> Thanks in advance,
> best
>
> Alex
>
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
>
> ___
> 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 Creator licensing for companies with Qt Commercial developers

[Elvis Stansvik]

Den tis 31 mars 2020 kl 20:46 skrev Elvis Stansvik :
>
> Den tis 31 mars 2020 kl 20:40 skrev Giuseppe D'Angelo via Interest
> :
> >
> > Il 31/03/20 20:34, Elvis Stansvik ha scritto:
> > > Do you see the absurdity? For me as manager at F, to be sure we're not
> > > breaking the contract with Frob, we would have to stipulate our
> > > contract with G not only that they themselves stick with paid-support
> > > Frob tools, but that they in turn must stipulate the same in their
> > > contracts with any H type subcontractors.
> > >
> > > And you think this will encourage people to pick commercial Qt?
> >
> > Without such a clause, you could easily incorporate a wholly owned
> > subsidiary, make it do all the development as "contractors" using Open
> > Source Qt, get the finished product back, slap it under Commercial Qt
> > and enjoy the benefits of the commercial terms without having paid for
> > it during the development. That's what the clause is protecting against.
>
> Sure, I understand what it's protecting against. With all the
> confusion in the thread, I don't think anyone is confused about that.
> I just think it's an absurd protection.-

And, with the risk of running my analogy into the ridiculous, this
would rather be as if F was buying say floor tiles (== Qt) from Frob,
and the jackhammer (== Qt Creator) H was using happened to be made by
Frob as well.

Elvis

>
> Elvis
>
> >
> > My 2 c,
> > --
> > 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

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Elvis Stansvik]

Den tis 31 mars 2020 kl 20:40 skrev Giuseppe D'Angelo via Interest
:
>
> Il 31/03/20 20:34, Elvis Stansvik ha scritto:
> > Do you see the absurdity? For me as manager at F, to be sure we're not
> > breaking the contract with Frob, we would have to stipulate our
> > contract with G not only that they themselves stick with paid-support
> > Frob tools, but that they in turn must stipulate the same in their
> > contracts with any H type subcontractors.
> >
> > And you think this will encourage people to pick commercial Qt?
>
> Without such a clause, you could easily incorporate a wholly owned
> subsidiary, make it do all the development as "contractors" using Open
> Source Qt, get the finished product back, slap it under Commercial Qt
> and enjoy the benefits of the commercial terms without having paid for
> it during the development. That's what the clause is protecting against.

Sure, I understand what it's protecting against. With all the
confusion in the thread, I don't think anyone is confused about that.
I just think it's an absurd protection.

Elvis

>
> My 2 c,
> --
> 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

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Elvis Stansvik]

Den tis 31 mars 2020 kl 19:32 skrev Tuukka Turunen :
>
>
>
> Hi Jérôme et al,
>
>
>
> This thread has long ago left the original question and become a discussion 
> about Qt licensing in general and especially about the point of not mixing 
> commercial Qt with open-source version of Qt.
>
>
>
> The key point is: The Qt Company, just like Trolltech initially and other 
> companies in between, does not want mixing open-source Qt and commercial Qt.
>
>
>
> Reason is simple: if mixing was allowed, many companies would use it to pay 
> less for their use of Qt.
>
>
>
> It is unfortunate that also real open-source projects may be affected in some 
> cases. Majority of users are not affected in any way.
>
>
>
> It is also unfortunate if licensing is felt to be so complex that it is 
> better to use some other technology. Commercial licensing of Qt is quite 
> flexible and it is also possible to negotiate and ask for advice in case it 
> is unclear what is allowed and what not.
>
>
>
> Here are some examples that hopefully clarify the point about mixing 
> open-source and commercial:
>
>
>
> Example 1: Company A has 10 developers creating a product. 5 of them use Qt 
> under commercial license and 5 do not use Qt at all. This is ok.
>
>
>
> Example 2: Company B has 10 developers creating a product. 5 of them use Qt 
> under open-source license and 5 do not use Qt at all. This is ok.
>
>
>
> Example 3: Company C has 10 developers creating a product. 5 of them use Qt 
> under commercial license and 5 use Qt under open-source license. This is not 
> allowed.
>
>
>
> Example 4: Large company D is creating a product with Qt under commercial 
> license. Part of the work is subcontracted to Company E that uses Qt under 
> commercial license. This is ok.
>
>
>
> Example 5: Large company F is creating a product with Qt under commercial 
> license. Part of the work is subcontracted to Company G that uses Qt under 
> commercial license. Company G subcontracts some of the work further to 
> low-cost Company H, who uses Qt under open-source license. This is not 
> allowed.

I'm sorry, but you cannot be serious.

My company F owns a mall and decide to do some renovating of the
bottom floor, using our own staff for the renovation. We use a suite
of power tools from company Frob Inc, where we've decided to go with
the more expensive option which includes support from Frob if they
fail. After a while, we decide we cannot finish the renovation in time
and subcontract some of the demolition work required to external
contractor G. They too use Frob tools with paid support. Some time
into the demolition, several people at G quit their jobs, and the
manager at G decide to hire some folks from H, who use happen to use
one single Frob tool (say a jackhammer), but have not gone with the
paid support option. Now my company F is infringing the contract with
Frob.

Do you see the absurdity? For me as manager at F, to be sure we're not
breaking the contract with Frob, we would have to stipulate our
contract with G not only that they themselves stick with paid-support
Frob tools, but that they in turn must stipulate the same in their
contracts with any H type subcontractors.

And you think this will encourage people to pick commercial Qt?

Elvis

>
>
>
> Example 6: Company I is building two independent products with separate 
> development teams. One development team uses Qt under commercial license to 
> create product 1 and the other development team uses Qt under open-source 
> license to create product 2. This is ok.
>
>
>
> Hopefully I was able to clarify the topic with these examples. The Qt Company 
> wants to provide Qt under open-source license. There is no mega corporation 
> with deep pockets behind. Development of Qt is funded with the revenues 
> gained from commercial licensing.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
>
>
>
>
> From: Jérôme Godbout 
> Date: Tuesday 31. March 2020 at 17.56
> To: Tuukka Turunen , Andy 
> Cc: "interest@qt-project.org" 
> Subject: RE: [Interest] Qt Creator licensing for companies with Qt Commercial 
> developers
>
>
>
> Hi,
>
> the mix is not a corner case, it’s the reality of many people around. We are 
> a services compagnie, and this is really a headache to understand where it 
> should fall since we do project for client but we are a single cie. The 
> license of Qt have is such an ambiguity and our lawyer recommend (not even 
> sure himself where we do fall) we avoid using it as much as we can given the 
> context we are in. When a client have commercial license, we ask them to use 
> their infrastructure and avoid having any commercial license on premise (we 
> cannot take any chance). If you think your licensing is clear and make it 
> easy, it ain’t, we do more and more Xamarin, just for license reason not 
> because we like it.  I continue Qt mostly on hobby, really like Qml and where 
> the binding in C++ is heading. But for my work job, Qt is fading out.
>
>
>
> The departure 

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Elvis Stansvik]

Den mån 30 mars 2020 kl 19:50 skrev Tuukka Turunen :
>
>
>
> Hi,
>
>
>
> Please read the commercial license agreement and the licensing FAQ. The 
> restriction has nothing to do with open-source licensing. It is about a 
> company, who is using a commercially licensed Qt not to use parts of the same 
> licensed Qt product under open-source license. If there was no such 
> restriction, a company could have a team of 10 developers, but only 1 or 2 
> commercial license for Qt.

Up until now, you've said "same project". Now you are switching to
"company". Please clarify.

I'm assuming it is "project", since that's what the FAQ says.

If it is "project", please clarify what definition of project is used.

Elvis

>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> From: Jean-Michaël Celerier 
> Date: Friday 27. March 2020 at 17.46
> To: Tuukka Turunen 
> Cc: Giuseppe D'Angelo , "interest@qt-project.org" 
> 
> Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
> developers
>
>
>
> > Answer to this is: No, it is not allowed to mix commercial "Licensed 
> > Software" and the open-source versions provided by The Qt Company in the 
> > same project.
>
>
> What about open-source versions provided by another distributor, e.g. someone 
> doing apt install qtcreator ?
>
>
>
> Also how is that compatible with this part of the Qt Creator license  ?
>
> https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/LICENSE.GPL3-EXCEPT#n493
>
>
>
>
>
> Best,
>
> Jean-Michaël
>
>
>
>
>
>
>
> On Fri, Mar 27, 2020 at 4:24 PM Tuukka Turunen  wrote:
>
>
> Hi,
>
> This seems to become a longer thread than I envisioned, as apparently my 
> original response was not clear enough.
>
> In general, if there are any questions or concerns related to licensing, 
> check the FAQ: https://www.qt.io/faq/
>
> If you are looking for advise on licensing, I recommend either to read the 
> FAQ or consult a lawyer. While everyone here tries their best to give good 
> advice, it is possible that some incorrect information or interpretation is 
> presented (because licensing can be a difficult topic).
>
> Anyways, I'll now explain again the answer to the original question asked. 
> The question was, as I understood it, "Is it allowed that people working in a 
> project use commercially licensed Qt and some other persons in the same 
> project who do not develop Qt use open-source licensed Qt tools?"
>
> Answer to this is: No, it is not allowed to mix commercial "Licensed 
> Software" and the open-source versions provided by The Qt Company in the same 
> project.
>
> This is a restriction coming from the commercial license agreement: 
> https://www.qt.io/terms-conditions/
>
> The basic rule of thumb is: Don't mix. Use either only commercial or only 
> open-source versions of items provided by The Qt Company.
>
> Yours,
>
> Tuukka
>
> On 27.3.2020, 16.26, "Interest on behalf of Giuseppe D'Angelo via Interest" 
>  wrote:
>
> On 27/03/2020 15:03, Tomas Konir wrote:
> >
> > Sorry for possible misunderstanding, but i think, that original question
> > was little different.
> > Question was:
> >
> > There is company, where are two developer groups:
> > Group1: Use QtCreator and works with QT libraries (and works with other
> > code which not use QT libraries). All users have Commercial License.
> > Group2: Would like to use QtCreator and not use QT libraries (they
> > working only with QT unrelated code). The want use QtCreator only as IDE
> >
> > Can both groups use QtCreator?
> > I thought, that using QtCreator as IDE is not conditioned with having QT
> > Commercial license.
>
> The only difference that comes to mind is that the first group can use
> Qt Creator under its commercial license, which may come with some extra
> features (not exactly sure of which ones, at this particular point in 
> time).
>
> The second group can instead just use Qt Creator under its open source
> license. The open source license of Qt Creator itself does NOT extend in
> any way to the software you develop (cf. the GPL FAQ).
>
> HTH,
> --
> 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] Qt Creator licensing for companies with Qt Commercial developers

[Elvis Stansvik]

Den fre 27 mars 2020 kl 20:08 skrev :
>
> Hi.
>
> Tuuka clearly stated, that you wouldn't violate GPL of the (OS-)
> QtCreator, **but** you'd violate your commercial contract with Qt.
>
> If the commercial contract says, you are not allowed to have a cat in
> the house and you've signed that contract - then youd better get rid of
> Garfield.
>
> It doesn't matter if pets are allowed inside the building if they are
> clean. It doesn't matter if the bunch of people who that contract was
> signed for is sitting in a different room.
>
> This contract - as I reed Tuukas words - doesn't allow mixed use of
> commercial & OS inside a *company*. That's it.

It's even more confusing, because Tuuka did not say "company" - he say
"project". And what defines a project? You'll get various answers
depending on who you ask. Ask a big multi-national and a "project" may
be something spanning several decades, with many teams across the
world, from difference divisions of the company (or subsidiaries,
contractors or consultants), and the "project" may consist of many
software components, operating systems and infrastructure. Ask a
random person about their pet project on GitHub and they'll say the
project is "whatever is in this repo". And then there's of course a
wide spectrum in between.

Which definition is the Qt commercial license using?

> P.S.: My personal view on that: stupid contract in the first place.

Indeed, increbily so.

Elvis

>
>
> Am 27.03.2020 um 19:51 schrieb Michael Jackson:
> > OK, Here goes the explanations of how to interoperate with Qt Software 
> > packages. IANAL. We will start from the easy and work our way towards 
> > difficult.
> >
> > QtCreator: QtCreator is free. You, as a developer of software, can use 
> > QtCreator as your IDE to develop your own software. The GPL license of 
> > QtCreator will NOT infect your software. Use QtCreator to create open or 
> > closed software. Free or commercial. Your choice.
> >
> > QtCreator as Part of a Commercial Qt License: The only thing this gets you 
> > is the ability to get some "commercial" support versus just posting on the 
> > qt-creator mailing list.
> >
> > Modifying QtCreator: If you are actually modifying QtCreator yourself to 
> > create a distribution outside of your organization then ANY codes you write 
> > or modify are subject to the QtCreator license. This has ramifications if 
> > you happen to have a Qt commercial license.
> >
> > Using Qt5 in your software project: If you use Qt in your project ANYBODY 
> > contributing to that same project MUST have the same kind of Qt license. 
> > Period. Full Stop.
> >
> > For the original question;
> > "Is it still possible for the developers who don't use Qt libraries in
> > any way, use Qt Creator IDE for editing and debugging?"
> >
> > The answer is YES, but the devil is in the details. They *should* be able 
> > to just download the free version of QtCreator from http://download.qt.io 
> > and use that version. They can't use the "commercial" version of QtCreator 
> > unless they have a commercial license for Qt. But if their projects are 
> > *not* using Qt, then why do they have a commercial license for Qt?
> >
> >
> > Again, IANAL, but I believe this to be a reasonable summary of the 
> > licensing of QtCreator and Qt.
> > --
> > Mike Jackson
> >
> >
> >
> > On 3/27/20, 12:21 PM, "Interest on behalf of alexander golks" 
> >  wrote:
> >
> > Am Fri, 27 Mar 2020 17:11:16 +0100
> > schrieb Jean-Michaël Celerier :
> >
> > > It is also the license of the binaries that you can download there :
> > > https://download.qt.io/official_releases/qtcreator/4.11/4.11.1/
> > >
> > > And it states quite succintly :
> > > "This License explicitly affirms your unlimited permission to run the
> > > unmodified Program."
> > >
> > > > but if you just use qtcreator, just use it. its free.
> > >
> > > well, that is not what
> > > "
> > > Anyways, I'll now explain again the answer to the original question 
> > asked.
> > > The question was, as I understood it, "Is it allowed that people 
> > working in
> > > a project use commercially licensed Qt and some other persons in the 
> > same
> > > project who do not develop Qt use open-source licensed Qt tools?"
> > >
> > > Answer to this is: No, it is not allowed to mix commercial "Licensed
> > > Software" and the open-source versions provided by The Qt Company in 
> > the
> > > same project."
> > >
> > > seems to mean, which is why I'm wondering.
> >
> > the problem is, as already stated, that some did not answer your 
> > question properly.
> > i understood your question. and as i said, your mixing up things. as we 
> > say: you mix apples and pears.
> >
> > you're talking about using an executable X, based on open source 
> > software.
> > you're talking about using an library Y, for which you have a license, 
> > based on open source software, too.
> > 

Re: [Interest] Building strings with .arg() (arrrgh)

[Elvis Stansvik]

Den tors 5 mars 2020 kl 21:24 skrev Max Paperno :
>
> On 3/5/2020 3:11 PM, Elvis Stansvik wrote:
> > Den tors 5 mars 2020 kl 19:26 skrev Max Paperno :
> >> One thing for sure, since my benchmarks, from here on I will very much
> >> prefer the "multiArg" version of .arg() vs. using multiple .arg()s.
> >
> > Closing side note: There's a a nice Clazy diagnostic for that.
>
> Indeed, but IIRC it only warns when using multiple strings, like
> .arg("string").arg("other"), not with, for example
> .arg("string").arg(5). Whereas it's still considerably faster (and I
> presume more "efficient") to do .arg("string", QString::fromNumber(5)).
> Even just a single .arg(QString::fromNumber(5)) seems a little faster
> than .arg(5).

Oh right, I have the memory of a gold fish, forgetting that part of
your results.

Thanks for doing those benchmarks. Maybe the Clazy check could be
improved following your findings.

Elvis

>
> Best,
> -Max
> ___
> 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] Building strings with .arg() (arrrgh)

[Elvis Stansvik]

Den tors 5 mars 2020 kl 19:26 skrev Max Paperno :
>
>
> On 3/5/2020 10:20 AM, Benjamin TERRIER wrote:
> >
> > I believe Marc was saying that using QStringLiteral *inside* a .arg()
> > call is an anti-pattern,
> > and not that using .arg() *on* a QStringLiteral is one.
> >
>
> Hmmm, good point, indeed it could be read that way. There are two
> references to .arg() being available "on" (which I read as "for use
> with") QL1S that make me wonder and probably why I originally read it
> the other way.
>
>  From that e-mail[1]:
>
> "composition (QStringBuilder, append, prepend, arg() (now partly
> available on QStringView and QLatin1String, too)"
>
> and
>
> "arg(string, , string) ("multiArg") is available now on QL1S and
> QStringView"
>
> Since QL1S has already been available in the .arg() overload since 5.10
> but QL1S.arg() is newer.
>
> (Strangely there's no .arg(const char *) even though there's an
> append(const char *).)
>
> One thing for sure, since my benchmarks, from here on I will very much
> prefer the "multiArg" version of .arg() vs. using multiple .arg()s.

Closing side note: There's a a nice Clazy diagnostic for that.

Cheers,
Elvis

>
> Anyway, thanks for pointing that out.
>
> Cheers,
> -Max
>
>
> [1]:
> https://lists.qt-project.org/pipermail/development/2019-August/037145.html
> ___
> 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

[Elvis Stansvik]

Den mån 13 jan. 2020 kl 10:35 skrev Christoph Cullmann :
>
> 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 ;=)

I've always thought that page to be a bit unclear too.

The way I've understood it, and someone please correct me if I'm wrong is:

- "Legacy" applications, those who do not consider the screen DPI in
any custom painting they might do et.c., can use
QT_AUTO_SCREEN_SCALE_FACTOR=1 (or the equivalent
Qt::AA_EnableHighDpiScaling application attribute) to enable automatic
scaling.
- New applications, which are DPI aware and consider the DPI whenever
they do custom painting, should not need to set that attribute.

I'm basing this off of the last section on the page "Migrate Existing
Applications" 
(https://doc.qt.io/qt-5/highdpi.html#migrate-existing-applications),
which says:

"To get an application designed for low DPI values running on high
resolution monitors quickly, consider one of the following:

- let the application run as DPI Unaware on Windows
- set the QT_AUTO_SCREEN_SCALE_FACTOR environment variable to 1.

However, these options may result in some scaling or painting artifacts.

In the long term, the application should be adapted to run unmodified:

- Always use the qreal versions of the QPainter drawing API.
- Size windows and dialogs in relation to the corresponding screen size.
- Replace hard-coded sizes in layouts and drawing code with values
calculated from font metrics or screen size."

The impression I get here when it says "In the long term [...]" is
that newly written applications, which are themselves DPI aware,
should not need to turn on the auto-scaling.

This is what we do in our application. We set the
Qt::AA_UseHighDpiPixmaps attribute like you do, but we do not set the
Qt::AA_EnableHighDpiScaling attribute. Whenever we do custom painting
using e.g. QPainter, or we use other APIs than Qt to do painting (for
example VTK), we have to ensure we take the DPI into account.

For the painting that Qt does itself, e.g. painting menus, buttons,
text on buttons et.c., I believe Qt should (modulo bugs of course)
take DPI into account, and work without the
Qt::AA_EnableHighDpiScaling attribute set.

Again, please correct me if I'm wrong here. The
Qt::AA_EnableHighDpiScaling attribute is for applications which were
written "DPI oblivious", to transparently scale drawn stuff for them?

As a side note, the cross-platform story is that in macOS, there's a
true pixel scaling going on at a lower level, and the devicePixelRatio
reported by Qt will reflect this scaling.

On Windows, the OS "scaling" mechnism is different - the OS reports
different sizes/metrics to Qt, which Qt will respect when sizing
buttons et.c. The devicePixelRatio reported by Qt to applications will
always be 1.0 (unless Qt's own auto-scaling is turned on). This means
in DPI aware applications on Windows, to figure out the factor you
should scale your painting with, you need to use something else than
Qt's devicePixelRatio. What we've done is something like logicalDpiX()
/ 96.0 to figure out the factor. This is motivated by
https://docs.microsoft.com/sv-se/windows/win32/learnwin32/dpi-and-device-independent-pixels
which says that 100% in Windows's screen scaling corresponds to a
logical DPI of 96.

Elvis

>
> Greetings
> Christoph
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
> ___
> 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] Klocwork errors in Qt

[Elvis Stansvik]

Den mån 16 dec. 2019 15:16Stefan Neubert  skrev:

> > On Sat, 14 Dec 2019 at 21:57, Roland Hughes 
> wrote:
>
>
> On 12/14/19 2:54 PM, Massimiliano Maini wrote:
> >
> >
> > On Sat, 14 Dec 2019 at 15:12, Roland Hughes
> > mailto:rol...@logikalsolutions.com>>
> wrote:
> >
> > On 12/9/19 5:00 AM, Massimiliano Maini wrote:
> > > On Fri, 6 Dec 2019 at 19:41, Max Paperno > >  wrote:
> > >
> > >> On 12/4/2019 9:31 AM, Roland Hughes wrote:
> > >>> If you think auto won't be removed as a failed experiment, how
> > about
> > >> "new"? Deprecated in C++20 and slated for removal in C++23.
> > >>>   https://www.modernescpp.com/index.php/no-new-new
> > >>> Some more reading on the removal of pointers
> > >>>
> > >>>
> >
> https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/
> > >> TL;DR: This was a 2018 April Fool's joke.
> > >>
> > > Ouch. That must hurt.
> >
> > Gosh no. I'm more stunned that only one person got it. That was an
> > incredibly well written post. Everyone should read it. Too many QML
> > users I guess.
> >
> >
> > By pure chance I happen to occasionally read that blog
> > (  https://www.fluentcpp.com/
> > <
> https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/;;;).
>
> > Even by picking only two random articles anybody could see that the
> > ideas it promotes
> > are at the total opposite of yours.
> >
> > Let me speculate on how it went: you googled some random keywords,
> > clicked on
> > one of the top links pointing to a blog you've never heard of,
> > overlooked the title and
> > wrongly concluded that this just confirms you're right without
> > noticing it was an April's
> > fool.
> >
> > Now, trying to turn the whole thing in your favor is something not
> > even a fool would try.
> > But apparently you are willing to give it a go. Unsurprisingly, I'd say.
> >
> > Yawn.
> >
> You make the assumption that it wasn't deliberate. Not a safe assumption.
>
>
>
> > Yeah, I make that assumption and I'm fairly comfortable in taking the
> associated (nanoscopic)
> > risk.
>
>
>
> > The day you want to start talking about your own assumptions with
> respect the competency
> > level of anybody else than you on this mailing list, let us know.
>
>
> > Other than that, I do hope the mailing list has an archive somewhere. On
> the off chance any
> > newcomer gets impressd by your 200 lines, totally offtopic and rambling
> replies advocatng
>
> > some crazy security policy or whatever.
>
> First, @Massimiliano, the list archiv ist at
> https://lists.qt-project.org/pipermail/interest/
>
> Second, I want to thank all of you in the Qt community, for beeing open,
> friendly and competent.
> This is the reason I take part in this mail list.
>
> Now concerning the content, it is a pity, but every project has it´s
> Roland. Just remeber the discussion on QML.
> After the first Mails about the Klocwork error, I was wondering, when
> Roland would drip in.
>
> To share my strategy: When I feel that the goal of an email is to get
> attention and the author is known to
> attach more importance to showmanship than to make a contribution, my
> solution is to
>
> JUST IGNORE IT!
>

Well said. I think most of us on this list have a pretty well-developed
Roland filter at this point. It's sad that we have to, but unfortunately
one can't simply kick someone out for being obnoxious.

I agree with you. Whenever Roland comes around, press "Already read" and go
do something productive instead, because engaging with that troll is
anything but.

Elvis


> Stefan
>
> ___
> 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] QML and sensitive data

[Elvis Stansvik]

Den tors 5 sep. 2019 01:22Alexander Ivash  skrev:

> Thank you for fast response, but my question is purely about QML. On
> C++ side I have a lot of ways for nullifying / erasing sensitive
> information *after* it is not needed (let say after particular QML
> screen gets' closed). But on QML / JS side I have no any control at
> all. Would be great if one of QML guys could step in and comment too.
>
> Here is the small example illustrating my issue (all I need is to make
> 'Piter Pen' to disappear from memory dumps):
>
> 
>
> import QtQuick 2.12
> import QtQuick.Window 2.12
>
> Window {
> visible: true
> width: 640
> height: 480
> title: qsTr("Hello World")
>
> Component.onCompleted: {
> var test = "Piter Pen";
>
> // uncommenting results in a crash
> // backend.cleanup(test);
>
> // doesnt' nullify "Piter Pen"
> // gc();
>
> // doesn't work either
> /*
> Qt.callLater(() => {
>   gc();
>  })
>  */
> }
> }
>
> 
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> class Backend : public QObject
> {
> Q_OBJECT
> public:
> explicit Backend(QObject *parent = nullptr) {
> QString str1 = "Piter Pen";
> QString str2 = str1;
> QString str3 = str2;
>
> qDebug() << "str1:" << str1;
> qDebug() << "str2:" << str2;
> qDebug() << "str3:" << str3;
>
> cleanup(str1);
>
> qDebug() << "str1:" << str1;
> qDebug() << "str2:" << str2;
> qDebug() << "str3:" << str3;
> }
>
> Q_INVOKABLE void cleanup(const QString& str) {
> std::mt19937
> eng(std::chrono::system_clock::now().time_since_epoch().count());
> std::uniform_int_distribution distribution;
>
> QChar* data = const_cast (str.constData());
>
> for(int i = 0; i < str.length(); ++i) {
> data[i] = distribution(eng);
> }
>

Just a word of caution: Even if you had not gotten a crash, like Thiago
said you need to be very careful here: A smart compiler could possibly
decide that since the memory pointed to by data is not used after this, it
can optimize this entire loop of yours away.

Not saying that's going to happen, but you need to be very careful. I think
there are platform specific memory-zeroing functions that could be used
that are written with that in mind. At least I know OpenBSD has something
like that.

}
> };
>
> int main(int argc, char *argv[])
> {
> QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
>
> QGuiApplication app(argc, argv);
>
> Backend backend;
> QQmlApplicationEngine engine;
> const QUrl url(QStringLiteral("qrc:/main.qml"));
> QObject::connect(, ::objectCreated,
>  , [url](QObject *obj, const QUrl ) {
> if (!obj && url == objUrl)
> QCoreApplication::exit(-1);
> }, Qt::QueuedConnection);
> engine.rootContext()->setContextProperty("backend", );
> engine.load(url);
>
> return app.exec();
> }
>
> #include "main.moc"
>
> чт, 5 сент. 2019 г. в 01:32, Thiago Macieira :
> >
> > On Wednesday, 4 September 2019 14:46:09 PDT Alexander Ivash wrote:
> > > Is there any mechanism for cleanup sensitive data like passwords etc
> > > from QML? This issue is that gc() doesn't seem to even nullify memory
> > > (at least in release on Windows) so all the sensitive information
> > > stays in memory.
> >
> > Write in C++ and manage your memory VERY carefully. Remember that
> memset()
> > before free / delete or going out of scope is removed by the compiler.
> >
> > Don't use new or malloc. Instead, mmap() your chunk of memory yourself
> and
> > mlock() it properly.
> >
> > Of course, to display such information you need to accept that it is no
> longer
> > secure. It'll go to QML, then to the text engines, then the pixels will
> be
> > transferred to the display server or the GPU, etc.
> > --
> > 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] Static build of Qt - debug mode and plugins

[Elvis Stansvik]

Den mån 26 aug. 2019 kl 18:49 skrev Matthew Woehlke :
>
> On 26/08/2019 12.18, Elvis Stansvik wrote:
> > Den mån 26 aug. 2019 17:32Matthew Woehlke skrev:
> >> ...or just run `make VERBOSE=1`.
> >
> > I didn't know if he was using ninja or make, so suggested the solution that
> > I believe will work with both (with recent versions of CMake) :)
>
> Fair point. I'm pretty sure the `[1%] ...` is not Ninja (Ninja would
> normally be e.g. `[1/52] ...`), but it might have been Visual Studio.

Ah yes, well spotted. It wasn't VS since it's Linux. So your Make
assumption was probably correct.

>
> For some reason I took one look and immediately believed it to be
> `make`, but now I think that was my bad :-). (Possibly related to how
> often I use Windows these days... hardly ever. Also, when I do have to
> use Windows, I still use Ninja ;-).)

Amen.

Elvis

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

Re: [Interest] Static build of Qt - debug mode and plugins

[Elvis Stansvik]

Den mån 26 aug. 2019 17:32Matthew Woehlke  skrev:

> On 25/08/2019 03.09, Elvis Stansvik wrote:
> > Den sön 25 aug. 2019 kl 02:56 skrev Thiago Macieira:
> >> On Saturday, 24 August 2019 10:53:45 PDT Jakub Narolewski wrote:
> >>> [  1%] Linking CXX executable mrserver_debug
> >>
> >> Please expand this line.
> >
> > Jakub, to do this you can pass -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE to
> CMake.
>
> ...or just run `make VERBOSE=1`.
>
> Or, better yet, install Ninja and use `-G Ninja` when running CMake ;-).
> (And then `ninja -v`.) Your build times will thank you.
>

I didn't know if he was using ninja or make, so suggested the solution that
I believe will work with both (with recent versions of CMake) :)

(I could have dreamed up that it also works with ninja though.. It may have
just been a suggestion.)

Elvis


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

Re: [Interest] Static build of Qt - debug mode and plugins

[Elvis Stansvik]

Den sön 25 aug. 2019 kl 02:56 skrev Thiago Macieira :
>
> On Saturday, 24 August 2019 10:53:45 PDT Jakub Narolewski wrote:
> > [  1%] Linking CXX executable mrserver_debug
>
> Please expand this line.

Jakub, to do this you can pass -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE to CMake.

Elvis

> Since this is a static build, the order in which the
> libraries is listed matters.
>
> Make sure that you list the plugin before the QtSql library.
>
> --
> 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

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

[Elvis Stansvik]

Den tors 11 juli 2019 kl 06:49 skrev Vadim Peretokin :
>
> Thanks for this - mind pasting it as a gist for easy access?

Here it is: https://gist.github.com/estan/505cd5b4c18d80f1dd17ac2ea0f6c69e

Elvis

>
> On Wed, Jul 10, 2019 at 9:59 PM Elvis Stansvik  wrote:
>>
>> Den ons 10 juli 2019 kl 21:44 skrev Elvis Stansvik :
>> >
>> > Den ons 10 juli 2019 kl 21:20 skrev Adam Light :
>> > >
>> > >
>> > >
>> > > On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik  
>> > > wrote:
>> > >>
>> > >>
>> > >> With "work around" do you mean from the user POV (e.g. somehow
>> > >> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
>> > >> developer POV (so, having to notarize)?
>> > >>
>> > >
>> > > Instead of repeating myself here, please see my comment at 
>> > > https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
>> > >  which explains what I mean by "work around". I just added screen shots 
>> > > of the dialogs I mentioned in that comment so it's clear what the user 
>> > > sees.
>> > >
>> > >>
>> > >> I'd like to know if there is some reasonably simple way for users to
>> > >> get around the requirement. We will not be able to notarize every
>> > >> build we do, because of the time it takes. But at the same time we,
>> > >> and our testers, must be able to test random builds from Git (we build
>> > >> a .dmg for every commit) to try out in-progress features/bug fixes...
>> > >> So I really hope there will be some way for the user to get around the
>> > >> notarization requirement.
>> > >
>> > >
>> > > Notarization doesn't take more than a few minutes (in my limited 
>> > > experience) but it's a hassle to script the process. Your build machines 
>> > > and possibly your testers will not need to have a notarized application 
>> > > because, as I understand it, notarization is not required if the 
>> > > application does not have a quarantine flag. If it's been downloaded via 
>> > > a standard web browser, it should have the flag. But if it was built on 
>> > > the machine, or if it was transferred from another machine using 
>> > > something like curl, rsync, etc. then it is unlikely to have the 
>> > > quarantine flag.
>> >
>> > Yes, looking at our last tagged release build, the notarization step
>> > took 3 minutes 58 seconds.That's a doubling of our normal build time
>> > though, which is why we're hesitant to do it on every commit. That,
>> > and also I guess Apple don't really want people doing this anyway.
>> >
>> > Our testers normally pull the build artifacts using their web browser,
>> > so the downloaded .dmg will be quarantined. We could tell them to curl
>> > it of course, but we'd like to keep it as simple as possible for them
>> > to test a feature/bugfix in progress, and asking them to use a
>> > dedicated download tool goes against that.
>> >
>> > Scripting the notarization wasn't the painful thing. I made a quick
>> > Python script that does it, and it has worked fine since then. What
>>
>> This is the snippet, in case someone else finds it useful (note that
>> the --primary-bundle-id flag to altool is hard-coded in the script, so
>> you'll want to edit that):
>>
>> #!/usr/bin/env python3
>> #
>> # Notarize a file
>> #
>> # Usage: notarize-macos.py   
>> #
>>
>> from argparse import ArgumentParser
>> from subprocess import check_output
>> from plistlib import loads
>> from time import sleep
>>
>>
>> def main():
>> parser = ArgumentParser()
>> parser.add_argument('username', help='Apple ID user')
>> parser.add_argument('password', help='Apple ID password')
>> parser.add_argument('path', help='File to be notarized (e.g. .dmg)')
>> args = parser.parse_args()
>>
>> print('requesting notarization of {}...'.format(args.path))
>>
>> request_uuid = loads(check_output([
>> 'xcrun',
>> 'altool',
>> '--notarize-app',
>> '--primary-bundle-id', 'com.yourdomain.yourapp.dmg',
>> '--username', args.username,
>> '--password', args.password,
>> '--file'

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

[Elvis Stansvik]

Den ons 10 juli 2019 kl 21:44 skrev Elvis Stansvik :
>
> Den ons 10 juli 2019 kl 21:20 skrev Adam Light :
> >
> >
> >
> > On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik  wrote:
> >>
> >>
> >> With "work around" do you mean from the user POV (e.g. somehow
> >> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
> >> developer POV (so, having to notarize)?
> >>
> >
> > Instead of repeating myself here, please see my comment at 
> > https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
> >  which explains what I mean by "work around". I just added screen shots of 
> > the dialogs I mentioned in that comment so it's clear what the user sees.
> >
> >>
> >> I'd like to know if there is some reasonably simple way for users to
> >> get around the requirement. We will not be able to notarize every
> >> build we do, because of the time it takes. But at the same time we,
> >> and our testers, must be able to test random builds from Git (we build
> >> a .dmg for every commit) to try out in-progress features/bug fixes...
> >> So I really hope there will be some way for the user to get around the
> >> notarization requirement.
> >
> >
> > Notarization doesn't take more than a few minutes (in my limited 
> > experience) but it's a hassle to script the process. Your build machines 
> > and possibly your testers will not need to have a notarized application 
> > because, as I understand it, notarization is not required if the 
> > application does not have a quarantine flag. If it's been downloaded via a 
> > standard web browser, it should have the flag. But if it was built on the 
> > machine, or if it was transferred from another machine using something like 
> > curl, rsync, etc. then it is unlikely to have the quarantine flag.
>
> Yes, looking at our last tagged release build, the notarization step
> took 3 minutes 58 seconds.That's a doubling of our normal build time
> though, which is why we're hesitant to do it on every commit. That,
> and also I guess Apple don't really want people doing this anyway.
>
> Our testers normally pull the build artifacts using their web browser,
> so the downloaded .dmg will be quarantined. We could tell them to curl
> it of course, but we'd like to keep it as simple as possible for them
> to test a feature/bugfix in progress, and asking them to use a
> dedicated download tool goes against that.
>
> Scripting the notarization wasn't the painful thing. I made a quick
> Python script that does it, and it has worked fine since then. What

This is the snippet, in case someone else finds it useful (note that
the --primary-bundle-id flag to altool is hard-coded in the script, so
you'll want to edit that):

#!/usr/bin/env python3
#
# Notarize a file
#
# Usage: notarize-macos.py   
#

from argparse import ArgumentParser
from subprocess import check_output
from plistlib import loads
from time import sleep


def main():
parser = ArgumentParser()
parser.add_argument('username', help='Apple ID user')
parser.add_argument('password', help='Apple ID password')
parser.add_argument('path', help='File to be notarized (e.g. .dmg)')
args = parser.parse_args()

print('requesting notarization of {}...'.format(args.path))

request_uuid = loads(check_output([
'xcrun',
'altool',
'--notarize-app',
'--primary-bundle-id', 'com.yourdomain.yourapp.dmg',
'--username', args.username,
'--password', args.password,
'--file', args.path,
'--output-format', 'xml'
]))['notarization-upload']['RequestUUID']

for i in range(200):
response = loads(check_output([
'xcrun',
'altool',
'--notarization-info', request_uuid,
'--username', args.username,
'--password', args.password,
'--output-format', 'xml'
]))
if response['notarization-info']['Status'] == 'success':
print('notarization succeeded, see
{}'.format(response['notarization-info']['LogFileURL']))
print('stapling notarization to {}'.format(args.path))
print(check_output(['xcrun', 'stapler', 'staple',
args.path]).decode('utf-8'))
return
if response['notarization-info']['Status'] == 'invalid':
raise RuntimeError('notarization failed, response
was\n{}'.format(response))
sleep(3)

raise RuntimeError('notarization timed out, last response
was\n{}'.format(response))


if __name__ == '__main__':
main()

> bothers me is if it will make it harder for our testers. I wish Apple
> coul

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

[Elvis Stansvik]

Den ons 10 juli 2019 kl 21:20 skrev Adam Light :
>
>
>
> On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik  wrote:
>>
>>
>> With "work around" do you mean from the user POV (e.g. somehow
>> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
>> developer POV (so, having to notarize)?
>>
>
> Instead of repeating myself here, please see my comment at 
> https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
>  which explains what I mean by "work around". I just added screen shots of 
> the dialogs I mentioned in that comment so it's clear what the user sees.
>
>>
>> I'd like to know if there is some reasonably simple way for users to
>> get around the requirement. We will not be able to notarize every
>> build we do, because of the time it takes. But at the same time we,
>> and our testers, must be able to test random builds from Git (we build
>> a .dmg for every commit) to try out in-progress features/bug fixes...
>> So I really hope there will be some way for the user to get around the
>> notarization requirement.
>
>
> Notarization doesn't take more than a few minutes (in my limited experience) 
> but it's a hassle to script the process. Your build machines and possibly 
> your testers will not need to have a notarized application because, as I 
> understand it, notarization is not required if the application does not have 
> a quarantine flag. If it's been downloaded via a standard web browser, it 
> should have the flag. But if it was built on the machine, or if it was 
> transferred from another machine using something like curl, rsync, etc. then 
> it is unlikely to have the quarantine flag.

Yes, looking at our last tagged release build, the notarization step
took 3 minutes 58 seconds.That's a doubling of our normal build time
though, which is why we're hesitant to do it on every commit. That,
and also I guess Apple don't really want people doing this anyway.

Our testers normally pull the build artifacts using their web browser,
so the downloaded .dmg will be quarantined. We could tell them to curl
it of course, but we'd like to keep it as simple as possible for them
to test a feature/bugfix in progress, and asking them to use a
dedicated download tool goes against that.

Scripting the notarization wasn't the painful thing. I made a quick
Python script that does it, and it has worked fine since then. What
bothers me is if it will make it harder for our testers. I wish Apple
could state clearly whether the user will be allowed to override this
check (à la Ctrl-click -> Open instead of doubleclicking, which you
can use to bypass certificate verification).

Elvis

>
> Of course, it is possible that in the future the quarantine flag will not 
> control whether the notarization check happens, so what I said in the 
> paragraph above may change.
>
> Adam
>
> ___
> 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] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den ons 10 juli 2019 kl 13:20 skrev Andy :
>
> It sounds like not signing at all is still an option?

Yes, I guess not signing our builds (except releases), and asking
testers to use Ctrl-click + "Open" instead of double-clicking, is what
we'll do as a workaround, if it turns out there's no way for a user to
launch a signed build without it being notarized.

It's just a bit of awkward, I sort of liked how we had set up our CI
so that every build is essentially built like it was a release (well,
with the exception of this notarization, which we only do on tagged
releases due to the time it takes).

>
> "Mac apps, installer packages, and kernel extensions that are signed with 
> Developer ID must also be notarized by Apple in order to run on macOS 
> Catalina."
>
> Apple has made this way too complicated to be useful IMHO.

Yes, and it doesn't help that the notarization process is rather slow.
Oh well, one only has to accept it.

Elvis

>
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney
>
>
>
> On Wed, Jul 10, 2019 at 5:28 AM Elvis Stansvik  wrote:
>>
>> Den tis 9 juli 2019 kl 19:57 skrev Adam Light :
>> >
>> >
>> >
>> > 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.
>>
>> With "work around" do you mean from the user POV (e.g. somehow
>> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
>> developer POV (so, having to notarize)?
>>
>> I'd like to know if there is some reasonably simple way for users to
>> get around the requirement. We will not be able to notarize every
>> build we do, because of the time it takes. But at the same time we,
>> and our testers, must be able to test random builds from Git (we build
>> a .dmg for every commit) to try out in-progress features/bug fixes...
>> So I really hope there will be some way for the user to get around the
>> notarization requirement.
>>
>> Elvis
>>
>> >
>> > 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
>> > ___
>> > 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] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den tis 9 juli 2019 kl 19:57 skrev Adam Light :
>
>
>
> 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.

With "work around" do you mean from the user POV (e.g. somehow
disabling Gatekeeper, or Ctrl+Open, or something else) or from a
developer POV (so, having to notarize)?

I'd like to know if there is some reasonably simple way for users to
get around the requirement. We will not be able to notarize every
build we do, because of the time it takes. But at the same time we,
and our testers, must be able to test random builds from Git (we build
a .dmg for every commit) to try out in-progress features/bug fixes...
So I really hope there will be some way for the user to get around the
notarization requirement.

Elvis

>
> 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
> ___
> 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] [ANNOUNCE] GammaRay 2.11.0

[Elvis Stansvik]

Den fre 5 juli 2019 kl 21:03 skrev Vadim Peretokin :
>
> The Ubuntu 18.04 .deb does not seem to work:
>
> vadi@volga:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.2 LTS
> Release: 18.04
> Codename: bionic
> vadi@volga:~/Downloads$ sudo dpkg -i gammaray_2.11.0_amd64.deb
> [sudo] password for vadi:
> Selecting previously unselected package gammaray.
> (Reading database ... 357335 files and directories currently installed.)
> Preparing to unpack gammaray_2.11.0_amd64.deb ...
> Unpacking gammaray (2.11.0) ...
> dpkg: dependency problems prevent configuration of gammaray:
>  gammaray depends on kdstatemachineeditor; however:
>   Package kdstatemachineeditor is not installed.
>  gammaray depends on libqt5quickwidgets5 (>= 5.5.0); however:
>   Package libqt5quickwidgets5 is not installed.
>
> dpkg: error processing package gammaray (--install):
>  dependency problems - leaving unconfigured

This simply means you need to install kdstatemachineeditor and
libqt5quickwidgets5.

Remember that unlike e.g. apt, dpkg does not install dependencies -
it's just a tool for installing a specific package.

You can fix up things (install kdstatemachineeditor and
libqt5quickwidgets5) either manually, or by running

sudo apt --fix-broken install

HTH,
Elvis

> Processing triggers for libc-bin (2.27-3ubuntu1) ...
> Processing triggers for desktop-file-utils (0.23-1ubuntu3.18.04.2) ...
> Processing triggers for gnome-menus (3.13.3-11ubuntu1.1) ...
> Processing triggers for bamfdaemon (0.5.3+18.04.20180207.2-0ubuntu1) ...
> Rebuilding /usr/share/applications/bamf-2.index...
> Processing triggers for mime-support (3.60ubuntu1) ...
> Processing triggers for hicolor-icon-theme (0.17-2) ...
> Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
> Errors were encountered while processing:
>  gammaray
> vadi@volga:~/Downloads$
>
> On Fri, Jul 5, 2019 at 7:33 PM Allen Winter via Interest 
>  wrote:
>>
>> Announcing GammaRay 2.11.0
>>
>> Highlights of this Release:
>> =
>>  * Drop support for Qt 4 and Qt <= 5.4.
>>  * Drop support for MSVC 2010 and MSVC 2012, as well as GCC < 4.8.
>>  * Add support for more QtNetwork properties.
>>  * Add new network operations monitoring tool.
>>  * Fix inspection of QJson types.
>>  * Add thread affinity check to the problem reporter.
>>  * Add new event monitoring tool.
>>  * Initial forward compatibility with Qt6 build system.
>>  * Improved performance of the Qt Quick 2 inspector and the signal monitor.
>>
>> The source code can be found on GitHub at: https://github.com/KDAB/GammaRay
>> Tarballs and zipballs for v2.11.0 are available from: 
>> https://github.com/KDAB/GammaRay/releases
>>
>> For Linux users:
>>  * we provide pre-built packages for some popular distributions at:
>> https://software.opensuse.org/package/gammaray
>>
>> For OSX users:
>>  * we provide a homebrew recipe, see:
>> https://github.com/KDAB/homebrew-tap
>>
>> For Windows users:
>>  * you'll need to build from source
>>
>> GammaRay is a tool to poke around in a Qt-application and also to manipulate
>> the application to some extent. GammaRay uses various DLL injection
>> techniques to hook into an application at runtime and provide access to a
>> lot of interesting information.
>>
>> For more information about GammaRay, please see:
>>  * the KDAB GammaRay home page at http://www.kdab.com/gammaray
>>  * the GammaRay wiki at https://github.com/KDAB/GammaRay/wiki
>>  * the GammaRay User Manual at https://docs.kdab.com/gammaray-manual/latest/
>>  * the GammaRay API doc at https://docs.kdab.com/gammaray/latest/
>>
>> --
>> Allen Winter | allen.win...@kdab.com | Senior Software Engineer
>> KDAB (USA) LLC, a KDAB Group company
>> Tel. USA +1-866-777-KDAB(5322) ext3
>> 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] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den lör 22 juni 2019 kl 01:14 skrev Hamish Moffatt :
>
> On 21/6/19 9:13 pm, Elvis Stansvik wrote:
>
> Den fre 21 juni 2019 09:13Kai Köhne  skrev:
>>
>>
>> For the time being, it seems you've to execute the codesign call yourself.
>
>
> This is what I've done at work to prepare our builds for this. We use CMake 
> though and we're already running codesign manually.
>
> Great, we are already running codesign ourselves (as we add some other 
> frameworks post-macdeployqt), so adding the extra parameter is no big deal.
>
>
>
> The notarization is annoying and takes around 5 minutes for Apple to run 
> their virus scanners or whatever they're doing, so at the moment we're doing 
> it only on Git-tagged CI builds (releases), not on every commit. What this 
> gives us currently is that the macOS "do you want to run this" prompt will 
> say "Was scanned by Apple on blah blah and found to look good" or something.
>
> Will be more annoying if/when macOS starts to demand notarized builds, 
> because then we'd need to do notarization of every commit, or force testers 
> that wants to test a random build to turn off that checking (which I assume 
> is still going to be possible through System Preferences).
>
>
> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
>  says that it will be required on 10.15. Hopefully this will be easy to 
> disable for our testers as we don't want to notarize the daily builds. 
> Otherwise are uploading half a Gb of packages and then waiting for them to be 
> checked each time.
>
> Do you know if it's sufficient to notarize the final .dmg or .pkg, or do you 
> have to separately notarize and staple the .app before it is packaged? I 
> haven't been able to find a good answer yet. But the Apple check is 
> complaining about files inside my .app inside my .pkg, so I guess it will be 
> sufficient to do the final .pkg.

We send just the .dmg for notarization and staple it to that. It's enough.

Elvis

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

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

[Elvis Stansvik]

Den fre 21 juni 2019 15:33Michael Jackson 
skrev:

> *From: *Interest  on behalf of Elvis
> Stansvik 
> *Date: *Friday, June 21, 2019 at 7:14 AM
> *To: *Kai Köhne 
> *Cc: *Qt Interest 
> *Subject: *Re: [Interest] notarizing builds for Mac - enabling hardened
> runtime
>
>
>
> Den fre 21 juni 2019 09:13Kai Köhne  skrev:
>
> > -Original Message-
> > From: Interest  On Behalf Of Hamish
> > Moffatt
> > Sent: Friday, June 21, 2019 8:42 AM
> > To: Qt Interest 
> > Subject: [Interest] notarizing builds for Mac - enabling hardened runtime
> >
> > 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?
>
> 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.
>
>
>
> This is what I've done at work to prepare our builds for this. We use
> CMake though and we're already running codesign manually.
>
>
>
> The notarization is annoying and takes around 5 minutes for Apple to run
> their virus scanners or whatever they're doing, so at the moment we're
> doing it only on Git-tagged CI builds (releases), not on every commit. What
> this gives us currently is that the macOS "do you want to run this" prompt
> will say "Was scanned by Apple on blah blah and found to look good" or
> something.
>
>
>
> Will be more annoying if/when macOS starts to demand notarized builds,
> because then we'd need to do notarization of every commit, or force testers
> that wants to test a random build to turn off that checking (which I assume
> is still going to be possible through System Preferences).
>
>
>
> Apple, sigh, I can understand and sympathize requiring signed builds, but
> this mandatory "virus scanned by Apple" is a little silly. As a user I
> trust the virus scanner I pick myself more than some blackbox process on
> Apple HQ servers.
>
>
>
> Elvis
>
>
>
>
> Regards
>
> Kai
>
>
>
>
>
> My guess is that macOS will allow you to “override” the need to have the
> app scanned just like you can do now by right-clicking the app and clicking
> “open”. They would have to or
>

Yes, I guess so. And I guess that is what we'll ask of our beta testers
(who regularly pull random builds to try out new features under
development) to do, since having to notarize each commit is a bit much. I
guess Apple will discourage such behavior anyway, considering the load it
would put on their infra if everyone did so.

Elvis

developers wouldn’t be able to run their own apps or testers wouldn’t be
> able to run test apps. I don’t think macOS has gone the full “App Store
> Only” model yet, those days are coming. Still it would be good to get a
> definitive answer through Apple docs as to whether Notarization is
> mandatory or just strongly encouraged.
>
>
>
> --
>
> Mike Jackson
>
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Elvis Stansvik]

Den fre 21 juni 2019 15:39Konstantin Tokarev  skrev:

>
>
> 21.06.2019, 16:36, "Michael Jackson" :
> > Apple, sigh, I can understand and sympathize requiring signed builds,
> but this mandatory "virus scanned by Apple" is a little silly. As a user I
> trust the virus scanner I pick myself more than some blackbox process on
> Apple HQ servers.
>
> To be fair, it's not about protection of your system, but about protection
> of AppStore users and reputation of Apple as a company. For protection of
> your system you are free in choice of tools.
>

Yes, I guess so. It's just a little awkward so I guess I was just venting
some frustration :)

We are not publishing to AppStore BTW, but distributing .dmg to clients
ourself.

Elvis


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

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

[Elvis Stansvik]

Den fre 21 juni 2019 09:13Kai Köhne  skrev:

> > -Original Message-
> > From: Interest  On Behalf Of Hamish
> > Moffatt
> > Sent: Friday, June 21, 2019 8:42 AM
> > To: Qt Interest 
> > Subject: [Interest] notarizing builds for Mac - enabling hardened runtime
> >
> > 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?
>
> 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.
>

This is what I've done at work to prepare our builds for this. We use CMake
though and we're already running codesign manually.

The notarization is annoying and takes around 5 minutes for Apple to run
their virus scanners or whatever they're doing, so at the moment we're
doing it only on Git-tagged CI builds (releases), not on every commit. What
this gives us currently is that the macOS "do you want to run this" prompt
will say "Was scanned by Apple on blah blah and found to look good" or
something.

Will be more annoying if/when macOS starts to demand notarized builds,
because then we'd need to do notarization of every commit, or force testers
that wants to test a random build to turn off that checking (which I assume
is still going to be possible through System Preferences).

Apple, sigh, I can understand and sympathize requiring signed builds, but
this mandatory "virus scanned by Apple" is a little silly. As a user I
trust the virus scanner I pick myself more than some blackbox process on
Apple HQ servers.

Elvis


> Regards
>
> Kai
> ___
> 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] Behavioural change in QFile/QDir rename

[Elvis Stansvik]

Den mån 17 juni 2019 kl 09:37 skrev Federico Buti :
>
> Thanks all.
>
> My bad, I referred the crosscompilation for Windows as a reference point from 
> where we started the Qt bump, mostly because that was the major showstopper. 
> But on Linux we use vanilla Qt from qt.io installers. Hence I think any 
> compilation issue in Qt can be ruled out; or at least it feels quite unlikely 
> to be the real problem.

The official binaries I think are built on CentOS 7 (?). It seems to
have glibc 2.17, so those binaries would not use renameat2.

(I could be wrong because I don't know exactly how the build machines
are set up).

Elvis

> The meld screenshot, from the first mail, is a comparison between vanilla Qt 
> 5.6.2 and vanilla Qt 5.12.2, both from the Qt installer.
>
> As a secondary note, we do not use QTemporaryFile isntances in the test but 
> plain QFile intances, created inside a "source" QTemporaryDir from which 
> files are moved.
>
> Bests,
> F.
>
>
> On Mon, 17 Jun 2019 at 08:48, Elvis Stansvik  wrote:
>>
>> Den mån 17 juni 2019 07:47Elvis Stansvik  skrev:
>>>
>>> Den mån 17 juni 2019 kl 01:29 skrev Federico Buti :
>>> >
>>> > Hi Thiago.
>>> >
>>> > Thanks for the feedback.
>>> > I'm on Fedora 29 so definitely not on an old kernel as that. My colleague 
>>> > is on Ubuntu but I'm pretty sure it is a 16.xx release. I guess the usage 
>>> > of renameat2() is failing for some other reason. What could that be? Any 
>>> > idea?
>>>
>>> Apart from what Thiago said (you need a Qt built on a kernel that
>>> supports the syscall), another reason could be the file system that
>>> does not support renameat2.
>>
>>
>> To be completely correct, it may support the syscall, just not the 
>> RENAME_NOREPLACE flag.
>>
>> Elvis
>>
>>>
>>> For example non-local file systems (e.g. Samba/NFS/...) and eCryptfs
>>> do not support it.
>>>
>>> (I once made a bugreport against QTemporaryFile::rename about this,
>>> https://bugreports.qt.io/browse/QTBUG-64008 , and Thiago fixed it by
>>> making QFileSystemEngine fall back to link/unlink if renameat2 fails
>>> with EINVAL)
>>>
>>> Elvis
>>>
>>> Elvis
>>>
>>> >
>>> > Just in case, here is the code of the test. It basically create two 
>>> > temporary directories, starts watching on one of them via our 
>>> > FileEventsGatherer class and once the files are moved via QFile::rename, 
>>> > it compares the number of registered move/renames with the expect ones. 
>>> > "mkFile" just creates the file via QFile. No more, no less.
>>> >
>>> > void <>::testMoveFile()
>>> > {
>>> > QFETCH(QStringList,
>>> >fileNames);
>>> > QFETCH(qint32,
>>> >expectedResult);
>>> > QFETCH(bool,
>>> >rename);
>>> >
>>> > QTemporaryDir monitoredDir;
>>> > QTemporaryDir externalDir;
>>> > FileEventsGatherer feg;
>>> > feg.setPath(monitoredDir.path(),
>>> > FileEventsGatherer::FILE_EVENT__ALL,
>>> > OUTBOX_FILE_NAME_FILTER);
>>> > QSet overallMoved;
>>> > connect(,
>>> > ::filesMoved,
>>> > this,
>>> > [](QSet const )
>>> > {
>>> > overallMoved.unite(movedFiles);
>>> > });
>>> >
>>> > for (auto const  : fileNames)
>>> > {
>>> > QString const choosenPath {rename
>>> >? monitoredDir.path()
>>> >: externalDir.path()};
>>> > auto const sourcePath = 
>>> > QString("%1/%2").arg(choosenPath).arg("TempName");
>>> > auto const destPath = 
>>> > QString("%1/%2").arg(monitoredDir.path()).arg(file);
>>> > mkFile(sourcePath);
>>> > QFile mover(sourcePath);
>>> > mover.rename(destPath);
>>> > }
>>> >
>>> > QTest::qWait(SIGNALS_TIMEOUT_MS);
>>> > QCOMPARE(overallMoved.count(),
>>> >  expectedResult);
>>> > }
>>> >
>>> >

Re: [Interest] Behavioural change in QFile/QDir rename

[Elvis Stansvik]

Den mån 17 juni 2019 07:47Elvis Stansvik  skrev:

> Den mån 17 juni 2019 kl 01:29 skrev Federico Buti :
> >
> > Hi Thiago.
> >
> > Thanks for the feedback.
> > I'm on Fedora 29 so definitely not on an old kernel as that. My
> colleague is on Ubuntu but I'm pretty sure it is a 16.xx release. I guess
> the usage of renameat2() is failing for some other reason. What could that
> be? Any idea?
>
> Apart from what Thiago said (you need a Qt built on a kernel that
> supports the syscall), another reason could be the file system that
> does not support renameat2.
>

To be completely correct, it may support the syscall, just not the
RENAME_NOREPLACE flag.

Elvis


> For example non-local file systems (e.g. Samba/NFS/...) and eCryptfs
> do not support it.
>
> (I once made a bugreport against QTemporaryFile::rename about this,
> https://bugreports.qt.io/browse/QTBUG-64008 , and Thiago fixed it by
> making QFileSystemEngine fall back to link/unlink if renameat2 fails
> with EINVAL)
>
> Elvis
>
> Elvis
>
> >
> > Just in case, here is the code of the test. It basically create two
> temporary directories, starts watching on one of them via our
> FileEventsGatherer class and once the files are moved via QFile::rename, it
> compares the number of registered move/renames with the expect ones.
> "mkFile" just creates the file via QFile. No more, no less.
> >
> > void <>::testMoveFile()
> > {
> > QFETCH(QStringList,
> >fileNames);
> > QFETCH(qint32,
> >expectedResult);
> > QFETCH(bool,
> >rename);
> >
> > QTemporaryDir monitoredDir;
> > QTemporaryDir externalDir;
> > FileEventsGatherer feg;
> > feg.setPath(monitoredDir.path(),
> > FileEventsGatherer::FILE_EVENT__ALL,
> > OUTBOX_FILE_NAME_FILTER);
> > QSet overallMoved;
> > connect(,
> > ::filesMoved,
> > this,
> > [](QSet const )
> > {
> > overallMoved.unite(movedFiles);
> > });
> >
> > for (auto const  : fileNames)
> > {
> > QString const choosenPath {rename
> >? monitoredDir.path()
> >: externalDir.path()};
> > auto const sourcePath =
> QString("%1/%2").arg(choosenPath).arg("TempName");
> > auto const destPath =
> QString("%1/%2").arg(monitoredDir.path()).arg(file);
> > mkFile(sourcePath);
> > QFile mover(sourcePath);
> > mover.rename(destPath);
> > }
> >
> > QTest::qWait(SIGNALS_TIMEOUT_MS);
> > QCOMPARE(overallMoved.count(),
> >  expectedResult);
> > }
> >
> > Thanks,
> > F.
> >
> >
> > On Sat, 15 Jun 2019 at 20:50, Thiago Macieira 
> wrote:
> >>
> >> On Saturday, 15 June 2019 08:58:31 PDT Federico Buti wrote:
> >> > We gave strace a go and we noticed that 5.12 runtime acts differently
> for
> >> > rename/move operations (see attached compare screenshot). In
> particular, on
> >> > 5.6 we have an actual rename whereas a link/unlink sequence happens on
> >> > 5.12. That sequence is not detected by our code, generating the
> failure.
> >>
> >> Alternative: upgrade your system to a version that supports the
> renameat2()
> >> system call. You need a 3.16 Linux kernel and glibc 2.28.
> >>
> >> The link()/unlink() sequence is used on Unix filesystems to prevent
> rename()
> >> clobbering existing files, as promised in our API, but they're only
> attempted
> >> if renameat2() fails.
> >>
> >> --
> >> 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] Behavioural change in QFile/QDir rename

[Elvis Stansvik]

Den mån 17 juni 2019 kl 07:47 skrev Elvis Stansvik :
>
> Den mån 17 juni 2019 kl 01:29 skrev Federico Buti :
> >
> > Hi Thiago.
> >
> > Thanks for the feedback.
> > I'm on Fedora 29 so definitely not on an old kernel as that. My colleague 
> > is on Ubuntu but I'm pretty sure it is a 16.xx release. I guess the usage 
> > of renameat2() is failing for some other reason. What could that be? Any 
> > idea?
>
> Apart from what Thiago said (you need a Qt built on a kernel that

s/kernel/glibc/

> supports the syscall), another reason could be the file system that
> does not support renameat2.
>
> For example non-local file systems (e.g. Samba/NFS/...) and eCryptfs
> do not support it.
>
> (I once made a bugreport against QTemporaryFile::rename about this,
> https://bugreports.qt.io/browse/QTBUG-64008 , and Thiago fixed it by
> making QFileSystemEngine fall back to link/unlink if renameat2 fails
> with EINVAL)
>
> Elvis
>
> Elvis
>
> >
> > Just in case, here is the code of the test. It basically create two 
> > temporary directories, starts watching on one of them via our 
> > FileEventsGatherer class and once the files are moved via QFile::rename, it 
> > compares the number of registered move/renames with the expect ones. 
> > "mkFile" just creates the file via QFile. No more, no less.
> >
> > void <>::testMoveFile()
> > {
> > QFETCH(QStringList,
> >fileNames);
> > QFETCH(qint32,
> >expectedResult);
> > QFETCH(bool,
> >rename);
> >
> > QTemporaryDir monitoredDir;
> > QTemporaryDir externalDir;
> > FileEventsGatherer feg;
> > feg.setPath(monitoredDir.path(),
> > FileEventsGatherer::FILE_EVENT__ALL,
> > OUTBOX_FILE_NAME_FILTER);
> > QSet overallMoved;
> > connect(,
> > ::filesMoved,
> > this,
> > [](QSet const )
> > {
> > overallMoved.unite(movedFiles);
> > });
> >
> > for (auto const  : fileNames)
> > {
> > QString const choosenPath {rename
> >? monitoredDir.path()
> >: externalDir.path()};
> > auto const sourcePath = 
> > QString("%1/%2").arg(choosenPath).arg("TempName");
> > auto const destPath = 
> > QString("%1/%2").arg(monitoredDir.path()).arg(file);
> > mkFile(sourcePath);
> > QFile mover(sourcePath);
> > mover.rename(destPath);
> > }
> >
> > QTest::qWait(SIGNALS_TIMEOUT_MS);
> > QCOMPARE(overallMoved.count(),
> >  expectedResult);
> > }
> >
> > Thanks,
> > F.
> >
> >
> > On Sat, 15 Jun 2019 at 20:50, Thiago Macieira  
> > wrote:
> >>
> >> On Saturday, 15 June 2019 08:58:31 PDT Federico Buti wrote:
> >> > We gave strace a go and we noticed that 5.12 runtime acts differently for
> >> > rename/move operations (see attached compare screenshot). In particular, 
> >> > on
> >> > 5.6 we have an actual rename whereas a link/unlink sequence happens on
> >> > 5.12. That sequence is not detected by our code, generating the failure.
> >>
> >> Alternative: upgrade your system to a version that supports the renameat2()
> >> system call. You need a 3.16 Linux kernel and glibc 2.28.
> >>
> >> The link()/unlink() sequence is used on Unix filesystems to prevent 
> >> rename()
> >> clobbering existing files, as promised in our API, but they're only 
> >> attempted
> >> if renameat2() fails.
> >>
> >> --
> >> 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] Behavioural change in QFile/QDir rename

[Elvis Stansvik]

Den mån 17 juni 2019 kl 01:29 skrev Federico Buti :
>
> Hi Thiago.
>
> Thanks for the feedback.
> I'm on Fedora 29 so definitely not on an old kernel as that. My colleague is 
> on Ubuntu but I'm pretty sure it is a 16.xx release. I guess the usage of 
> renameat2() is failing for some other reason. What could that be? Any idea?

Apart from what Thiago said (you need a Qt built on a kernel that
supports the syscall), another reason could be the file system that
does not support renameat2.

For example non-local file systems (e.g. Samba/NFS/...) and eCryptfs
do not support it.

(I once made a bugreport against QTemporaryFile::rename about this,
https://bugreports.qt.io/browse/QTBUG-64008 , and Thiago fixed it by
making QFileSystemEngine fall back to link/unlink if renameat2 fails
with EINVAL)

Elvis

Elvis

>
> Just in case, here is the code of the test. It basically create two temporary 
> directories, starts watching on one of them via our FileEventsGatherer class 
> and once the files are moved via QFile::rename, it compares the number of 
> registered move/renames with the expect ones. "mkFile" just creates the file 
> via QFile. No more, no less.
>
> void <>::testMoveFile()
> {
> QFETCH(QStringList,
>fileNames);
> QFETCH(qint32,
>expectedResult);
> QFETCH(bool,
>rename);
>
> QTemporaryDir monitoredDir;
> QTemporaryDir externalDir;
> FileEventsGatherer feg;
> feg.setPath(monitoredDir.path(),
> FileEventsGatherer::FILE_EVENT__ALL,
> OUTBOX_FILE_NAME_FILTER);
> QSet overallMoved;
> connect(,
> ::filesMoved,
> this,
> [](QSet const )
> {
> overallMoved.unite(movedFiles);
> });
>
> for (auto const  : fileNames)
> {
> QString const choosenPath {rename
>? monitoredDir.path()
>: externalDir.path()};
> auto const sourcePath = 
> QString("%1/%2").arg(choosenPath).arg("TempName");
> auto const destPath = 
> QString("%1/%2").arg(monitoredDir.path()).arg(file);
> mkFile(sourcePath);
> QFile mover(sourcePath);
> mover.rename(destPath);
> }
>
> QTest::qWait(SIGNALS_TIMEOUT_MS);
> QCOMPARE(overallMoved.count(),
>  expectedResult);
> }
>
> Thanks,
> F.
>
>
> On Sat, 15 Jun 2019 at 20:50, Thiago Macieira  
> wrote:
>>
>> On Saturday, 15 June 2019 08:58:31 PDT Federico Buti wrote:
>> > We gave strace a go and we noticed that 5.12 runtime acts differently for
>> > rename/move operations (see attached compare screenshot). In particular, on
>> > 5.6 we have an actual rename whereas a link/unlink sequence happens on
>> > 5.12. That sequence is not detected by our code, generating the failure.
>>
>> Alternative: upgrade your system to a version that supports the renameat2()
>> system call. You need a 3.16 Linux kernel and glibc 2.28.
>>
>> The link()/unlink() sequence is used on Unix filesystems to prevent rename()
>> clobbering existing files, as promised in our API, but they're only attempted
>> if renameat2() fails.
>>
>> --
>> 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] Behavioural change in QFile/QDir rename

[Elvis Stansvik]

Den lör 15 juni 2019 kl 18:00 skrev Federico Buti :
>
> Hi all.
>
> Recently we successfully switched from Qt 5.6 to Qt 5.12.3 after some 
> struggles on win. Very few unit tests failed out of hundreds. Among those one 
> stood out as quite strange and I'm looking for feedback on it.
>
> We wrote a simple wrapper around inotify API to collect events in a target 
> directory for the set {IN_CREATE, IN_OPEN, IN_MODIFY, IN_CLOSE, IN_MOVED_TO, 
> IN_DELETE}. All the unit tests for those events pass correctly on 5.12. All 
> of them with the exception of the test for moved/renamed files which fails 
> miserably.
> We gave strace a go and we noticed that 5.12 runtime acts differently for 
> rename/move operations (see attached compare screenshot). In particular, on 
> 5.6 we have an actual rename whereas a link/unlink sequence happens on 5.12. 
> That sequence is not detected by our code, generating the failure.
>
> How can we handle this change? We should maybe pay attention to IN_ATTRIB 
> attributes for link, shouldn't we? Can someone point out the commit that 
> changes the behaviour?

The change is https://codereview.qt-project.org/c/qt/qtbase/+/199004
and it seems to have been made in order to avoid the overwriting
semantics of rename(2).

I don't know how to handle it as I'm not familiar with inotify, but I
bet someone here is.

Elvis

>
> Any advice is pretty much appreciated!
> Thanks in advance
> F.
>
> ___
> 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 Crash on libQt5Purchasing

[Elvis Stansvik]

Den fre 14 juni 2019 11:36Nuno Santos  skrev:

> Hi,
>
> I’m having a real hard time find a solution to a crash that is hunting me
> for a couple of months on Android systems with my Qt based Android apps.
>
> The crash reports on Google Play point to libQt5Purchasing but it doesn’t
> happen on all devices. I have finally found a device on which I can
> reproduce the problem.
>
> I would like to share the output of a crash reproduced on a Samsung Galaxy
> S4 running 5.0.1
>
> Can someone please take a look at this logcat output and tell me if there
> is another possible cause for the problem? I have bolded some of the events.
>

I've never developed for Android, but is it possible to run a debug build
(including debug build of Qt) on the failing device, to pinpoint where
within libQt5Purchasing it is crashing?

That would shine more light on it, unless someone recognizes it right off
the bat.

Elvis


> Has someone had similar problems in the past?
>
> Thanks in advance,
>
> Best regards,
>
> Nuno
>
> I/Timeline( 1528): Timeline: Activity_launch_request id:com.imaginando.drc
> time:1573929
> V/ApplicationPolicy(  902): isApplicationStateBlocked userId 0 pkgname
> com.imaginando.drc
> I/ActivityManager(  902): START u0 {act=android.intent.action.MAIN
> cat=[android.intent.category.LAUNCHER] flg=0x1020
> cmp=com.imaginando.drc/.DRCActivity (has extras)} from uid 10029 on display
> 0
> D/ResourcesManager(  902): creating new AssetManager and set to
> /data/app/com.imaginando.drc-1/base.apk
> I/ActivityManager(  902): Start proc com.imaginando.drc for activity
> com.imaginando.drc/.DRCActivity: pid=18080 uid=10202 gids={50202, 9997,
> 3003, 1028, 1015} abi=armeabi-v7a
> D/ResourcesManager(18080): creating new AssetManager and set to
> /data/app/com.imaginando.drc-1/base.apk
> D/DRC (18080): Starting activity
> I/Qt JAVA (18080): Can't find
> '/data/data/com.imaginando.drc/qt-reserved-files/lib/libQt5QuickParticles.so'
> D/DRC (18080): Starting service
> D/ActivityManager(  902): startService
> callerProcessName:com.imaginando.drc, calleePkgName: com.imaginando.drc
> D/OneSignal(18080): curActivity is NOW:
> com.imaginando.drc.DRCActivity:com.imaginando.drc.DRCActivity@2f6d4af1
> *E/com.facebook.a.b.v(18080): java.lang.ClassNotFoundException: Didn't
> find class "com.android.vending.billing.IInAppBillingService$Stub" on path:
> DexPathList[[zip file 
> *"/data/app/com.imaginando.drc-1/base.apk"],nativeLibraryDirectories=[/data/app/com.imaginando.drc-1/lib/arm,
> /vendor/lib, /system/lib]]
> I/Finsky  (14819): [1805] erx.b(9): com.imaginando.drc: Account determined
> from installer data - [4NDPNfBN-V-DD6HE13G2sQ96SRU]
> I/Finsky  (14819): [1805] erx.b(16): com.imaginando.drc: Account from
> preferred account - [4NDPNfBN-V-DD6HE13G2sQ96SRU]
> D/ResourcesManager( 1272): creating new AssetManager and set to
> /data/app/com.imaginando.drc-1/base.apk
> W/GCM (18080): GCM SDK is deprecated, com.imaginando.drc should update
> to use FCM
> I/ActivityManager(  902): Displayed com.imaginando.drc/.DRCActivity:
> +1s303ms
> I/Timeline(  902): Timeline: Activity_windows_visible id:
> ActivityRecord{3a3d66f1 u0 com.imaginando.drc/.DRCActivity t239}
> time:1575256
> I/WindowManager(  902): Screen frozen for +1s210ms due to Window{2bd0e662
> u0 Starting com.imaginando.drc}
> *I/OneSignal(18080): Caused by: java.lang.ClassNotFoundException: Didn't
> find class "com.google.android.gms.ads.identifier.AdvertisingIdClient" on
> path: DexPathList[[zip file 
> *"/data/app/com.imaginando.drc-1/base.apk"],nativeLibraryDirectories=[/data/app/com.imaginando.drc-1/lib/arm,
> /vendor/lib, /system/lib]]
> E/Vold(  280): Failed to find mounted volume for
> /storage/extSdCard/Android/data/com.imaginando.drc/files/Documents/
> W/ContextImpl(18080): Failed to ensure directory:
> /storage/extSdCard/Android/data/com.imaginando.drc/files/Documents
> I/Finsky  (14819): [1802] erx.b(9): com.imaginando.drc: Account determined
> from installer data - [4NDPNfBN-V-DD6HE13G2sQ96SRU]
> I/Finsky  (14819): [1802] erx.b(16): com.imaginando.drc: Account from
> preferred account - [4NDPNfBN-V-DD6HE13G2sQ96SRU]
> I/Finsky  (14819): [1805] erx.b(9): com.imaginando.drc: Account determined
> from installer data - [4NDPNfBN-V-DD6HE13G2sQ96SRU]
> I/Finsky  (14819): [1805] erx.b(16): com.imaginando.drc: Account from
> preferred account - [4NDPNfBN-V-DD6HE13G2sQ96SRU]
> I/Timeline(  902): Timeline: Activity_windows_visible id:
> ActivityRecord{3a3d66f1 u0 com.imaginando.drc/.DRCActivity t239}
> time:1582379
> D/DRC (18080): Initializing Android services
> I/art (18080): Rejecting re-init on previously-failed class
> java.lang.Class
> I/art (18080): Rejecting re-init on previously-failed class
> java.lang.Class
> I/art (18080): Rejecting re-init on previously-failed class
> java.lang.Class
> I/art (18080): Rejecting re-init on previously-failed class
> java.lang.Class
> D/DRC (18080): Starting MIDI Mananger
> D/DRC 

Re: [Interest] Online doc URL improvement

[Elvis Stansvik]

Den tors 6 juni 2019 kl 04:09 skrev Christian Gagneraud :
>
> Hi there,
>
> I quite often read the documentation online, b/c the urls are quite
> short and simple i usually type them in directly in the URL bar. One
> little thing is annoying me, the '.html extension.
> Wouldn't it be great if instead the url would be 'doc.qt.io/qt-5/qwidget'.
> That is shorter to type and easier to navigate to a class you know the
> name of. Currently you have to move the cursor around in the url field
> so that you replace the class name b/w '/' and '.html'. not having to
> deal with '.html' would make the process way faster/easier.
> Of course to avoid breaking search engine, bookmarks, ... the url with
> '.html' would have to redirect to the one w/o.
>
> Any thoughts?

Not apart from +2 I've been thinking the exact same thing :)

Elvis

>
> Chris
> ___
> 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] How does one use Q_ASSUME?

[Elvis Stansvik]

Den sön 26 maj 2019 kl 17:15 skrev Thiago Macieira :
>
> On Saturday, 25 May 2019 02:43:11 PDT Giuseppe D'Angelo via Interest wrote:
> > On the other hand, Q_ASSUME(cond) tells the compiler that cond is true,
> > always. If cond is actually false at runtime, you have undefined
> > behavior. And since undefined behavior cannot happen, the compiler is
> > free to optimize the following code assuming that cond is true.
>
> Please be careful with Q_ASSUME and GCC. Unlike the other three major
> compilers, it does not have __assume or __builtin_assume. So Q_ASSUME
> implements by the if {} else __builtin_unreachable() expression that Peppe's
> link shows. That has two important side-effects:
>
> 1) sometimes, the compare-and-branch isn't removed. You end up with worse code
> than not assuming at all.
>
> 2) unlike the other compilers, the conditional is actually in evaluated
> context. So make sure you only Q_ASSUME on variables, never on function calls.
> GCC will call them, the others won't. This is the same rule as Q_ASSERT, btw.

The way Q_ASSUME is defined, isn't that true for non-GCC too?

#define Q_ASSUME(Expr) \
do {\
const bool valueOfExpression = Expr;\
Q_ASSERT_X(valueOfExpression, "Q_ASSUME()", "Assumption in
Q_ASSUME(\"" #Expr "\") was not correct");\
Q_ASSUME_IMPL(valueOfExpression);\
} while (false)

Won't Expr be evaluated at the const bool valueOfExpression = Expr; ?

Elvis

>
> My idea with Q_ASSUME was to make Q_ASSERT expand to it when asserts are
> disabled. After all, calling a [[noreturn]] function is the same as having a
> __builtin_unreachable() after that function call, right?
>
> Unfortunately, because of the issues above, it couldn't be done.
>
> PS: Q_UNREACHABLE() is implemented on MSVC with __assume(false).
>
> --
> 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

Re: [Interest] How does one use Q_ASSUME?

[Elvis Stansvik]

Den sön 26 maj 2019 kl 12:37 skrev René J. V. Bertin :
>
> Giuseppe D'Angelo via Interest wrote:
>
> Hi,
>
> > On the other hand, Q_ASSUME(cond) tells the compiler that cond is true,
>
> After reading the MS doc I sort of understand how you can use the construct to
> implement a Q_UNREACHABLE (but in the example given I don't see the codegen
> advantage of `default: Q_UNREACHABLE` vs. not adding a `default:` at all).
>
> > Look here at a possible example at how it can improve codegen:
> >
> > https://gcc.godbolt.org/z/KlWBRY
>
> Not really, I'm afraid.
>
> The only thing that's evident to me from there is that there is much fewer
> generated machine code when you add the assume statement. I don't see at all 
> why
> that would be, what difference it would make for the loop that it is always
> iterated over a multiple of 16. I thought the difference might be in 
> evaluating
> the `i < count` expression, but even after trying to factor that out the
> difference remains:
> https://gcc.godbolt.org/z/2Zclp5
>
> Take home message for me is that this is a construct that's probably useful 
> only
> if you have very intimate knowledge about code generation, and thus not very
> cross-platform/compiler (and even less cross-architecture). Except for the
> Q_UNREACHABLE thing.

Yes, I would also think it's something you bring out only for really
tight spots. And it is just a hint. The compiler is free to ignore it.

It is compiler specific like you say, but Q_ASSUME is not. It will
expand to the compiler specific hint on compilers that supports it,
else it'll just be an assert.

#define Q_ASSUME(Expr) \
do {\
const bool valueOfExpression = Expr;\
Q_ASSERT_X(valueOfExpression, "Q_ASSUME()", "Assumption in
Q_ASSUME(\"" #Expr "\") was not correct");\
Q_ASSUME_IMPL(valueOfExpression);\
} while (false)

(Q_ASSUME_IMPL will be the compiler specific hint, if supported, else a no-op)

Elvis

>
> What I was hoping it might do is what the Qt documentation suggests, a more
> graceful version of a Q_ASSERT. That is, a version that does the usual abort 
> in
> debug builds, but becomes a regular if in production code. I've seen too many
> examples of coding where a Q_ASSERT is used to guard against situations that 
> are
> *assumed* never to occur, and then forgotten (or the devs assume everyone else
> uses debug/development builds). In many if not most of those cases it's 
> trivial
> to add a graceful handling of the situation.
>
> R
>
> ___
> 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] How does one use Q_ASSUME?

[Elvis Stansvik]

Den sön 26 maj 2019 kl 12:37 skrev René J. V. Bertin :
>
> Giuseppe D'Angelo via Interest wrote:
>
> Hi,
>
> > On the other hand, Q_ASSUME(cond) tells the compiler that cond is true,
>
> After reading the MS doc I sort of understand how you can use the construct to
> implement a Q_UNREACHABLE (but in the example given I don't see the codegen
> advantage of `default: Q_UNREACHABLE` vs. not adding a `default:` at all).

It's a bit subtle, but in the MS example, if you were to remove the
default: altogether, the compiler would have to generate instructions
to check if p is 1, else check if p is 2. With the default: added with
the unreachable hint, it's enough for it to generate instructions to
check if p is 1, because if it isn't, then it is 2 for sure (because
the default:, which covers every other value of p, is unreachable).

HTH,
Elvis

>
> > Look here at a possible example at how it can improve codegen:
> >
> > https://gcc.godbolt.org/z/KlWBRY
>
> Not really, I'm afraid.
>
> The only thing that's evident to me from there is that there is much fewer
> generated machine code when you add the assume statement. I don't see at all 
> why
> that would be, what difference it would make for the loop that it is always
> iterated over a multiple of 16. I thought the difference might be in 
> evaluating
> the `i < count` expression, but even after trying to factor that out the
> difference remains:
> https://gcc.godbolt.org/z/2Zclp5
>
> Take home message for me is that this is a construct that's probably useful 
> only
> if you have very intimate knowledge about code generation, and thus not very
> cross-platform/compiler (and even less cross-architecture). Except for the
> Q_UNREACHABLE thing.
>
> What I was hoping it might do is what the Qt documentation suggests, a more
> graceful version of a Q_ASSERT. That is, a version that does the usual abort 
> in
> debug builds, but becomes a regular if in production code. I've seen too many
> examples of coding where a Q_ASSERT is used to guard against situations that 
> are
> *assumed* never to occur, and then forgotten (or the devs assume everyone else
> uses debug/development builds). In many if not most of those cases it's 
> trivial
> to add a graceful handling of the situation.
>
> R
>
> ___
> 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] How does one use Q_ASSUME?

[Elvis Stansvik]

Den sön 26 maj 2019 kl 12:37 skrev René J. V. Bertin :
>
> Giuseppe D'Angelo via Interest wrote:
>
> Hi,
>
> > On the other hand, Q_ASSUME(cond) tells the compiler that cond is true,
>
> After reading the MS doc I sort of understand how you can use the construct to
> implement a Q_UNREACHABLE (but in the example given I don't see the codegen
> advantage of `default: Q_UNREACHABLE` vs. not adding a `default:` at all).
>
> > Look here at a possible example at how it can improve codegen:
> >
> > https://gcc.godbolt.org/z/KlWBRY
>
> Not really, I'm afraid.
>
> The only thing that's evident to me from there is that there is much fewer
> generated machine code when you add the assume statement. I don't see at all 
> why
> that would be, what difference it would make for the loop that it is always
> iterated over a multiple of 16. I thought the difference might be in 
> evaluating
> the `i < count` expression, but even after trying to factor that out the
> difference remains:
> https://gcc.godbolt.org/z/2Zclp5

If you look at the generated code for Guiseppe's example after
removing the assume, you'll see that it'll use vector instructions for
the addition/assignment in the loop body for as long as it can, but
then there are a bunch of non-vector instructions for handling the
remaining iterations (when (count % 16) != 0).

With the added hint that (count % 16) == 0, the compiler was free to
omit those instructions.

At least that's how I interpret it.

Elvis

>
> Take home message for me is that this is a construct that's probably useful 
> only
> if you have very intimate knowledge about code generation, and thus not very
> cross-platform/compiler (and even less cross-architecture). Except for the
> Q_UNREACHABLE thing.
>
> What I was hoping it might do is what the Qt documentation suggests, a more
> graceful version of a Q_ASSERT. That is, a version that does the usual abort 
> in
> debug builds, but becomes a regular if in production code. I've seen too many
> examples of coding where a Q_ASSERT is used to guard against situations that 
> are
> *assumed* never to occur, and then forgotten (or the devs assume everyone else
> uses debug/development builds). In many if not most of those cases it's 
> trivial
> to add a graceful handling of the situation.
>
> R
>
> ___
> 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] How does one use Q_ASSUME?

[Elvis Stansvik]

Den lör 25 maj 2019 kl 10:13 skrev René J.V. Bertin :
>
> Hi,
>
> I can't seem to wrap my head around what one can do with Q_ASSUME, i.e. which 
> will be the code for which the compiler won't emit code (and how the compiler 
> could know not to emit code as a function of a runtime condition?!)

I hadn't heard about this compiler hint, but isn't it simply that
putting in Q_ASSUME(cond), then the compiler is free in its code
generation to not generate any code to handle cases when cond is
false?

E.g.

Q_ASSUME(!atWar);

if (atWar) {
fireNukes(); <-- Oops, nukes may not be fired, even if at war,
because compiler may have taken the hint and assumed we're not at war
}

Microsoft seems to have a nice article about their __assume (which
Q_ASSUME expands to):
https://docs.microsoft.com/en-us/cpp/intrinsics/assume?view=vs-2019

>
> Squinting at the macros it seems evident that you cannot do something like 
> this, which to me the documentation suggests (and I think) you SHOULD be able 
> to do:
>
> Q_ASSUME(conditionsMet, {
>   // do something that should be done only when conditions are met
> });

I don't understand. That just looks like an if statement?

Elvis

>
>
> R
> ___
> 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] QtIFW Multiple entries in Apps & features

[Elvis Stansvik]

I cannot find anything about it in the config docs at
https://doc.qt.io/qtinstallerframework/ifw-globalconfig.html

But looking at the patch that added a UUID to the registry uninstall
key (https://codereview.qt-project.org/#/c/104183/2//ALL), it seems it
checks for a "ProductUUID" config key, so try setting that to an fixed
UUID.

Disclaimer: Haven't tested this and haven't used QtIFW :)

Elvis

Den fre 12 apr. 2019 kl 15:37 skrev Harald Vistnes :
>
> Hi,
>
> I am using QtIFW for installing my application. In the Apps & features page 
> in Settings on Windows, my application is listed multiple times. I usually 
> install new versions without first removing the old version.
>
> In regedit I've found the corresponding entries for my application in 
> Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall,
>  each time with a different GUID.
>
> I guess I have set some setting in the QtIFW configuration files incorrectly 
> to cause this behaviour, but I'm not sure what it is. Can anyone point me in 
> the right direction? Why does the application get a new GUID each time? Can 
> one enforce the GUID to remain the same, so that the entry in Apps & features 
> is updated instead of adding new ones? Or can one at least remove old entries 
> when installing?
>
> Thanks,
> Harald
> ___
> 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] Confused about High-DPI icons...

[Elvis Stansvik]

Den fre 15 mars 2019 kl 06:07 skrev Nikos Chantziaras :
>
> On 14/03/2019 16:41, Matthew Woehlke wrote:
> > On 13/03/2019 18.41, Sérgio Martins via Interest wrote:
> >> Do you have:
> >>
> >> QApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
> >
> > Uh... *why* is that not the default? Without that, I still get a scaled
> > UI, but it is an ugly mix of stuff that's *properly* scaled (and making
> > use of the higher resolution) and stuff that isn't.
> >
> > AFAIK, applications that don't turn that on are still susceptible to
> > scaling problems...
>
> I still don't understand what the proper way to support high DPI
> displays is... In some places I see that using
> QApplication::setAttribute(Qt::AA_EnableHighDpiScaling) is for legacy
> applications that don't natively support it. Yet, if I don't use that,
> my applications are blurry.
>
> The documentation is silent about this.

I've also always been a bit confused about this.

The docs describe the Qt built-in scaling as:

"Qt 5.6 supports cross-platform high-DPI scaling for legacy
applications, similar to the scaling done natively by macOS. This
allows applications written for low-DPI screens to run unchanged on
high-DPI devices."

and then also:

"Migration of Existing Applications

In order to get an application designed for low DPI values running on
a high resolution monitors quickly, consider one of the scaling
options (let the application run as DPI Unaware on Windows or set the
environment variable QT_AUTO_SCREEN_SCALE_FACTOR to "1". These options
may incur some scaling or painting artifacts, though.

In the longer term, the application should be adapted to run unmodified:

Always use the qreal versions of the QPainter drawing API.
Size windows and dialogs in relation to the screen size.
Replace hard-coded sizes in layouts and drawing code by values
calculated from font metrics or screen size."

(From https://doc.qt.io/qt-5/highdpi.html)

I've always interpreted these pieces of docs as saying the Qt built-in
scaling is meant as an easy way to get something acceptable, or for
legacy applications that want something acceptable, but that the
"proper" solution is to not enable it and instead make sure the
application itself is DPI aware.

We're trying to follow this advice, and not using the Qt scaling in
our desktop app, but it is a bit of a struggle since Qt has had
problems following this advice themselves in places, and especially
reacting on its own to DPI changes (whether they occur through moving
the app to a new screen, the screen setup changing, the resolution
changing, et.c.) and to Windows screen scaling option changes (which
is not really a true scaling, but anyway). It has also been a struggle
sometimes because there has been issues with some icon engines (the
one on Mac in particular) not reacting to DPI changes properly. I'm
unsure what the status is nowadays, but I know we have it on our TODO
to make sure the app works well in hidpi/mixed dpi setups.

We do enable hidpi pixmaps support though, though we use SVGs as
icons, not 2x versions (not sure if that is officially
supported/recommended).

Sorry for not giving much advice here, just a fellow developer
lamenting that hidpi is quite hard to get right still, if following
the official recommendation of not using Qt built-in scaling for new
applications.

Elvis

>
> ___
> 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] Whole edit window closes.

[Elvis Stansvik]

Den tis 12 mars 2019 kl 21:40 skrev Bill Crocker :
>
> Hello:
>
> Sorry. A boring old desktop widget problem...

Just wanted to comment on this: I'm doing 99% widgets and 1% QML, so I
for one welcome some good'ol fashioned widgets posts :) Keep them
coming.

Elvis

>
> I have a QTableView.
> I use a QStyledItemDelegate on each cell.
> The delegate opens a custom, modal editor on double click.
> The editor is based on a QDialog and contains a number of widgets,
> one of which is a QComboBox.
> When I press  in the text entry area of the QComboBox,
> the whole edit window closes, but I am not done "editing". Arg.
>
> (Most of the time that is what you want because the QComboBox is
>   the only widget in the editor, but not here.)
>
> I have tried a number of things related to focus, default buttons
> but nothing has worked.
>
> How do I keep the editor open
> until I press the OK button.
>
> Thanks.
>
> Bill
> ___
> 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] parallel asynchrone action

[Elvis Stansvik]

Den mån 4 mars 2019 16:34Sylvain Pointeau 
skrev:

> On Sun, Mar 3, 2019 at 10:56 PM Elvis Stansvik  wrote:
>
>> There should be no such delay in QFutureWatcher. I've never seen that,
>> and I've used QtConcurrent::run/mapped + QFutureWatcher quite a lot.
>>
>> I would investigate that before making my own mechanism.
>>
>
> I am on macos, on which OS are you doing it?
>

Windows, macOS and Linux.

I had the same issue for FileSystemWatcher, where on windows it was
> immediate and it was implemented on macos via polling.
> I was thinking that it may be the same issue for QFutureWatcher.
>
> However, if we exclude QFutureWatcher, is this approach good? could it be
> simplified?
>

I don't think so. But don't exclude QFutureWatcher. The proper thing to do
is to investigate where the delay you're seeing is really coming from.

There should not be any such delay inherent to QFutureWatcher, on any
platform. I suspect you're blocking event processing/signal delivery
somehow, but only you can answer that. Time all sections of your code to
make sure you're not blocking the UI thread somewhere.

We're using QtConcurrent/QFutureWatcher intensively in our product, running
hundreds of jobs. If there was even the slightest such delay, our customers
would yell like crazy :)

Elvis


> Also how would it be so different with a QFutureWatcher, it removes one
> class TaskNotifier, but the rest stays the same, do you see another way
> to make a action asynchrone?
>
> Best regards,
> Sylvain
>
>
>
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] parallel asynchrone action

[Elvis Stansvik]

There should be no such delay in QFutureWatcher. I've never seen that,
and I've used QtConcurrent::run/mapped + QFutureWatcher quite a lot.

I would investigate that before making my own mechanism.

Elvis

Den lör 2 mars 2019 kl 21:13 skrev Sylvain Pointeau
:
>
> Dear all,
>
> I made an action processed in another thread in QML, and I would like your 
> review.
>
> When in QML, I click on a button, I send a signal to an object 
> "TaskProcessor" (declared in QML) to start the action.
> Within this slot I start a future with QtConcurrent.
>
> Before I was using QFutureWatcher to know when the future is finished, but I 
> observed a delay of 1 seconde if the future was taking 4 secondes to complete.
> so now I use one object ("TaskNotifier") instantiated in the concurrent 
> lambda, that connect to "this", and trigger a message to "TaskProcessor" when 
> it finishes.
> TaskProcessor then triggers a signal to QML with the result.
>
> Is this approach good? I was wondering if this is really the way to follow
> Do you use another approach?
>
> in QML:
>
> Button {
>
> id: btnStart
>
> text: "Start"
>
>
> onClicked: {
>
> output.text = "computing..."
>
> taskc.doCalculation(Number(p1.text),Number(p2.text))
>
> enabled = false
>
> }
>
> }
>
>
> TaskComputer {
>
> id: taskc
>
>
> onCalculationFinished: {
>
> btnStart.enabled = true
>
>
> // do something with rs
>
> }
>
>
> }
>
>
> in C++:
>
> void TaskComputer::doCalculation(int p1, int p2)
>
> {
>
> QFuture f1 = QtConcurrent::run( [this, p1, p2]() -> int {
>
>
> TaskNotifier tnotifier;
>
> connect(, ::finished, this, 
> ::futureFinished);
>
>
> // do the task
>
>
> TaskResult tres(/*...my results...*/);
>
>
> emit tnotifier.finished(tres);
>
> } );
>
> }
>
>
> void TaskComputer::futureFinished(TaskResult rs)
>
> {
>
> // do some stuff
>
>
> emit calculationFinished(rs);
>
> }
>
>
> Best regards,
> Sylvain
>
>
>
> ___
> 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] Animating viewable rect of QGraphicsView

[Elvis Stansvik]

Den mån 25 feb. 2019 kl 19:54 skrev Patrick Stinson :
>
> How can I animate the viewable scene rect of a QGraphicsView using screen 
> coordinates? This means animating both center pos and scale. This is similar 
> to Google Earth where the map scrolls and zooms smoothly from one point to 
> another. I have searched for an answer for this several times in the last 
> couple of years with little success.
>
> The use case is that I use QGraphicsView::fitInView to show the bounding rect 
> of all visible items. Then some items are hidden and I want to animate 
> zooming/scrolling to fit the new bounding rect of all the items.
>
> Simply setting up one animation to periodically call 
> QGraphicsView::centerOn() and another to call QGraphicsView::scale() doesn't 
> work because calling one displaces the values of the other as the 
> interpolation progresses.
>
> Thoughts? This seems like a pretty essential use case for QGraphicsView.

It was quite some time since I worked with QGV/QGS, but can't you just
have your animation update a QTransform and set that on the view with
setTransform?

Elvis

>
> Thanks!
> -Patrick
> ___
> 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] Work for hire to solve a Qt bug that's been a thorn in our side.

[Elvis Stansvik]

Den fre 15 feb. 2019 kl 21:25 skrev Paul Knopf :
>
> Are there any experienced Qt developers out there interested in solving this 
> bug that my company is experiencing? Maybe you know someone who is interested?
>
> https://bugreports.qt.io/browse/QTBUG-73830
>
> It is easy to reproduce with any Qt version, on Linux.
>
> Thanks for your attention/help.

I posted a theory on the bug, but I don't know if it's right (don't
have a Qt build handy nor any touchscreens).

Elvis

> ___
> 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 are you using for continuous integration?

[Elvis Stansvik]

Den tors 14 feb. 2019 kl 10:08 skrev Nuno Santos :
>
> Hey,
>
> Thank you all for sharing your solutions and approaches. Among here there are 
> two obvious winners:
>
> - Jenkins
> - Buildbot
>
> I want to keep the build config within the project so I guess Jenkins will be 
> my way to go.

For brevity, this is the side-project I mentioned to make Buildbot
more like Travis in that respect:
https://github.com/buildbot/buildbot_travis

It's maintained (and I believe used) by the Buildbot maintainers
themselves. I've looked at it, but we haven't tried to use it. One
reason is that it works by dynamically adjusting the Buildbot config,
and I was unsure how this would work if we still wanted to have parts
of the Buildbot config that were custom/static (like I mentioned, we
have some other automation tasks that we run on top of the same
Buildbot master instance).

Anyway, just thought I'd drop the link. Probably good idea to go with
Jenkins if you want in-repo build recipies out of the box.

Elvis

>
> Now I just need to go though all the configuration details. If anyone knows 
> any really pragmatic documentation on how to setup Jenkins server with GitHub 
> and how to setup a worker on Mac and Windows, please share.
>
> Thanks,
>
> Best regards,
>
> Nuno
>
> On 13 Feb 2019, at 19:02, Elvis Stansvik  wrote:
>
> Den ons 13 feb. 2019 kl 00:06 skrev Nuno Santos :
>
>
> Hi,
>
> I’m curious about what you Qt heads are using for continuous integration.
>
> I have googled a few times this for this topic and I have found a couple of 
> options but every time I tried to spend the minimum amount of time to setup 
> one, it seems an incredible effort. I’m looking for a solution that allows me 
> to:
>
> - push to a specific branch on GitHub
> - get a local CI agent to fetch that branch and build it
>
> Ideally I would like it to be :
>
> - fast to setup
> - Windows & Mac compatible
> - ideally with docker integration
>
> Drone works damn well for web projects. I wanted something that cool for 
> automatic desktop software building and packaging
>
> What are you people using?
>
>
> We use Buildbot. It has worked very well, and we use it for some other
> automation tasks besides software builds. It builds and tests software
> from our local GitLab instance. Builds are mostly done in Docker
> containers, though for macOS and Windows we run the Buildbot workers
> on bare metal.
>
> Downside is it's configured using Python and the configuration takes
> some getting used to when setting it up for the first time (but it's
> very well designed and worth learning). The upside is it's Python :)
> so it's *very* flexible. Downside is also that the config is central
> and not kept with the repos (though there is a project to support
> Travis-style in-repo config).
>
> Elvis
>
>
> Thanks!
>
> Best,
>
> Nuno
> ___
> 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] What are you using for continuous integration?

[Elvis Stansvik]

Den ons 13 feb. 2019 kl 00:06 skrev Nuno Santos :
>
> Hi,
>
> I’m curious about what you Qt heads are using for continuous integration.
>
> I have googled a few times this for this topic and I have found a couple of 
> options but every time I tried to spend the minimum amount of time to setup 
> one, it seems an incredible effort. I’m looking for a solution that allows me 
> to:
>
> - push to a specific branch on GitHub
> - get a local CI agent to fetch that branch and build it
>
> Ideally I would like it to be :
>
> - fast to setup
> - Windows & Mac compatible
> - ideally with docker integration
>
> Drone works damn well for web projects. I wanted something that cool for 
> automatic desktop software building and packaging
>
> What are you people using?

We use Buildbot. It has worked very well, and we use it for some other
automation tasks besides software builds. It builds and tests software
from our local GitLab instance. Builds are mostly done in Docker
containers, though for macOS and Windows we run the Buildbot workers
on bare metal.

Downside is it's configured using Python and the configuration takes
some getting used to when setting it up for the first time (but it's
very well designed and worth learning). The upside is it's Python :)
so it's *very* flexible. Downside is also that the config is central
and not kept with the repos (though there is a project to support
Travis-style in-repo config).

Elvis

>
> Thanks!
>
> Best,
>
> Nuno
> ___
> 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] 5.11.3 make install failure

[Elvis Stansvik]

Den mån 14 jan. 2019 kl 18:53 skrev :
>
>
> Quoting Elvis Stansvik :
>
> > Den mån 14 jan. 2019 17:38Jason H  skrev:
> >
> >> Applying Occam's razor,
> >> I think your make is failing, make install is making the default target
> >> (resuming your broken build, and failing again) and not actually getting to
> >> install?
> >>
> >> Can you confirm your make of the default target ended successfully?
> >>
> >
> > Note also that using make -jN, the error may in some cases not be
> > immediately obvious from the last bit of output, but is visible some pages
> > up. Search backwards for errors or do a serial build to be sure.
> >
> > Elvis
> >
>
> Was using 5.12.0 with following configure command
>
> ./configure -prefix /home/developer/Qt-5.12.0 -no-xcb -opensource
> -confirm-license  -system-freetype -system-pcre -no-harfbuzz -no-xcb
> -nomake examples -no-sql-mysql  -shared -no-sql-psql -no-sqlite
> -enable-linuxfb -no-directfb -widgets --enable-linuxfb -no-directfb
> -no-xcb -no-opengl  -no-eglfs -no-openssl -fontconfig -no-gif
> -no-libjpeg -system-libpng -no-dbus -no-tslib -no-glib -icu -libinput
> -no-gtk
>
> Wow, it was over 500 lines back. Still doesn't explain how that source
> file could have this code
>
> void QWaylandIviSurface::sendConfigure(const QSize )
> {
>  if (!size.isValid()) {
>  qWarning() << "Can't configure ivi_surface with an invalid
> size" << size;
>  return;
>  }
>  Q_D(QWaylandIviSurface);
>  d->send_configure(size.width(), size.height());
> }
>
> and not include qdebug header file.

My only guess is that it perhaps (sloppily) relies on it being
transitively included, but that something along the way to that
#include  is conditional and happen to be excluded with your
particular combination of configure flags (which may be untested).
Just a long shot..

Elvis

>
> g++ -c -include .pch/Qt5XmlPatterns -pipe -O2 -std=c++1z
> -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -Wvla
> -Wdate-time -Wshift-overflow=2 -Wduplicated-cond
> -Wno-stringop-overflow -D_REENTRANT -fPIC -DQT_NO_FOREACH
> -DQT_NO_USING_NAMESPACE
> -DQT_ENABLE_QEXPLICITLYSHAREDDATAPOINTER_STATICCAST
> -DYYLTYPE_IS_DECLARED=1 -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
> -DQT_BUILD_XMLPATTERNS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII
> -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
> -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
> -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -Iacceltree -Idata -Iapi
> -Ienvironment -Iexpr -Ifunctions -Iiterators -Ijanitors -Iparser
> -Ischema -Itype -Iutils -I../../include -I../../include/QtXmlPatterns
> -I../../include/QtXmlPatterns/5.12.0
> -I../../include/QtXmlPatterns/5.12.0/QtXmlPatterns
> -I/home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtCore/5.12.0
>  
> -I/home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtCore/5.12.0/QtCore
>  -I/home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include 
> -I/home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtNetwork 
> -I/home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtCore 
> -I.moc 
> -I/home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/mkspecs/linux-g++ 
> -o .obj/qrangevariablereference.o
> expr/qrangevariablereference.cpp
> extensions/qwaylandivisurface.cpp: In member function ‘void
> QWaylandIviSurface::sendConfigure(const QSize&)’:
> extensions/qwaylandivisurface.cpp:202:18: error: invalid use of
> incomplete type ‘class QDebug’
>   qWarning() << "Can't configure ivi_surface with an invalid
> size" << size;
>^
> In file included from
> /home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtCore/qlogging.h:1:0,
>   from
> /home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:1200,
>   from
> /home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtCore/qglobal.h:1,
>   from
> /home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtGui/../../src/gui/kernel/qtguiglobal.h:43,
>   from
> /home/developer/qt_5_12_0/qt-everywhere-src-5.12.0/qtbase/include/QtGui/qtguiglobal.h:1,
>   from
> ../../include/QtWaylandCompositor/../../src/compositor/global/qtwaylandcompositorglobal.h:54,
>   from
> ../../include/QtWaylandCompositor/qtwaylandcompositorglobal.h:1,
>   from
> ../../include/QtWaylandCompositor/

Re: [Interest] 5.11.3 make install failure

[Elvis Stansvik]

Den mån 14 jan. 2019 17:38Jason H  skrev:

> Applying Occam's razor,
> I think your make is failing, make install is making the default target
> (resuming your broken build, and failing again) and not actually getting to
> install?
>
> Can you confirm your make of the default target ended successfully?
>

Note also that using make -jN, the error may in some cases not be
immediately obvious from the last bit of output, but is visible some pages
up. Search backwards for errors or do a serial build to be sure.

Elvis


>
>
> > Sent: Monday, January 14, 2019 at 9:30 AM
> > From: rol...@logikalsolutions.com
> > To: interest@qt-project.org
> > Subject: [Interest] 5.11.3 make install failure
> >
> >
> > I kick off the 5.11.3 build from source using same environment as the
> > previous 5.12.0 failure. Once again, make install, which shouldn't
> > compile __anything__ fails with a compilation error after make -j3 ran
> > just fine.
> >
> > What is the point of having configure if make install completely ignores
> it?
> >
> > g++ -c -pipe -O2 -std=c++1z -fvisibility=hidden
> > -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time
> > -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow
> > -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS
> > -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_EXCEPTIONS
> > -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_PLUGIN
> > -DQT_SERVICE_SUPPORT_LIB -DQT_WAYLANDCLIENT_LIB -DQT_GUI_LIB
> > -DQT_CORE_LIB -I.
> > -I../../../../hardwareintegration/client/shm-emulation-server
> > -I../../../../../include/QtWaylandClient/5.11.3
> > -I../../../../../include/QtWaylandClient/5.11.3/QtWaylandClient
> > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include
> >
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtServiceSupport
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtServiceSupport/5.11.3
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtServiceSupport/5.11.3/QtServiceSupport
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtGui/5.11.3
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtGui/5.11.3/QtGui
> -I../../../../../include -I../../../../../include/QtWaylandClient
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtGui
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtCore/5.11.3
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtCore/5.11.3/QtCore
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtCore
> -I.moc
> -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/mkspecs/linux-g++
> -o .obj/shmserverbufferintegration.o
> >
> ../../../../hardwareintegration/client/shm-emulation-server/shmserverbufferintegration.cpp
> >
> ../../../../hardwareintegration/client/shm-emulation-server/shmserverbufferintegration.cpp:
> In function ‘QOpenGLTexture* createTextureFromShm(const QString&, int, int,
> int,
> > int)’:
> >
> ../../../../hardwareintegration/client/shm-emulation-server/shmserverbufferintegration.cpp:81:10:
> error: ‘QOpenGLContext’ has not been
> > declared
> >   if (!QOpenGLContext::currentContext())
> >^~
> >
> ../../../../hardwareintegration/client/shm-emulation-server/shmserverbufferintegration.cpp:84:59:
> error: incomplete type ‘QOpenGLTexture’ used in nested name
> > specifier
> >   auto *tex = new QOpenGLTexture(image,
> > QOpenGLTexture::DontGenerateMipMaps);
> >
>  ^~~
> >
> ../../../../hardwareintegration/client/shm-emulation-server/shmserverbufferintegration.cpp:84:78:
> error: invalid use of incomplete type ‘class
> > QOpenGLTexture’
> >   auto *tex = new QOpenGLTexture(image,
> > QOpenGLTexture::DontGenerateMipMaps);
> >
> >  ^
> > In file included from
> >
> ../../../../../include/QtWaylandClient/5.11.3/QtWaylandClient/private/qwaylandserverbufferintegration_p.h:1:0,
> >   from
> >
> ../../../../hardwareintegration/client/shm-emulation-server/shmserverbufferintegration.h:45,
> >   from
> >
> ../../../../hardwareintegration/client/shm-emulation-server/shmserverbufferintegration.cpp:40:
> >
> ../../../../../include/QtWaylandClient/5.11.3/QtWaylandClient/private/../../../../../src/client/hardwareintegration/qwaylandserverbufferintegration_p.h:62:7:
> note: forward declaration of ‘class
> > QOpenGLTexture’
> >   class QOpenGLTexture;
> > ^~
> > Makefile:1269: recipe for target '.obj/shmserverbufferintegration.o'
> failed
> > make[6]: *** [.obj/shmserverbufferintegration.o] Error 1
> > make[6]: Leaving directory
> >
> '/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtwayland/src/plugins/hardwareintegration/client/shm-emulation-server'
> > Makefile:56: recipe for target
> > 'sub-shm-emulation-server-install_subtargets' failed
> > make[5]: *** [sub-shm-emulation-server-install_subtargets] Error 2
> > make[5]: 

Re: [Interest] linuxdeployqt?

[Elvis Stansvik]

Den fre 16 nov. 2018 16:55Boudewijn Rempt  skrev:

> On vrijdag 16 november 2018 16:53:55 CET Alexander Dyagilev wrote:
> > Hello,
> >
> > On Windows we have windeployqt.
> >
> > On MAC - macdeployqt.
> >
> > On Linux - there is no tool for this ? Is there some convenient
> > alternative way to copy all the required Qt files then (my project uses
> > Quick Controls 2)?
>
> There's https://github.com/probonopd/linuxdeployqt -- we use it to
> package
> Krita for Linux as an appimage.
>

Thanks for the pointer, we use an ugly shell script by yours truly to do
the same, but this might be handier.

Elvis


> --
> https://www.valdyas.org | https://www.krita.org
>
>
> ___
> 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] Updated Debian packages or ppa for Qt 5.9+

[Elvis Stansvik]

Den fre 9 nov. 2018 kl 23:23 skrev Lisandro Damián Nicanor Pérez Meyer
:
>
> Hi Konstantin!
>
> El miércoles, 7 de noviembre de 2018 05:12:28 -03 Konstantin Shegunov
> escribió:
> > On Wed, Nov 7, 2018 at 9:59 AM Hamish Moffatt 
> >
> > wrote:
> > > Does anyone know of a repository for updated Qt packages for Debian
> > > stable (stretch / 9)?
>
> With my Debian Qt maintainer hat on: I'm afraid there is no official repo for
> that. I once tried to provide backports but that would mean that many packages
> would need to get rebuilt against the new Qt version, which seems not possible
> to do on Debian backports.
>
> Backporting Qt 5.10/11 to stable also requires a new dpkg due to the changes
> we did in order to be able to cross compile using plain Debian packages +
> multi arch.
>
> With my personal hat on: I would *love* to provide a PPA-like semi-official
> repo for this, but Debian currently lacks PPAs/bikesheds in order to do that,
> and my build power is limited t a 10 years old machine, so not for now. But
> yes, I do get lots of requests for this :-(

For what it's worth, I know Stephan Binner keeps a bunch of PPAs with
Qt builds for Ubuntu Xenial, which I guess _may_ work on Debian
stretch (?).

They're here for those who are interested: https://launchpad.net/~beineri

I've only tried those builds briefly, and it was quite a while ago
(they install to /opt btw).

Elvis

>
> > Pin debian testing repos with a low priority in the apt configuration and
> > you can get the binaries from there. Current it 5.11.2.
>
> Only if you really know what you are doing. If you use KDE stuff (kwin for
> example) you will certainly have to upgrade it, and thus half your system,
> because it uses Qt's private methods.
>
> Cheers, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> ___
> 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 API annoyances: where to log/discuss?

[Elvis Stansvik]

Den ons 31 okt. 2018 kl 18:35 skrev Jason H :
>
>
>
> > Sent: Tuesday, October 30, 2018 at 3:23 PM
> > From: "Thiago Macieira" 
> > To: interest@qt-project.org
> > Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
> >
> > On Tuesday, 30 October 2018 08:39:22 PDT Jason H wrote:
> > > I was wondering if there is a place to log annoyances/discuss with the Qt5
> > > API for fix in Qt6?
> >
> > This list or the development mailing list are fine.
> >
> > >
> > > Two I am thinking of right now is:
> > > - QUrl::port() returns an int, but QTcpServer accepts a quint16, so no
> > > matter what I do, unless I add a cast, I get a warning.
> >
> > That's because QUrl::port() can return -1, indicating "no port was set in 
> > the
> > URL". QTcpServer needs a valid port number. So the warning is correct and
> > should be acted on.
>
> I thought QUrl::port() can take a default port if not set. Does it need to be 
> able to return negative?
>
> > > - Similarly with
> > > QImage::pixel there are signed/unsigned issues between pixel and qRgb().
> >
> > Sounds like something to be fixed.
> >
> > > Also, as I go between several languages, I find myself wanting to use
> > > lambdas more in a functional programming style. ( I would like a lambda 
> > > for
> > > QImage::pixel ([] (x,y,pixelValue) { } ) (This one is neat because you can
> > > use scanline() transparently) Also for the various containers.
> >
> > Highly inefficient, so unlikely to happen.
>
> In my own testing it was not that inefficient. In fact the lambda using 
> scanLine() was faster than using pixel(), but yes slower than using scanLine 
> with for loops.
>
> >
> > As for the containers, use  and C++2a Ranges.
>
> I attempted this recently, but failed to figure out how to do the following:
> QVector triple = apply(QVector {1,2,3},[](item) { return item*3;});
> or
> QVector originals {1,2,3};
> QVector triples = originals.apply([](item) { return item*3;});
>
> My options are std::for_each, std::transform, but they all have an ugly, 
> over-complicated syntax.
>
> Compare that to:
>  std::vector originals { 1,2,3};
>  std::vector triples;
>  std::transform(originals.begin(), originals.end(), 
> std::back_inserter(triples), [](int item){ return item*3; });

Sorry to say it, but welcome to C++ :)

No, mostly kidding. I think what you suggest sort of makes sense. If
Qt are to keep its containers, with a goal of offering an alternative
more convenient/Java-esque API, then a helper member function like you
suggest seems to fit that goal. Whether Qt still has this as a goal in
another matter. Maybe not to the extent that they once had?

For the pattern above, I guess one could make a generic helper in a
header of the application. I know e.g. Qt Creator has a bunch of such
helpers in its headers.

Elvis

>
> Sure the std way works 100% of the time, but I don't want to read that code, 
> much less write it. I think there's something about how "friendly" and 
> "beautiful" Qt code looks.
>
>
>
>
>
> ___
> 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