Re: [Development] Issues with QPainter::drawPolygon (off by one error?)

[Henry Skoglund]

On 2024-04-26 21:52, Christian Ehrlicher via Development wrote:

Hello,

I'm currently trying to investigate a painting problem within the
windowsvista / common style:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5} };
    QPainter p(&img);
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.drawPolygon(poly);
    p.setPen(QColor(0, 255, 0, 128));
    p.drawPoints(poly.data(), poly.size());
    p.end();
    img.save("output.png");

This code should draw a small down arrow (e.g. for a QPushButton with a
QMenu attached) and should look similar to this:

  0123456
0
1  X
2   XXX
3   XXX
4    X
5    X
6

But the outcome is this:

  0123456
0
1  
2   XX
3   XX
4
5
6

Setting a non-cosmetic pen at least result in painting of all three
corners but gives a non-symmetric triangle:

  0123456
0
1  X
2  
3   XXX
4   XX
5    X
6

I've no idea how to draw this triangle the way I want (and everyone is
satisfied with the outcome). Do you have any ideas?


Thx,
Christian


Hi, I think the QPainter draws very poorly using direct polygon paths.
You could try going via a QPainterPath, say:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    img.fill(QColor(0, 255, 0, 128));    // to be sure the img contains 
no junk values

    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5} };
    QPainter p(&img);
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.setPen(QColor(0, 255, 0, 128));
    QPainterPath path;
    path.addPolygon(poly);
    p.drawPath(path);
    p.end();
    img.save("output.png");

Rgrds Henry

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Issues with QPainter::drawPolygon (off by one error?)

[Henry Skoglund]

On 2024-04-28 11:00, Christian Ehrlicher via Development wrote:


Am 26.04.2024 um 22:48 schrieb Henry Skoglund:

On 2024-04-26 21:52, Christian Ehrlicher via Development wrote:

Hello,

I'm currently trying to investigate a painting problem within the
windowsvista / common style:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5} };
    QPainter p(&img);
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.drawPolygon(poly);
    p.setPen(QColor(0, 255, 0, 128));
    p.drawPoints(poly.data(), poly.size());
    p.end();
    img.save("output.png");
...


Hi, I think the QPainter draws very poorly using direct polygon paths.
You could try going via a QPainterPath, say:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    img.fill(QColor(0, 255, 0, 128));    // to be sure the img
contains no junk values
    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5} };
    QPainter p(&img);
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.setPen(QColor(0, 255, 0, 128));
    QPainterPath path;
    path.addPolygon(poly);
    p.drawPath(path);
    p.end();
    img.save("output.png");

Rgrds Henry



This helped a little bit but it then fails again for other sizes. It's a
mess :(
I'm shortly before drawing the triangles pixel by pixel by myself...

If you close the polygon by adding the first point again, it will help 
to draw a better triangle:

    QImage img(7, 7, QImage::Format_ARGB32_Premultiplied);
    img.fill("white");    // clear the scene
    QPolygon poly{ QPoint(1, 1), {5, 1}, {3, 5}, {1, 1} };  // added a 
point

    QPainter p(&img);
    p.setPen(Qt::NoPen);
    p.setBrush(QColor(Qt::black));
    p.setPen(QColor(0, 255, 0, 128));
    QPainterPath path;
    path.addPolygon(poly);
    p.drawPath(path);
    p.end();
    img.save("output.png");

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Exceptions

[Henry Skoglund]

On 2024-05-07 21:05, Turtle Creek Software wrote:
TurtleSoft posted on the Interest list earlier about problems we had 
with exception handling, and Thiago suggested I post here.


Since the early 90s, our C++ code has had about 10,000 sanity checks 
which give an error message with source file & line number, then throw 
an exception. There is a try/catch block in the event loop which 
swallows them.  That way users can continue work.  Only a small % of 
the checks are ever called, but it makes bugs very easy to fix when 
users or testers report them. Our app almost never crashes thanks to 
the many checks. We learned the system from Bill Atkinson, author of 
MacPaint and HyperCard.


The sanity system started in Metrowerks PowerPlant, then worked OK in 
Carbon, Cocoa, and MFC.  For Qt we wrapped QApplication::notify with 
try/catch. It worked for most checks on Macintel and Wintel, but 
failed for Mac ARM. After the message, instant termination. Users lose 
their work, testers must start over.


Turns out that Qt intentionally does not support exceptions thrown 
through GUI classes, and the early success was just an accident.


Exceptions are an "exceptionally" handy C++ feature. Instant "beam me 
up, Scotty". It is too bad that Qt does not support them fully, and 
I'd like to change that. So I would be willing to work on getting GUI 
classes like QWidget able to pass exceptions, if it means we can get 
our old sanity-checking back. It would be our open-source contribution.


I realize this is a huge, fundamental change to Qt. It would need to 
be a multi-year project, done in tiny bits so as not to break things.  
Anyhow, my time is limited.


Getting exceptions through signals/slots is lower priority. We don't 
use those much and probably could bypass them somehow. We just want a 
reliable path to the event loop.


Personally, I've programmed since punch card days in 1966 or so. I've 
designed and shipped several apps for PCs. I've refactored and rebuilt 
all sorts of C++ code from other people, and could do this work 
politely and competently.


Does this seem reasonable?

Dennis Kolva
Programming Director
TurtleSoft.com




Hi, interesting idea! However such a fundamental replumbing of Qt might 
be a Herculean task.
I assume you've already looked a QException? It's a part of Qt 
Concurrent and requires extra, receiving thread for the catching so it 
might not fit the bill.


Maybe instead of using vanilla throws and catches, try implementing a 
qThrow function that uses std::basic_stacktrace 
https://en.cppreference.com/w/cpp/utility/basic_stacktrace to do your 
own portable, generic stack unwinding?


Just some thoughts :-) Rgrds Henry

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Suggestion - Remove Windows 7 as supported development host

[Henry Skoglund]

Hi, you mean I will not able to use Qt Creator on my Windows 7 machine 
after 5.12? Please do not toss Windows 7 out of the window this fast.


Don't know about MSVC2021 yet, but MSVC2019 is the same 32-bit flavored 
app that MSVC2017 is and MSVC2019 will run on Windows 7 SP1, i.e. I will 
be able to build Qt Creator on Windows 7 with it. Please if possible 
also allow me to continue to work in Qt Creator on Windows 7 in Qt 5.13 
and 5.14.


Rgrds Henry


On 2018-11-13 14:13, Harald Kjølberg wrote:


Hi,


Referring to: https://bugreports.qt.io/browse/QTBUG-70891

The suggestion is to remove Windows 7 as a supported development host, but keep 
it as a target. From the numbers I have access to, more than 55% of the users 
are on Windows 10. However, I would like to get feedback on this in case there 
are other opinions.



Thanks!



Best,
Harald Kjølberg
Product Manager – QtAD
  



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Missing documentation in Qt 5.12

[Henry Skoglund]

On 2018-12-19 19:26, Thiago Macieira wrote:

On Wednesday, 19 December 2018 04:38:48 PST Martin Smith wrote:

1. Simply merge the inherited members into the list that is already there.
2. Merge the inherited members into the list but qualified with their base
class name. 3. list the inherited members from each base class all on the
same page but separately for each base class.

QWidget members
...
QPaintDevice members
...
QObject members
...


I would personally prefer #2. When I search that all-members list, I am
looking for a specific term, so having an alphabetically-sorted list might
help and does place similarly-named functions together (all setters, hence all
properties, for example).



+1 for #2.

This would reinstate the pre-5.12 doc behavior, with the added bonus of 
having the inherited members prefixed with their base class, so for 
example QWidget's list would say "QObject::sender() const" instead of 
just "sender() const". Nice!


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 Planning: Consideration of dropping support for UWP applications

[Henry Skoglund]

On 2019-04-18 14:46, Oliver Wolff wrote:

Hi,

as you might have heard, we are currently in Qt 6's planning phase and
thus checking things that have to be done to make Qt even better.
Of course we also want to use this opportuniy to drop support for
platforms that are no longer relevant in Qt's new environment.

One of these platforms is Microsoft's Universal Windows Platform which
is used on desktop PCs (for "Tiled" UWP applications, no classic desktop
applications), Windows Phone, Xbox one, Microsoft Hololens, and
Microsoft IoT devices. With Windows Phone no longer being relevant and
Microsoft's IoT strategy being unclear we now consider dropping support
for these platforms. Additional benefits and reasons can be found in
https://bugreports.qt.io/browse/QTBUG-74755

To be able to make the right decision, we now want your input as well.
If you can give some input on why support should be kept or have
additional reasons for dropping support, please reply to this mail or
add your input to https://bugreports.qt.io/browse/QTBUG-74755 where we
want to gather all the needed information before making a decision.

As said before, nothing is set in stone. At the moment we are gathering
information so that we can make a well informed decision.
Olli


Hi, please drop, I think UWP has seen its better days. Both Microsoft 
Edge and Office 2019 are now classic Win32 desktop apps.


Also, could you also drop support for UWP in Qt Creator? When I install 
Qt on my Mac I look at the Qt Creator plugin libWinRt.dylib and wonder 
why? Same on Linux, I get libWinRt.so included in Qt Creator, and on 
Windows 7 of course I get winRt4.dll. Neither Wine or Windows 7 will 
never support UWP so that plugin can be tossed even before Qt6 for those 
OS's.


Happy Easter /Henry

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Henry Skoglund]

Please, don't drop MinGW, it's in my meaning the best compiler on Windows.

I've switched from VS to MinGW, the #1 reason: I can distribute an .exe 
file which is runnable directly on the user's desktop (no installation). 
This is *verboten* when using VS, you have to send along the 
distribution dlls (ucrtbase.dll etc.) and install them.


Also, big wheels like Qt's installer program (MaintenanceTool.exe) have 
also switched from using Visual Studio to MinGW. I believe for the same 
reason as mine above, except MaintenanceTool.exe didn't include any VS 
.dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to 
start, because no VS2015 runtime was installed.


Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be 
present, and tbat .dll always gonna be there (just like the VB6 runtime 
etc.)


This is one of the few places where Windows still shines: Qt's OOBE on 
Windows. On that platform, you don't need any chmod +x or waiting for a 
.dmg to unpack, just double-click on the .exe file.


Rgrds Henry



On 2019-08-21 20:35, Mathias Hasselmann wrote:

Am 21.08.2019 um 19:38 schrieb Thiago Macieira:

PPS: can we drop MinGW support in Qt 6?

What alternative do you propse?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Henry Skoglund]

Yes, I also used app-local deployment, problem is that Microsoft has not 
committed 100% to allow it (as far as I know), instead they have a 
seesaw approach, saying "you can temporarily use app-local deployment but.."


Anyway, my ultimate goal is to create and distribute my Qt apps the same 
way as Qt's installation program (you can tell I really admire that 
program a lot :-)
i.e. link *everything* statically and build myself a ~ 20 MB humongous 
.exe file (which only needs msvcrt.dll). And that kind of linking, 
Microsoft has never supported nor allowed it.



On 2019-08-21 21:22, Elvis Stansvik wrote:

Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :

Please, don't drop MinGW, it's in my meaning the best compiler on Windows.

I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
file which is runnable directly on the user's desktop (no installation).
This is *verboten* when using VS, you have to send along the
distribution dlls (ucrtbase.dll etc.) and install them.

Why not just ship those DLLs? I wouldn't call that "verboten"
(forbidden), just a bit more to do for deployment.

We do app-local deployment (putting the DLLs next to our application),
which is still supported, and makes it possible for us to deliver a
portable ZIP in addition to an installer. You don't have to go the
route of launching the redistributables installer.

To make it less inconvenient we use CMake's
InstallRequiredSystemLibraries module along with setting
CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are
also bundled.

Elvis


Also, big wheels like Qt's installer program (MaintenanceTool.exe) have
also switched from using Visual Studio to MinGW. I believe for the same
reason as mine above, except MaintenanceTool.exe didn't include any VS
.dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to
start, because no VS2015 runtime was installed.

Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be
present, and tbat .dll always gonna be there (just like the VB6 runtime
etc.)

This is one of the few places where Windows still shines: Qt's OOBE on
Windows. On that platform, you don't need any chmod +x or waiting for a
.dmg to unpack, just double-click on the .exe file.

Rgrds Henry



On 2019-08-21 20:35, Mathias Hasselmann wrote:

Am 21.08.2019 um 19:38 schrieb Thiago Macieira:

PPS: can we drop MinGW support in Qt 6?

What alternative do you propse?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Henry Skoglund]

Hi, no I was only thinking of /MD all the time.

I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be 
happily built using /MT then that would beat MinGW, since such an .exe 
wouldn't then even require msvcrt.dll.



On 2019-08-21 21:59, Konstantin Tokarev wrote:


21.08.2019, 22:39, "Henry Skoglund" :

Yes, I also used app-local deployment, problem is that Microsoft has not
committed 100% to allow it (as far as I know), instead they have a
seesaw approach, saying "you can temporarily use app-local deployment but.."

Anyway, my ultimate goal is to create and distribute my Qt apps the same
way as Qt's installation program (you can tell I really admire that
program a lot :-)
i.e. link *everything* statically and build myself a ~ 20 MB humongous
.exe file (which only needs msvcrt.dll). And that kind of linking,
Microsoft has never supported nor allowed it.

Does it mean that distribution of software built with /MT runtime is illegal?



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Henry Skoglund]

Nice. Those .exe files would be closer to 30 MB than 20 MB, right? But 
nowadays that kind of sizes are quite common/normal and does not incur 
any noticeable delays when launching them.


Building static Qt apps this way for Windows I think will be more 
popular. I wish Qt would include a static building wizard, like showing 
say the most common static build flavors as check boxes, and perhaps a 
detailed view for cherrypicking exactly what modules you want.


Rgrds Henry

On 2019-08-21 23:10, Ola Røer Thorsen wrote:
ons. 21. aug. 2019 kl. 20:54 skrev Henry Skoglund <mailto:he...@tungware.se>>:



I've switched from VS to MinGW, the #1 reason: I can distribute an
.exe
file which is runnable directly on the user's desktop (no
installation).
This is *verboten* when using VS, you have to send along the
distribution dlls (ucrtbase.dll etc.) and install them.


Agreed. I cross-build completely statically linked Qt quick apps on 
Linux using mingw-w64 and share them (.exe only, no DLLs) to 
colleagues who only run windows. Very useful! So I would not vote for 
requiring MSYS2 or similar if it would mean the end of cross building 
Windows apps on Linux (if I've understood what MSYS2 is correctly).


I would not however mind upgrading the compiler/toolchain if my 
particular one was too old for some future Qt version.


Cheers,
Ola


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Henry Skoglund]

Aha, sorry for my ignorance! Yes, Thiago wrote about the -static-runtime 
option yesterday, I have to try it out (perhaps also wait for that 
update 16.0 to MSVC2017, when it supposedly has less static-flavored bugs)


Rgrds Henry
P.S. Recently I uninstalled Visual Studio from all my machines, guess 
it's time to say:
"Come back Microsoft, everything is forgiven, your linking ability is 
second to none"



On 2019-08-22 07:47, Kai Köhne wrote:

> Anyway, my ultimate goal is to create and distribute my Qt apps the same
> way as Qt's installation program (you can tell I really admire that
> program a lot :-)
> i.e. link *everything* statically and build myself a ~ 20 MB humongous
> .exe file (which only needs msvcrt.dll). And that kind of linking,
> Microsoft has never supported nor allowed it.

I'm pretty sure the Qt Installer / MaintenanceTool is actually built 
with MSVC 🙂


Microsoft supports linking in a static version of the visual studio 
runtime library  by the /MT compiler flag. Qt will automatically do 
this for you if you configure it with |||-static-runtime |.


Kai
----
*From:* Development  on behalf of 
Henry Skoglund 

*Sent:* Wednesday, August 21, 2019 9:36 PM
*To:* Elvis Stansvik 
*Cc:* Qt development mailing list 
*Subject:* Re: [Development] Dropping MinGW support in Qt 6 (Was: 
HEADS-UP: QStringLiteral)

Yes, I also used app-local deployment, problem is that Microsoft has not
committed 100% to allow it (as far as I know), instead they have a
seesaw approach, saying "you can temporarily use app-local deployment 
but.."


Anyway, my ultimate goal is to create and distribute my Qt apps the same
way as Qt's installation program (you can tell I really admire that
program a lot :-)
i.e. link *everything* statically and build myself a ~ 20 MB humongous
.exe file (which only needs msvcrt.dll). And that kind of linking,
Microsoft has never supported nor allowed it.


On 2019-08-21 21:22, Elvis Stansvik wrote:
> Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :
>> Please, don't drop MinGW, it's in my meaning the best compiler on 
Windows.

>>
>> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
>> file which is runnable directly on the user's desktop (no 
installation).

>> This is *verboten* when using VS, you have to send along the
>> distribution dlls (ucrtbase.dll etc.) and install them.
> Why not just ship those DLLs? I wouldn't call that "verboten"
> (forbidden), just a bit more to do for deployment.
>
> We do app-local deployment (putting the DLLs next to our application),
> which is still supported, and makes it possible for us to deliver a
> portable ZIP in addition to an installer. You don't have to go the
> route of launching the redistributables installer.
>
> To make it less inconvenient we use CMake's
> InstallRequiredSystemLibraries module along with setting
> CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are
> also bundled.
>
> Elvis
>
>> Also, big wheels like Qt's installer program (MaintenanceTool.exe) have
>> also switched from using Visual Studio to MinGW. I believe for the same
>> reason as mine above, except MaintenanceTool.exe didn't include any VS
>> .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to
>> start, because no VS2015 runtime was installed.
>>
>> Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be
>> present, and tbat .dll always gonna be there (just like the VB6 runtime
>> etc.)
>>
>> This is one of the few places where Windows still shines: Qt's OOBE on
>> Windows. On that platform, you don't need any chmod +x or waiting for a
>> .dmg to unpack, just double-click on the .exe file.
>>
>> Rgrds Henry
>>
>>
>>
>> On 2019-08-21 20:35, Mathias Hasselmann wrote:
>>> Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
>>>> PPS: can we drop MinGW support in Qt 6?
>>> What alternative do you propse?
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Wither QString?

[Henry Skoglund]

Hi, while writing lots of QString string fiddling code (keyboard macro 
utility) I feel something tugging at my sleeve:

the upcoming C++20, looking at std::format(), it seems really handy, e.g.:

std::string s = std::format("String '{}' has {} characters\n", string, 
string.length());


// for a German flavor you can use arg #
std::string s = std::format("{1} Zeichen lang ist die Zeichenkette 
'{0}'\n", string, string.length());


// lots of formatting options with a ':'|inside the curlies
||std::string s = std::format("{0:b} {0:d} {0:x}", 42);   // s == 
"101010 42 2a"|

|
Using QString::arg() works fine but it's getting harder to ignore all 
the new C++ stuff and C++20 looks to be one of the bigger additions to 
the language since C++11.


Perhaps the time has come to think about a retirement plan for QString?

Rgrds Henry

|
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Wither QString?

[Henry Skoglund]

Thanks for the answers!
I haven't got much experience yet of std::string so I thought the grass 
was greener over there. But sure, functions like split() and trimmed() I 
use regularly, and they indeed seem to be lacking in std::string.
So sorry QString about that brief moment of infidelity, won't happen 
again :-)



On 2019-10-18 03:49, Sze Howe Koh wrote:

On Fri, 18 Oct 2019 at 08:43, Alexander Nassian
 wrote:

C++ hasn‘t even proper Unicode handling integrated. std::string is a mess in my 
opinion.

Beste Grüße / Best regards,
Alexander Nassian

Am 18.10.2019 um 02:30 schrieb Henry Skoglund :


 Hi, while writing lots of QString string fiddling code (keyboard macro 
utility) I feel something tugging at my sleeve:
the upcoming C++20, looking at std::format(), it seems really handy, e.g.:

std::string s = std::format("String '{}' has {} characters\n", string, 
string.length());

// for a German flavor you can use arg #
std::string s = std::format("{1} Zeichen lang ist die Zeichenkette '{0}'\n", 
string, string.length());

// lots of formatting options with a ':' inside the curlies
std::string s = std::format("{0:b} {0:d} {0:x}", 42);   // s == "101010 42 2a"

Using QString::arg() works fine but it's getting harder to ignore all the new 
C++ stuff and C++20 looks to be one of the bigger additions to the language 
since C++11.

Perhaps the time has come to think about a retirement plan for QString?

Rgrds Henry

I agree with Alexander; QString is far more pleasant to use than
std::string for many everyday tasks.

Aside from Unicode support, std::string lacks (clean) equivalents of
the following functions which I use regularly:
- QString::startsWith(), QString::endsWith()
- QString::split(), QString::section()
- QString::simplified(), QString::trimmed()
- QString::contains(), QString::indexOf() by regex
- QString::replace(), QString::remove() by substring or by regex

I refuse to ditch QString for std::string until Unicode and the above
functionality are offered in std::string, at the very least.


Here are more functions that are lacking in std::string. I personally
don't use them much, but they look pretty handy if the right project
comes along:
- QString::right()
- QString::localeAwareCompare()
- QString::compare() with Qt::CaseInsensitive
- QString::chop(), QString::chopped()
- QString::leftJustified(), QString::rightJustified()


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QWidget font settings propagation parent to child

[Henry Skoglund]

Hi,

I use Qt Creator's excellent Form Editor, however sometimes I've noticed 
an inconsistency in the font settings, because I'm lazy I usually only 
set the font property for the top MainWindow and relying on it to 
"trickle down" and affect the widgets as well. Except sometimes it 
doesn't trickle down :-( So I wrote a test app, just a main.cpp:


#include "QtWidgets"

int main(int argc, char** argv)
{
    QApplication a(argc,argv);
    QMainWindow w;

    auto listFonts = [&w]
    {
    for (auto pKid : 
w.findChildren("",Qt::FindDirectChildrenOnly))
    qDebug() << pKid->metaObject()->className() << 
pKid->font().family();

    };

    w.setFont(QFont("Courier"));
    new QTextEdit(&w);
    new QLabel(&w);
    new QPushButton(&w);
    new QCalendarWidget(&w);
    new QListWidget(&w);
    new QTableWidget(&w);

    qDebug() << "Before w.show();"; listFonts();

    w.show();  // start the party

    qDebug() << "\nAfter w.show();"; listFonts();
}

The above app simulates what Qt Creator's Form Editor does (or, rather 
what the generated code in ui_mainwindow.h does), i.e. it sets the font 
prop for the MainWindow and then adds the children. If you run this 
program on Linux, the debug output is as expected:


Before w.show();
QTextEdit "Courier"
QLabel "Courier"
QPushButton "Courier"
QCalendarWidget "Courier"
QListWidget "Courier"
QTableWidget "Courier"

After w.show();
QTextEdit "Courier"
QLabel "Courier"
QPushButton "Courier"
QCalendarWidget "Courier"
QListWidget "Courier"
QTableWidget "Courier"

Everything is nice and dandy. However, running the same program on 
Windows gives this output (the Before part is the same)


...
After w.show();
QTextEdit "Courier"
QLabel "Courier"
QPushButton "Courier"
QCalendarWidget "Courier"
QListWidget "Tahoma"
QTableWidget "Tahoma"

Lost 2 font propagations there. And on the Mac it's even worse (the 
Before part is the same here, but):


...
After w.show();
QTextEdit "Courier"
QLabel ".AppleSystemUIFont"
QPushButton ".AppleSystemUIFont"
QCalendarWidget "Courier"
QListWidget ".AppleSystemUIFont"
QTableWidget ".AppleSystemUIFont"

Lost another 2, i.e. only 33% hit rate.

Now. the obvious solution is of course to always set the font properties 
explicitly for all widgets on my MainWindow. But it's so convenient to 
be able to change only the topmost font prop. Also the documentation for 
QWidget says "font propagation" should always occur. And sure, on Linux 
the docs are correct. But what about us running Windows or Macs?


Well, the first thing I tried was to reshuffle the lines in my test app:
...
    // w.setFont(QFont("Courier"));
    new QTextEdit(&w);
    new QLabel(&w);
    new QPushButton(&w);
    new QCalendarWidget(&w);
    new QListWidget(&w);
    new QTableWidget(&w);
    w.setFont(QFont("Courier"));
...

Setting the font *after* adding the children does the trick, the hit 
rate is now 100% also on Windows and Mac. But, the problem is that this 
isn't the way the Form Editor (ui_mainwindow.h) works, it is hardwired 
to always set the properties for the MainWindow before adding any children.



So as a workaround, I've resorted to adding one line of code in the 
MainWindow constructor in my Qt widget-flavored programs:

...
{
    ui->setupUi(this);

    auto f = font(); setFont(QFont("Grapefruit")); setFont(f);
...

Why the grapefruit? It's needed to "shake the tree", because when 
setting the same font as the code in ui_mainwindow.h does. it's ignored. 
You need to change to another font first, then the setFont(f) call will 
register properly (and propagate 100% to the kids). This can be 
illustrated if we change the test program to:

...
    w.setFont(QFont("Courier"));
    new QTextEdit(&w);
    new QLabel(&w);
    new QPushButton(&w);
    new QCalendarWidget(&w);
    new QListWidget(&w);
    new QTableWidget(&w);
    w.setFont(QFont("Courier"));
...

That version behaves exactly like the first version above (with the 
misses), i.e. like the 2nd setFont() call does not exist. But adding the 
dummy font call:

...
    w.setFont(QFont("Courier"));
    new QTextEdit(&w);
    new QLabel(&w);
    new QPushButton(&w);
    new QCalendarWidget(&w);
    new QListWidget(&w);
    new QTableWidget(&w);
    w.setFont(QFont("Grapefruit"));
    w.setFont(QFont("Courier"));
...

works, 100$ font prop propagation on all systems :-)


Question: is this hit or miss font propagation on Windows and Mac a bug 
or a feature? If it's a feature, could it be documented?


Rgrds Henry

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QWidget font settings propagation parent to child

[Henry Skoglund]

On 2019-10-23 20:49, Elvis Stansvik wrote:

Den ons 23 okt. 2019 kl 20:18 skrev Ville Voutilainen
:

On Wed, 23 Oct 2019 at 18:49, Elvis Stansvik  wrote:

Den ons 23 okt. 2019 16:29Henry Skoglund  skrev:

Hi,

I use Qt Creator's excellent Form Editor, however sometimes I've noticed an inconsistency 
in the font settings, because I'm lazy I usually only set the font property for the top 
MainWindow and relying on it to "trickle down" and affect the widgets as well. 
Except sometimes it doesn't trickle down :-( So I wrote a test app, just a main.cpp:


I don't want to be that person who always asks "why are you even doing this", 
but.. Why are you even doing this? :p

Changing the font is normally not recommended. I think the best practice is to 
let the font remain as the platform plugin decided, so that the user's choice 
of font is respected.

And if the user changes their choice, should it be possible to reflect
that dynamically on a running application? I have no trouble coming up
with dozens of use cases where you want to change the font of an
application, or a part of its widget hierarchy.

I believe you get that for free if you leave the font alone. At least
my Qt applications change when I change my system font choice under
KDE.

Elvis
In my case, I apply the font setting as a "look and feel" or signature 
telling the user that it's an app from me. Granted, a big/complicated 
application you'll be doing all of the widget settings more or less 
explicitly anyway. This is more of a concern for me for short-lived apps 
(say 500 lines in mainwindow.cpp) that I want to churn out quickly for a 
specific reason, but nevertheless convey my signature "look and feel".


Note that the point size of the font is lost as well when the 
propagation parent to child widget fails. For example, I use a 16-point 
sized font (because many of my users are old doctors) but the default 
vanilla font that appears (in my example for Windows it's in QListWidget 
and QTableWidget ) is Tahoma 8.25-point size. So even if I can live with 
Tahoma the point size of the font needs to be almost doubled.


Also. I think this is a philosophical question, because if you look at 
the "Before w.show():" debug output in my example, all the widgets 
answers: "Yes sir, we have got your order, we'll be showing the Courier 
font when the party starts". Except that some of them don't (unless 
you're on Linux).


I mean, I could live with this if the widgets that cannot deliver would 
tell me so, i.e. if they would answer "Tahoma" instead of "Courier" when 
I ask them in the "Before w.show():" section. And the fact that I have 
to pull that grapefruit trick indicates that the widget has received the 
font change, but not completely :-(


Rgrds Henry

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QWidget font settings propagation parent to child

[Henry Skoglund]

On 2019-10-24 08:13, Giuseppe D'Angelo via Development wrote:

Il 23/10/19 16:28, Henry Skoglund ha scritto:
Question: is this hit or miss font propagation on Windows and Mac a 
bug or a feature? If it's a feature, could it be documented?


Please do some extra investigation: who's setting those fonts?

* Is it the style, e.g. in QStyle::polish(QWidget*)?
* Is it coming from QApplication::font? Or maybe QStyle::polish(QApp*)?
* Do the widgets have WA_SetFont enabled?
etc.

It certainly sounds surprising at first that some widgets don't 
inherit the font, but there could be a good explanation. Lacking such 
explanation, then we're talking about a quite serious bug.

First the easy questions:

* Do the widgets have WA_SETFont enabled? No, none of the kids, just the 
parent (because I called setFont() on it).
(The WA_SetFont() flag is pretty easy to understand (even for me :-) 
i.e. widgets with that flag=true says: leave me alone, don't do the font 
propagation on me, got my own font setting figured out.)


* Is it coming from QApplication::font()? No, because I do that 
setFont("Courier") on my top window. But if I comment that line out, my 
top widget would get that application default font instead (on my 
Windows PC it's "MS Shell Dlg 2", 8.25 point size).


Off topic: those 8.25 point sizes as default was an excellent choice 20 
years ago when the common display size was 1024x768 or so. Nowadays the 
display sizes are bigger, why not change those prewired 
QApplication::font point sizes to say 12 or even 14?



This is a pretty complicated subject, for example, for a QTableWidget, 
the font propagation works for the vertical and horizontal header rows, 
but not for the text inside the cells. And it's platform dependent, i.e. 
on Linux everything just *works*.


Anyway, the reason I started this thread was that I couldn't understand 
how the font propagation really worked. I would be perfectly happy with 
the current state of affairs, if it could be documented somehow. Right 
now QWidget's font documentation says that the font propagation should 
occur, except when the QWidget's isWindow() is true, but all of the 
widgets in my example: isWindow() == false.


I'll look into the QStyle stuff, and I'm pretty sure as you say, that 
the behavior I'm observing is a result of many years hard work with the 
QWidgets.


Rgrds Henry

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Dark appearance on iPhone not so dark

[Henry Skoglund]

Hi, just tested my first Qt 14.0 iPhone app. My iPhone is running iOS 13 
and I'm using the new dark appearance mode on it.


When I run my Qt app (a vanilla widgets app just invoking a QMessageBox 
and then exiting) on my Mac, which is set to dark mode, everything is 
indeed dark in my Qt app (both the mainwindow and the QMessageBox).


But when I try the same simple widgets app on my iPhone, only the 
QMessageBox becomes dark, the mainwindow is white :-(

(The simulator behaves the same).

Is this something that will be fixed or?

Rgrds Henry

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dark appearance on iPhone not so dark

[Henry Skoglund]

On 2019-12-27 13:35, Shawn Rutledge wrote:



On 26 Dec 2019, at 01:09, Henry Skoglund  wrote:

Hi, just tested my first Qt 14.0 iPhone app. My iPhone is running iOS 13 and 
I'm using the new dark appearance mode on it.

When I run my Qt app (a vanilla widgets app just invoking a QMessageBox and 
then exiting) on my Mac, which is set to dark mode, everything is indeed dark 
in my Qt app (both the mainwindow and the QMessageBox).

But when I try the same simple widgets app on my iPhone, only the QMessageBox 
becomes dark, the mainwindow is white :-(
(The simulator behaves the same).

It sounds like you should write up a bug.


Good idea, it's here https://bugreports.qt.io/browse/QTBUG-81004

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix

[Henry Skoglund]

On 2020-01-14 09:02, Kai Köhne wrote:

From: Development  On Behalf Of Dmitriy 
Purgin
Sent: Tuesday, January 14, 2020 8:46 AM
To: Thiago Macieira 
Cc: Qt development mailing list 
Subject: Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix

I've just discovered another side-effect of this change. I've integrated the qdoc.exe 
in a custom toolchain for internal use, and it should be able to run in environments 
> without any Qt installations. So I used to do the windeployqt.exe on it, and it 
always worked until 5.14. Now windeployqt says that the qdoc.exe is a Debug 
executable > (!), and it fails to deploy Qt5Cored.dll for obvious reasons. It 
seems like windeployqt is broken as well.

Can you file a bug about this? I’m still hoping to fix all remaining issues for 
5.14.1 …
  

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

If you don't to wait for 5.14.1 then I've patched utils.cpp (see the bug 
above), you can then rebuild windeployqt so that it works in MinGW 
5.14.0 or download the patched .exe it from here: 
https://tripleboot.org/Uploads/windeployqtreleaseonly.zip (32-bit) or 
https://tripleboot.org/Uploads/windeployqt64releaseonly.zip (64-bit)

Just drop it in MinGW's bin directory.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt vulnerabilities

[Henry Skoglund]

On 2020-01-30 18:09, Olivier Goffart wrote:

On 30/01/20 17:12, Thiago Macieira wrote:

On Thursday, 30 January 2020 03:05:50 PST Olivier Goffart wrote:

$PWD is not the same as the binary dir
(QCoreApplication::applicationDirPath) The later is still searched 
while
looking for plugin. (so that covers the case where plugin is in the 
folder

next to the binary)

But I am also not sure why Windows is not affected.


Because LoadLibrary() works differently from dlopen().

The Qt plugin loader code will open the DLL relative to $PWD and 
inspect its
plugin metadata, in order to decide whether to load or not. Then it 
tells
LoadLibrary to load a plain filename with no path components and 
LoadLibrary()
goes and searches the system paths (which include the .exe's) first. 
So it

loads a different file.

This is similar to a TOCTOU attack, but I couldn't come up with a 
reasonable

attack scenario. If the interposing DLL has metadata saying not to load,
QLibrary will find the actual plugin later and will load that. The 
worst that
could happen is that the interposing DLL has valid but incorrect 
metadata
causing another DLL to be loaded that shouldn't be. This other DLL 
isn't under

the control of the attacker, though and neither is the name of the DLL.


I think a reasonable attack scenario remains if the plugin does not 
exist in the system.


Hi, since Qt's plugin loader does not care what the filename is, as long 
as it ends with .dll (i.e. if you rename qwindows.dll to grapefruit.dll 
it will still be loaded), isn't an attack always possible?


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Thank you for qScopeGuard

[Henry Skoglund]

Hi, just want to thank whoever worked to implement qScopeGuard (in 
5.12), it was a perfect gift from heaven today :-)


I'm writing a LOB app with heavy database munging, and want to show the 
user an hourglass cursor while munging/waiting for MS SQLServer.
However my functions have lots of exits due to bad weather etc. and I 
dreaded pasting a restore-mouse-cursor call everywhere. Googled a bit 
and now I use this 2-line magic at the top of my functions:

...
    qApp->setOverrideCursor(Qt::WaitCursor);
    auto restoreCursor = qScopeGuard([] { 
qApp->restoreOverrideCursor(); });

...

Before I discovered Qt I spent 20 years in MFC purgatory, but now I've 
seen the light!


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Thank you for qScopeGuard

[Henry Skoglund]

On 2020-02-21 15:02, NIkolai Marchenko wrote:
it's definitely neat, but it's nothing that you can't do with pure c++ 
though. It's just qt's native implementation of score guard pattern. 
Tbh I didn't even know it existed because I use my own scope guarder 
class.


On Fri, Feb 21, 2020 at 4:33 PM Henry Skoglund <mailto:he...@tungware.se>> wrote:


Hi, just want to thank whoever worked to implement qScopeGuard (in
5.12), it was a perfect gift from heaven today :-)

I'm writing a LOB app with heavy database munging, and want to
show the
user an hourglass cursor while munging/waiting for MS SQLServer.
However my functions have lots of exits due to bad weather etc. and I
dreaded pasting a restore-mouse-cursor call everywhere. Googled a bit
and now I use this 2-line magic at the top of my functions:
...
 qApp->setOverrideCursor(Qt::WaitCursor);
 auto restoreCursor = qScopeGuard([] {
qApp->restoreOverrideCursor(); });
...

Before I discovered Qt I spent 20 years in MFC purgatory, but now
I've
seen the light!



Agreed, you could roll your own class say in an hour, but it's there, 
*documented* and someone has tested and debugged it for me already. 
That's what "standing on the shoulder of giants" is all about...


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Announce] Qt Creator 4.12 released

[Henry Skoglund]

On 2020-04-23 11:48, List for announcements regarding Qt releases and 
development wrote:

We are happy to announce the release of Qt Creator 4.12!

https://www.qt.io/blog/qt-creator-4.12-released

Thank you! I like the new Restart feature, i.e. when you switch Theme, 
say from Flat Light to Flat Dark, Qt Creator now suggests to restart by 
itself (instead of saying "will take effect after restart" and you have 
to do it yourself).


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QString and related changes for Qt 6

[Henry Skoglund]

On 2020-05-12 12:36, Lars Knoll wrote:
...
Leaving things behind simplifies our lives and in the longer term also 
our users life. And yes, non unicode encodings are legacy in todays 
world. They need to disappear, and most people are working towards 
that goal. We can and should do our part.

Lars


+1

I still have some .exe files around I wrote for WIndows 3.0 in 1991, 
while they run nicely today (GDI graphics) on my Windows 10 PC, the 
Swedish characters display wrong, because somewhere along the way 
Microsoft decided that the kosher codepage for Windows programs would 
cease to be 850 and instead be 1251. Yes in 1991 CP 850 was hot, today 
not so much. So I'd prefer if Qt would require UTF-8 even on Windows.


P.S. Consider a similar type of "technical debt" being settled by Qt: 
I'm thinking of the "DPI awareness" setting in 5.14, i.e. for a default 
widgets program, Qt nowadays tells WIndows that it's "DPI aware" and 
wants the truth about screen coordinates, even on those portable PCs 
with high DPIs that have Scale set to 125% or 150%.  On the Qt forum 
I've seen lot of heat/complaints about QLabels being shoehorned in with 
the QLineEdits because the fonts are too big for those 125% or 150% 
screens, I'd answer: create a qt.conf file with the contents:

[Platforms]
WindowsArguments = dpiawareness=0

and your legacy widgets program will go back to display fine, albeit a 
bit blurry and bloated.
But! If you're asking (with that qt.conf file present) what the screen 
size is (e.g. QGuiApplication::screens(0)->geometry() etc.) Windows will 
lie to you and scale "backwards" so that a normal 2560x1440 screen is 
reported as "QRect(0,0,1707,960)". So using dpiawareness=0 is a bad 
long-term solution :-(


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 high-dpi support

[Henry Skoglund]

On 2020-05-13 16:53, Morten Sørvig wrote:

We are indeed planning to addreess high-DPI support for Qt 6. You can test the 
implementation on
Qt 5.14+ today by setting

 QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
 
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);

This should make sure labels and line edits are correctly sized, also for 125% 
and 150%.

Interestingly, Qt will then “lie” about the about the screen size the same way 
that dpiawareness=0
does, although while rendering at the full resolution (so no blurriness).

Morten

Thank you for this!

All of my apps had the blurriness problem, in fact recently one of my 
users on a brand new laptop (with a 150% scale screen) complained and 
said that my program looked like "East Germany" which (if you're old 
enough to realize) is not a compliment :-(


My old code (I wanted a fire-and-forget solution, i.e. no qt.conf which 
is easily forgotten, so C++) was this:

...
#if !defined(DPI_AWARENESS_CONTEXT_UNAWARE)
// (these lines are copied from a fresh windef.h)
    DECLARE_HANDLE(DPI_AWARENESS_CONTEXT);

    #define DPI_AWARENESS_CONTEXT_UNAWARE ((DPI_AWARENESS_CONTEXT)-1)
    #define DPI_AWARENESS_CONTEXT_SYSTEM_AWARE ((DPI_AWARENESS_CONTEXT)-2)
    #define DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE 
((DPI_AWARENESS_CONTEXT)-3)
    #define DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 
((DPI_AWARENESS_CONTEXT)-4)
    #define DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED 
((DPI_AWARENESS_CONTEXT)-5)

#endif
    static const int nnBuild1703 = 15063;   // can use 
DPI_AWARENESS_CONTEXT_UNAWARE
    static const int nnBuild1809 = 17763;   // can use 
DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED


// Windows 10 build 1703 or later?
    if (QOperatingSystemVersion::current() >= 
QOperatingSystemVersion(QOperatingSystemVersion::Windows,10,0,nnBuild1703))

    {
    // dynamically resolve the address to SetProcessDpiAwarenessContext()
    auto f = reinterpret_cast*)(DPI_AWARENESS_CONTEXT)>(QLibrary("user32.dll").resolve("SetProcessDpiAwarenessContext"));

    auto value = DPI_AWARENESS_CONTEXT_UNAWARE;

    // on build 1809 (or later)? let's try GDISCALED
    if (QOperatingSystemVersion::current() >= 
QOperatingSystemVersion(QOperatingSystemVersion::Windows,10,0,nnBuild1809))

    value = DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED;

    bool bOk = f(value);
    if (!bOk)
    qWarning("SetProcessDpiAwarenessContext() failed.");
    }
...
I think very few of my users are on Windows 8.1 so I leapfrogged the 
DpiAware functions in SHCore.dll and went for the new ones in Windows 10 
(they are in user32.dll) but to no avail, it was East Germany anyway, 
here are 2 screenshots, first from a 100% screen for comparison, then 
from a 125% screen using my code above (I've anonymized patient names etc.):

https://tripleboot.org/Pictures/Scale100Percent.png
https://tripleboot.org/Pictures/Scale125PercentDpiAwareness0.png

On the 100% screen all is fine and dandy but on the 125% screen -> 
fuzziness galore.


So I tossed the code above and tried your 2 liner from today:
...
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
...

Voila: https://tripleboot.org/Pictures/Scale125PercentPassThrough.png
Goodbye East Germany!

Thank you again /Henry

P.S. Now this wouldn't be complete without some small complaint, I'm 
thinking of the horizontal lines for separating the different rows of 
patients (they are QFrames, or "Horizontal Line" as they are called in 
Qt Creator's widget designer).
I insert them manually on top of the QTableWidget, they have a lineWidth 
of 1 and are rendered as such on the 100% or the 200% screens. But on 
125%, 150% etc. screens they are rendered a bit uneven using the new 2 
liner/passthrough code, you can see it on my last/3rd screenshot. I 
suspect it's some kind of rounding problem. This is *not* a big deal, 
just me being pedantic.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 high-dpi support

[Henry Skoglund]

On 2020-05-13 23:41, Henry Skoglund wrote:

On 2020-05-13 16:53, Morten Sørvig wrote:
We are indeed planning to addreess high-DPI support for Qt 6. You can 
test the implementation on

Qt 5.14+ today by setting

 QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);

This should make sure labels and line edits are correctly sized, also 
for 125% and 150%.


Interestingly, Qt will then “lie” about the about the screen size the 
same way that dpiawareness=0
does, although while rendering at the full resolution (so no 
blurriness).


Morten

Thank you for this!

All of my apps had the blurriness problem, in fact recently one of my 
users on a brand new laptop (with a 150% scale screen) complained and 
said that my program looked like "East Germany" which (if you're old 
enough to realize) is not a compliment :-(


My old code (I wanted a fire-and-forget solution, i.e. no qt.conf 
which is easily forgotten, so C++) was this:

...
#if !defined(DPI_AWARENESS_CONTEXT_UNAWARE)
// (these lines are copied from a fresh windef.h)
    DECLARE_HANDLE(DPI_AWARENESS_CONTEXT);

    #define DPI_AWARENESS_CONTEXT_UNAWARE ((DPI_AWARENESS_CONTEXT)-1)
    #define DPI_AWARENESS_CONTEXT_SYSTEM_AWARE 
((DPI_AWARENESS_CONTEXT)-2)
    #define DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE 
((DPI_AWARENESS_CONTEXT)-3)
    #define DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 
((DPI_AWARENESS_CONTEXT)-4)
    #define DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED 
((DPI_AWARENESS_CONTEXT)-5)

#endif
    static const int nnBuild1703 = 15063;   // can use 
DPI_AWARENESS_CONTEXT_UNAWARE
    static const int nnBuild1809 = 17763;   // can use 
DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED


// Windows 10 build 1703 or later?
    if (QOperatingSystemVersion::current() >= 
QOperatingSystemVersion(QOperatingSystemVersion::Windows,10,0,nnBuild1703))

    {
    // dynamically resolve the address to SetProcessDpiAwarenessContext()
    auto f = reinterpret_cast*)(DPI_AWARENESS_CONTEXT)>(QLibrary("user32.dll").resolve("SetProcessDpiAwarenessContext"));

    auto value = DPI_AWARENESS_CONTEXT_UNAWARE;

    // on build 1809 (or later)? let's try GDISCALED
    if (QOperatingSystemVersion::current() >= 
QOperatingSystemVersion(QOperatingSystemVersion::Windows,10,0,nnBuild1809))

    value = DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED;

    bool bOk = f(value);
    if (!bOk)
    qWarning("SetProcessDpiAwarenessContext() failed.");
    }
...
I think very few of my users are on Windows 8.1 so I leapfrogged the 
DpiAware functions in SHCore.dll and went for the new ones in Windows 
10 (they are in user32.dll) but to no avail, it was East Germany 
anyway, here are 2 screenshots, first from a 100% screen for 
comparison, then from a 125% screen using my code above (I've 
anonymized patient names etc.):

https://tripleboot.org/Pictures/Scale100Percent.png
https://tripleboot.org/Pictures/Scale125PercentDpiAwareness0.png

On the 100% screen all is fine and dandy but on the 125% screen -> 
fuzziness galore.


So I tossed the code above and tried your 2 liner from today:
...
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough); 


...

Voila: https://tripleboot.org/Pictures/Scale125PercentPassThrough.png
Goodbye East Germany!

Thank you again /Henry

P.S. Now this wouldn't be complete without some small complaint, I'm 
thinking of the horizontal lines for separating the different rows of 
patients (they are QFrames, or "Horizontal Line" as they are called in 
Qt Creator's widget designer).
I insert them manually on top of the QTableWidget, they have a 
lineWidth of 1 and are rendered as such on the 100% or the 200% 
screens. But on 125%, 150% etc. screens they are rendered a bit uneven 
using the new 2 liner/passthrough code, you can see it on my last/3rd 
screenshot. I suspect it's some kind of rounding problem. This is 
*not* a big deal, just me being pedantic.
About that "rounding problem", don't bother with it, I think I fixed it, 
or at least understand it:
turns it occurs on 125% and 175% screens every 4 row, and on a 150% 
screen every 2nd row.


So I added this tweaking code (which simulates the rounding error) where 
I calculcate the QRect for the QFrame:

...
int top = .. // the top for the QFrame's geometry for the current row
int nDPRatioPercent = qRound(devicePixelRatioF() * 100); // will be 100, 
125, 150 etc.

int topNudged = (((top * nDPRatioPercent) / 100) * 100) / nDPRatioPercent;
...

topNudged will differ with 1 pixel (compared to top) for every 4th row 
on 125% and 175% screens, and for every 2nd row on 150% screens, so I 
just use topNudged instead of top for QFrame's geometry. Wit

Re: [Development] QProperty and library coding guide

[Henry Skoglund]

On 2020-07-23 23:09, Ville Voutilainen wrote:

On Fri, 24 Jul 2020 at 00:03, Ville Voutilainen
 wrote:

On Thu, 23 Jul 2020 at 23:59, Thiago Macieira  wrote:

On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:

I think the primary environment where a transition and resulting BC
breakage would be annoying is the Linux system environment with gcc. This
is where Olivier’s solution is quite elegant IMO.

I'd rather go to [[no_unique_address]] instead of this. The extension doesn't
compile in all cases (you can't have a Flexible Array Member everywhere) and
is going to produce warnings.

Let's just drop GCC 8.

Does that also drop QNX?

It'll also drop mingw for now, unless we start using
https://nuwen.net/mingw.html, which
is 64-bit only.

If you're thinking of mingw on Windows, then there's an other 
alternative msys2 https://www.msys2.org/
it has gcc 10.1.0 (and it also has fresh downloads of 32-bits and 
64-bits Qt Creator 4.12.4 built with 5.15.0 gcc 10.1.0).


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] std::atomic

[Henry Skoglund]

On 2016-10-21 00:11, Sergio Martins wrote:

On 2016-10-20 21:43, Thiago Macieira wrote:

Em quinta-feira, 20 de outubro de 2016, às 17:28:39 PDT, Philippe
escreveu:

std::atomic is used as underlying implementation for the the Qt atomic
API with CLang on Mac.
But why not with Visual Studio 2015? You will certainly mention some
bug,
but then where is the problem? (shortly)


Because the Microsoft compiler does not support constexpr properly. See
https://connect.microsoft.com/VisualStudio/feedback/details/2011648

I haven't tested Update 3 to see if that is fixed.


Do you have a testcase for this bug ?
I couldn't reproduce with Update2 by using a class with constexpr ctor
and an array member, so I think I'm not testing it correctly.


If you click on "DETAILS" there is a testcase attached. Also, I just 
tested on Visual Studio 2015 Update 3 and it still fails. /Rgrds Henry



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Henry Skoglund]

On 2017-06-16 21:52, Thiago Macieira wrote:

On Friday, 16 June 2017 11:14:20 PDT André Pönitz wrote:

On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote:

character set. Without the /utf-8 option added in MSVC 2015 Update 2, the
conversion fails and the compiler prints:

warning C4566: character represented by universal-character-name '\u0431'
cannot be represented in the current code page (1252)

[ok, not a C++11 issue per se, but we still want to use Unicode source
code]

There was never *consensus* on using something outside plain ASCII in
Qt sources.

This is predicted, self-inflicted pain.


Right, we've had to live with ASCII-only sources for the last 25 years. We
could wait a little longer.

I just don't want to!

Here's a tricky question: how do you create a QStringLiteral with non-ASCII
characters that will work on all our supported compilers?



That question reminds me of the discussion last August 
http://lists.qt-project.org/pipermail/interest/2016-August/023882.html 
about Unicode code points in MSVC and how to fix so that 
tr("Coördinaat") or tr("Co\u00F6rdinaat"); worked with old MSVC compilers.


My workaround: use raw UTF8 hex bytes: tr("Co\xC3\xB6rdinaat");

I think using that stunt should allow you to encode any non-ASCII 
characters inside a QStringLiteral with any compiler that supports "\x..."


Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ActiveQt Events

[Henry Skoglund]

On 2017-06-27 10:54, neel patel wrote:

Hi All,

As I am using "QAxWidget". I took the "webbrowser" example as reference.
As I am using "QTabWidget" as mainwindow widget and adding "QAxWidget" 
as tab widget. Below is the code for reference.



 m_tabWidget = new QTabWidget(mainwindow);

 m_mainGridLayout = new QGridLayout(m_tabWidget);
 m_mainGridLayout->setContentsMargins(0, 0, 0, 0);

 m_MainTab = new QWidget(m_tabWidget);
 m_tabGridLayout = new QGridLayout(m_MainTab);
 m_tabGridLayout->setContentsMargins(0, 0, 0, 0);

 m_activeX = new WebAxWidget(m_MainTab);
 
m_activeX->setControl(QStringLiteral("{8856F961-340A-11D0-A96B-00C04FD705A2}"));

 m_activeX->setObjectName(QStringLiteral("WebBrowser"));
 m_activeX->setFocusPolicy(Qt::StrongFocus);

 m_tabGridLayout->addWidget(m_activeX, 0, 0, 1, 1);
 m_tabWidget->addTab(m_MainTab, QString());

 mainwindow->setCentralWidget(m_tabWidget);

class WebAxWidget : public QAxWidget
{
public:

 WebAxWidget(QWidget* parent = 0, Qt::WindowFlags f = 0)
 : QAxWidget(parent, f)
 {
 }
}



I want to receive events like NewWindow3, NewWindow2, BeforeNavigate2 
with Qt. As such there is no signal available in "QAxWidget". How can we 
receive those signals from windows COM interface ?


Let me know reference or pointers so that i can implement and suggest in 
above code.


Thanks in Advance.


Hi, you can receive those events through the generic QAxBase::signal, 
see http://doc.qt.io/qt-5/qaxbase.html#signal
In it, you'll see the example code for receiving "BeforeNavigate2", and 
all the other event flavors you retrieve the same way.


So first, add the slot declaration to your MainWindow class:
...
private slots:
void slot(const QString& name,int argc, void* argv);
...

then connect your m_activeX object to that signal, here is some sample 
code added after your " mainwindow->setCentralWidget(m_tabWidget);":


...
connect(m_activeX,SIGNAL(signal(const 
QString&,int,void*)),this,SLOT(slot(const QString&,int,void*)));
//connect(m_activeX,&QAxWidget::signal,this,&MainWindow::slot);  // 
this is better syntax but alas will *not* compile :-(


// setup a sample navigation
QString url = "http://doc.qt.io/qt-5/qaxbase.html";;
m_activeX->dynamicCall("Navigate(const QString&)",url);
}

// here's how to receive all of them
// you'll have to check the name for the correct one, I'll give you 2 
for free

// just add the others you need...
// note: the example in QAxBase::signal is too old to compile correctly, 
(changed below)


// need this for the VARIANTARG chaps
#include "windows.h"

void MainWindow::slot(const QString &name, int argc, void *argv)
{
VARIANTARG *params = (VARIANTARG*)argv;
if (name.startsWith("BeforeNavigate2("))
{
// 
"BeforeNavigate2(IDispatch*,QVariant&,QVariant&,QVariant&,QVariant&,QVariant&,bool&)"

IDispatch *pDisp = params[argc-1].pdispVal;
VARIANTARG URL = *params[argc-2].pvarVal;
VARIANTARG Flags = *params[argc-3].pvarVal;
VARIANTARG TargetFrameName = *params[argc-4].pvarVal;
VARIANTARG PostData = *params[argc-5].pvarVal;
VARIANTARG Headers = *params[argc-6].pvarVal;
VARIANT_BOOL *Cancel = params[argc-7].pboolVal;

QString url = QString::fromStdWString(URL.bstrVal);
qDebug() << "BeforeNavigate2, ur" << url;
}

if (name.startsWith("NewWindow3("))
{
// NewWindow3(IDispatch**,bool&,uint,QString,QString)"
IDispatch *pDisp = params[argc-1].pdispVal;
VARIANT_BOOL* Cancel = params[argc-2].pboolVal;
uint Flags = params[argc-3].uintVal;
BSTR URLContext = params[argc-4].bstrVal;
BSTR URL = params[argc-5].bstrVal;

QString urlContext = QString::fromStdWString(URLContext);
QString url = QString::fromStdWString(URL);
qDebug() << "NewWindow3, opening" << url << "from" << urlContext;
}
}
...

Good luck! Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] A taste of the future: declaring QLists without <>

[Henry Skoglund]

Hi,

reading about the new C++17 standard, I decided to test some Qt code:
...
QList li = {7,8,4,2,5,4,3};
QList ll = {5,3,34,5,44};

qDebug() << li;
qDebug() << ll;
...

The normal g++ 5.4 on vanilla Qt 5.9.1 on my Ubuntu 16.04 returns:
"home/henry/test/mainwindow.cpp:13: error: missing template arguments 
before ‘ll’

 QList ll = {5,3,34,5,44};
   ^
Upgraded gcc to g++ 6. Same error. But finding this ppa: 
https://launchpad.net/~jonathonf/+archive/ubuntu/gcc-7.1
I've managed to upgrade to the spanking new g++ 7.1, and voila, no sour 
grapes from the compiler (i.e the 2 qDebug() statements above returned 
both their proper lists). Nice!


Rgrds Henry


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [BB++] Now is 3.5x faster than Node.JS

[Henry Skoglund]

On 2017-07-24 00:13, Phil Bouchard wrote:

On 07/23/2017 03:54 PM, Thiago Macieira wrote:

On Sunday, 23 July 2017 12:27:44 PDT Phil Bouchard wrote:

..
..
..

How does your tool deal with runtime code generation via eval() ?


First you need to ask yourself if that function is really used a lot 
because I never used it but if it is then you'll have to use it like a C 
printf to pass the parameters, embed a compiler and compile it on-demand.




But what about Qt.include? I'm helping in on a QML project that reloads 
QML code from db using Qt.include. They won't like having to ship 
different c++ compilers for their different runtimes :-(


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] How to make a fancy QMap c++17 initializer_list

[Henry Skoglund]

Hello, I've been testing more C++17 class template auto deduction awith 
gcc-7, and got stuck on QMap, consider this simple test program:


-
#include "qapplication.h"
#include "qmap.h"
#include "qdebug.h"

int main(int argc, char *argv[])
{
QApplication a(argc, argv);

QMap m = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, 
{5,"years"}, {3,"and"}, {6,"ago"}};


for (auto v : m)
qDebug() << v;
}
-

I really would like to just write a {{Key,T}..} list but it will not 
compile. As a kludge/compromise it works if I write "std::pair" around 
the first {} pair, to force the compiler to see it my way. Then the 
speech of Mr. Lincoln comes out fine.


In C++17 you should be able to fix this through a "User-defined 
deduction guide" to help the compiler. I've been trying various template 
one-liners but alas, I think my brain is too small. Anyone got a clue?


Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to make a fancy QMap c++17 initializer_list

[Henry Skoglund]

Hi,

I think there are almost no need for deduction guides, for example a 
similar program using QVector compiles fine on gcc-7:


--
#include "qapplication.h"
#include "qvector.h"
#include "qdebug.h"

int main(int argc, char *argv[])
{
QApplication a(argc, argv);

QVector vec = {"Now", "is", "the", "time", "for", "all"};

for (auto v : vec)
qDebug() << v;
}
--

It's just QMap that I got stuck on, but as you say, it's very bleeding 
edge, mostly for showing off :-)


/Henry

On 2017-07-24 09:00, Marc Mutz wrote:

Hi,

We haven't added deduction guides to any Qt class, yet. If you want to 
use bleeding-edge C++, use C++, iow: std::map.


Patches welcome, bug reports accepted.

Thanks,
Marc

On 2017-07-24 06:32, Henry Skoglund wrote:

Hello, I've been testing more C++17 class template auto deduction
awith gcc-7, and got stuck on QMap, consider this simple test program:

-
#include "qapplication.h"
#include "qmap.h"
#include "qdebug.h"

int main(int argc, char *argv[])
{
QApplication a(argc, argv);

QMap m = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"},
{5,"years"}, {3,"and"}, {6,"ago"}};

for (auto v : m)
qDebug() << v;
}
-

I really would like to just write a {{Key,T}..} list but it will not
compile. As a kludge/compromise it works if I write "std::pair" around
the first {} pair, to force the compiler to see it my way. Then the
speech of Mr. Lincoln comes out fine.

In C++17 you should be able to fix this through a "User-defined
deduction guide" to help the compiler. I've been trying various
template one-liners but alas, I think my brain is too small. Anyone
got a clue?

Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development





___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to make a fancy QMap c++17 initializer_list

[Henry Skoglund]

On 2017-07-24 16:53, Thiago Macieira wrote:

On Monday, 24 July 2017 00:00:36 PDT Marc Mutz wrote:

Hi,

We haven't added deduction guides to any Qt class, yet. If you want to
use bleeding-edge C++, use C++, iow: std::map.


std::map currently (GCC 7.1.1) works less well than QMap, since you can't even
trick it. The std::pair that std::map uses requires a const Key, which you
can't get with a primitive prvalue.



Tested a bit more, here's the current best effort for both maps 
(yielding 12 words from Pres. Lincoln) and indeed Qt is ahead in this 
game (std::map requires more handholding):


-
#include "qapplication.h"
#include "qmap.h"
#include "map"
#include "qdebug.h"

int main(int argc, char *argv[])
{
QApplication a(argc, argv);

QMap m1 = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, 
{5,"years"}, {3,"and"}, {6,"ago"}};
std::map m2 = {std::pair{8,"fathers"}, 
{10,"forth"}, {7,"our"}, {11,"on"}, {9,"brought"}, {12,"this"}};


for (auto v : m1)
qDebug() << v;

for (auto v : m2)
qDebug() << v.second;
}

-

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to make a fancy QMap c++17 initializer_list

[Henry Skoglund]

On 2017-07-24 21:32, Grégoire Barbier wrote:

Le 24/07/2017 à 18:45, Henry Skoglund a écrit :
 QMap m1 = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, 
{5,"years"}, {3,"and"}, {6,"ago"}};


Or even this:

QMap m1 { {2, "score"}, {4, "seven"}, };



Yes that works nicely too but it's not bleeding edge/c++17 :-)

This post was just to show that in c++17 it's possible to declare a QMap 
without any trailing <> i.e. letting the compiler figure out the types 
(less visual clutter) More here: 
http://en.cppreference.com/w/cpp/language/class_template_argument_deduction


Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QRandomGenerator and boot times

[Henry Skoglund]

On 2017-09-14 09:21, Sami Nurmenniemi wrote:

Hi,

Commit 120ecc976fc3d5504d234702f68c2ad3898b77a4 changes default behavior 
of QRandomGenerator to use getentropy instead of /dev/urandom. This 
causes problems for device boot times when using QRandomGenerator in the 
boot sequence. As the commit message itself states "What's more, the 
glibc implementation blocks until entropy is available on early boot". 
Depending on the hw + kernel configuration of the device, this can 
increase boot time by more than a minute. For example in the Boot2Qt 
image qdbd and qtlauncher demo now block until the nonblocking pool is 
initialized. See QTBUG-63188.


What do you suggest for working around this problem?
1. Disable feature "getentropy" from Boot2Qt builds
- This is the behavior in Qt < 5.10.x
- Only difference in the entropy of randomness is in the early boot
2. Add "rng-tools" to the image for inputting entropy to the kernel
- Speeds up initialization of nonblocking pool
- On devices with HW random generator, this adds real entropy to the 
kernel pool
- On devices without HW random generator, this adds bad entropy from 
/dev/urandom to the kernel pool

3. Setting  QT_HASH_SEED for the affected processes
- Not a good solution IMO
- It seems code using this in qhash.cpp is the actual reason for the 
blocked processes (originated from QDebug)

4. Something else?


Hi, couldn't you just look at system's uptime (using sysinfo() for 
example), use /dev/urandom if the uptime is less than say 10 minutes, 
and use getentropy for the rest of the day?


Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] #pragma once

[Henry Skoglund]

On 2018-01-24 16:19, Ville Voutilainen wrote:

On 24 January 2018 at 16:30, Oswald Buddenhagen
 wrote:

but that's only tangentially related to the issue at hand, because the
compiler would still pick only one of the files under normal
circumstances. a problem would arise if different include styles in
different files lead to different headers being picked up from the same
-I list. it's fairly hard to construct such a case, and it *probably*
doesn't appear inside qt's "regular" build system (that specifically
excludes webkit & webengine).



That risk is not worth taking. Get your include guards right, and
don't mess with #pragma once.
There are tools that can help, but I haven't used them myself, and I
don't know whether clang
has anything for this.



Thank you for this clarification. I always thought #pragma once is 
superior to include guards, but I didn't really realize that the 
compiler is dealing with two different kind of namespaces (filenames vs 
#defined names), which could cause those problems mentioned above.


For exaample on Windows, if your're including files from a 
server/SMB-share, then I've seen sometimes the including files keep 
their drive letter, e.g P:\\dir\\file.h but sometimes it gets resolved 
into \\computername\\sharename\\dir\\file.h, and it's unclear if a 
#pragma once would treat those as the same file.


Rgrds Henry


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Prebuilt 32-bit versjon for MSVC 2017

[Henry Skoglund]

Hi,
if I want to download prebuilt Qt binaries for the UWP platform then I 
can choose between 32-bit and 64-bit flavors of both MSVC 2015 and MSVC 
2017.


It should be possible to offer the same variety for the Win32 versions, 
especially since I think the # of downloads for the Win32 Qt versions 
exceed the # of downloads for the UWP platform (for example, UWP 
requires Windows 10, but Win32 versions also work on Windows 7 and 8).


Rgrds Henry


On 2018-02-21 14:04, NIkolai Marchenko wrote:
This dedication to dropping MSVC2015x32 seems quite stange after the 
whole controversy of dropping MSVC2013 and how many people prefered to 
tread very carefully and slowly.


Unlike msvc 2013, 15th compiler is way better and doesn't restrain Qt 
codebase nearly as much


On Wed, Feb 21, 2018 at 3:44 PM, Harald Kjølberg > wrote:



Hi,

Currently Qt ships with 32-bit binaries for MSVC 2015, but not for
MSVC 2017. The Qt Company have received requests for adding prebuilt
32-bit binaries also for MSVC 2017. By adding more prebuilt
binaries, we increase the complexity, and add to the overall
maintenance of our QA system. Our preferred approach would be to add
binaries for MSVC 2017 and remove the binaries for MSVC 2015, as the
numbers of binaries in the build remains the same. It will still be
possible to manually build Qt for MSVC 2015, in the same way as it
is possible to manually build for MSVC 2017 today. Feedback and
viewpoints are much appreciated and will enable us to make the best
possible decision.




Best regards,
Harald Kjølberg
Product Manager - Qt for Application Development



___
Development mailing list
Development@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/development





___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Prebuilt 32-bit versjon for MSVC 2017

[Henry Skoglund]

On 2018-02-21 14:22, Maurice Kalinowski wrote:

The reason we have had x86 and x64 packages for UWP is not to target those two 
architectures for the desktop, but rather that the x86 version also works for 
the emulators for Windows Phone 8 / Windows 10 Mobile as well as Windows 10 IoT 
(Core).

Given that two out of those are basically gone by now, I'd be fine with 
dropping UWP x86 packages, but keep the arm packages for out embedded user base 
on Windows 10 IoT.

BR,
Maurice


This is very good news. Several times in the Qt Forums I've helped 
people who wanted 32-bit prebuilt MSVC2017 Qt binaries, and ended up 
downloading the UWP version for building Win32 apps.



Of course Visual Studio when building UWP apps does not use the linker 
switch /SUBSYSTEM:WINDOWS,6.2 setting to disallow starting the .exe file 
on Windows 7 (but allowing the same .exe to run on Windows 10).
Instead you get a missing .dll error like "The program can't start 
because api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your 
computer." And this leads to people struggling with trying to install 
that .dll etc. Windows 7 (see for example here 
https://forum.qt.io/topic/85047/can-t-launch-application-dll-is-missing )


But Visual Studio uses the same switch set to /SUBSYSTEM:WINDOWS,6.0 to 
disallow MSVC2015/MSVC2017 Win32 apps to run on Windows XP and Win2K3, 
go figure.



Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] To improve UX of the online installer

[Henry Skoglund]

Hi, excellent initiative, a better MaintenanceTool UX would also improve 
the general opinion of Qt I think.


Just one to add 2 things to Sze Howe's list:

8c. For the users that, in search of a 32-bit MSVC2017-flavored Qt 
version, downloads the UWP x86 (MSVC 2017) version of Qt, and then tries 
to run it on Windows 7: please explain that the UWP stuff only runs on 
Windows 10.


11. Please make 'Update components' the default selection once you've 
logged in, or 'Add or remove components'. Anything but 'Remove all 
components' !!!


Rgrds Henry


On 2018-04-03 02:14, Sze Howe Koh wrote:

3 broad issues impede new users who want to start using Qt and
frustrate old users who want to update Qt:

 (A) Downloading metadata is very time-consuming.
 (B) The automatic mirror selection algorithm doesn't always pick
the best mirror.
 (C) (New users) It's not clear how to choose what to install.


==
Factors that contribute to (A) include:

* The metadata downloader opens lots of short-duration TCP
connections. Wireshark revealed 2391 HTTP GET requests from
77.86.229.90 (download.qt.io) on Windows. This process is less painful
on Linux (1205 GETs -- almost half of Windows') as there are fewer
compilers/platforms.


* Downloading many small files is very inefficient compared to
downloading a few large files. While GET-ting metadata from
download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten
kibibytes). After this, the actual binaries download from my
designated mirror at ~1 MiB/s, which shows that metadata downloader
doesn't make good use of available bandwidth. I'm in Australia.


* MaintenanceTool downloads metadata too frequently (QTIFW-975).


* If the metadata download fails halfway (e.g. one file times out),
the whole process needs to start from scratch. There is no
retry/resume. This makes the online installer nigh unusable if the
user's connection to download.qt.io is flaky:
https://forum.qt.io/post/450076


* Currently, there is a way to manually avoid downloading unwanted
metadata: Deselecting the unwanted Temporary Repositories. However,
all 91 Repositories must be unchecked one-by-one, and this process
must be repeated each time MaintenanceTool is restarted:
https://forum.qt.io/post/450076


==
Evidence for (B) include:

* Geographical proximity does not imply mirror quality. E.g. a user
from China finds Chinese mirrors too slow, and opts for non-Chinese
mirrors instead:
http://lists.qt-project.org/pipermail/interest/2013-December/010336.html


* The algorithm doesn't pick the closest mirror anyway. E.g. a user
from Israel was given a Japanese mirror instead of a European mirror:
https://forum.qt.io/topic/87221/


==
Examples of (C) include:

* Some users don't realize there are multiple kits per Qt version.
They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB):
https://forum.qt.io/topic/87608/windows-install-download-size


* Some users don't realize Qt Creator != Qt. They install Qt Creator
without Qt and end up unable to build anything:
https://forum.qt.io/topic/84198/no-valid-kits-found


* Some users don't realize they need to install a compiler separately.
They also end up unable to build anything:
https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements


==
Ideas for improvement (some render others unnecessary):

1. Amalgamate and compress all metadata into one file (or at least one
file per "group").

2. Cache metadata locally and use a hash to identify them; avoid
re-downloading metadata that's already available (Mitch Curtis
suggested this at QTIFW-975)

3. Avoid downloading metadata for archived/advanced packages by
default (Iikka Eklund said this is planned in QTIFW-975)

4a. Remember the which Repositories the user has deselected before,
and ignore them for future sessions.

4b. Let the user choose broad "groups" that they are interested in,
and remember this choice. For example, there is no point getting
metadata for Android/UWP packages or showing these packages in the
"Selection Tree" if I'm only interested in Desktop development.

5. Add a "Select/Deselect All" button to the Repositories page.

6. Allow retry/resume if the metadata download fails halfway.

7. Allow users to manually pick a mirror for binary download.

8a. Before the user is asked to "Select the components to install",
show a short page that to explain the difference between Qt and Qt
Creator and explain that a compiler must be installed separately
unless MinGW is used.

8b. Before the user is asked to "Select the components to install",
have a small wizard to ask a new user some questions -- Which
version(s): Latest version, LTS version, or older version? Which
target platforms? Which compiler? Or do they not care/know and want us
to suggest a good default? Use the answers to pre-fill the "Selection
Tree" and remind the

Re: [Development] Using #pragma once

[Henry Skoglund]

On 2018-10-07 20:39, Thiago Macieira wrote:

On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote:

Hi,

Just a quick question: Does anybody have any good arguments against us
starting to use #pragma once instead of header guards throughout our code
base?


Yes, two:

a) not supported everywhere
b) not well-defined behaviour when it comes to anything but the simplest
organisation

For example, I have ~/src as a bind-mount to ~/dev/src. That means
~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h
~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h
are actually the same file, but they aren't for the effects of #pragma once
because the paths differ.

Another problem is qcompilerdetection.h, qprocessordetection.h,
qsystemdetection.h, qtypeinfo.h, etc. which depend on the header guards to
break the include cycle. Ditto for qlist.h + qstringlist.h and
qbytearraylist.h


...
...


I recommend against changing Qt.



Hi, but isn't C++17's __has_include preprocessor cmd an implicit 
endorsement of #pragma once? I mean, they both assume that the file 
namespace is stable and idempotent.


The example with ~/src as a bind-mount to ~/dev/src above, reminds me of 
the old pointer aliasing problems in C++. But cannot it be solved by 
requiring #pragma once to always call realpath() first, i.e. always test 
on "the canonicalized absolute pathname" that realpath() returns?


Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Using #pragma once

[Henry Skoglund]

On 2018-10-08 07:13, Thiago Macieira wrote:

On Sunday, 7 October 2018 15:17:30 PDT Henry Skoglund wrote:

I recommend against changing Qt.


Hi, but isn't C++17's __has_include preprocessor cmd an implicit
endorsement of #pragma once? I mean, they both assume that the file
namespace is stable and idempotent.


No, I don't see how one thing has to do with the other.

__has_include imples that the #include will not fail with "No such file or
directory" and hopefully won't fail either with "Is a directory". Other checks
are welcome, but I wouldn't be too picky if they didn't get done.

#pragma once only applies after the #include and changes nothing about whether
the #include succeeds or not.


The example with ~/src as a bind-mount to ~/dev/src above, reminds me of
the old pointer aliasing problems in C++. But cannot it be solved by
requiring #pragma once to always call realpath() first, i.e. always test
on "the canonicalized absolute pathname" that realpath() returns?


No.

$ realpath ~/dev/src/qt/ ~/src/qt
/home/tjmaciei/dev/src/qt
/home/tjmaciei/src/qt

Bind-mounts are not symlinks. For all intents and purposes they are different
filesystems: you can't link() from one to the other, for example. You may be
able to tell that they are the same because the dev_t is the same:

$ stat -c '%D %i %n' ~/dev/src ~/src
fe03 4456449 /home/tjmaciei/dev/src
fe03 4456449 /home/tjmaciei/src

But to tell that the file is the same you'd need to compare inodes and those
are not guaranteed on network mounts.

Another option is to use name_to_handle_at(), a Linux-specific function, but
that will also fail with bind mounts and multiple mounts of the same
filesystem. The manpage suggests resolving mount IDs to actual disks by
looking for them in /dev/disks/by-uuid.

So you see why this is not a very easy solution.



Yes, I see.

When #pragma once was introduced 20 years ago by Microsoft I thought it 
was the greatest thing since sliced bread, but maybe it's time to 
reconsider.


So, what about a new preprocessor command:

__has_same_md6_digest

It would require the compiler to store an md6 hash/checksum of the 
contents of each of the #include files seen during compilation, but if 
most of the compiler's time is spent waiting for file i/o, then 
computing those md6 sums wouldn't be so costly.


It would work the same way as the traditional header guards, but more 
automated, example:


#if !__has_same_md6_digest
...
...
...
#endif

Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Using #pragma once

[Henry Skoglund]

On 2018-10-08 18:12, Matthew Woehlke wrote:

On 08/10/2018 02.23, Henry Skoglund wrote:

So, what about a new preprocessor command:

__has_same_md6_digest


See also http://wg21.link/p0538 and note that EWG rejected it. The
general consensus, AFAICT, is that modules is expected to make all this
stuff irrelevant, and therefore EWG does not want to invest in fiddling
with the preprocessor for a problem that is becoming irrelevant.



Aha, didn't know about your proposal, looks good.

I forgot about modules, and even if they don't make it into C++20, I 
agree that most likely they are the future/best way to solve this problem.


Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

[Henry Skoglund]

Hi, I think treating Qt 5.3.1 as a patch level upgrade to 5.3 is a good 
idea, but currently in execution it’s a bit lacking, i.e. when I do 
fresh installs of 5.3.1:

Windows 1st line from qtdiag: “Win: Qt 5.3.1 (Jun 19 2014, MSVC 2013, 32 
bit, release build) on “windows” little endian/“
Windows Qt Creator 3.1.2 Auto-Detected Kit: “Desktop Qt 5.3 MSVC2013 32bit”

Mac 1st line from qtdiag: “Mac: Qt 5.3.1 (Jun 19 2014, Clang 5.0 
(clang-500.2.79) (Apple), 64 bit, release build) on “cocoa” little endian/
Mac Qt Creator 3.1.2 Auto-Detected Kit: “Desktop Qt 5.3.0 clang 64bit”

Also, using Windows 5.3.1 online installer, default directory for 
Qt5Core.dll is “C:\Qt\5.3\msvc2013\bin”, offline installer defaults to 
“C:\Qt\Qt5.3.1\5.3\msvc2013\bin”.

It’s easy to get schizophrenia. Personally I trust qtdiag the most. But 
having different part of Qt’s infrastructure disagree on such an 
*important* number as the current version of Qt, is going down a 
treacherous road.

So far Qt has been using the “dog-eat-dog” distribution algorithm, i.e. 
a new release wipes the existing one. Compare for example with the 
“mindmeld” in-place upgrade of Net 4.5.x on an existing Net 4.0 
installation. This has been a source of much confusion. But with the 
generous release cycle of Qt, I agree that the # of packages in the 
repository can be overwhelming.

So a suggestion: Qt patch level releases = good, but I think we need to 
think of them not as a completely new “dog” or installation, but as an 
*upgrade* to the existing installation (like if you buy a new collar for 
your dog). Something you download which cannot by itself install Qt, 
instead requiring an existing Qt installation which it can patch.

And these upgrades, to keep them mentally and logistically different, 
shouldn’t be called 5.3.1 or 5.4.1 etc. We need some other name, one way 
is to mimic what Microsoft does with Visual Studio, like with VS2012, 
when I install it from scratch, it says “.. 2012 RTM” in the about box. 
Then if I download and apply Update 4 to it, the about box says “.. 2012 
Update 4”. So releases and updates are two different beasts altogether.

Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Henry Skoglund]

On 2014-08-01 21:01, Adam Strzelecki wrote:
 >...
 > Well, to be frank there is a simple workaround for that :) Why not 
symlink Qt frameworks at build time, then replace symlinks with real 
copies on deployment step?
 >
 > So the easiest solution would be to symlink Qt frameworks when your 
create app bundle otherwise add /full/path/to/qt when you use 
bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
 >
 >...

Please don't add more file I/O to Qt Creator's build effort, at least 
not until Apple switches to BTRFS, since HFS+ can be a real dog 
sometimes (compared to Ext4 or NTFS).

Also, a bit of topic, but re. how to divide work between macdeployqt and 
Qt Creator, and which one should support @rpath; one way to solve this 
would be for Qt Creator to usurp macdeployt, i.e. add a Build for 
Distribution menu choice in Qt Creator.

Rgrds Henry


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] libqsqlodbc.dylib has jumped the shark?

[Henry Skoglund]

Hi,

just installed Qt 5.4 on OSX (with the online installer) noticed that 
libqsqlodbc.dylib isn't included in the plugins/sqldrivers folder 
anymore (it was there in 5.2 and 5.3).

If this removal is by purpose, for example to fix QTBUG-37835, then I 
can fully understand the decision; using ODBC on OSX is painful at best. 
But I couldn't see any mention of libqsqlodbc.dylibs' demise in 5.4's 
release notes?

Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecating modules with 5.5

[Henry Skoglund]

+1 for dropping VS2008. For those with thin wallets it's easier to
upgrade nowadays anyway to the VS2013 Community Edition.

/Rgrds Henry


On 2015-02-05 08:31, Bo Thorsen wrote:
> Den 04-02-2015 kl. 15:56 skrev Olivier Goffart:
>> On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
>>> On 04/02/15 10:20, "Olivier Goffart"  wrote:
 Also, is it not time to decide which platform are we going to stop
 supporting in Qt 5.6?

 For example, if we were to decide to start using some of the C++11, we
 should drop MSVC 2008 which would allow us to already use things like auto
 and decltype.
 We could also drop gcc 4.4 which would let us lambda function.
>>>
>>> In principle I agree. The problem with 2008 is that this is currently the
>>> only compiler supporting Windows Embedded 7, so we can’t easily get rid of
>>> it. Dropping gcc 4.4 is afaik not a big problem.
>> The question then is how relevant will Windows Embedded 7 be in 2016 when Qt
>> 5.6 will be there. And if it is worth to limit ourselves because of it.
>
> Sounds to me like 5.5 will be a release that will be around for a while
> then. This could be the one where those who need webkit, VS 2008 og Qt
> Quick 1 would use. So declaring support for this will continue for a
> while could make it easier to remove those parts.
>
> If this could be the case, it could even be considered to go even
> further and get rid of more stuff. VS 2010 would be one possibility. I'm
> writing this with VS 2010 open for the project I'm currently on, so I
> know it's still in use :) But getting rid of this opens for a lot more
> C++11 features.
>
> What I'm suggesting here is sort of a mini major release. It doesn't
> feel like a 6.0 is necessary yet, but as the 5 line is mayby around half
> through it's life, it might not be a bad idea to make a longer term release.
>
> Bo.
>


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Henry Skoglund]

Hi, just my 2 cents: just coding some database stuff using QVariants, 
and invariably (especially Monday mornings) it takes me a couple of 
milliseconds extra to comprehend what the tooltip for QVariant's toInt() 
means:

 int toInt(bool *ok = 0) const;

instead, if qvariant.h could be written using nullptr or Q_NULLPTR:

 int toInt(bool *ok = Q_NULLPTR) const;

It would increase the quality of Qt for me, at least.

Rgrds Henry



On 2015-02-09 08:36, Bo Thorsen wrote:
> Den 08-02-2015 kl. 22:42 skrev André Pönitz:
>> On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote:
>>> What would be the point of macros if they always expanded? The entire point
>>> and usefulness of these macros is that they expand to standard keywords when
>>> those standard keywords exists.
>>
>> What's the point of using a macro in circumstances where a portable, standard
>> conforming, safe-to-use, shorter-to-type, version _without_ using a macro
>> exists?
>>
>> I.e. in case of a simple pointer initialization, why should one *ever* prefer
>>
>> void something()
>> {
>>   Foo *f = Q_NULLPTR;
>>   ...
>> }
>>
>> over
>>
>> void something()
>> {
>>   Foo *f = 0;
>>   ...
>> }
>>
>> ?
>>
>> For the sake of keeping this part of the discussion simple, I specifically
>> mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
>> context of initializing a local pointer variable. So: Any advantage? Any
>> advantage outweighing the disadvantages?
>
> For this simple example, there is absolutely no benefit. Not even if you
> had replaced Q_NULLPTR with nullptr.
>
> But you forget that it isn't about this simple case. It's about the
> harder cases, which makes you want to compile your code with warnings
> about 0 for pointers. And that's impossible if at least the Qt headers
> are not clean for it.
>
> Whether we should use Q_NULLPTR in the cpp files is more of our own choice.
>
> Bo Thorsen,
> Director, Viking Software.
>


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] date/time adjust for (auto) testing

[Henry Skoglund]

Hi, I also had the same needs for testing my app, on different times of 
the day or year etc. But instead of patching Windows or some Qt code, I 
created a new virtual Windows VM in WMWare, and deployed my app into it.

Switched off "Synchronize guest time with host" in the Options, and 
whenever I test, first a .bat file is run that sets the requested 
date/time in the Windows VM. This can you do in VirtualBox as well.

Note that when you run on a fake date/time, https (certificates) and a 
lot of other internet stuff will fail, but for local app testing it's ok.

Rgrds Henry


On 2015-06-03 08:38, André Somers wrote:
> Hi,
>
> We have applications that use the current date and time at places spread
> around the code. For normal operations, that works very nicely. However,
> we find that for (auto) testing, it would be very convenient if we could
> trick the application into believing it is some other date/time, so that
> we can test if certain behaviours work the way we would like to
> automatically. Currently, these tests take a lot of time because we
> actually need to manually adjust the system date and time, do some
> stuff, then adjust again, etc.
>
> It would be really confortable if there was some control to set a
> date/time offset (so the time keeps running) or a fixed date/time to be
> returned from currentDate(), currentTime() or currentDateTime()
> respectively. I guess access to such a thing does not belong in the main
> Qt classes, but is really a testing tool, so perhaps it could find
> refuge in QtTest somewhere. Would a contribution adding such a thing
> stand any chance of being accepted, or would this be considered out of
> scope or even unwanted?
>
> An alternative might be to hook the windows kernel API, but that may be
> much tricker to get right and may have unforseen consequences for the
> code injected by Squish doing the actual testing.
>
> André
>


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] could not find or load the Qt platform plugin "cocoa"

[Henry Skoglund]

Hi,

just guessing but if your /Volumes/Data is an external hard disk this 
might be due to a permissions problem. If you try testing by 
(temporarily!) move the platforms directory (containing the 
libqcocoa.dylib file) from /Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/ to 
Volumes/Data/p4client/ProAudio/dev_main/ProAudio/Products/Release/Apps/CODEX 
App.app/Contents/MacOS/ you still get the same error?


Rgrds Henry


On 2015-10-28 15:09, Gil Moses wrote:

Hi,

I've built Mac universal binaries of v5.5.1 (built separately for i386 and 
x86_64, then used lipo).
Built and ran my Qt app (Xcode 5, Mavericks), and got this error:

. could not find or load the Qt platform plugin "cocoa".

Further diagnosis using DYLD_PRINT_LIBRARIES and QT_DEBUG_PLUGINS prints this 
when running the app:

==

QFactoryLoader::QFactoryLoader() checking directory path "/Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at "/Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib"
Found metadata in lib /Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib, metadata=
{
 "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
 "MetaData": {
 "Keys": [
 "cocoa"
 ]
 },
 "className": "QCocoaIntegrationPlugin",
 "debug": false,
 "version": 328961
}


Got keys from plugin meta data ("cocoa")
QFactoryLoader::QFactoryLoader() checking directory path 
"/Volumes/Data/p4client/ProAudio/dev_main/ProAudio/Products/Release/Apps/CODEX 
App.app/Contents/MacOS/platforms" ...
dyld: loaded: /Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib
dyld: unloaded: /Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib
loaded library "/Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib"
QLibraryPrivate::loadPlugin failed on "/Library/Application 
Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib" : "Cannot load library 
/Library/Application Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib: 
(dlopen(/Library/Application Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib, 5): 
Library not loaded: @rpath/QtGui.framework/Versions/5/QtGui\n  Referenced from: 
/Library/Application Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib\n  Reason: 
image not found)"
This application failed to start because it could not find or load the Qt platform plugin 
"cocoa".

Available platform plugins are: cocoa.

Reinstalling the application may fix this problem.
Abort trap: 6



I verified that the Qt frameworks (especially the QtGui mentioned in the error) and 
libqcocoa.dylib are universal i386 & x86_64.

Any ideas?

Thanks,
Gil Moses
Waves Ltd.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Modify QLibraryInfo to support any default location of qt.conf

[Henry Skoglund]

Hi,

this is the same problem that the Qt installation program has, it solves 
it by binary patching your copy of Qt5Core.dll when it installs Qt onto 
your computer (e.g. set qt_prfxpath="C:\Qt\5.5\msvc2013").


Maybe you can to the same?

Or perhaps a more viable long-range solution is to introduce a r/w API 
to Qt's resource system, so that instead of patching Qt5Core.dll it 
would be possible to patch the contents of the embedded 
":/qt/etc/qt.conf" resource file inside your .exe file. (That would 
imply it isn't zipped when compiled and also that ample patch space is 
provided, as it is done in Qt5Core.dll for the qt_prfxpath property.)


Rgrds Henry


On 2016-01-28 10:47, Maximilian Hrabowski wrote:

Hi,

our application has an auto-update feature that allows to download and
install a new version of the application. The update package includes
everything, also Qt. The only permanent files are a launcher executable
and a config file that points to the real application folder. The folder
which contains the launcher is usually not writable by the user so the
this application folder can be located anywhere on the system. The
primary target platform is windows.

Our application uses qt plugins, qt webengine etc. so we need to rely on
a proper qt.conf file so any plugins and especially the
QWebEngineProcess.exe is found.

Since on Windows qt.conf is looked up in
1. :/qt/etc/qt.conf
2. applicationDirPath()+/qt.conf
it is not found since the applicationDirPath() points to the folder of
the launcher.

What we need is a way to look up the qt.conf at another location as
well. Of course i could patch Qt myself to do what i like but i target a
solution that would qualify to become part of qt and i would be willing
to contribute this feature.

However, before do this i would like to discuss how this could be
achieved and if there is any chance this feature could be accepted in qt.

I thought about the following ways (order gives my personal opinion’s
priority):

1. Add a new public API: static void QLibraryInfo::setQtConfFilePath(
const QString& filePath) which defaults to ":/qt/etc/qt.conf“ and is
used in QSettings*QLibraryInfoPrivate::findConfiguration() instead of
the hard-coded path.
2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is
how we got the plugins found)
3. introduce an environment variable that points to the qt.conf similar
to the one of QWebEngineProcess.exe

Please comment.

Cheers,
Maximilian

--
Maximilian Hrabowski mailto:hrabow...@clausmark.com>>
Clausmark GmbH
Tel: +49 (721) 98963941
Clausmark - The creators of BeeCore and Bee4IT



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.7.0 rc packages for testing

[Henry Skoglund]

Hi, just tested 5.7 RC on Ubuntu, looks good. (Also I see Qt Creator 
4.01's project view has nicer icons.) But I spotted one problem, problem 
for me at least:


When building a vanilla HelloQt widgets test app, I notice that the 
chrpath of the app just points to Qt's installation path, e.g.:


chrpath TestApp
TestApp: RPATH=/home/henry/Qt/5.7/gcc_64/lib

(in Qt 5.5 it was:
TestApp: RPATH=/home/henry/Qt/5.5/gcc_64:/home/henry/Qt/5.5/gcc_64/lib
removing the first RPATH entry in 5.7 makes sense, it is almost never used.)

but in Qt 5.6 it was:
TestApp: RPATH=$ORIGIN:/home/henry/Qt/5.6/gcc_64/lib
and that was *really* nice because then, on a deployment PC without Qt 
installed, you could place the .so files the app needs like 
libQt5Core.so.5 together with the .elf file in the same directory (i.e. 
the same type of deployment that are used on Windows).


But in this 5.7RC it's back to pre-5.6 behavior. To get it to work 
anyway, I usually add to the .pro file (for deployment):


QMAKE_LFLAGS += -Wl,-rpath,"'\$$ORIGIN'"

But this is not so well documented for average developer I think.
So if this lossage of $ORIGIN in RPATH remains in 5.7, I will miss 5.6 :-(


P.S. Also the platform plugin DLL libqxcb.so has reverted to 5.5 
behavior regarding it's RPATH settings, i.e. in Qt 5.5 and 5.7 RC it's


libqxcb.so: RUNPATH=$ORIGIN/../../lib

In Qt 5.6 it was:
libqxcb.so: RUNPATH=$ORIGIN:$ORIGIN/../../lib

Before Qt 5.5 the RPATH settings of the plugin .so files were 
immaterial, but starting with 5.5 they matter for loading the .so files 
needed by libqxcb.so, like libQt5XcbQpa.so.5 and libQt5DBus.so.5.


On a development PC with Qt installed 5.5, 5.6 and 5.7 all work fine 
because the .so files are placed correctly, i.e. $ORIGIN/../../lib 
points correctly.


But on a deployment PC without Qt installed this is a pain point for 5.5 
and 5.7 RC because usually (for a naive developer like me) you place all 
the .so files needed next to the .elf file. And to fix good plugin 
loading in 5.6, you just placed a copy of libQt5XcbQpa.so.5 and 
libQt5DBus.so.5 together with libqxcb.so in the platforms subdirectory 
and all was fine and dandy for deployment.


Of course you emulate the installed Qt's directory structure and create 
a subdirectory called 'lib' one position above where the .elf file is so 
that $ORIGIN/../../lib works, but why can't we continue to get a 
libqxcb.so in 5.7 that has a $ORIGIN as well in its RPATH setting?


Rrgrds Henry


On 2016-06-01 12:02, Jani Heikkinen wrote:

Hi all,


We have finally Qt 5.7.0 rc packages for testing:


Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/482/

Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/442/

Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/376/

src: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/latest_src/


Packages are RTA tested & seems to be pretty much Ok. Known issues in
the packages here: https://bugreports.qt.io/issues/?filter=17719


We will release these packages as Qt 5.7.0 rc this Friday if nothing
really serious found during testing. So please inform me immediately if
there is something badly broken.


And at this time we are really minimizing changes between rc & final and
so on we are taking in only fixes for real release blockers. All others
should be just listed in known issues page
(https://wiki.qt.io/Qt_5.7.0_Known_Issues) & fixed in '5.7' branch
instead. Documentation changes and missing change files are exception:
We will take those in still during this week so please finalize those as
well really soon, latest this Sunday. We will start creating final
packages Monday 6th June morning.


br,

Jani


Jani Heikkinen
ReleaseManager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikki...@qt.io
+358 50 4873735
http://qt.io 



  







___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.7.0 rc packages for testing

[Henry Skoglund]

On 2016-06-06 15:27, Ronan Jouchet wrote:

On 2016-06-03 18:40, Henry Skoglund wrote:

Hi, just tested 5.7 RC on Ubuntu, looks good.
(Also I see Qt Creator 4.01's project view has nicer icons.)


Hi Henry.

What do you mean? Could you be also affected by
https://bugreports.qt.io/browse/QTBUG-53844 ?

Good day.



Yes, indeed I also see the blue icons with Qt 5.7 RC on my Ubuntu 14.04 
(Unity). And I thought they looked nicer, didn't realize it is a bug :-)



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programs crashing left and right in the CI

[Henry Skoglund]

Hi, most likely I've had too much coffee, but has anyone checked if 
these intermittent crashes are due to outside DDOS/some trying to 
introduce a race condition and injecting new code into Qt's codebase?


Rgrds Henry


On 2016-07-26 23:24, Giuseppe D'Angelo wrote:

On Mon, Jul 25, 2016 at 5:51 PM, Thiago Macieira
 wrote:


Let's pay attention of what crashes and where. But we'll need to reproduce
this in order to debug it.


It just happened again:

http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959db98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Henry Skoglund]

On 2016-09-21 17:02, Thiago Macieira wrote:

On quarta-feira, 21 de setembro de 2016 11:06:59 PDT Konrad Rosenbaum wrote:

RPath may be a bit tricky: normally Qt compiles it's lib path into RPath,
but with a deploy script you do not want that RPath anymore, instead you'd
want to change it to $ORIGIN (literally, not the value of a variable).


Don't change. If you want $ORIGIN, you tell the linker you want it.

Also, RPATH is tricky, but for another reason:

- If DT_RUNPATH is present, check $LD_LIBRARY_PATH first and ignore DT_RPATH
- if only DT_RPATH is present, check it before $LD_LIBRARY_PATH



About paths, if we want linuxdeployqt to harmonize with windeployqt's 
behavior: since last year windeployqt unpatches (i.e. neuters) Qt's 
installation path in Qt5Core.dll, so that for example my Qt5Core.dll is 
patched from "qt_prfxpath=C:\Qt\5.7\msvc2013\" to "qt_prfxpath=.". This 
severes any pathological connections my app would have with my Qt 
installation (and shuts a small but possible backdoor).


(And, when I copy my app to a vanilla PC, I can either place the 
platforms subdirectory next to my .exe file, or I want to get fancy, 
copy the whole plugins tree and place it next my .exe file. Either works 
fine for loading qwindows.dll.)


So perhaps linuxdeployt could do the same, i.e. neuter the path to my Qt 
installation (e.g. change "prfxpath=/home/henry/Qt/5.7/gcc_64" to 
"prfxpath=." in libQt5Core.so.5.7.0?



In theory you could apply the same reasoning to RPATH, why let Qt's 
installation path remain artifacted in the .elf file? Perhaps $ORIGIN is 
a nicer default. (windeployqt does not do this step, as on Windows 
$ORIGIN is the "standard" anyway).


Rgrds Henry


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6

[Henry Skoglund]

On 2021-04-07 16:11, Volker Hilsheimer wrote:

On 7 Apr 2021, at 15:55, Allan Sandfeld Jensen  wrote:

On Mittwoch, 7. April 2021 15:18:10 CEST Giuseppe D'Angelo via Development
wrote:

Il 07/04/21 14:56, Sze Howe Koh ha scritto:

Is it acceptable to remove them during Qt 6's lifetime? Or should we
wait till Qt 7?

It's for Qt 7, I'm afraid. We're bound to an API/ABI compatibility
promise. And not marking things _in code_ but only in docs isn't good
enough.


We remove and change private API all the time. If it was declared
deprecated long ago, we could argue it is kind of private in qt6.

'Allan

But declaring an API deprecated requires two things:

* documentation marking it as obsolete
* QT_DEPRECATED_SINCE macro usage to trigger compile time warnings

QMessageBox::buttonText for instance doesn’t have said macro, and is not 
inline, so we can’t remove it without de-facto breaking BiC in a material way 
(since at least on Windows, the DLL found at runtime has to provide all symbols 
that the static import library had at link time, no matter if used or not).


So, what would be not only acceptable but desirable is a bunch of changes that 
add QT_DEPRECATED_SINCE to those methods that so far have only been documented 
as obsolete. And perhaps even a bit of qdoc tinkering to help us maintain 
consistency.

Volker

Hi, not to be a nitpick, but doing that stunt is possible on Windows, 
i.e. you can remove obsolete stuff from .dlls without rebuilding any 
app, if that obsolete stuff never is called.
You can see what symbols/functions your .exe or .dll needs by doing a 
*dumpbin/imports* on it, and normally (unless you're crazy and call 
*all* functions in a library) the list of imports will be a subset of 
what the static import library provides/offers at link time.

Rgrds Henry

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QString, QVariant and QSQLite

[Henry Skoglund]

On 2021-05-26 21:39, Alberto Mardegan wrote:

Hi there!
   I'm encountering some sort of memory corruption issue in a library I'm
using, which does not cause a crash, but rather a QSQLite query to
sometimes simply return no results, without errors or warnings.

You can find the valgrind trace here:
https://git.sailfishos.org/mer-core/qtcontacts-sqlite/issues/7#note_90394

What is happening is that we bind a couple of SQLite parameters to a
prepared query. The first bound parameter is a QString.

1) The string is stored into a QVariant
2) QSqlQuery::bindValue() is called
3) in the sqlite plugin, the qvariant is copied into a const QVariant:
https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp?h=5.12#n503
4) in line 539 of the SQLite plugin, the contents of the QVariant are
obtained just by calling QString::utf16() on the string data, without
extracting it from the QVariant.
5) the data is passed to sqlite with SQLITE_STATIC (sqlite will NOT copy it)
6) we move forward and iterate to the next bound parameter
7) our const QVariant goes out of scope (though valgrind shows that the
destructor is actually called on the next iteration of the for loop --
but I guess this is not fundamental)
8) the destructor of the const QVariant calls the destructor of the
QString stored in it, which frees the memory allocated in point 4 by
QString::utf16()

Now, I haven't dug very deep in QString and QVariant, I preferred to let
the experts talk first :-) Does the code in the QSQLite plugin look
correct to you?
Is it expected that QString::utf16() makes a memory allocation? And is
it correct that this happens even when the QString is const?
And why destroying a const QVariant causes the deallocation of the data
created by QString::utf16()??

The most plausible explanation is that I have some memory corruption
somewhere else in the program, but I find it curious that it never
crashes the program and that it manifests itself always in this code
path. Notice also that if I call QString::detach() on my parameter
before storing it into the QVariant I pass to QSqlQuery::bindValue(),
then valgrind never complains and QSQLite returns the expected results.

Or do you think it could be a bug in the QSQLite plugin?

Ciao,
   Alberto

Hi, as a first quick test, if instead of using the binding mechanism, 
you use sprintf() or QString(..%1 .. %2).arg() etc. to construct your 
query string. Does your memory corruptions still occur?
(Note: this is not recommened since it allows SQL injection or similar 
bad things, but you could try it as a test.)


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 not seeing the same DPI as Qt 5

[Henry Skoglund]

On 2021-11-29 17:41, Thiago Macieira wrote:

I'll probably have to report this as a bug, but just in case someone has seen
it before:

$ diff -u qtdiag5 qtdiag6
[...]
Geometry: 1920x1200+0+0 (native: 3840x2400+0+0) Available: 1920x1200+0+0
Virtual geometry: 5760x1200+0+0 Available: 5760x1200+0+0
2 virtual siblings
-  Physical size: 288x180 mm  Refresh: 59.9939 Hz Power state: 0
-  Physical DPI: 169.333,169.333 Logical DPI: 120.118,120 (native:
240.236,240) Subpixel_None
+  Physical size: 406x228.6 mm  Refresh: 29.9806 Hz Power state: 0
+  Physical DPI: 120.118,120 Logical DPI: 96,96 Subpixel_None
High DPI scaling factor: 2 DevicePixelRatio: 2

Qt 5 agrees with xrandr:
$ xrandr | grep eDP-1
eDP-1 connected primary 3840x2400+0+0 (normal left inverted right x axis y
axis) 288mm x 180mm

I start X with the "-dpi 240" setting, which gives me the best font size to
work on either display. Qt 5 obeys it just fine, dividing it by 2 because of
the scale factor, so my desktop looks fine. However, the one Qt 6 application
I use (Qt Creator) does not and has tiny fonts. I can override it with
QT_FONT_DPI=240 in the environment, but shouldn't have to.

That logical DPI of 96 makes zero sense. It's not physically correct and is
not part of the X config. Where is it coming from?

What's changed between 5 and 6?



Slightly offtopic but did you build your own Qt Creator using Qt 6?
(The downloadable vanilla 5.0.3 is based on Qt 5.15.2).

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Windows plugin customisation: QWindowsKeyMapper

[Henry Skoglund]

On 2022-08-02 00:07, Laszlo Papp wrote:

#include 
#include 

#include 

class MyMSGEventFilter : public QAbstractNativeEventFilter
{
public:
    bool nativeEventFilter(const QByteArray &eventType, 
[[maybe_unused]] void *message, long *) override

    {

        std::cout << eventType.toStdString() << std::endl;
#ifdef Q_OS_WIN
        if (eventType == "windows_generic_MSG") {
            MSG *msg = static_cast(message);
        } else if (eventType == "windows_dispatcher_MSG") {
            MSG *msg = static_cast(message);
        }
#endif
        return false;
    }
};

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    MyMSGEventFilter filterObject;
    app.installNativeEventFilter(&filterObject);
    return app.exec();
}



Hi, it works fine on Windows, but without a (hidden) window on the 
desktop you're doomed to receiving *very few* message. I.e. no HWND 
(that's why for example the DDE server creates a hidden window on the 
desktop). So easiest workaround is to add say a QWidget window:

...
    QApplication app(argc, argv);
    MyMSGEventFilter filterObject;
    app.installNativeEventFilter(&filterObject);
    MainWindow w;
    w.show(); // you can hide it now
    return app.exec();
...
BTW, I couldn't get it to compile on MSVC 2019 Qt 6.3.1 
("MyMsgEventFilter: cannot instantiate abstract class") but on MSVC 2019 
5.15.2 it works fine.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using '#pragma once' instead of include guards?

[Henry Skoglund]

On 2022-10-10 21:27, Thiago Macieira wrote:

...
This situation is annoying either way. With include guards, you will get a
working build, but you may spend some time trying to figure out why the changes
you're making to the headers aren't taking effect. With the pragma, you get
hard build errors due to redefined types, probably with both paths so you'd
notice easily that there are two copies.

The problem I have with switching to #pragma once is for whom the problem
happens and who gets to fix it. Most people who build Qt from source are not
developing or modifying it; they're simply building for use in their own
content. So if the problem of incorrect include paths happens with
preprocessor guards, most likely they will not see any ill effect because both
copies of headers are the same. But if those headers use #pragma once, those
people will get build errors despite the file contents being identical, because
they are different files.


Hi, this kind of reminds me of detecting violations of ODR but instead 
of objects it's about .h files. And #pragma once can then be seen as the 
weaker sibling of the include guard mechanism, i.e. not as efficient as 
detecting multiple instances of the same .h file.
But perhaps there could be use of #pragma once anyway, as a way to 
detect those duplicate files? Say something like this at the top of an 
.h file:


#pragma once
#if defined QGLOBAL_H
#error "Multiple instances of qglobal.h detected"
#endif
#define QGLOBAL_H
...

Rgrds Henry

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using '#pragma once' instead of include guards?

[Henry Skoglund]

On 2022-10-11 22:04, Thiago Macieira wrote:

...

// This macro can be used to calculate member offsets for types with a non
standard layout. // It uses the fact that offsetof() is allowed to support
those types since C++17 as an optional // feature. All our compilers do
support this, but some issue a warning, so we wrap the offsetof() // call
in a macro that disables the compiler warning.

And we had a lengthy discussion on whether it was acceptable to use offsetof
and such like in our public headers. It was touch and go for a while.

But as the comment you quoted says, offsetof() on non-stdlayout types is
recognised by the standard explicitly. It's not required, but the standard
says it's permitted.

The pragma, on the other hand...


Same example. The comment on Q_OFFSETOF hints that C++17 seems to allow for
optional implementations to go beyond what the standard specifies. Why is
not standardized then? I think the same could be said about this pragma.
What it does is conceptually very simple, and if it only can hurt on very
corner cases, then it's a matter of weighting the tradeoffs.

... can't be standardised because the standard can't come up with a meaningful
description of what a file is. It's unable to add text that explains the
behaviour compilers should have, because it doesn't even have the concept of
files and filesystem where the compiler is running.


Sometime in the far future when Qt requires c++20 things might improve:
we could use std::source_location::filename
(https://en.cppreference.com/w/cpp/utility/source_location/file_name )

||___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Copying a struct the easy (perhaps too easy) way

[Henry Skoglund]

Hi, just got the need to copy a struct so I started doing it the hard 
way (i.e. member by member) but on a lark I tried a simple copy from 
*this, say like this:


struct S
{
    int i;
    QString s;
    QDate d;
    QStringList sl;

    S clone() { return *this; }
};

S a;
S b = a.clone();

it seems to work like a charm (6.5.2 on Linux and the Mac. 5.15.2 on 
Windows) but my question is if it's kosher?
I have bad memories from my MFC days in the previous century doing this 
simple cloning but maybe it's considered good code now...

Rgrds Henry

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Copying a struct the easy (perhaps too easy) way

[Henry Skoglund]

On 2023-09-16 01:55, Giuseppe D'Angelo via Development wrote:

Wrong mailing list?

Il 16/09/23 01:41, Henry Skoglund ha scritto:

S a;
S b = a.clone();

it seems to work like a charm (6.5.2 on Linux and the Mac. 5.15.2 on
Windows) but my question is if it's kosher?


You class has value semantics, so:

S b = a;



I have bad memories from my MFC days in the previous century doing this
simple cloning but maybe it's considered good code now...


Many types in MFC has value semantics as well (CString, COleDateTime, 
etc.).




Thanks Guiseppe and sorry if this was a kind of noob question 😄

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development