Re: [Interest] Qt 6.8.0 Win: no longer links to MFC ?

[Henry Skoglund]

On 2024-07-02 04:55, David M. Cotter wrote:

On Windows, using Qt 6.7.1 (with VS2019), in my project I was able to do this

#include  // MFC core and standard components

and that header would be "found" by the compiler, and the linker would link to 
mfc140u(d).lib just fine.
BUT: When i upgraded to Qt 6.8.0, (meaning i had to upgrade to VS2022), now the compiler 
is no longer able to "find" afxwin.h, nor link to MFC.  ??!?

Okay, so, if i now add these lines to my .pro file:


versionAtLeast(QT_VERSION, 6.8.0) {
DIR_ALTMFC = C:\Program Files\Microsoft Visual 
Studio\2022\Community\VC\Tools\MSVC\14.29.30133\atlmfc\

INCLUDEPATH += $${ALTMFC_PATH}include
LIBS += -L$${ALTMFC_PATH}lib\x64 -lmfc140ud
}

It will now compile (ie: it FINDS the header file) but it still won't link, 
says:

LINK1104: cannot open file 'mfc140ud.lib'


If you compile in Release mode (instead of Debug) and remove the 
appended u, like this:
LIBS += -L$${ALTMFC_PATH}lib\x64 -lmfc140u you still get the same 
LINK1104 error?___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Update widget geometry BEFORE window shown

[Henry Skoglund]

On 2024-05-24 21:14, David M. Cotter wrote:
I’ve tried everything I can think of. The ONLY one that works the way 
I NEED is the first one, but that one flashes the window on the screen


#if 1
qWidgetP->show();
qWidgetP->hide();
QtLetTimersFire(0);
#endif

Hi, have you tried the old Windows trick of moving the widget to 
Cleveland, i.e. way off into negative territory like Minimize does? 
https://devblogs.microsoft.com/oldnewthing/20041028-00/?p=37453

Say you have this code:

   auto qWidgetP = new QWidget();
   qWidgetP->setGeometry({100,100,1000,1000});
   qWidgetP->show();
   QTimer::singleShot(1000,[qWidgetP]{ qWidgetP->hide(); });

FLashes for sure. But if you position it like this:
   qWidgetP->setGeometry({-32000,-32000,1000,1000});
do all the setup and then later move it back into the normal coords.
The flash will still occur but noone will here you scream/flash.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] displaying Qt-coded JPEG image in browser

[Henry Skoglund]

On 2024-01-26 13:55, Alexander Carôt via Interest wrote:

Hi all,

I have a raw image:

QImage *img = new QImage(imgBufferOut,
  reso.width(),
  reso.height(),
  QImage::Format_RGB888);


that I convert to JPG via


QBuffer bufferJpeg;
bufferJpeg.open(QIODevice::WriteOnly);
img->save(, "JPEG");
finalJpg = bufferJpeg.data();


Now I transfer the content finalJpg in form of a Base64 encoded QString via a 
websocket to a web browser. Within the browser it should be displayed via


const imageDataUri ="data:image/jpeg;base64,"  + msg.jpgBuffer;
videoImage.src = imageDataUri;


Now my question is how should I create the required sting ? I tried:


QString jpgBufferString( finalJpg.data() );
QString encodedString = jpgBufferString.toUtf8().toBase64();


but this does not decode the image and simply shows the broken image icon in 
the browser.

Can anyone help with this ?

Thanks in advance,
best

Alex



Hi, maybe passing JPG through fromUtf8() and toUtf8() munges it too 
much, what happens if you simplify, instead of:


QString jpgBufferString( finalJpg.data() );
QString encodedString = jpgBufferString.toUtf8().toBase64();

try:
QString encodedString = finalJpg.data().toBase64();

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

Re: [Interest] Qt online installer error (Mac)

[Henry Skoglund]

On 2023-12-14 14:13, Calogero Mauceri wrote:

Hi all,

I'm trying to install latest Qt 6 release for Mac through qt online 
installer but I get the following error message


Cannot download archive 
http://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z: 
Socket operation timed out



Any clues on how to fix this?

Thanks,

Calogero


--
Calogero Mauceri
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com 



Hi, maybe a bad/down mirror, mine works, using wget to find the url:

wget 
http://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z
--2023-12-14 14:17:17-- 
http://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z

Resolving download.qt.io (download.qt.io)... 77.86.162.2
Connecting to download.qt.io (download.qt.io)|77.86.162.2|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: 
https://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z 
[following]
--2023-12-14 14:17:18-- 
https://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z

Connecting to download.qt.io (download.qt.io)|77.86.162.2|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: 
https://ftp.acc.umu.se/mirror/qt.io/qtproject/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z 
[following]
--2023-12-14 14:17:18-- 
https://ftp.acc.umu.se/mirror/qt.io/qtproject/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z
Resolving ftp.acc.umu.se (ftp.acc.umu.se)... 194.71.11.165, 
194.71.11.173, 194.71.11.163
Connecting to ftp.acc.umu.se (ftp.acc.umu.se)|194.71.11.165|:443... 
connected.

HTTP request sent, awaiting response... 302 Found
Location: 
https://chuangtzu.ftp.acc.umu.se/mirror/qt.io/qtproject/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z 
[following]
--2023-12-14 14:17:18-- 
https://chuangtzu.ftp.acc.umu.se/mirror/qt.io/qtproject/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z
Resolving chuangtzu.ftp.acc.umu.se (chuangtzu.ftp.acc.umu.se)... 
194.71.11.167
Connecting to chuangtzu.ftp.acc.umu.se 
(chuangtzu.ftp.acc.umu.se)|194.71.11.167|:443... connected.

HTTP request sent, awaiting response... 200 OK
Length: 11001956 (10M) [application/x-7z-compressed]
Saving to: 
‘4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z.1’


4.6.1-0-202308231236tqtc-installer-f 
100%[>] 
10,49M  41,8MB/s    in 0,3s


2023-12-14 14:17:18 (41,8 MB/s) - 
‘4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z.1’ 
saved [11001956/11001956]


So try this URL:
https://chuangtzu.ftp.acc.umu.se/mirror/qt.io/qtproject/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/qt.tools.maintenance/4.6.1-0-202308231236tqtc-installer-framework-MacOS-MacOS_10_13-Clang-MacOS-MacOS_10_13-X86_64-QtInstaller.7z 



Rgrds Henry


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

Re: [Interest] No rule to make target. Stop.

[Henry Skoglund]

On 2023-11-29 18:05, Turtle Creek Software wrote:
We deleted build folder, fiddled with settings, and deleted Qt 
completely a couple times with fresh installs of Qt 6.6.1 for MacOS.  
None of that was successful.  The fresh installs had problems 
auto-detecting the correct kit.  Is that the root of the "no rule to 
make target" error?


Re-installing Qt 6.5.3 worked OK again.

All previous Qt updates from 5.15 onward went smoothly. 6.6.0 gave 
similar errors but we hoped that 6.6.1 would fix them, and just 
reverted to 6.5.3.


What has changed in kits/build process between 6.5.3 and 6.6.0?  Our 
setup is pretty vanilla.


Thanks, Casey McD

Hi, had similar problems with Qt 6.6.1 on my Mac, but after updating to 
Xcode 15.0.1 it was smooth sailing.


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

Re: [Interest] unresolved WinMain on porting to Qt 6

[Henry Skoglund]

On 2023-06-23 07:15, Hamish Moffatt via Interest wrote:
I'm porting my applications to Qt6, from 5.15. Still using qmake. My 
console applications build and run fine, but my widgets applications 
fail to link with an error (Windows, VS 2022):


1>MSVCRTD.lib(exe_winmain.obj) : error LNK2019: unresolved external 
symbol WinMain referenced in function "int __cdecl invoke_main(void)" 
(?invoke_main@@YAHXZ)


I have a traditional entrypoint: int main(int argc, char* argv[]).


I see in Qt 5 there was a magic helper library qtmain, but this does 
not exist in Qt 6.


If I add the linker flag /ENTRY:mainCRTStartup then it builds. What's 
the correct Qt solution for this though?




The fact that adding /ENTRY:mainCRTStartup helped implies that you're 
linking with /SUBSYSTEM:CONSOLE and not /SUBSYSTEM:WINDOWS, i.e. 
defaulting to console flavor.

Maybe you forgot "QT += widgets" in the .pro file (just guessing :-)

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

Re: [Interest] Qt Sql BLOB data converting

[Henry Skoglund]

On 2022-11-28 09:32, Yauheni Pervenenka via Interest wrote:

Hi, Tony, thanks for your reply,
OS: win 11
DB: SQLite

Unfortunately, QVariant::toByteArray returns size 52(hex 104), 
QVariant::toString returns size 30


There is data returned by QVariant::toByteArray::toHex
Qt data in hex(size 104):
763130492d46c2ab4cc29c7bc2b0efbfbd78c29b29c3ab1e4723dea6efbfbdefbfbdefbfbdefbfbd66c2a275efbfbdefbfbdc4a6

Original value in hex 
size(68): 763130492d46ab4c9c7bb0e9789b29c3ab1e4723dea6c8e5d2f9b266a275e1fbe4a6 



there are some data that is parsed correct but time to time it is broken



On Mon, Nov 28, 2022 at 11:17 AM Tony Rietwyk  
wrote:


Hi Yauheni,

You don't say which type of database you are using?  There may be
issues
with the database client library altering the blob to UTF8. Though I
would expect the python code using the same client to have the same
problem.

Assuming that QVariant has the byte array unaltered, then
QVariant.toByteArray().length() should give 34.  Using qstrlen,
suggests
that you are using QVariant.toString instead.  To print the hex you
should just use QVariant.toByteArray().toHex().

Hope that helps,

Tony


On 28/11/2022 6:46 pm, Yauheni Pervenenka via Interest wrote:
> Hello, community
> I have faced with issue that qvariant using qstrlen for getting
data
> size, but sometimes it returns wrong size especially for BLOB
data(if
> there are some special symbols), are there any way to get data
correct?
>
> Note:
> Database value 34, python returns correct data size, but
> qvariant::toByteArray returns 52
>
> Python data and Database data in hex(size
>
68): 763130492d46ab4c9c7bb0e9789b29c3ab1e4723dea6c8e5d2f9b266a275e1fbe4a6
>
> Qt data in hex(size 104):
>

763130492d46c2ab4cc29c7bc2b0efbfbd78c29b29c3ab1e4723dea6efbfbdefbfbdefbfbdefbfbd66c2a275efbfbdefbfbdc4a6
>



Hi, most of the data is preserved in Qt but some other data is injected 
midstream.
Just a guess, but maybe the Qt version has a multithreading issue, like 
two threads are settings values in the same array at the same time.



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

Re: [Interest] ASAN (Qt 6.4 + Glib) build shows stackoverflow in trivial Qt program

[Henry Skoglund]

On 2022-11-13 18:29, Thiago Macieira wrote:

On Sunday, 13 November 2022 09:03:40 PST Henry Skoglund wrote:

I can confirm "several tiny libraries" i.e. I had the same problem when
building Qt on Ubuntu 22.04.
After fiddling for a while, I took the easy way out:
sudo apt-get install libxcb*

That installed 68 libs (all beginning with libxcb-) probably overkill
but at least it solved the problem :-)

Those XCB libraries are generated from the X specification, that's why there
are so many of them. But this split up is counter-productive now.

As you've seen, it causes headache in forgetting just one of them. And as we
add content to Qt, what built one version may not build the next, so you have
to review after the upgrade.

The next problem is memory fragmentation. At a bare minimum, each library on
Linux must be one read-only page containing code and one read-write page
containing the GOT. Most Linux distros actually split a bit more for security,
with a read-only non-executable page before the executable one, then one more
after for read-only constant data and yet another for post-relocation read-
only, like so:

Address   Kbytes RSS PSS   DirtySwap Mode  Mapping
7fed1e9e6000   4   4   0   0   0 r--p- libxcb-shm.so.
0.0.0
7fed1e9e7000   4   4   0   0   0 r-xp-libxcb-shm.so.
0.0.0
7fed1e9e8000   4   4   0   0   0 r--p- libxcb-shm.so.
0.0.0
7fed1e9e9000   4   4   4   4   0 r--p- libxcb-shm.so.
0.0.0
7fed1e9ea000   4   4   4   4   0 rw-p-libxcb-shm.so.
0.0.0

And the last two pages are not sharable between processes, so each one of
those costs 5 VMA entries in the page tables, 8 kB of non-sharable data, and a
bit of load-time work processing relocations.

All this for this tiny XCB library:
-rwxr-xr-x 1 root root 14416 Aug 31 05:33 /lib64/libxcb-shm.so.0.0.0


For Clear Linux, we've "tricked" the build to just merge all those libraries
and libX11.so into a single .so, so they are loaded once only and occupy Much
less memory.


Yeah maybe Ubuntu is not the cream of the crop anymore:
find / -name libxcb-shm.so.0.0.0
/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
/snap/snap-store/582/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
/snap/snap-store/599/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
/snap/gnome-3-38-2004/119/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
/snap/gnome-3-38-2004/115/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0

not only are those libcxb files cluttering up my RAM they're also 
creating litter on my SSD :-(


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

Re: [Interest] ASAN (Qt 6.4 + Glib) build shows stackoverflow in trivial Qt program

[Henry Skoglund]

On 2022-11-13 17:52, Thiago Macieira wrote:

On Saturday, 12 November 2022 23:11:45 PST Dennis Luehring wrote:

forcing -xcb gives me these configure output (https://pastebin.com/ML8QCJRQ)

XCB:
  Using system-provided xcb-xinput . no
  GL integrations:
GLX Plugin . yes
  XCB GLX .. yes
EGL-X11 Plugin . yes

but also configure fails with

ERROR: Feature "xcb": Forcing to "ON" breaks its condition:
  QT_FEATURE_thread AND TARGET XCB::XCB AND TEST_xcb_syslibs AND
QT_FEATURE_xkbcommon_x11


i've double checked every required package that is needed and can't find
a missing package

Your log says:


   TEST_xcb_syslibs = "FALSE"

This is the problem. You're missing the XCB libraries in your environment (we
don't ship them bundled in Qt any more). You may want to increase the log
level because XCB support requires several tiny libraries and any of them
missing means the entire support is missing.



I can confirm "several tiny libraries" i.e. I had the same problem when 
building Qt on Ubuntu 22.04.

After fiddling for a while, I took the easy way out:
sudo apt-get install libxcb*

That installed 68 libs (all beginning with libxcb-) probably overkill 
but at least it solved the problem :-)

/Henry

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

Re: [Interest] Build report - QT 6.3 on FreeBSD 13.1

[Henry Skoglund]

On 2022-06-19 17:57, Thiago Macieira wrote:

On Saturday, 18 June 2022 21:42:23 PDT Chris Benesch wrote:

especially that annoying xcb stuff which for some reason on Linux is broken
down into about 20 separate packages.
CMAKE_LIBRARY_PATH=/usr/local/lib

That's not only annoying, it's counter-productive. Those libraries are tiny,
and yet each library has a *minimum* RSS commitment of 3 pages (12 kB) on
Linux (FreeBSD *may* compile them to 2, I haven't checked), one of which
cannot be shared. The 33 libraries combined need only a total of 16 writable
pages, instead of the 35 they actually consume.


That plethora of libxcb-xxx libraries kept breaking my build of 6.3.1 on 
a new Ubuntu 22.04 recently. First I tried installing them nicely one by 
one:

sudo apt install libxcb-fruitbasket
sudo apt install libxcb-flowerarrangement
sudo apt install libxcb-birdwatcher
...
etc. etc. until I learned that you could do
sudo apt install libxcb*

Got all 68 (!) of them but at least my Qt build was successful :-)

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

Re: [Interest] Qt5.15 from source on centOS 7

[Henry Skoglund]

On 2022-06-17 07:46, Alexander Carôt wrote:

Hi all,

I have to compile Qt5.15 from source on an older centOS 7.9 machine but it 
fails due to this issue (sorry, only german language):

.In file included from ../include/QtCore/qmetatype.h:1:0,
  from ../include/QtCore/../../src/corelib/kernel/qvariant.h:46,
  from ../include/QtCore/qvariant.h:1,
  from ../include/QtCore/../../src/corelib/text/qlocale.h:43,
  from ../include/QtCore/qlocale.h:1,
  from 
../include/QtCore/../../src/corelib/serialization/qtextstream.h:46,
  from ../include/QtCore/qtextstream.h:1,
  from ../include/QtCore/../../src/corelib/io/qdebug.h:49,
  from ../include/QtCore/qdebug.h:1,
  from 
/var/www/vhosts/soundjack.eu/qt5/qtbase/qmake/library/proitems.h:34,
  from 
/var/www/vhosts/soundjack.eu/qt5/qtbase/qmake/library/qmakeparser.h:34,
  from 
/var/www/vhosts/soundjack.eu/qt5/qtbase/qmake/library/qmakeevaluator.h:36,
  from 
/var/www/vhosts/soundjack.eu/qt5/qtbase/qmake/project.h:32,
  from 
/var/www/vhosts/soundjack.eu/qt5/qtbase/qmake/main.cpp:30:
../include/QtCore/../../src/corelib/kernel/qmetatype.h: In Instanziierung von 
»QtMetaTypePrivate::QSequentialIterableImpl::QSequentialIterableImpl(const T*) [with 
T = QList]«:
../include/QtCore/../../src/corelib/kernel/qvariant.h:772:139:   von hier 
erfordert
../include/QtCore/../../src/corelib/kernel/qmetatype.h:1160:135: Fehler: mehrdeutige 
Klassentemplate-Instanziierung für »struct 
QtMetaTypePrivate::ContainerCapabilitiesImpl, void>«
, _iteratorCapabilities(ContainerAPI::IteratorCapabilities | (1 << 4) | 
(ContainerCapabilitiesImpl::ContainerCapabilities << (4+3)))
  


There is an ambigious class template instantiation for struct 
QtMetaTypePrivate::ContainerCapabilitiesImpl – that obvious but 
I currently don't know how to resolve it.

Can anyone help ?

Thanks !

Alex

Hi, default GCC version on CentOS 7.9 is 4.8.5 but Qt 5.15 requires at 
least GCC version 5.


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

Re: [Interest] Crash in QAbstractEventDispatcher::filterNativeEvent when trying to show a QMessageBox

[Henry Skoglund]

On 2022-04-14 23:15, Thiago Macieira wrote:

On Thursday, 14 April 2022 12:02:06 PDT Henry Skoglund wrote:

if I look at the debugger data and in the QThreadData * dump, I see that
the looplevel is 1 but if this is the GUI thread shouldn't it be 2
considering we've passed through the exec() call in QDialog? I mean
since a Qt GUI app usually starts with an exec() call which changes the
looplevel from 0 to 1 for the lifetime of the app.
Is that why you're suspecting the crash occurs becase we're still in the
worker thread?

Hello Henry

You can't trust that data dump. The very first pointer in it is suspicious:


- d 0x02030600

That doesn't look like a valid pointer to me. However, I confess I don't know
for sure because that's a Windows pointer and I don't know the memory layout
on Windows as well as I do on Linux. Points in favour of it being valid are:
...
Indeed it looks weird (it's pointing into 2TB territory) but I believe 
it's just an effect of Microsoft's Control Flow Guard (tm) being active 
for that .exe.


Thanks for the analysis!

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

Re: [Interest] Crash in QAbstractEventDispatcher::filterNativeEvent when trying to show a QMessageBox

[Henry Skoglund]

On 2022-04-14 17:01, Thiago Macieira wrote:

On Thursday, 14 April 2022 06:24:29 PDT Rainer Wiesenfarth wrote:

However, I am using QThread, and the crash happens
in a slot connected (queued connection) to a signal emitted by the thread
(m_pWorkerThread)

Are you sure it was queued?

Your backtrace stops in the QMessageBox::information, so we can't tell what it
was called from.



Hi, while we're waiting for an answer, I've recently started using 
QThread so this might be a noob question (sorry):
if I look at the debugger data and in the QThreadData * dump, I see that 
the looplevel is 1 but if this is the GUI thread shouldn't it be 2 
considering we've passed through the exec() call in QDialog? I mean 
since a Qt GUI app usually starts with an exec() call which changes the 
looplevel from 0 to 1 for the lifetime of the app.
Is that why you're suspecting the crash occurs becase we're still in the 
worker thread?


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

Re: [Interest] painter.fillRect() with gradient on PDF printer produces all white?

[Henry Skoglund]

On 2022-04-07 23:08, Israel Brewster wrote:

On Apr 7, 2022, at 12:59 PM, Henry Skoglund  wrote:


On 2022-04-07 22:04, Israel Brewster wrote:

On Apr 7, 2022, at 11:58 AM, Henry Skoglund  wrote:

On 2022-04-07 20:28, Israel Brewster wrote:
Using Qt 5.15 and PySide2, I am working on a project that requires 
me to produce a PDF output. My process so far is to create a 
QWidget containing the content I want, render it to a QPicture (so 
it won’t be rasterized upon “printing”), then create a PDF 
QPrinter and use the painter.drawPicture() function to “print” the 
widget into a PDF.


This works well, giving me a high-quality vectorized PDF output, 
with one exception: any item that is filled with a gradient. When 
printing to PDF, the gradient always comes out as solid white. 
With some digging, I determined that this is even the case when 
doing nothing but a simple painter.fillRect() with a gradient.


Is there any “fix” for this? Thanks.

If it helps, here is some simple code that reproduces the issue:

from PySide2.QtWidgets import QApplication
from PySide2.QtGui import QPainter, QPageSize, QLinearGradient
from PySide2.QtPrintSupport import QPrinter
from PySide2.QtCore import QSize, QRect, Qt

app = QApplication()

gradient_rect = QRect(0, 0, 500, 25)
gradient = QLinearGradient(0, 0, 1, 0)
gradient.setColorAt(0, Qt.blue)
gradient.setColorAt(1, Qt.red)

page_size = QPageSize(QSize(500, 25), matchPolicy = 
QPageSize.ExactMatch)

printer = QPrinter()
printer.setOutputFormat(QPrinter.PdfFormat)
printer.setPageSize(page_size)
printer.setOutputFileName('/tmp/testPDFGradient.pdf')

painter = QPainter(printer)
painter.fillRect(gradient_rect, gradient)
painter.end()


Hi, try
...
gradient_rect = QRect(0, 0, 500, 25)
gradient = QLinearGradient(0, 0, 500, 25)
gradient.setColorAt(0, Qt.blue)
gradient.setColorAt(1, Qt.red)
...
(i.e. QLinearGradient's ctor expects coords)
No change. The 1 value was picked because that’s what displays 
correctly in testing, but even with the suggested change I still get 
a solid white box.


Hmm, I just tested on Ubuntu 20.04, created an empty vanilla widget 
program in Qt 5.15.2. added "printsupport" to the .pro file and 
changed mainwindow.cpp to look like this:


#include "mainwindow.h"
#include "ui_mainwindow.h"
#include "QtPrintSupport"

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    auto gradient_rect = QRect(0,0,500,25);
    auto gradient = QLinearGradient(0,0,500,25);
    gradient.setColorAt(0,Qt::blue);
    gradient.setColorAt(1,Qt::red);

    QPrinter printer;
    QPageSize ps(QSize(500,25),"GradientTest",QPageSize::ExactMatch);
printer.setOutputFormat(QPrinter::PdfFormat);
    printer.setPageSize(ps);
printer.setOutputFileName("/home/henry/Downloads/testPDFGradient.pdf");

    QPainter painter;
    painter.begin();
painter.fillRect(gradient_rect,gradient);
    painter.end();
}

MainWindow::~MainWindow()
{
    delete ui;
}

screenshot here:https://tungware.se/GradientOnUbuntu.png
(also tested on Windows 10 MSVC2019 Qt 5.15.2 and works there as well)

Maybe pySide2 messes up something, you could try with some C++ :-)


Interesting…must be a MacOS thing then. I just tried your C++ code 
with the exact same results - plain white rectangle. So the only 
difference I can see now is that you tested on Windows and Linux, 
while I am testing on MacOS.


Wonderfull. Now I apparently need different code depending on which OS 
I am running on (assuming I can get this to work on MacOS at all)...

---

I fired up my Mac, tested my code above on Qt 6.2.4 and verified I got 
the same "A whiter shade of pale" as you.


Then I tested by copying a working .pdf from Ubuntu into Monterey, it 
also displayed as totally white (when double-clicked or when viewed in 
Safari).
But when I copied the .PDF generated in Monterey into Ubuntu, guess 
what: it displayed correctly.


But it gets better! Guess what happens if you choose to view the PDF on 
Monterey with either Chrome or Firefox (instead of Safari), then the 
blue-red gradient lights up, yes even on the Mac :-)


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

Re: [Interest] painter.fillRect() with gradient on PDF printer produces all white?

[Henry Skoglund]

On 2022-04-07 22:04, Israel Brewster wrote:

On Apr 7, 2022, at 11:58 AM, Henry Skoglund  wrote:

On 2022-04-07 20:28, Israel Brewster wrote:

Using Qt 5.15 and PySide2, I am working on a project that requires me to 
produce a PDF output. My process so far is to create a QWidget containing the 
content I want, render it to a QPicture (so it won’t be rasterized upon 
“printing”), then create a PDF QPrinter and use the painter.drawPicture() 
function to “print” the widget into a PDF.

This works well, giving me a high-quality vectorized PDF output, with one 
exception: any item that is filled with a gradient. When printing to PDF, the 
gradient always comes out as solid white. With some digging, I determined that 
this is even the case when doing nothing but a simple painter.fillRect() with a 
gradient.

Is there any “fix” for this? Thanks.

If it helps, here is some simple code that reproduces the issue:

from PySide2.QtWidgets import QApplication
from PySide2.QtGui import QPainter, QPageSize, QLinearGradient
from PySide2.QtPrintSupport import QPrinter
from PySide2.QtCore import QSize, QRect, Qt

app = QApplication()

gradient_rect = QRect(0, 0, 500, 25)
gradient = QLinearGradient(0, 0, 1, 0)
gradient.setColorAt(0, Qt.blue)
gradient.setColorAt(1, Qt.red)

page_size = QPageSize(QSize(500, 25), matchPolicy = QPageSize.ExactMatch)
printer = QPrinter()
printer.setOutputFormat(QPrinter.PdfFormat)
printer.setPageSize(page_size)
printer.setOutputFileName('/tmp/testPDFGradient.pdf')

painter = QPainter(printer)
painter.fillRect(gradient_rect, gradient)
painter.end()


Hi, try
...
gradient_rect = QRect(0, 0, 500, 25)
gradient = QLinearGradient(0, 0, 500, 25)
gradient.setColorAt(0, Qt.blue)
gradient.setColorAt(1, Qt.red)
...
(i.e. QLinearGradient's ctor expects coords)

No change. The 1 value was picked because that’s what displays correctly in 
testing, but even with the suggested change I still get a solid white box.

Hmm, I just tested on Ubuntu 20.04, created an empty vanilla widget 
program in Qt 5.15.2. added "printsupport" to the .pro file and changed 
mainwindow.cpp to look like this:


#include "mainwindow.h"
#include "ui_mainwindow.h"
#include "QtPrintSupport"

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    auto gradient_rect = QRect(0,0,500,25);
    auto gradient = QLinearGradient(0,0,500,25);
    gradient.setColorAt(0,Qt::blue);
    gradient.setColorAt(1,Qt::red);

    QPrinter printer;
    QPageSize ps(QSize(500,25),"GradientTest",QPageSize::ExactMatch);
    printer.setOutputFormat(QPrinter::PdfFormat);
    printer.setPageSize(ps);
printer.setOutputFileName("/home/henry/Downloads/testPDFGradient.pdf");

    QPainter painter;
    painter.begin();
    painter.fillRect(gradient_rect,gradient);
    painter.end();
}

MainWindow::~MainWindow()
{
    delete ui;
}

screenshot here: https://tungware.se/GradientOnUbuntu.png
(also tested on Windows 10 MSVC2019 Qt 5.15.2 and works there as well)

Maybe pySide2 messes up something, you could try with some C++ :-)

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

Re: [Interest] painter.fillRect() with gradient on PDF printer produces all white?

[Henry Skoglund]

On 2022-04-07 20:28, Israel Brewster wrote:
Using Qt 5.15 and PySide2, I am working on a project that requires me 
to produce a PDF output. My process so far is to create a QWidget 
containing the content I want, render it to a QPicture (so it won’t be 
rasterized upon “printing”), then create a PDF QPrinter and use the 
painter.drawPicture() function to “print” the widget into a PDF.


This works well, giving me a high-quality vectorized PDF output, with 
one exception: any item that is filled with a gradient. When printing 
to PDF, the gradient always comes out as solid white. With some 
digging, I determined that this is even the case when doing nothing 
but a simple painter.fillRect() with a gradient.


Is there any “fix” for this? Thanks.

If it helps, here is some simple code that reproduces the issue:

from PySide2.QtWidgets import QApplication
from PySide2.QtGui import QPainter, QPageSize, QLinearGradient
from PySide2.QtPrintSupport import QPrinter
from PySide2.QtCore import QSize, QRect, Qt

app = QApplication()

gradient_rect = QRect(0, 0, 500, 25)
gradient = QLinearGradient(0, 0, 1, 0)
gradient.setColorAt(0, Qt.blue)
gradient.setColorAt(1, Qt.red)

page_size = QPageSize(QSize(500, 25), matchPolicy = QPageSize.ExactMatch)
printer = QPrinter()
printer.setOutputFormat(QPrinter.PdfFormat)
printer.setPageSize(page_size)
printer.setOutputFileName('/tmp/testPDFGradient.pdf')

painter = QPainter(printer)
painter.fillRect(gradient_rect, gradient)
painter.end()



Hi, try
...
gradient_rect = QRect(0, 0, 500, 25)
gradient = QLinearGradient(0, 0, 500, 25)
gradient.setColorAt(0, Qt.blue)
gradient.setColorAt(1, Qt.red)
...
(i.e. QLinearGradient's ctor expects coords)

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

Re: [Interest] Windows: "loadlibrary failed with error 87" on a configuration with a fake video card?

[Henry Skoglund]

On 2022-03-22 07:11, Alexander Dyagilev wrote:

Hello,

The stack trace is the following. Should I file a bug report? Is there 
a workaround I can suggest to the user?


win32u.dll!NtUserWaitMessage()
user32.dll!DialogBox2()
user32.dll!InternalDialogBox()
user32.dll!SoftModalMessageBox()
user32.dll!MessageBoxWorker(struct _MSGBOXDATA *)
user32.dll!MessageBoxTimeoutW()
user32.dll!MessageBoxTimeoutA()
user32.dll!MessageBoxA()
atig6pxx.dll!7ffd04194e11()
atig6pxx.dll!7ffd0419526e()
opengl32.dll!pgldrvLoadAndAllocDriverInfo()
opengl32.dll!LoadAvailableDrivers()
..



On 3/18/2022 6:41 AM, Thiago Macieira wrote:

On Thursday, 17 March 2022 19:50:45 PDT Alexander Dyagilev wrote:

This error message is shown by Windows OS when it's failed to load a
library the process sayed it to load.

I.e. Qt calls LoadLibrary (directly, or by loading some other modules
which calls it to load another modules they depends on).

Short googling tells that it's an graphics card driver related issue
(e.g. https://github.com/spyder-ide/spyder/issues/10084).

But, maybe there is some known work around for this...
If you can generate a backtrace from the application at the moment 
that dialog
is shown, it can help pinpoint what was being loaded and where from. 
There are

too many LoadLibrary in the source code to guess which one has incorrect
parameters.





If you google for that video driver **atig6pxx.dll** you'll find non-Qt 
programs that also exhibit the same error 87, for example AutoCAD:

https://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/AutoCAD-startup-error-load-liabrary-failed-with-error-87.html

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

Re: [Interest] Windows: "loadlibrary failed with error 87" on a configuration with a fake video card?

[Henry Skoglund]

On 2022-03-18 04:41, Thiago Macieira wrote:

On Thursday, 17 March 2022 19:50:45 PDT Alexander Dyagilev wrote:

This error message is shown by Windows OS when it's failed to load a
library the process sayed it to load.

I.e. Qt calls LoadLibrary (directly, or by loading some other modules
which calls it to load another modules they depends on).

Short googling tells that it's an graphics card driver related issue
(e.g. https://github.com/spyder-ide/spyder/issues/10084).

But, maybe there is some known work around for this...

If you can generate a backtrace from the application at the moment that dialog
is shown, it can help pinpoint what was being loaded and where from. There are
too many LoadLibrary in the source code to guess which one has incorrect
parameters.

Hi, note: it's not certain that the LoadLibrary error is from Qt, for 
example a similar error:
"Load Library failed with error 126: The specified module could not be 
found." was found to be from within the bowels of Windows itself (non-Qt 
apps also got this error).
More here about error 126: 
https://forum.qt.io/topic/132880/qt-creator-error-126-running-on-windows-10-via-rdp


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

Re: [Interest] Installation Sizes for Applications using Qt

[Henry Skoglund]

On 2021-08-30 21:43, Thiago Macieira wrote:

On Monday, 30 August 2021 12:23:54 PDT Henry Skoglund wrote:

Thanks Thiago for the clarification re. those "-skip xxx" options. I
guess I can skip them :-)
Ok, one benefit remains: saving some time when compiling/building the
static Qt version.

Indeed. But you could save time by just downloading qtbase too. Then you save
time in the download, time in the build as well as disk space.


Riddle me this though:
for 5.15.2 I built 2 MSVC versions: one with built-in SSL 1.1.1K support
and one without.
When I build a hello world widget app, the .exe file without SSL lands
at 10541 kB but the one *with* SSL 1.1.1K support is 10531 kB. Why is
the .exe file with more functionality smaller??

I assume you're not using QSslSocket or any of the classes that would
indirectly use it (QNetworkAccessManager), otherwise that makes no sense. As
in, it doesn't make sense to support HTTP only, not HTTPS.

I can't account for the difference. If I needed to know this, I'd inspect the
linker map to find out what got linked in.

Which means "don't use MSVC's link.exe"



Re: downloads, you're right, but you forgot the noob factor, I use no 
fancy git get, I download the humongous zip: 
http://download.qt.io/official_releases/qt/5.15/5.15.2/single/qt-everywhere-src-5.15.2.zip


Re: QsslSocket usage: no it's not pulled in in either of the 2 versions. 
(If I try them with the SecureSocketClient example, one runs ok and the 
other fails to compile with "required feature ssl ... not available). I 
was just curious how the static lib with SSL support yields sliighly 
smaller .exe files.  But a linker map and some coffee is a good idea...


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

Re: [Interest] Installation Sizes for Applications using Qt

[Henry Skoglund]

On 2021-08-30 20:48, Thiago Macieira wrote:

On Monday, 30 August 2021 10:32:03 PDT Henry Skoglund wrote:

configure that has a "-skip " for all
modules expect qtbase.

That makes zero difference in your final binary.

If you need a library that wasn't compiled, your application will fail to
link. If you have a library that your application doesn't link to, it won't be
linked to.

The convenience "-skip" option to the top-level configure is not at all the
same as the feature system that we're discussing.


When using MinGW 8.1.0 the .exe size is 19151 kB and when using MSVC2019
it becomes 11616 kB, i.e. 40% smaller.

Do note that both QtCore and QtGui are compiled with -O3, which expands code
size, when using GCC or Clang. There's no equivalent option to MSVC. You may
want to disable this feature too and stick to -O2.

You may also want to optimise for size, at the expense of runtime performance.
That's usually not worth it.

Thanks Thiago for the clarification re. those "-skip xxx" options. I 
guess I can skip them :-)
Ok, one benefit remains: saving some time when compiling/building the 
static Qt version.


Re. compiler options, I'm too lazy and just go with the default settings 
that Qt gives me, and since they provided a 40% decrease of the final 
.exe size when switching to MSVC I'm happy.


Riddle me this though:
for 5.15.2 I built 2 MSVC versions: one with built-in SSL 1.1.1K support 
and one without.
When I build a hello world widget app, the .exe file without SSL lands 
at 10541 kB but the one *with* SSL 1.1.1K support is 10531 kB. Why is 
the .exe file with more functionality smaller??


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

Re: [Interest] Installation Sizes for Applications using Qt

[Henry Skoglund]

On 2021-08-30 18:15, Thiago Macieira wrote:

On Monday, 30 August 2021 04:04:42 PDT Joerg Bornemann wrote:

Use configure -list-features and pick something you definitely don't
need, for example
lcdnumber  Widgets: Provides LCD-like digits.
and configure and build Qt with -no-feature-lcdnumber

That's probably not a good example, since the LCD number widget (the oldest
widget in Qt, aside from QWidget itself, because Qt had no font support yet
when this class was created) is fairly self-contained.

Anyway, there are a couple of suggestions in this thread to make the
application even smaller.

But it won't be tiny. That's just not in the cards.


Hi, also the choice of compiler can influence the size of the executable.
For example, on Windows I have a LOB Qt 5.15.2 Widgets-only app that I 
build statically, with a configure that has a "-skip " for all 
modules expect qtbase.
When using MinGW 8.1.0 the .exe size is 19151 kB and when using MSVC2019 
it becomes 11616 kB, i.e. 40% smaller.


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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Henry Skoglund]

On 2021-04-25 13:56, André Pönitz wrote:

...
Hi Nuno.

This is an interesting statement.

My personal experience is exactly the opposite: By using Qt Quick one is
forced to use non-trivial amounts of glue code that is conceptually
unnecessary in the QWidget case.

As a concrete example: A while ago I converted Qt Creator's Welcome screen
(on the UI side essentially the thing that you see whe selecting the Welcome
mode plus a bit of helper code) from Qt Quick to QWidgets. The driving force
behind that change were re-occurring issues in setups with limited or
"broken" OpenGL support and the overall application startup time previously
dominated by this rather small plugin. Having to tell people to run with
"-noload Welcome" to mitigate these created a rather unwelcoming user
experience.

Besides solving the actually triggering problems this had the (not
completely, but surely at this level unexpected) side effect of reducing the
overall code side considerably: The original setup consisted some C++
"backend", the QML "frontend" and the "glue" to expose the backend to the
frontend (i.e. what Peppe calls "presentation" layer in Message-ID:
<421f4e26-dc6f-c06f-782f-72b67caf5...@kdab.com>). I do, btw, agree this is
indeed "best practice" for a Qt Quick application, so the original
implementation was ok, given the limits of the chosen technology.

For the replacement I had to do add some custom finger-painting code with
e.g. absolute pixel counts to mimic the original appearance closely (which
is, btw, quite unusual for a normal QWidget based setup), but even with that
the total LOC of backend + the complete frontend was less than previous LOC
of backend + glue. I.e. already the absolute number of LOC of the C++ bits
(with shifted functionality) overall decreased, and the QML bits were
completely gone.

One thing I noticed contributing to this effect is that it is apparently
difficult to pass objects of "medium" complexity through the glue layer.
Simple stuff like integers and strings are fine (enums already get
interesting...), really complex stuff like QAbstractItemModels can be fine,
but for "two strings, an enum and an optional QDir" you already have to make
up your mind whether this is more like "three strings and an int" or more
like "something that needs moc". This contributes to an effect that I
consider self-censorship when it comes to selecting appropriate data
structures for the backend: If I know I can only expose certain types to the
frontend, I am tempted to used these types in the backend, not necessarily
the ones best suited one for the task. If the only tool is a hammer, ...


Anticipating some potential responses here: Of course, using QWidgets you
have at some point a _conceptually_ similar problem of having to associate
your QDir "data" with e.g. a QLineEdit, and your enum value with a QComboBox
or some QRadioButtons in a QButtonGroup. The concept of a "glue" layer
doesn't magicaly go away. However, in this case you have the choice to put
this glue code at a place were they make most sense (and also shift stance
easily once requirement changes), by e.g. putting the "necessary"
"three-line-lambda" in a place where your "logical" backend/frontend divide
actually is. With Qt Quick there is already some divide between .qml and
.cpp after you have prototype, and even when this turns out to be not the
the best place for the cut in the end, or when the requirements change
(a.k.a. "always"...) there is a high inertia to keep the divide as-is, even
if it doesn't fit the problem well anymore - simply because converting even
only a handfuls lines of code between C++ and QML is significantly more
effort then shifting these lines between different parts of a uniform C++
code base.

Please note that I am really not saying that there is no backend/frontend
glue in any QWidget based application. I surely have seen enough code piling
glue layer on glue layer for no traceable reason also for QWidget
applications so I know this generalization is not true. The point is really
that for a _reasonably_ developed QWidget application the amount of
_necessary_ glue is significantly(!) less than the _necessary_ glue of an
equally _reasonably_ developed Qt Quick application.  On top of that go
benefits like being the ability to use the same kind of tooling (debugger,
profiler, static analyzer, ...) for both parts in one go.

As you seem to have made different experiences I'd like to ask whether there
are concrete examples I may look at?

Andre'


Hi, re. backend/frontend glue i QWidget flavored apps:
you could also say that some "glue" will appear when you choose a 
QTableView instead of a QTableWidget in your Qt app.
IOW, most of the time (at least in my apps) working directly with a 
QTableWidget gets the job done easier/faster. Of course the QTableView 
model stuff is useful in some cases but I think the default design 
choice should be the plain widget.


Rgrds Henry
P.S. Reminds me of another, slightly similar 

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

[Henry Skoglund]

On 2021-03-29 21:29, Matthew Woehlke wrote:

On 28/03/2021 09.52, Jason H wrote:
The developers at Qt Co need to push back and tell Digia "that's not 
how this
works" before we get to the points of users revolting in threads on 
the forums /

lists.


*Before*?

I guess this thread, and the multiple others like it, are then 
discussions on the variation in carrying capacity of English and 
African swallows.




Shouldn't that be "... on the variation in carrying capacity of European 
and African swallows."


Perhaps we need to start another thread to resolve this matter...

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

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

[Henry Skoglund]

On 2021-03-22 11:48, Allan Sandfeld Jensen wrote:

On Montag, 22. März 2021 10:38:09 CET Roland Hughes wrote:

On 3/22/21 4:07 AM, Bernhard Lindner wrote:

Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
Qt-6-rolling-out-incomplete + deleted-convenience-methods =
customers-leaving

I wonder if the loss of confidence in the current Qt owners can ever be
compensated.

Even if TQC took back their critical decisions, I can't imagine that
people would ever trust them again. This could cause fatal damage to Qt
in the long run if they don't sell it to someone more responsible.

Dude,

Comcast, TimeWarner, and all of those other set-top box vendors formed
an OpenSource project to create RDK so they could kick Qt to the curb.


That happened 5 years ago. Comcast was only using QtWebKit from Qt anyway.

'Allan


It was in late 2013 if this announcement could be viewed as the launch:
https://press.opera.com/2013/12/13/opera-launches-the-industrys-first-commercial-grade-chromium-blink-engine-designed-for-rdk-set-top-boxes/

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

Re: [Interest] QQuickWindow Transparent Window Issues on Windows NVIDIA GPU

[Henry Skoglund]

Hi, I think GTX 950M is too old (the laptop is from 2015) for Direct3D 
12, see for example: 
https://www.nvidia.com/en-us/geforce/forums/discover/234361/gtx-950m-dirextx-12/


Also, the driver for the Intel HD 4600 is a bit old, try updating it 
from 20.19.15.4549 to 20.19.15.4853, it might help for the transparency 
problem.



On 2020-08-04 17:02, Fabrice Mousset | GEOCEPT GmbH wrote:


Hello,

If you are targeting Windoows10, you could try to use Direct3D 12 
renderer with Qt 5.15.x 
èhttps://doc.qt.io/qt-5/qtquick-visualcanvas-adaptations-d3d12.html


Regards

Fabrice

*Von:* Interest  *Im Auftrag von 
*Furkan Uzumcu

*Gesendet:* Dienstag, 4. August 2020 16:33
*An:* inter...@lists.qt-project.org
*Betreff:* [Interest] QQuickWindow Transparent Window Issues on 
Windows NVIDIA GPU


Hello everyone.

I’ve been having this issue on NVIDIA cards on Windows in all versions 
from Qt v5.12.2 to v5.15.0. I created a ticket here: 
https://bugreports.qt.io/browse/QTBUG-85524
But I wanted to reach out to see If anybody else encountered this. I’m 
not that well versed in this issue. I’m trying to research to see If 
there’s anything I can do about it or find a work around. There’s a 
few other related tickets in QTBUG but they don’t really offer a clear 
(At least to me) definition of the problem.


If anyone with the same problem can share their experience or provide 
any insight, I’d appreciate it.


Regards,

Furkan Üzümcü


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


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

Re: [Interest] I love QML

[Henry Skoglund]

On 2020-07-08 08:09, Till Oliver Knoll wrote:

Am 03.07.20 um 17:46 schrieb joao morgado via Interest:

When I started using Qt I never touched WIndows MFC again.


Ha! But you actually /did/ touch MFC then ;)

Here's another fan story (even though I am - unfortunately - not 
working professionally with Qt for a very long time)...


...
...
Having some first experience with Linux and KDE 1.x I had heard about 
a thing called Qt (which was at version 2.x at the time, IIRC). My 
diploma work in 2001 was about developing a "3d paint editor" 
(www.pointshop3.com, for the interested) based on an existing 
"point-based software renderer", which was... of course written in C 
and MFC - yikes! So my first suggestion to the PhD student who was 
overseeing my work was to rip away everything that spelled "MFC", make 
it compile with a C++ compiler and use Qt instead. "Go ahead, son. But 
if you run into trouble you're on your own!"


Turned out that my decision to use Qt (of which I only knew so little, 
but had browsed its excellent documentation, which already convinced 
me that I could pull it off - and of course the nice "Java-like" 
syntax of its API) was worth pure gold. After just two weeks or so I 
had the existing 3D "point-based renderer" compiling and running 
within a basic Qt application, with a main window and menu - yesss!


After exact four months I had a "3d paint editor" with selectable 
brushes, "gauss texture filtering", a software and OpenGL renderer 
(switchable at runtime), and all extendable with plugins. Hadn't it be 
for Qt, its excellent API and especially the documentation and 
examples I wouldn't have come that far, in so little time!


The application was later ported to Qt 3 by others and made runnable 
on Linux as well (I developed it mainly on Windows at the time), and 
was extended with some plugins "all over the world" (well, from some 
universities in France and Holland at least ;))



Lessons learned: a clean API and a great documentation with examples 
is what makes a great toolkit! And of course its functionality ;)


Hooray for Qt! :)




Hi, I think you used MFC in the wrong century :-)

For all the MFC bashing: before it I used Microsoft C and the Windows 
SDK. So when MFC was released in 1992, it was a game changer which had a 
lot of influence (for example I wrote C++ code for the Palm Pilot using 
Metrowerks and a MFC clone). But with so many other Microsoft things, 
MFC had its peak in the early 00's.


One great feature of Qt is the ownership model, which allows stuff like 
deleteLater(). MFC had no such concept, e.g. all the CStrings you placed 
on a listview, who owned them? Memory leaks were common.


Another great feature of Qt is portability, on my Raspberry PI 4 I've 
just replaced the SD-card with a USB3-SSD, speed difference in file 
loading is about 10x. So now Qt Creator is just so nice to run on it,  
gives you a cheaper taste of the Apple Silicon to come :-)


Rgrds Henry

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

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

[Henry Skoglund]

On 2020-06-15 12:37, Florian Bruhin wrote:

On Thu, Jun 11, 2020 at 06:02:53PM +, Jérôme Godbout wrote:

or Windows 11 by the time Qt 6 and you get your application ready "Microsoft
will release Windows 11 on July 29, 2020, and will be available to the
general public."

Do you have a source for that? I'm assuming it's
https://www.window11updates.com/ which is a hoax.

Florian

Wow! They also have Windows 12 
https://www.window11updates.com/windows-12-lite-download-linux-iso/

(must be *even better* than Windows 11 :-)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] is it ok to push audio on a background thread, not a timer?

[Henry Skoglund]

On 2020-05-19 03:19, Thiago Macieira wrote

PS: if you're using Hungarian notation, doesn't the "i" prefix indicate
"integer"? Why are you using it for pointers?

An "i" *after* the underscore would indicate an integer, yes, but the 
letter is before the underscore, so it indicates a scope, perhaps 
"i_..."  means an internal (not exported) class? Perhaps you're too 
young for proper Hungarian writing :-)


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

Re: [Interest] Arduino TeensyLC USB serial CDC + Qt not working on Windows

[Henry Skoglund]

On 2020-05-19 00:52, Jason H wrote:

The Teensy provides a virtual serial port via the USB Serial CDC. It works 
great on OSX.

I have a program where I wrote some code in Qt on my Mac.  My co-worker is 
trying to run it on Windows 10.
We expected to have to change the serial port name, which we did, to COM4. 
Teensyduino IDE sees serial traffic from it on Windows.
However, the program writes data to the teensy and expects it to reply back. 
The program reports having written the data but no reply is received. The 
Teensy is hooked to a contact switch and it's supposed to send a status message 
when this happens. He can see characters in the teensy serial terminal. But 
when we do it with Qt listening on the serial port, no readyRead call back is 
called.

Does anyone have any idea?
It works perfectly on OSX.

Just guessing but perhaps some USB buffering is happening on Windows. If 
you press that contact switch multiple times (to overcome the USB buffer 
of 64 bytes) do you see any bytes received in your Qt program?


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

Re: [Interest] Handling WM_QUIT messages when no window is shown

[Henry Skoglund]

On 2020-05-06 11:09, Julius Bullinger wrote:
Usually, sending a WM_QUIT message to a QApplication triggers the 
QCoreApplication::aboutToQuit() signal, e.g. when ending the 
application via Windows's Task Manager, or using "taskkill /PID ".


We discovered that no aboutToQuit() signal is emitted when a 
QApplication without windows receives a WM_QUIT:


    #include 
    #include 
    #include 

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

  QApplication::connect(, ::aboutToQuit, []() {
    qDebug() << "QApplication::aboutToQuit";
  });

  // Commenting those lines will not trigger aboutToQuit() when
  // the application is closed via Task Manager:
  QWidget w;
  w.show();

  return app.exec();
    }

Our application supports a text-only variant, where the GUI is 
disabled. We're basically doing it like that, and wondered why our 
shutdown code was not called when the application was quit via the 
Task Manager.


Is there anything that needs to be done to get consistent behavior?

Hi, when running apps on Windows without a window, you'll be missing out 
on a lot of inter-process stuff like WM_QUIT (that's why it's common for 
windowless apps to create a hidden, non-interactive window just to be 
able to receive all those WM_XXX). So no aboutToQuit() will be emitted 
for you when you skip creating that widget window.


But there's an API for windowless apps where you can receive a control 
signal, e.g. Ctrl-C was pressed or someone (like the Task Manager) is 
shutting down the app, more here: 
https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler 
and the callback: 
https://docs.microsoft.com/en-us/windows/console/handlerroutine


There's no support for that API in Qt but it's pretty easy to use. 
Here's an example, I created a vanilla Qt console app, and changed 
main.cpp to this:

-
#include 
#include 

BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
{
    switch (fdwCtrlType)
    {
    case CTRL_CLOSE_EVENT:
 ::OutputDebugStringA("Ctrl-Close event"); // catch taskkill or 
Task Manager End task

    return TRUE;

    default:
    return FALSE;
    }
}

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

    SetConsoleCtrlHandler(CtrlHandler, TRUE);

    return app.exec();
}
-
Note: I'm using OutputDebugString and DbgView.exe to view the output, 
qDebug() output has a tendency to disappear when you test with "End 
task" from TaskManager.


Note 2: this API is very flakey if you try it from a GUI-built .exe, for 
Qt apps I mean built with "QT += core gui etc" in the .pro file, and use 
of QApplication in main.cpp. Instead you need to build your app like a 
Qt console app, "QT -= gui" and CONFIG += console, and use 
QCoreApplication in main.cpp, like in my example above.


Rgrds Henry

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

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

[Henry Skoglund]

Hmm perhaps one way forward is to move some COM-related code to a new 
thread (which is then untarnished by any prior CoInitialize(xxx), either 
your QNetworkAccessManager instance or the code somewhere in your 
HEADER/SOURCES that causes the crash (in concert with 5.14.1's 
QNetworkAccessManager).


On 2020-02-06 11:35, maitai wrote:

Good idea, and I just tried. Unfortunately it still crashes...

Philippe.

Le 06-02-2020 11:21, Henry Skoglund a écrit :

Hi, also since constructing a QNetworkAccessManager() does a
CoInitialize(nullptr), have you tried doing a CoUninitialize() just
before, e.g;
...
QApplication app(argc, argv);
CoUninitialize();
QNetworkAccessManager *inet = new QNetworkAccessManager();
delete inet;
...

On 2020-02-06 08:02, coroberti . wrote:
Have you tried to comment out cleanup of reply objects 
(QNetworkReply) ?



On Thu, Feb 6, 2020 at 8:49 AM maitai  wrote:
I've checked it already, and anyway a QFileDialog is a QWidget and 
as such cannot be created before QApplication (that's what it said 
when I tried).


Philippe




Le 05-02-2020 21:20, Henry Skoglund a écrit :

Hi, maybe you already checked this, but if you have any big wheels 
like a QFileDialog declared static, their ctors most likely will 
run before main(), i.e. some COM/networking activity could occur 
before main() kicks in.


On 2020-02-05 21:10, maitai wrote:

As I said, I now have doubts it comes from COM threading...

I have built a small app with nothing inside, with the same .pro 
file exactly (qt modules, libs, etc, in the same order). The only 
difference is HEADERS and SOURCES of course, main.cpp being the 
same at least until it crashes. No problem in this small app 
(running in the same directory).


Again for those who missed it:

main.cpp:

 QNetworkAccessManager *inet = new QNetworkAccessManager();

 delete inet;

 QApplication app(argc, argv);

this works.

    QApplication app(argc, argv);

    QNetworkAccessManager *inet = new QNetworkAccessManager();

 delete inet;

this crashes on new in our app, not in a sample without HEADERS and 
SOURCES.


I cannot understand that, certainly there is something obvious I am 
missing.


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

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

[Henry Skoglund]

Hi, also since constructing a QNetworkAccessManager() does a 
CoInitialize(nullptr), have you tried doing a CoUninitialize() just 
before, e.g;

...
QApplication app(argc, argv);
CoUninitialize();
QNetworkAccessManager *inet = new QNetworkAccessManager();
delete inet;
...

On 2020-02-06 08:02, coroberti . wrote:

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


On Thu, Feb 6, 2020 at 8:49 AM maitai  wrote:

I've checked it already, and anyway a QFileDialog is a QWidget and as such 
cannot be created before QApplication (that's what it said when I tried).

Philippe




Le 05-02-2020 21:20, Henry Skoglund a écrit :

Hi, maybe you already checked this, but if you have any big wheels like a 
QFileDialog declared static, their ctors most likely will run before main(), 
i.e. some COM/networking activity could occur before main() kicks in.

On 2020-02-05 21:10, maitai wrote:

As I said, I now have doubts it comes from COM threading...

I have built a small app with nothing inside, with the same .pro file exactly 
(qt modules, libs, etc, in the same order). The only difference is HEADERS and 
SOURCES of course, main.cpp being the same at least until it crashes. No 
problem in this small app (running in the same directory).

Again for those who missed it:

main.cpp:

 QNetworkAccessManager *inet = new QNetworkAccessManager();

 delete inet;

 QApplication app(argc, argv);

this works.

QApplication app(argc, argv);

QNetworkAccessManager *inet = new QNetworkAccessManager();

 delete inet;

this crashes on new in our app, not in a sample without HEADERS and SOURCES.

I cannot understand that, certainly there is something obvious I am missing.

Philippe Lelong.


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

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

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


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

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

[Henry Skoglund]

Hi, maybe you already checked this, but if you have any big wheels like 
a QFileDialog declared static, their ctors most likely will run before 
main(), i.e. some COM/networking activity could occur before main() 
kicks in.


On 2020-02-05 21:10, maitai wrote:


As I said, I now have doubts it comes from COM threading...

I have built a small app with nothing inside, with the same .pro file 
exactly (qt modules, libs, etc, in the same order). The only 
difference is HEADERS and SOURCES of course, main.cpp being the same 
at least until it crashes. No problem in this small app (running in 
the same directory).


Again for those who missed it:

main.cpp:

QNetworkAccessManager*inet=newQNetworkAccessManager();
deleteinet;
QApplicationapp(argc,argv);
this works.
QApplicationapp(argc,argv);
QNetworkAccessManager*inet=newQNetworkAccessManager();
deleteinet;
this crashes on new in our app, not in a sample without HEADERS and SOURCES.

I cannot understand that, certainly there is something obvious I am missing.

Philippe Lelong.

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

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

[Henry Skoglund]

On 2020-02-05 16:32, maitai wrote:


Hi Rainer,

Unfortunately your suggestion didn't work

I have added in my pro file:

win32:QMAKE_LFLAGS+=/CLRTHREADATTRIBUTE:MTA
and I can see the option in the link command (I also tried the 2 other 
possibilities STA and NONE of course), but that does not fix anything.

My feeling is that it does not come fromCoInitializeEx() finally, because anyway in regular builds we are 
calling it at the very beginning of main, before creating QApplication 
or QNetworkManager, so the threading model should be already determined.


Hi, I've seen similar discussions re. COM threading model and Qt, mostly 
though they are about QFileDialog and not QNetworkManager, anyways one 
solution seems to be to call CoUninitialize when switching the threading 
model, more for example here: 
https://stackoverflow.com/questions/46581081/qt-qfiledialog-create-unknown-com-object-and-security


P.S. Also that linker switch /CLRTHREADATTRIBUTE:MTA isn't that mostly 
for .NET programs?


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

Re: [Interest] The Mobile Agenda?

[Henry Skoglund]

On 2020-01-06 08:49, Maurice Kalinowski wrote:
There are still quite many apps out there relying on OpenGL and hence 
even though deprecated, any additional step would be too risky IMO.

Having said that, you might have missed Laszlo's blog post about QtRhi, which 
will remove this (potential) problem by directly talking via different 
backends. Here's a link to his second blog post, I also recommend the first one 
as an entry read:
https://www.qt.io/blog/qt-quick-on-vulkan-metal-and-direct3d-part-2

Maurice

Agreed that Apple will most likely not pull the plug on OpenGL anytime 
soon (perhaps iOS16?), and thank you for that link. Now I am less 
worried, looking forward to Qt using Metal on iOS!


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

Re: [Interest] The Mobile Agenda?

[Henry Skoglund]

Hi, I'm on my first Qt iPhone app and I also worry about the future, for 
example, seems Qt uses OpenGL on the iPhone (i.e. 
QPlatformOpenGLContext) but Apple deprecated OpenGL 2 years ago in iOS12 
https://asciiwwdc.com/2019/sessions/611


If this is true then what happens if Apple disallows creating a 
CAEAGLLayer in iOS14 or iOS15?


Rgrds Henry

On 2020-01-05 16:12, Nelson, Michael wrote:

Jason, thanks for making these great points focused on missing features. Let's 
also not forget mobile specific bugs that sit unaddressed.

Mike

-Original Message-
From: Interest  On Behalf Of Jason H
Sent: Saturday, January 4, 2020 3:49 PM
To: Lars Knoll ; interestqt-project.org 

Subject: [Interest] The Mobile Agenda?

So it looks like the QtWS 2019 videos are up on YouTube.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DYmwAeS-5FojPA=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=udWwVeDC5d8x9i-GGrsUlyzaDh_8l_874S9CaY6DA3g=kVDYbsUThHDxyV5SM35vedYZIUsyXduaRGqMScK30PM=
  "Qt 6 will bring massive improvements to QML and 3D development"

At time 53:40 Lars is asked a question about mobile, and answers "We will continue 
to support them. Was that the answer you were looking for? (giggles)" - Actually, no 
it is not.
At 57:00 Lars takes another question about mobile, and responds with a hesitant "Um, 
yes..." and continues" We have a lot of ideas... want to make sure Qt is working nicely 
on mobile.. things have been moving quickly... have to catch up there".
Actually the QA segment ended up being bookended by Mobile questions.

Well I'm glad to hear Lars admit that there is catching up to do, but I take 
issue with the claim that things have been moving quickly. The majority of 
mobile features that I and others are requesting are not bleeding edge, it is 
basic things, like
* NFC on iOS (Available iOS 11, September 19, 2017, 2+y)
* Media keys (volume, play/pause, etc., Since before Qt 5.2)
* Push Notifications (Since before Qt 5.2)
* Display control (Since before Qt 5.2)
* Battery Info (Since before Qt 5.2)
* Vibration/haptics control (Since before Qt 5.2)
* DeviceInfo (model, OS version, hardware enumeration, etc)
* Biometric authentication
* Datatype conversion (Java and ObjC to Qt types and back)

Many of these are not that hard, the code is known and settled, I've posted 
code where I think it helps, but the issue is for every app I make, I have the 
friction of adding 8 of my own classes to every project... which is composed of 
bout 8 files, and the tome doctoring manifests and plists). The expense of 
these classes is over, but these classes that took me days to create and test 
in environments where I am not expert. I hack at native Objective C and 
Android, and those experiences are troubling. I don't mind for some really 
weird feature, but what is being asked for by me and the community is pretty 
basic stuff. Objective-C code examples are becoming rarer as Swift takes over.  
The experience of using Eclipse or XCode is another problem itself, as the Qt 
integration is less than ideal. (Even ignoring having to use 2 IDEs to code.)

Mobile (in general) really hasn't advanced in any way that Qt needs to react 
to, there's a lot of new biometrics stuff, but really we only need a way to 
integrate for authentication. (Fingerprint, FaceID, etc) Also the only thing I 
know Android has changed lately is the permission requests, but Qt already has 
a helper for that.

A lot of these needs are tracked at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugreports.qt.io_browse_QTBUG-2D74049=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=udWwVeDC5d8x9i-GGrsUlyzaDh_8l_874S9CaY6DA3g=Z8qkrPvJrbw_WWF92VSjRB54ItmnT7UUxrEeriWJKXY=
  which was opened 11 months ago, but there has not been *any* activity, at least visibly.

However I have had several mobile support issues serviced and closed, but I 
also have a commercial support agreement.

If you are interested in my current code (that I recently refactored to be more 
granular than a monolithic catch-all shim that I had before) I can see about 
getting it shared to Qt, at least as inspiration (I don't use D-ptrs and am not 
subject to binary compatibility constraints). I think the most complicated bit 
on anyone's list is the Push Notifications, as the two platforms have different 
message structures.

So my question to Lars is:
Lars, can we get a better (in terms of: better stated, more attention, schedule 
clarity) commitment to mobile in 2020? I think with not a lot of effort we 
could get everything of what we are asking for, and then we can get out of your 
hair.



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

Re: [Interest] cpputest with QTest output issue on embedded target console

[Henry Skoglund]

On 2019-12-08 19:19, Thiago Macieira wrote:

On Sunday, 8 December 2019 00:35:04 PST Ramakanth Kesireddy wrote:

   Something is very wrong. Check this assertion and fix:0: error:
Deallocating non-allocated memory
allocated at file:  line: 0 size: 0 type: unknown
deallocated at file:  line: 0 type: delete

Main to run qt unit tests looks like below:
int main(int argc, char *argv[])
{
 qputenv("QT_LOGGING_TO_CONSOLE","1");
 QApplication app( argc, argv );
 CommandLineTestRunner::RunAllTests(argc, argv);
 return 0;
}

This message didn't come from Qt. Your other unit test tool caused it. Use it
to debugu what happened.

Yes, I remember seeing that output before, it's an old bug/feature of 
cpputest

more here: https://github.com/cpputest/cpputest/issues/37

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

Re: [Interest] Tricks to improve moc performance?

[Henry Skoglund]

On 2019-12-06 02:09, Adam Light wrote:
We have several machines running Windows 10 that are quite powerful 
(eg. 8 or 16 core (16 or 32 thread) processors, lots of RAM, NVMe SSD 
storage). However, since upgrading to Windows 1903, we have noticed 
that sometimes the compile time of our large Qt 5.12 based application 
increases dramatically.


As an example, on one 16 core/32 thread machine, a debug build can 
take as little as 4 minutes. However it sometimes takes 18 minutes. 
This is for the exact same code, compiler, settings, etc. I can 
literally do a full build that takes 4 minutes, do something, delete 
the build directory and rebuild and now it takes 16 minutes. The "do 
something" may be going to lunch or making a trivial change in the 
code. Otherwise the state of the machine is the same (no other 
heavyweight processes running, etc.)


We see this behavior both when using Qt Creator 4.10.2 to do the build 
(using jom.exe) and also when done outside of Creator with calls to 
qmake and then jom. All files involved in anything I mention here are 
on and/or written to the local SSD. I see these issues with no 
antivirus running, no backup, etc.



...
Does anyone else have any ideas of how we could change our build to 
improve moc performance when Windows decides to be "slow"? Like, for 
example, is there any way to have the moc calls run with only a few 
moc processes running at once but have the rest of the build done with 
all threads running. I'm pretty sure that the OS slowdown has 
something to do with thread contention of some sort.


If anyone thinks they have run into this situation or is intimately 
familiar with Windows minifilter drivers, I'm happy to share the 
details behind why I think they are involved here.


Thanks for any ideas
Adam



Hi, just guessing, but it could be network related. For a quick test, 
when you experience that slowdown, try pulling out the network cable 
from the PC and see if the build time changes.


For a more elaborate test, consider moving your Windows build PC into 
the virtual realm, say like this: Use Disk2vhd 
https://docs.microsoft.com/en-us/sysinternals/downloads/disk2vhd to 
migrate your C: into a .vhd file. Install Ubuntu 19.10 on the PC and 
VirtualBox (or VMWare Workstation player, also free). Then load up the 
.vhd file into Ubuntu and, in my case, that combo (a virtual Windows 
running inside Ubuntu) builds faster than my vanilla Windows 10 ever did.


This year when 1903 arrived I saw some changes as well, the boot/startup 
time is better but I felt it was slower in general than 1809. So I dug 
up an old Windows 7 DVD and installed it into VMWare and reinstalled Qt 
on that Windows 7. Upgrading from Windows 10 to Windows 7 made jom happy 
again. So while it's impossible today to find a new PC that you can 
install Windows 7 on, it is still very much possible on VirtualBox or 
VMWare. Finally, since Microsoft will cease support of Windows 7 next 
month, make sure *never* to browse the internet or do your email from 
Windows 7, always use Ubuntu.


Rgrds Henry

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

Re: [Interest] Write QSettings to a QString in INI format

[Henry Skoglund]

On 2019-10-26 17:31, Murphy, Sean wrote:

Because QSettings has the file locked. Make sure settings goes out of
scope before you re-open the file.


Granted, it's complex with the locking code, but underneath it all you have
this hidden gem writeIniFile(), which takes a QIODevice and the map (you
know, the function with those hardwired [General] and [General%] strings).

Suggestion: you have this nice extension/plugin call
QSettings::registerFormat(), which takes a readFunc and a writeFunc ptr.
If that writeIniFile() could be exposed as a public writeFunc ptr (yes it has 
the
same function signature) then you could have users bypass the locking stuff,
by requiring them to register a new format (say with the extension "buffer"
for a QBuffer) but allowing them to reuse the existing writeIniFile() as their
own writeFunc (and say a QBuffer as the QIODevice).
That way you could access the streaming functionality of QSettings without
involving the file system.

Is the suggestion to me, or to the Qt development team? Because even if I
somehow expose the writeIniFile() function so that I can use it, the only
applicable QSettings constructor that allows me to specify a registered format
is this one:
 QSettings(const QString , QSettings::Format format, QObject 
*parent = nullptr)
And the behavior of that constructor is that it opens an actual file on the
filesystem with "fileName" (use an existing file if the file already existed 
before
this call, otherwise creating a file with that name if it didn't already 
exist), then
sets the QIODevice to point at the file, and then uses your registered format's
function pointers to handle the reading and writing of it. There does not appear
to be any way for me to point the created QSettings object at my QBuffer, even
if I got access to the writeIniFile(), correct? Or am I missing something?

A suggestion for development, to add these 2 static public members to 
QSettings:

QSettings::ReadFunc getReadFunc(QSettings::Format format);
QSettings::WriteFunc getWriteFunc(QSettings::Format format);

never mind about the ReadFunc functionality right now, let's look at the 
getWriteFunc, say you could use it to obtain a function pointer to that 
hidden gem I wrote about earlier, writeIniFile():


QSettings::ReadFunc myReadFunc; // only a dummy for now

QString s;
QBuffer b();
bool myWriteFunc(QIODevice , const QSettings::SettingsMap )
{
// ignore the QIODevice QSettings gives us, instead replace it with our 
QBuffer;

    bool bOk = QSettings::getWriteFunc(QSettings::IniFormat)(b,map);
}

// register
QSettings::Format myFormat = 
QSettings::registerFormat("buffer",myReadFunc,myWriteFunc);


// and then start the party by:
{
    auto mySettings = QSettings("tempfile.buffer",myFormat);
    settings.setValue("string", "hello");
    settings.setValue("int", 2);
}
// with a bit of luck the b.buffer() should now contain 
"[General]\nstring=Hello\nint=2"


So you're right that there's no way to avoid dipping your toes into the 
file system, but by short-circuiting the writes the resulting file would 
always be empty and the QBuffer b would be the lucky winner.


Rgrds Henry

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

Re: [Interest] Write QSettings to a QString in INI format

[Henry Skoglund]

On 2019-10-26 11:43, Konrad Rosenbaum wrote:

Hi,

On 10/24/19 5:53 PM, Murphy, Sean wrote:
I'd like to be able to have QSettings write out my settings to an INI 
file format, but I'd like to avoid writing it to an actual file, 
instead just writing it to "something" in memory (for example, a 
QString, QByteArray, QBuffer, etc.).


That's because QSettings is rather complex underneath - it handles 
stuff like multiple instances accessing the same file at the same 
time, hierarchies of settings-files (e.g. system level and user 
level), etc. If you handed in a QIODevice then QSettings could not be 
sure what the state of the underlying IO-Object is and whether it is 
safe to access it.
So I if all the above is correct, and there is no way to write an INI 
formatted string to memory, and given the fact that I really don't 
want a file in the first place, I decided to look at writing the 
settings out to a QTemporaryFile, then just reading that data back in 
as a string, and then let the QTemporaryFile go out of scope and 
clean itself up. But according to the following test code, QSettings 
does not seem to play nicely with QTemporaryFile:

This is basically the way to go.


void MainWindow::writeSettings()
{
// comment/uncomment the *define* below to switch implementations
#define USE_QTEMPORARY_FILE

#ifdef USE_QTEMPORARY_FILE
 // using a QTemporaryFile doesn't seem to work
 QTemporaryFile tempFile;
 bool ok = tempFile.open();
#else
 // if instead you use a regular QFile, it works
 QFile tempFile("tempFile.ini");
 bool ok = tempFile.open(QIODevice::ReadWrite);
#endif

 if(ok)
 {
 qDebug() << "Opened" << tempFile.fileName();
 } else {
 qDebug() << "Unable to open" << tempFile.fileName();
 }
Call tempFile.fileName() before you call close()! (But close() before 
you instantiate QSettings.)

 tempFile.close();

 QSettings settings(tempFile.fileName(), QSettings::IniFormat);
 settings.setValue("string", "hello");
 settings.setValue("int", 2);

 settings.sync();
 // using QTemporaryFile always produces an AccessError here,
Because QSettings has the file locked. Make sure settings goes out of 
scope before you re-open the file.


Granted, it's complex with the locking code, but underneath it all you 
have this hidden gem writeIniFile(), which takes a QIODevice and the map 
(you know, the function with those hardwired [General] and [General%] 
strings).


Suggestion: you have this nice extension/plugin call 
QSettings::registerFormat(), which takes a readFunc and a writeFunc ptr. 
If that writeIniFile() could be exposed as a public writeFunc ptr (yes 
it has the same function signature) then you could have users bypass the 
locking stuff, by requiring them to register a new format (say with the 
extension "buffer" for a QBuffer) but allowing them to reuse the 
existing writeIniFile() as their own writeFunc (and say a QBuffer as the 
QIODevice).
That way you could access the streaming functionality of QSettings 
without involving the file system.


Rgrds Henry

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

Re: [Interest] TLS/SSL XML encryption security

[Henry Skoglund]

Yes, I also know about the lizardmen from Phobos who can crack SSL/TLS 
keys instantly.
If you can show some code all this would be much more credible. After 
all, this is a Qt mailing list, not a science fiction one.


Rgrds Henry


On 2019-10-07 16:06, Roland Hughes wrote:


On 10/7/19 5:00 AM, Thiago Macieira wrote:
You do realise that's not how modern encryption works, right? You do 
realise
that SSL/TLS rekeys periodically to avoid even a compromised key from 
going
further? That's what the "data limit for all ciphersuits" means: 
rekey after a

while.

yeah.
You're apparently willfully ignoring the fact that the same cleartext 
will not
result in the same ciphertext when repeated in the transmission, even 
between

two rekey events.


No. We are working from two completely different premises. It appears 
to me your premise is they have to be able to decrypt 100% of the 
packets 100% of the time. That's not the premise here.


The premise here is they don't need it all to work today. They just 
need to know that a Merchant account service receives XML/JSON and 
responds in kind. The transaction is the same for a phone app, Web 
site, even when you are standing at that mom & pop retailer physically 
using your card. They (whoever they are) sniff packets to/from the IP 
addresses of the service logging them to disk drives.


The dispatch service hands 100-1000 key combinations out at a time to 
worker computers generating fingerprints for the database. These 
computers could be a botnet, leased from a hosting service or machines 
they own. The receiver service stores the key results in the database.


A credit card processing service of sufficient size will go through a 
massive number of salts and keys, especially with the approaching 
Holiday shopping season. 1280 bytes "should" be more than enough to 
contain a credit card authorization request so this scenario is only 
interested in fast cracking a single packet. Yes, the CC number and 
some other information may well have additional obfuscation but that 
will also be a mechanical process.


Periodically a batch job wakes up and runs the sniffed packets against 
the database looking for matching fingerprints. When it fast cracks 
one it moves it to a different drive/raid array, storage area for the 
next step. This process goes in steps until they have full CC 
information with a transaction approval, weeding out the declined cards.


When the sniffed packet storage falls below some threshold the sniffer 
portion is reactivated to retrieve more packets.


This entire time workers are adding more and more entries to the 
fingerprint database.


These people don't need them all. They are patient. This process is 
automated. They might even configure it to send an email when another 
100 or 1000 valid CCs so they can either sell them on the Dark Web or 
send them through the "buying agent" network.


Yeah, "buying agent" network might need a bit of explanation. Some of 
you may have seen those "work from home" scams where they want a 
"shipping consolidation" person to receive items and repackage them 
into bulk packs for overseas (or wherever) shipping. They want a fall 
person to receive the higher end merchandise which they then bulk ship 
to someone who will sell it on eBay/Amazon/etc.


The CC companies constantly scan for "unusual activity" and call you 
when your card has been compromised. This works when the individuals 
are working with limited information. They have the CC information, 
but they don't have the "where you shop" information. The ones which 
have the information about where you routinely use the card can have a 
better informed "buying agent" network and slow bleed the card without 
tripping the fraud alert systems. If you routinely use said card at 
say, Walmart, 2-3 times per week for purchases of $100-$500 they can 
make one more purchase per week in that price range until you are 
maxed out or start matching up charges with receipts.


The people I get asked to think about are playing a long game. They 
aren't looking to send a crew to Chicago to take out $100 cash 
advances on a million cards bought on the Dark Web or do something 
like this crew did:


https://www.mcall.com/news/watchdog/mc-counterfeit-credit-cards-identity-theft-watchdog-20160625-column.html 



Or the guy who just got 8 years for running such a ring in Las Vegas. 
That's the most recent one turning up in a quick search.


Maybe they are looking to do just that, but are looking for more 
information?


At any rate, the "no-breach" scenario is being seriously looked at. 
Yes, the Salt will change with every packet and the key might well 
change with every packet but these players are only looking to crack a 
subset of packets. Most organizations won't have the infrastructure to 
utilize a billion compromised credit cards. They can handle a few 
hundred to a few thousand per month.


In short, they don't need _everything_. They just need enough to get 

Re: [Interest] Finish QLineEdit editing when user clicks anywhere outside the QLineEdit

[Henry Skoglund]

Hmm, about that extra step, to remember the filter stuff, since you 
already have a custom line edit class, why not embed the MouseFilter 
class inside it?
I mean, the filter does not have to reside in MainWindow, it needs only 
the qApp pointer, so you could wire it up in your custom line edit's 
ctor instead. Thus making it an integrated part of your custom class :-)



On 2019-08-13 21:55, Murphy, Sean wrote:

Hi, had a similar problem, couldn't find any other solution than using an
event filter, but it turned out being not so bad, made a small class:

In my MainWindow I have an instance of that class, and in MainWindows's
ctor I initialize it:

MouseFilter mf;
...
mf.setWidget(ui->lineEdit);
qApp->installEventFilter();

Thank you. I was going down this path as well, that I might have to do it as an
event filter installed somewhere up the hierarchy, instead of just being able
to do it within a custom class that inherits from QLineEdit. So far I haven't
found a way to do that.

And you're right, it's not so bad to do it via an event filter, but it's just 
one
extra step I have to remember to do, every time I want to re-use this
custom line edit, either within this application, or in other applications.

Sean


This message has been scanned for malware by Forcepoint. www.forcepoint.com
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] Finish QLineEdit editing when user clicks anywhere outside the QLineEdit

[Henry Skoglund]

Hi, had a similar problem, couldn't find any other solution than using 
an event filter, but it turned out being not so bad, made a small class:


#include "qevent.h"

class MouseFilter : public QObject
{
    Q_OBJECT

    QWidget* pW;  // ptr to widget to check for inside/outside mouse clicks

    bool eventFilter(QObject* pObj, QEvent* pEvent)
    {
    if (QEvent::MouseButtonPress == pEvent->type())
    {
    QMouseEvent* pME = static_cast(pEvent);

    QRect 
r(pW->mapToGlobal(QPoint(0,0)),pW->mapToGlobal(QPoint(pW->width(),pW->height(;

    bool bClickOutside = !r.contains(pME->globalPos());
    qDebug << bClickOutside;
    }

    return QObject::eventFilter(pObj,pEvent);
    }

public:
    void setWidget(QWidget* pW)
    {
    this->pW = pW;
    }
};

In my MainWindow I have an instance of that class, and in MainWindows's 
ctor I initialize it:


MouseFilter mf;
...
mf.setWidget(ui->lineEdit);
qApp->installEventFilter();
...


Rgrds Henry


On 2019-08-13 16:47, Murphy, Sean wrote:

I'm trying to create a custom QLineEdit where while editing, the user can click 
anywhere *outside* the QLineEdit to finish editing.

The default QLineEdit behavior appears to be that once the user has clicked 
inside the QLineEdit and begins editing the text, if the user then clicks on 
some other widget that *will* accept focus via a mouse click, the editing 
finished signal is emitted and the cursor/focus moves to whatever they clicked 
on. What I'm struggling with is that if the user clicks on something that 
*doesn't* normally accept focus via a mouse click, like any whitespace in my 
app, the cursor stays within the QLineEdit and editing is still active.

I thought maybe I could use focusOutEvent(), but in the case where the user 
clicks on whitespace, the QLineEdit doesn't receive a focusOutEvent(). So that 
doesn't appear to be useful, unless I'm missing something.

Ideally I want a solution that is completely contained within my custom 
QLineEdit-inherited class - with all the other widgets unaware that this 
behavior is happening. The only solution I'm finding via Google is doing things 
like installing event filters or setting the focus policy on other widgets to 
then force the QLineEdit to give up focus or end editing.

Sean



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

Re: [Interest] Strange unexplainable RCC error

[Henry Skoglund]

On 2019-05-26 21:32, Robert Heller wrote:

I am trying to bundle a directory of files generated by Doxygen into a Qt
resource file, but I am getting a strange error from rcc.  Here is the
transscript:

Script started on Sun 26 May 2019 03:09:18 PM EDT
gollum.deepsoft.com% less -X release/htmldoc.qrc

 
 release/html/open.png
 release/html/doxygen.png
 release/html/tab_h.png
 release/html/files.html
 release/html/graph_legend.md5
 release/html/bc_s.png
 release/html/graph_legend.dot
 release/html/doxygen.css
 release/html/jquery.js
 release/html/closed.png
 release/html/index.html
 release/html/tab_a.png
 release/html/pages.html
 release/html/tab_b.png
 release/html/graph_legend.html
 release/html/nav_f.png
 release/html/tab_s.png
 release/html/nav_h.png
 release/html/Copying.html
 release/html/COPYING_8h_source.html
 release/html/tabs.css
 

gollum.deepsoft.com% /usr/lib64/qt5/bin/rcc --verbose -name htmldoc 
release/html doc.qrc -o release/qrc_htmldoc.cpp

Qt resource compiler
Processing 1 files [0]
Interpreting release/htmldoc.qrc
RCC: Error in 'release/htmldoc.qrc': Cannot find file 'release/html/open.png'
gollum.deepsoft.com% ls -l release/html/

total 196
-rw-r--r--. 1 heller users   677 May 26 14:22 bc_s.png
-rw-r--r--. 1 heller users   126 May 26 14:22 closed.png
-rw-r--r--. 1 heller users  3964 May 26 14:22 COPYING_8h_source.html
-rw-r--r--. 1 heller users 19435 May 26 14:22 Copying.html
-rw-r--r--. 1 heller users 12350 May 26 14:22 doxygen.css
-rw-r--r--. 1 heller users  3942 May 26 14:22 doxygen.png
-rw-r--r--. 1 heller users  1406 May 26 14:22 files.html
-rw-r--r--. 1 heller users  2226 May 26 14:22 graph_legend.dot
-rw-r--r--. 1 heller users  4653 May 26 14:22 graph_legend.html
-rw-r--r--. 1 heller users32 May 18 23:47 graph_legend.md5
-rw-r--r--. 1 heller users  1506 May 26 14:22 index.html
-rw-r--r--. 1 heller users 84882 May 26 14:22 jquery.js
-rw-r--r--. 1 heller users   159 May 26 14:22 nav_f.png
-rw-r--r--. 1 heller users97 May 26 14:22 nav_h.png
-rw-r--r--. 1 heller users   118 May 26 14:22 open.png
-rw-r--r--. 1 heller users  1344 May 26 14:22 pages.html
-rw-r--r--. 1 heller users   140 May 26 14:22 tab_a.png
-rw-r--r--. 1 heller users   178 May 26 14:22 tab_b.png
-rw-r--r--. 1 heller users   192 May 26 14:22 tab_h.png
-rw-r--r--. 1 heller users  1095 May 26 14:22 tabs.css
-rw-r--r--. 1 heller users   189 May 26 14:22 tab_s.png
gollum.deepsoft.com% exit

Script done on Sun 26 May 2019 03:10:06 PM EDT

I am on a Linux machine (CentOS 6) using Qt 5.6.1 (from the EPel repository):
gollum.deepsoft.com% /usr/lib64/qt5/bin/rcc -v
rcc 5.6.1

rcc has no problem processing other qrc files.

Why us rcc claiming it cannot find a file that all of my FS tools say is
there?



Hi, shouldn't the entries in your .qrc file look like:

...
html/open.png
html/doxygen.png
html/tab_h.png
html/files.html
...

because that .qrc file is in the subdirectory "release"?

(Or the other way around, if you want to keep the original .qrc file, 
create another "release" subdirectory below the first one and move the 
files down to that, i.e.

ls -l release/release/html

total 196
> -rw-r--r--. 1 heller users   677 May 26 14:22 bc_s.png
> -rw-r--r--. 1 heller users   126 May 26 14:22 closed.png
> -rw-r--r--. 1 heller users  3964 May 26 14:22 COPYING_8h_source.html
...

Rgrds Henry

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

Re: [Interest] QFile/QDir: force move mode only?

[Henry Skoglund]

On 2019-05-11 21:13, Alexander Dyagilev wrote:

Hello,

QFile/QDir rename function copies file in the case it's not possible to 
just move it.


Is there a  way to learn in advance what type of operation will occur?

Let's suppose I have 10GB file. In case of copy, I would definitely like 
to use my own copy function and show UI with the progress of the operation.


And of course I do not want to use my copy function always if the fast 
move is available.




Hi, unless you're changing chars in the filename to uppercase/lowercase, 
where I know QFile tries to help on case-insensitive filesystems, 
QFile/QDir is pretty much at the mercy of the OS, i.e. if the OS refuses 
the renaming (for example on NTFS when you try to rename across volumes) 
then QFile dutifully copies the file instead.


So I think this is not a Qt question and you need to drop down to the OS 
level, for example on Windows you can call ::MoveFileEx() with the 3rd 
param = 0, then the call will err out if a copy is needed.

(Note: I haven't tested this myself, just relying on Google :-)

Rgrds Henry

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

[Interest] My first 5 years with Qt and 2 suggestions

[Henry Skoglund]

Hi, 5 years ago I started with Qt, it's been a very nice ride, thank 
you! Looking forward to the next 5. Got 2 suggestions:



1) Make Qt more easily accessable for first timers:

Why not introduce a Qt Starter Pack?

I'm thinking of an *extremely* simplified installation tool. For 
Windows, it could be Qt LTS version bundled with the 32-bit MinGW compiler.


No login, no selection of kits and no selection of a directory where to 
install (instead hardwired to C:\Qt). Just one big button: "Install".


Uninstall is done through the control panel. No updates possible, 
uninstall/download/reinstall only.



2) Improved Qt DLL morphology: for a given DLL, today we have very 
coarse naming schemes, it's either Qt4Core.dll, Qt5Core.dll or 
Qt6Core.dll (and similar namings on the other platforms).


On the Qt forums I see questions, they have the MinGW version installed, 
and instead of windeployqt, for deployment they have manually copied the 
DLLs from the QtCreator bin directory --> DLL hell.


Or they have a Qt program like Krita installed on their C:, and some 
PATH setting causes Qt DLLs to clash with their Qt installation or 
deployment --> DLL hell.


Or they have copied Qt5Core.dll with wrong bitness, 64 instead of 32 etc.

For that last syndrome, I remember from my Visual Basic days, there were 
16-bit and 32-bit versions, but Microsoft had different DLL names then, 
either VBRUN40016.DLL or VBRUN40032.DLL. (Today for example 
vcruntime140.dll has the same name regardless of bitness, 32-bit version 
is in C:\Windows\SysWOW64 and 64-bit version is in C:\Windows\System32, 
if this seems logical you need to change medication.)


So my suggestion is, let's reverse this trend, introduce a much more 
fine-grained naming scheme, examples:


Qt5Core.dll for Qt 5.12.3 MSVC2017   32-bit --> QtCore51203MS1732.dll
Qt5Core.dll for Qt 5.12.3 MSVC2017   64-bit --> QtCore51203MS1764.dll
Qt5Core.dll for Qt 5.12.3 MinGW7.3.0 32 bit --> QtCore51203GW7332.dll
Qt5Core.dll for Qt 5.12.3 MinGW7.3.0 64 bit --> QtCore51203GW7364.dll

Qt5Gui.dll for Qt 5.12.3 MSVC2017   32-bit --> QtGui51203MS1732.dll
Qt5Gui.dll for Qt 5.12.3 MSVC2017   64-bit --> QtGui51203MS1764.dll
Qt5Gui.dll for Qt 5.12.3 MinGW7.3.0 32 bit --> QtGui51203GW7332.dll
Qt5Gui.dll for Qt 5.12.3 MinGW7.3.0 64 bit --> QtGui51203GW7364.dll

and so on.

This naming scheme would eliminate lots of DLL hells occurring today in 
Windows, and would be much more tolerant/allowing to a Windows system 
having multiple Qt installations of different versions.


Rgrds Henry

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

Re: [Interest] vs. Flutter

[Henry Skoglund]

Hi, totally agree C/C++ will outlive many of these new languages.
It's also most likely Javascript will wane off sooner rather than later 
due to WebAssembly steadily improving.


Been working/programming for 43 years now, while I fondly remember 
Pascal on CP/M from my youth (before C++ was invented), once I switched 
to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home".


Also you could say that good and stable ecosystems for a language takes 
decades to arrive, at least one generation of programmers has to come 
and go I think. So the peak of C++ will be in the future :-)


Rgrds Henry

On 2019-02-19 21:13, Christoph Feck wrote:

On 02/19/19 20:47, Jason H wrote:
What I've learned is that it's better to stand on the shoulders of 
giants than to rewrite the universe from scratch. I dream of a say 
where we can code things and everyone else regardless of platform can 
run it. I thought this was going to be .Net CLR, or Java VM, but 
corporate ownership initiatives derailed them (Much like the "You 
will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ 
runs all more platforms/processors. Linux has come a long way in terms 
of bringing all CPUs a usable software ecosystem. And this though 
rather obtuse is one reason to pick Qt - that it'll support any system 
that can run a C++ compiler. You don't technically need to use QML, 
you can keep going with C++.


Once upon a time a mother of two curious boys called me, asking me to 
teach them programming. They have no clue what language to start with, 
so I suggested C as a base, to later learn Python, C++, Java (or C#).

Then some "smart" student told one of the kids "JavaScript is da future
of da Internetz". I stopped teaching them after it was suggested to
stop the C course and swap it for a JavaScript course.

C/C++ will be relevant in the future. All other languages will come and
go (no pun intended).

Whether Qt will be relevant in the future lies in the hands of its
developers. Don't ruin it.

Christoph Feck


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

Re: [Interest] Issue using QSettings INI format on Windows

[Henry Skoglund]

On 2019-02-08 23:56, Murphy, Sean wrote:

Hi, just tested your example program in MSVC 2017 Qt 5.12.1 and it fails
as well.

But a simple fix is just to make sure that the QFile file isn't open at
the same time as you write out the settings to it.
I.e. in your example program, it suffices to move that first
file.close(); up to just before the "// write out via QSettings" comment
line is, then it runs flawlessly.

But perhaps that's not possible to keep those writes separate in time in
your "real" app that your porting?


Thanks for testing!

Yes, I discovered that issue as well, and then forgot to post a follow-up
here. Where I had trouble, and something I did differently in the real
app vs. the minimal example, is that the file I was trying to use to write
the settings to was a QTemporaryFile. I stumbled across the same fix you
did in the example, but that fix never seemed to work in my real app with a
QTemporaryFile. After testing, I believe that is because the QSettings
object is trying to open the associated settings file with write permissions,
and it isn't able to acquire them. In my example, it was because I already
had opened the file with write permissions (mistakenly thinking I needed
to do that before all the QSettings stuff). In my real app, I think that it
must be because QTemporaryFile holds a lock on the file so it can
remove it when the QTemporaryFile object goes out of scope, and
therefore the QSettings object gets an access error because the file is
already in use.

What I'm actually trying to accomplish is far more simple: I don't actually
want an INI file, I just want to get data that I've put into a QSettings object
written to a QString, in the INI file format. I couldn't see any other way to
do that than to write it out to a file, then read the file contents back into
a QString. So if you see a simpler solution for that, I'm open to suggestions!



Well there's always QSettings::registerFormat ( 
https://doc.qt.io/qt-5/qsettings.html#registerFormat )


Haven't tried it myself but it will give you a QSettings::SettingsMap 
which means you'll still have to serialize out it yourself to a QString, 
but at least you can get rid of the file i/o by ignoring those

QIODevices that QSettings hands over. /Rgrds Henry

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

Re: [Interest] Issue using QSettings INI format on Windows

[Henry Skoglund]

On 2019-02-08 14:46, Murphy, Sean wrote:

I'm porting an old application from Qt 5.3.2 to Qt 5.9.6 (yeah, I know, we're a 
lot behind...). I'm running into an issue where code we had that was writing 
out settings via the QSettings constructor that takes a file name doesn't work 
anymore. I've attached a fairly minimal example that shows this.

What I've found so far:
- this code works perfectly on Windows using Qt 5.3.2 (mingw 4.8.2)
- this code works perfectly on a Mac using Qt 5.9.6 (clang)
- this code fails on Windows using Qt 5.9.6 (mingw 5.3.0)

Anyone have any ideas?

Sean




Hi, just tested your example program in MSVC 2017 Qt 5.12.1 and it fails 
as well.


But a simple fix is just to make sure that the QFile file isn't open at 
the same time as you write out the settings to it.
I.e. in your example program, it suffices to move that first 
file.close(); up to just before the "// write out via QSettings" comment 
line is, then it runs flawlessly.


But perhaps that's not possible to keep those writes separate in time in 
your "real" app that your porting?


Rgrds Henry

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

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

[Henry Skoglund]

On 2019-01-17 11:52, Nuno Santos wrote:
I have tried to put everything that is relevant in a single image. What 
is crashing is the Qt Creator template for a Qt Quick App.


As you can see not even the first line of debug is printed. Maybe 
something was not configured correctly.


I can’t spot anything wrong…. Can you?



That error "Cannot retrieve debugging output" you should try to fix: try 
to close all other programs running, for example Visual Studio and 
DbgView. (It could be that some of your qDebug() statement actually runs 
but you're not seeing any output because of that error).


Rgrds Henry

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

Re: [Interest] need a QT 5.12.0 MinGW 32bit release for windows in all the upcoming QT versions

[Henry Skoglund]

On 2018-12-18 17:34, Frank Hemer wrote:

Indeed - working in medical IT this is the major issue for me.

Frank

On Tuesday, 18 December 2018 17:28:05 CET Thiago Macieira wrote:

On Tuesday, 18 December 2018 03:56:47 PST Kai Koehne wrote:

Anyhow, we don't want to maintain two different MinGW builds; there was
quite some popular demand for 64 bits (see e.g.
https://bugreports.qt.io/browse/QTBUG-35288), so we switched to 64 bit in
Qt 5.12. I don't see us switching back until there's clear evidence that
the majority would prefer 32 bit.


I think the point is not to switch, but to provide an additional build. I'm
going to guess the requestors' argument is going to be that they still need
to ship 32-bit applications for Windows, since they still have users with
32-bit Windows, despite running on a 64-bit CPU.




Also, if you look in 5.12's Maintenance Tool and the available 
components for Windows, MinGW has one (1) and UWP has six (6) choices.


Now about UWP. earlier this year Microsoft's Office Team ditched their 
UWP flavor of MS Office and now the Edge team has done the same (since 
Chromium will never be an UWP app). I bet you a beer with anyone having 
access to the download numbers of those 6 different UWP Qt 5.12 
components, that the # of downloads for them has steadily decreased all 
of this year. Most likely UWP is heading to the same place in the sky 
where Silverlight etc. are. So I mean if the # of component slots in 
Maintenance Tool is a limiting factor, consider tossing the 3 MSVC-2015 
UWP ones to make room for the MinGW 32-bit one.


Rgrds Henry

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

Re: [Interest] QDir::entry(Info)List on macos

[Henry Skoglund]

On 2018-11-15 17:07, Thiago Macieira wrote:

On Thursday, 15 November 2018 05:54:22 PST Manner Róbert wrote:

Hope it is useful for someone. To be honest, I always imagined that if
everyone would use UTF-8 life would be much better, now I'm unsure


Blame Apple for deciding to use an uncommon normalisation back in the day for
HFS. The HFS stores filenames in NFD, even if you type NFC and that's what you
do in Terminal.app. But APFS doesn't convert.

Anyway, this is an open bug that needs a fix. I can't fix it because I don't
have access to any Mac with APFS (my 2011 Mac Mini is running HFS).



Hi, couldn't resist looking into this bug (my 2012 MBP has 10.14 with APFS):

The problem I think is that the encodeName(decodeName(filename)) if 
statement in qfilesystemiterator_unix.cpp is lossy; the incoming 
direntries can be either encoded as NFC (e.g. files created in Terminal) 
or NFD (files created via a Qt App or Finder), but the 
Q_OS_DARWIN-flavored QFile::encodeName() function is hardwired to use 
NormalizationForm_D only, that's why the NFC types of direntries get 
tossed out :-(


So one solution could be to check for both NFC- and NFD-flavored 
direntries that matches, say something like:


bool QFileSystemIterator::advance(QFileSystemEntry , 
QFileSystemMetaData )

{
if (!dir)
return false;

for (;;) {
dirEntry = QT_READDIR(dir);

if (dirEntry) {
// process entries with correct UTF-8 names only
QString nfc = QFile::decodeName(dirEntry->d_name);  // (any 
NFDs are now converted to NFCs)


if ((nfc.normalized(QString::NormalizationForm_C).toUtf8() 
== dirEntry->d_name) ||
(nfc.normalized(QString::NormalizationForm_D).toUtf8() 
== dirEntry->d_name)) {
fileEntry = QFileSystemEntry(nativePath + 
QByteArray(dirEntry->d_name), QFileSystemEntry::FromNativePath());

metaData.fillFromDirEnt(*dirEntry);
return true;
}
} else {
break;
}
}

lastError = errno;
return false;
}

Note: this is written without any testing or compiling, just an idea!
Rgrds Henry

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

Re: [Interest] Q_ENUM doesn't work for private enums

[Henry Skoglund]

On 27/10/2018 03.07, Tom Isaacson wrote:

I'm using Qt 5.6 in Visual Studio 2017. I've got a class that looks like:
class tClass : public QObject
{
 Q_OBJECT

private:
 enum class eMode
 {
 Mode1,
 Mode2,
 Mode3
 };

When I add:
 Q_ENUM(eMode)
after the enum declaration I get an error:
moc_tclass.cpp(): error C2248: 'tClass::eMode': cannot access private enum 
declared in class 'tClass'
tclass.h(348): note: see declaration of 'tClass:: eMode'
tclass.h(): note: see declaration of 'tClass

Is this a known limitation of Q_ENUM? Is it fixed in later versions of Qt?



Hi, the Q_ENUM macro relies on static data structures declared in the 
moc_tclass.cpp file (outside of the scope of the tclass) and these 
declarations fail for private stuff. So changing that "private:" to 
"public:" is the pretty much your only choice for Q_ENUM to work :-(


Rgrds Henry

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

Re: [Interest] Help with QSslSocket race condition?

[Henry Skoglund]

On 23/10/2018 20.43, Israel Brewster wrote:
I am using QSslSockets with a QTcpServer to create a simple 
client/server program (is there a higher level API I could use 
instead?). I have subclassed QTcpServer to create my server side sockets 
as QSslSockets and call startServerEncryption(), but otherwise it is 
just a standard QTcpServer.


When a socket first connects to the server, I make the following connection:

connect(clientConnection, SIGNAL(disconnected()), 
clientConnection, SLOT(deleteLater()));


where clientConnection is the QSslSocket created by the QTcpServer. 
Later, when using the socket (again on the server), I have the following 
function to wait for data from the client:


  
/// \brief EZPCore::waitForResponseReady
/// \param socket
/// \param msec
/// \return true=data available, false=timeout/error
///
/// Documentation for QAbstractSocket "waitForReadyRead" says
/// "This function may fail randomly on Windows. Consider using the event loop 
and the readyRead()
/// signal if your software will run on Windows."
/// so that's what this function does.
bool EZPCore::waitForResponseReady(QSslSocket *socket,int msec){
   
   if(!socket || !socket->isValid() || !socket->isEncrypted() || socket->state()!=QAbstractSocket::ConnectedState)
   
   return false; //there is something wrong with the socket, no point in waiting.


     if(socket->bytesAvailable()>0)
         return true;//success! Bytes are available!

     QEventLoop wait;  //don't block other operations while waiting
     QTimer waitTimeout; //only wait a set length of time.
     waitTimeout.setSingleShot(true);

     connect(,::timeout,[]{wait.exit(-1);});
   
   connect(socket,::disconnected,[]{wait.exit(-2);}); //catch if the socket closes while waiting.
   
   connect(socket,::readyRead,[]{wait.exit();}); //zero exit


     waitTimeout.start(msec);
     int result=wait.exec();
   
   waitTimeout.stop(); //stop the timer if it is still running (probably unneeded?)


     if(result<0)
         return false; //not connected or timeout

     //should only get here if result is 0, indicating readyRead signal 
received.


     //if we have bytes available, then return success (0), even if
     //we had a timeout
     if(socket->bytesAvailable()>0) //

Re: [Interest] Find frontmost widget of specific type?

[Henry Skoglund]

On 22/10/2018 23.34, Giuseppe D'Angelo via Interest wrote:

Il 22/10/18 23:22, Henry Skoglund ha scritto:

Hi, just an idea, but obviously somewhere deep inside Qt's bowels
(rather, the painting system) there's knowledge of which window obscures
which etc.


There isn't. Compositing window managers have been a reality on desktop 
machines since Mac OS X 10.2 (2002), maybe even before that.


The only really robust approach is asking the WM what are the visible 
windows and their stacking order. Keeping the order in Qt is also 
feasable, modulo of course bugs in the Qt / WM interaction...


My 2 c,



Ok, I see, nice try but 16 years too late. I guess that only shows my 
age :-(


Rgds Henry

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

Re: [Interest] Find frontmost widget of specific type?

[Henry Skoglund]

On 22/10/2018 22.37, John Weeks wrote:

We faced pretty much exactly this issue when we ported our very large 
application to Qt, starting with Qt 4.8. We have many places where we expect to 
be able to walk a window list in Z order. I wound up using Activate/Deactivate 
events to keep the list myself. I can't really recommend it- it has been pretty 
much of a nightmare to make it robust and bug-free, especially as Qt has a 
couple of bugs in their own notion of window activation. You can't really use 
the debugger to debug these issues, as the activation of the debugger changes 
the activation of the application's windows.

I have made it work pretty well, but I quake in my boots whenever I get a bug 
report about window order.

We are now using Qt 5.9 and don't have any sort of replacement for my delicate 
and difficult code.

-John Weeks
WaveMetrics, Inc.


On Oct 22, 2018, at 11:37 AM, Israel Brewster  wrote:

I have an application (Qt 5.9) that has a variety of different types of windows 
you can open. If a user selects to open a type of window that is already open, 
I want to position the new  window relative to the existing one. I can easily 
find any existing windows of a given type by going through the list of widgets 
in QApplication::allWidgets(), doing a qobject_cast to the proper type, and 
checking the result, but is there a way to determine which of these is the 
frontmost of that type? QApplication::ActiveWindow() doesn't help, because the 
activeWindow may not be of that type.




Hi, just an idea, but obviously somewhere deep inside Qt's bowels 
(rather, the painting system) there's knowledge of which window obscures 
which etc.


Say you issue a dummy QWidget::update() on your topmost/app window, then 
catches all the QPaintEvents that are called. Inside those QPaintEvents 
is a QPaintEvent::rect() that holds the rectangle that needs to be 
updated/repainted. If you then search your QApplication::allWidgets()'s 
list of rectangles; then I think (guessing) that only the 
topmost/foremost windows will match QPaintEvent's rectangles. I.e. 
windows that are partially or fully obscured by another window should 
receive a smaller (or none) rectangle in those QPaintEvents. That could 
be one way to establish a z-order on the fly...


Rgrds Henry

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

Re: [Interest] Can't install Qt-5.11.2 on latest Windows 10

[Henry Skoglund]

On 17/10/2018 23.11, Patrick Stinson wrote:
Hello! I can’t seem to find any way to install qt-5.11.2 on Windows 10 
from either the online installer or the all-in-one open source 
installer. Surely this isn’t happening for everyone?


I am getting installer errors as in this bug report:

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

Does anyone know a workaround for this?

-Patric


Just guessing, but have you tried disabling your anti-virus program and 
then install Qt?


Rgrds Henry

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

Re: [Interest] hmac sha256

[Henry Skoglund]

On 2018-10-15 23:16, Jérôme Godbout wrote:

Hi,
I'm trying to find the C++ equivalent of this python:
/import hashlib/
/import hmac/
/hmac.new(bytearray(m_api_secret, 'utf-8'), bytearray(payload, 'utf-8'), 
hashlib.sha256).hexdigest()/

/
/
Or my Javascript equivalent (both give the same results):
crypto.createHmac("sha256", m_api_secret).update(payload).digest("hex");
/
/
I have try the following:

  * QMessageAuthenticationCode::hash(payload,
QByteArray::fromHex(m_api_secret), QCryptographicHash::Sha256).toHex();
  * QMessageAuthenticationCode::hash(payload,
QByteArray::fromHex(m_api_secret),
QCryptographicHash::Sha3_256).toHex();
  * QMessageAuthenticationCode::hash(payload, m_api_secret,
QCryptographicHash::Sha256).toHex();
  * QMessageAuthenticationCode::hash(payload, m_api_secret,
QCryptographicHash::Sha3_256).toHex();
  * QMessageAuthenticationCode::hash(QByteArray::fromHex(payload),
QByteArray::fromHex(m_api_secret), QCryptographicHash::Sha256).toHex();
  * QMessageAuthenticationCode::hash(QByteArray::fromHex(payload),
QByteArray::fromHex(m_api_secret),
QCryptographicHash::Sha3_256).toHex();

But I never get the same results as the Python or Javascript one. Maybe 
I'm using the wrong class here. Anybody have a good pointer on how to do 
this?

Any good hmac sha256 class to perform this?



Hi, the QMessageAuthenticationCode class should work fine, and your #3 
attempt should be correct.


Just tested with key = "my secret key" and payload "my message":

Python3.6.6 on Ubuntu:
>>> hmac.new(bytearray('my secret key', 'utf-8'), bytearray('my 
message', 'utf-8'), hashlib.sha256).hexdigest()

'8cb6f28c5bd8e02fef83fdb7cc00b2116f5aefd868c3c4bed4db3b99b0450372'

Qt 5.11.2 on Win7:
qDebug() << QMessageAuthenticationCode::hash("my message","my 
secret key", QCryptographicHash::Sha256).toHex();


23:43:52: Starting 
C:\Projects\build-untitled-Desktop_Qt_5_11_2_MSVC2015_32bit-Release\release\untitled...

"8cb6f28c5bd8e02fef83fdb7cc00b2116f5aefd868c3c4bed4db3b99b0450372"

Rgrds Henry

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

Re: [Interest] qmlscene install problems (was: Interest, Digest, Vol 82, Issue 5)

[Henry Skoglund]

Hi, I just downloaded Qt Creator's sources and perused the welcome 
plugin, try as I might I couldn't find any usage of qml, instead I found 
lots of widgets like QStackedWidgets, QHBoxLayouts and QVBoxLayouts 
being created by the welcome plugin.


I don't understand how not loading that welcome plugin would help in any 
way with any qml problems?


Rgrds Henry


On 2018-07-16 18:10, Roland Hughes wrote:



On 07/16/2018 11:10 AM, Ulf Hermann wrote:

And none of that has anything to do with qmlscene being installed or not, or 
how Qt Creator deals with it. Also, the qmlscene utility and the QML language 
are two rather different things. The welcome screen (used to) be written in 
QML, but Qt Creator doesn't use qmlscene to run it. So, all of this rant is as 
misplaced as it is unnecessary. The only thing that may be remotely relevant is 
the comment about Ubuntu's testing practices, but the information we have here 
is far from being conclusive on this being an actual problem. The author should 
be sorry for wasting everybody's time.

best regards,
Ulf Hermann
The rant was not misplaced and I do not apologize. This issue has been 
cropping up for many, many years. One of the primary work arounds to was 
to no load the welcome screen. In fact, I found the topic so important 
for newbs I created a blog post from this.


http://www.logikalsolutions.com/wordpress/information-technology/qtcreator-no-qmlscene-installed/

You should apologize for wasting everyone's time not providing the 
historically known work arounds.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com




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

Re: [Interest] Use Qt release DLLs while debugging application

[Henry Skoglund]

On 2018-04-25 07:35, Rainer Wiesenfarth wrote:
*You can, if* you are interested in the debug code of your application 
only, but not in the one of Qt and the C runtime.


If you use the release version of Qt, you have to make sure that you 
link with the same runtime, i.e. you use /MD (Mulit-threaded DLL) for 
your debug build instead of /MDd (Multi-threaded Debug DLL).


​Note: You have to make sure that any other library you link against is 
using the same C runtime​
Note: I have no idea how to configure this using QMake (we use 
hand-crafted .vcxproj and .props)


​Cheers, Rainer​


Morning, just want to add, qDebug() output works fine in Release builds 
also. I.e. just printf()-style debugging but sometimes that's all you need.


Rgrds Henry

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

Re: [Interest] Tricky to download Qt online installer for 64-bit Linux

[Henry Skoglund]

On 2018-01-06 04:36, Christian Gagneraud wrote:

On 6 January 2018 at 13:25, Thiago Macieira <thiago.macie...@intel.com> wrote:

On Friday, 5 January 2018 19:27:40 -02 Henry Skoglund wrote:

However, while on
Windows and MacOs you only get one Download button, on Linux you'll get
two, one for 64-bit and one for 32-bit.

2 buttons are fine, the problem is that whichever button I click on, I
always get qt-unified-linux-x86-2.0.5-2-online.run downloaded, not the
qt-unified-linux-x64-3.0.2-online.run


Uh... why do we provide a 32-bit installer in the first place, if we don't
provide a 32-bit build of Qt?


This one allows to install Qt/32bits on a 32bits PC, up to Qt-5.5.



Problem is that the 32-bit installer is no good for someone on a 64-bit 
Linux (= most people nowadays), i.e. a newcomer to Qt will click on the 
Download button for 64-bit, chmod +x the installer and then double-click 
on it. And nothing will happen, no error dialog box or warnings.


Perhaps he will visit the Qt forums, where someone will advise him to 
launch the installer from a Terminal window to see the actual error 
message. And the message will most likely be "*not an executable file*" 
since the i386 architecture usually isn't installed.


Hopefully he will spot the fine print on the bottom of
https://www.qt.io/download-qt-installer for the link to the offline 
packages, where there's no 32-bit Linux installer, only 64-bit flavored. 
And that file works.


But this road to getting Qt installed could be simpler, I think it's a 
bug in the javascript.


Rgrds Henry

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

[Interest] Tricky to download Qt online installer for 64-bit Linux

[Henry Skoglund]

Hi, today I installed Ubuntu 17.10 and it really looks nice, can't wait 
to deploy the more "serious", I mean LTS, 18.04 release.


Of course I want Qt to go with that so I went to qt.io and landed on 
https://www.qt.io/download-qt-installer. Looks nice and new, the 
download buttons animate when you hover on them. However, while on 
Windows and MacOs you only get one Download button, on Linux you'll get 
two, one for 64-bit and one for 32-bit.


2 buttons are fine, the problem is that whichever button I click on, I 
always get qt-unified-linux-x86-2.0.5-2-online.run downloaded, not the 
qt-unified-linux-x64-3.0.2-online.run :-(


Using the classic trick of disabling javascript to speed up the loading 
of the pages of qt.io works also here, if you reload 
https://www.qt.io/download-qt-installer without javascript then you'll 
get to choose yourself which of the 4 online installers you want to 
download (just like last year).


I think this is javascript bug on qt.io which does not benefit new users 
trying to download Qt on Linux. Is there somewhere to send a bug report?


Rgrds Henry

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

Re: [Interest] Windows 10 + native QFileDialog + QPrinter + some magic = application hangs

[Henry Skoglund]

On 2017-12-20 22:42, Rainer Wiesenfarth wrote:

Hi all,


..
..
..
I took a close look at the m_fileDialog in QWindowsNativeFileDialogBase 
for the Windows 10 case that gets stuck:
- at (1), m_fileDialog references a vtable in comdlg32.dll!const 
CFileOpenSave
- at (3), m_fileDialog references a vtable in 
OneCoreUAPCommonProxyStub.dll!0x...


So it seems to be related to Windows "umbrella" libraries, but I have no 
idea how. I looked even deeper into where m_fileDialog is getting 
assigned and found the call to CoCreateInstance(), where 
CLSID_FileOpenDialog and IID_IFileOpenDialog is passed in both (1) and 
(3), but in (1) the comdlg32 object is returned while in (3) it is the 
OneCore... object.


My guess so far:
1. The constructor or destructor of QPrinter could lead to the 
replacement of the object behind CLSID_FileOpenDialog, but
2. this replacement not done always, but is triggered by the "some 
magic" part in my application that is executed before (1)


​Any ideas what the "​some magic" part could be? Unfortunately my 
application is quite complex and can not be stripped down easily...


Hmmm, maybe that "magic" part is some UWP functionality, because 
OneCoreUAPCommonProxyStub.dll should only be loaded for UWP apps, but 
your app is a normal Windows .exe file.



Anyway, one way to get some more insight, add more QPA logging to your 
app by including:


#include "qloggingcategory.h"

and then turn it on with:
QLoggingCategory::setFilterRules("qt.qpa.dialogs=true");

Might help to see where to hangup is.

Rgrds Henry
P.S. Looking at the code, I see one possibility, if that FileOpenDialog 
window is not visible, then the close will fail and a hang will occur. 
But how can be it not visible...


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

Re: [Interest] QDataStream not increasing position of QByteArray

[Henry Skoglund]

On 2017-10-02 14:23, stephan.ebel...@hs-anhalt.de wrote:


Dear Qt-list-members,


i got the following problem with Qt and i hope that you can help me:


When I write raw network bytes to a QDataStream object repeatedly, the 
QDataStream never increases the write position of the underlying QByteArray.


Here's the code:

|QByteArray recvBuf; int bytePosition = 0; void init( ){ recvBuf = 
QByteArray( 240 * 10, Qt::Uninitiliazed ); } void receiveAppend( ){ 
QByteArray buffer( 240, Qt::Uninitialized ); QDataStream datastream( 
recvBuf, QIODevice::WriteOnly ); datastream.setByteOrder( 
QDataStream::LittleEndian ); if( udpSocket->readDataGram( buffer.data(), 
buffer.size(), ,  ){ datastream.device().seek( bytePosition ); 
datastream.writeRawData( buffer.data(), buffer.size() ); bytePosition += 
240; } } |


Why is this happening?

The code works fine on Linux Mint 18 64Bit. But it's not working on 
Windows 10 64Bit. I'm using Qt Creator 4.3.1 with Qt 5.9.1.





Maybe a stupid question, but you're sure you're receiving the same 240 
network bytes in Win10 as you do in Mint? If you do a trace printout of 
the buffer.size() in receiveAppend(), is it the same in both systems?

Maybe Win10's firewall is messing the program...

Rgrds Henry

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

Re: [Interest] Issue with toLatin1()

[Henry Skoglund]

On 2017-09-14 16:52, Thiago Macieira wrote:

On Wednesday, 13 September 2017 23:34:20 PDT Sudhir Sharma wrote:

Hi,

I am getting following error while executing my application on QT 5.9.1 with
VS2015 (win64). Any idea what could be issue?

"The procedure entry point tolatin1 could not be located in qt5xml.dll"


First of all, C++ is case sensitive, so please be sure you did a proper copy &
paste. There's no method called "tolatin1" anywhere in Qt. If you meant
"toLatin1", then it exists as a member of QString, which lives in Qt5Core.dll.
In any case, I'd expect to see a class name somewhere too.

So there's something wrong with your error message. Paste the *correct* error
message here so we can investigate.



Just a note, perhaps this is on Windows 10, in that case Microsoft has 
decided to "improve" that ages-old error message "The procedure entry 
point xxx could not be located in yyy" (it's been the same in Windows 
2,3,7,NT,ME,Vista believe me I've been there).


Anyway on Windows 10, the error message now points out the 
importing/consuming file of the entry point/function, *not* the 
producing/exporting file housing that function. So the message could 
mean that the qt5xml.dll failed to import toLatin1() from Qt5Core.dll. 
Perhaps you have an old (not 5.9.1) Qt5Xml.dll?


Rgrds Henry

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

Re: [Interest] Link error while building Qt/32 on Linux 64 bits

[Henry Skoglund]

On 2017-08-27 07:42, Christian Gagneraud wrote:

On 27 August 2017 at 16:08, Thiago Macieira  wrote:

On Saturday, 26 August 2017 18:25:16 PDT Christian Gagneraud wrote:

/usr/bin/ld.gold: warning: skipping incompatible
//usr/lib/x86_64-linux-gnu/libSM.so while searching for SM
/usr/bin/ld.gold: error: cannot find -lSM
/usr/bin/ld.gold: warning: skipping incompatible
//usr/lib/x86_64-linux-gnu/libICE.so while searching for ICE
/usr/bin/ld.gold: error: cannot find -lICE
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QXcbSessionManager::~QXcbSessionManager(): error: undefined reference
to 'SmcCloseConnection'


The undefined reference is caused by the libraries listed right before it not
being found.


Not sure to get what you mean.

Given this:
-lxcb-xinerama -L/home/krys/Projects/qt5/qtbase/lib
-lQt5ServiceSupport -lQt5ThemeSupport -lQt5EventDispatcherSupport
-lQt5FontDatabaseSupport -lfontconfig -lfreetype
-lQt5LinuxAccessibilitySupport -lQt5AccessibilitySupport -lGL -lQt5Gui
-lQt5DBus -lQt5Core -lpthread -lX11 -lX11-xcb -lXi -lSM -lICE
-lxcb-xkb -lxcb-render-util -lxcb-render -lxcb -lxcb-shm -lxcb-sync
-lxcb-xfixes -lxcb-randr -lxcb-image -lxcb-keysyms -lxcb-icccm
-lxcb-shape -lGL

Should I focus at the libs on the right or on the left of "-lSM -lICE"?
My understanding of ld tells me to look on the right (reverse dependency order).

I think I have installed all these libraries. The only weird thing i
can see comes from my libGL:
krys@krys-pc:~/Projects/qt5$ ldconfig -p | grep libGL.so
 libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-375/libGL.so.1
 libGL.so.1 (libc6) => /usr/lib32/nvidia-375/libGL.so.1
 libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so
 libGL.so (libc6,x86-64) => /usr/lib/nvidia-375/libGL.so
 libGL.so (libc6) => /usr/lib/i386-linux-gnu/libGL.so
 libGL.so (libc6) => /usr/lib32/nvidia-375/libGL.so

And apt-get always complaining with:
/sbin/ldconfig.real: /usr/lib/nvidia-375/libEGL.so.1 is not a symbolic link
/sbin/ldconfig.real: /usr/lib32/nvidia-375/libEGL.so.1 is not a symbolic link


Those nvidia errors I also had for a long time, but upgrading Nvidia 
driver solved it (for example to 'nvidia-384') by adding this ppa:

sudo add-apt-repository ppa:graphics-drivers/ppa

Rgrds Henry

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

Re: [Interest] Link error while building Qt/32 on Linux 64 bits

[Henry Skoglund]

Hi, about that missing libSM.so, some googling found this:
https://askubuntu.com/questions/611933/missing-libsm-so-6-library-qt-creator-installation-error

Rgrds Henry


On 2017-08-27 03:25, Christian Gagneraud wrote:

Hi there,

I'm trying to build a 32 bits version of Qt on a 64 bits Linux machine
(KUbuntu 17.04).

At the very beginning i wouldn't even pass the bootstrapping of Qt. So
i installed all the 'lib32' packages (eg, lib32stdc++, ...) and some
i386 version of the build dependencies listed on Qt Wiki.

I can now pass the configure stage, but the build fails while linking
libQt5XcbQpa.

See below for details. I wonder if i need to pass in some CFLAGS,
CXXFLAGS, LDFLAGS to ./configure

Any help appreciated. Thanks,
Chris


The error is:
g++ -m32 -Wl,--no-undefined -Wl,--version-script,QtXcbQpa.version
-Wl,-O1 -fuse-ld=gold -Wl,--enable-new-dtags
-Wl,-rpath,/home/krys/Projects/qt5/qtbase/lib -shared
-Wl,-Bsymbolic-functions -Wl,-soname,libQt5XcbQpa.so.5 -o
libQt5XcbQpa.so.5.9.0 .obj/qxcbclipboard.o .obj/qxcbconnection.o
.obj/qxcbintegration.o .obj/qxcbkeyboard.o .obj/qxcbmime.o
.obj/qxcbdrag.o .obj/qxcbscreen.o .obj/qxcbwindow.o
.obj/qxcbbackingstore.o .obj/qxcbwmsupport.o
.obj/qxcbnativeinterface.o .obj/qxcbcursor.o .obj/qxcbimage.o
.obj/qxcbxsettings.o .obj/qxcbsystemtraytracker.o
.obj/qxcbconnection_xi2.o .obj/qxcbsessionmanager.o
.obj/qxcbglintegrationfactory.o .obj/qxcbglintegration.o
.obj/qxcbnativeinterfacehandler.o .obj/atom.o .obj/xkb-compat.o
.obj/context.o .obj/xkb-keymap.o .obj/keysym.o .obj/keysym-utf.o
.obj/state.o .obj/text.o .obj/context-priv.o .obj/keymap-priv.o
.obj/utils.o .obj/utf8.o .obj/action.o .obj/ast-build.o .obj/compat.o
.obj/expr.o .obj/include.o .obj/keycodes.o .obj/keymap-dump.o
.obj/keymap.o .obj/keywords.o .obj/rules.o .obj/scanner.o
.obj/symbols.o .obj/types.o .obj/vmod.o .obj/xkbcomp.o .obj/parser.o
.obj/util.o .obj/x11-keymap.o .obj/x11-state.o
.obj/moc_qxcbconnection.o .obj/moc_qxcbmime.o
.obj/moc_qxcbnativeinterface.o .obj/moc_qxcbsystemtraytracker.o
.obj/moc_qxcbglintegrationplugin.o  -lxcb-xinerama
-L/home/krys/Projects/qt5/qtbase/lib -lQt5ServiceSupport
-lQt5ThemeSupport -lQt5EventDispatcherSupport -lQt5FontDatabaseSupport
-lfontconfig -lfreetype -lQt5LinuxAccessibilitySupport
-lQt5AccessibilitySupport -lGL -lQt5Gui -lQt5DBus -lQt5Core -lpthread
-lX11 -lX11-xcb -lXi -lSM -lICE -lxcb-xkb -lxcb-render-util
-lxcb-render -lxcb -lxcb-shm -lxcb-sync -lxcb-xfixes -lxcb-randr
-lxcb-image -lxcb-keysyms -lxcb-icccm -lxcb-shape -lGL
/usr/bin/ld.gold: warning: skipping incompatible
//usr/lib/x86_64-linux-gnu/libSM.so while searching for SM
/usr/bin/ld.gold: error: cannot find -lSM
/usr/bin/ld.gold: warning: skipping incompatible
//usr/lib/x86_64-linux-gnu/libICE.so while searching for ICE
/usr/bin/ld.gold: error: cannot find -lICE
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QXcbSessionManager::~QXcbSessionManager(): error: undefined reference
to 'SmcCloseConnection'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QXcbSessionManager::release(): error: undefined reference to
'SmcInteractDone'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
sm_setProperty(char const*, char const*, int, SmPropValue*) [clone
.part.2]: error: undefined reference to 'SmcSetProperties'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QSmSocketReceiver::socketActivated(int): error: undefined reference to
'SmcGetIceConnection'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QSmSocketReceiver::socketActivated(int): error: undefined reference to
'IceProcessMessages'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QXcbSessionManager::QXcbSessionManager(QString const&, QString
const&): error: undefined reference to 'SmcOpenConnection'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QXcbSessionManager::QXcbSessionManager(QString const&, QString
const&): error: undefined reference to 'SmcGetIceConnection'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
QXcbSessionManager::QXcbSessionManager(QString const&, QString
const&): error: undefined reference to 'IceConnectionNumber'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
sm_setProperty(QString const&, QStringList const&): error: undefined
reference to 'SmcDeleteProperties'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
sm_performSaveYourself(QXcbSessionManager*): error: undefined
reference to 'SmcInteractDone'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
sm_performSaveYourself(QXcbSessionManager*): error: undefined
reference to 'SmcSaveYourselfDone'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
sm_performSaveYourself(QXcbSessionManager*): error: undefined
reference to 'SmcInteractDone'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function
sm_performSaveYourself(QXcbSessionManager*): error: undefined
reference to 'SmcRequestSaveYourselfPhase2'
.obj/qxcbsessionmanager.o:qxcbsessionmanager.cpp:function

Re: [Interest] Is there a way to simulate serial port data?

[Henry Skoglund]

Hi, I faced a simular situation last summer, and I used this: 
http://com0com.sourceforge.net/


Rgrds Henry
P.S. I think it only works on Windows, though.

On 2017-03-28 00:48, Murphy, Sean wrote:

I've got a class that inherits from QSerialPort. The bulk of the code in the 
class is parsing that I'm doing in a slot that is connected to QSerialPort's 
readyRead() signal. I want to inject known data  into this class as if it's 
actually coming across the serial port to validate my parsing code, is there 
any way to do that? Ideally I'd be able to write data in and have it trigger 
the readyRead() signal, but I'm not seeing any way to do that.

I know I could write a separate application that writes out one serial port, 
and then I could cable that back to my other serial port, but I was just 
looking for a way to do it all in code.

Sean

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




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

Re: [Interest] Support for Visual Studio 2017

[Henry Skoglund]

Hi, just guessing, but googling the error suggests: check that your .NET 
Framework has been updated to 4.6 and also turn off any antivirus program.


Rgrds Henry

On 2017-03-09 23:33, Tom Isaacson wrote:

Unfortunately it fails for me:

10/03/2017 11:31:08 AM - Microsoft VSIX Installer
10/03/2017 11:31:08 AM - ---
10/03/2017 11:31:08 AM - vsixinstaller.exe version:
10/03/2017 11:31:08 AM - 15.0.26228.0 built by: D15REL
10/03/2017 11:31:08 AM - ---
10/03/2017 11:31:08 AM - Command line parameters:
10/03/2017 11:31:08 AM - C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Professional\Common7\IDE\VSIXInstaller.exe,C:\Users\Tom\Downloads\qt-vsaddin-msvc2017-2.1.1-beta
 (1).vsix
10/03/2017 11:31:08 AM - ---
10/03/2017 11:31:08 AM - Microsoft VSIX Installer
10/03/2017 11:31:08 AM - ---
10/03/2017 11:31:09 AM - Initializing Install...
10/03/2017 11:31:09 AM - Extension Details...
10/03/2017 11:31:09 AM -Identifier : 
QtVsTools.13121978-cd02-4fd0-89bd-e36f85abe16a
10/03/2017 11:31:09 AM -Name   : Qt Visual Studio Tools
10/03/2017 11:31:09 AM -Author : The Qt Company Ltd.
10/03/2017 11:31:09 AM -Version: 2.1.1
10/03/2017 11:31:09 AM -Description: The Qt Visual Studio Tools 
allow developers to use the standard development environment without having to 
worry about any Qt-related build steps or tools.
10/03/2017 11:31:09 AM -Locale : en-US
10/03/2017 11:31:09 AM -MoreInfoURL: http://www.qt.io/
10/03/2017 11:31:09 AM -InstalledByMSI : False
10/03/2017 11:31:09 AM -SupportedFrameworkVersionRange : [4.6,)
10/03/2017 11:31:09 AM -
10/03/2017 11:31:09 AM -SignatureState : Unsigned
10/03/2017 11:31:09 AM -Supported Products :
10/03/2017 11:31:09 AM -Microsoft.VisualStudio.Pro
10/03/2017 11:31:09 AM -Version : [15.0]
10/03/2017 11:31:09 AM -Microsoft.VisualStudio.Premium
10/03/2017 11:31:09 AM -Version : [15.0]
10/03/2017 11:31:09 AM -Microsoft.VisualStudio.Ultimate
10/03/2017 11:31:09 AM -Version : [15.0]
10/03/2017 11:31:09 AM -Microsoft.VisualStudio.Community
10/03/2017 11:31:09 AM -Version : [15.0]
10/03/2017 11:31:09 AM -
10/03/2017 11:31:09 AM -References :
10/03/2017 11:31:09 AM -Prerequisites  :
10/03/2017 11:31:09 AM -
---
10/03/2017 11:31:09 AM -Identifier   : 
Microsoft.VisualStudio.Component.CoreEditor
10/03/2017 11:31:09 AM -Name : Visual Studio core editor
10/03/2017 11:31:09 AM -Version  : [15.0.26208.0,16.0)
10/03/2017 11:31:09 AM -
10/03/2017 11:31:09 AM -
---
10/03/2017 11:31:09 AM -Identifier   : 
Microsoft.VisualStudio.Component.VC.CoreIde
10/03/2017 11:31:09 AM -Name : Visual Studio C++ core 
features
10/03/2017 11:31:09 AM -Version  : [15.0.26208.0,16.0)
10/03/2017 11:31:09 AM -
10/03/2017 11:31:09 AM - Signature Details...
10/03/2017 11:31:09 AM -Extension is not signed.
10/03/2017 11:31:09 AM -
10/03/2017 11:31:09 AM - Searching for applicable products...
10/03/2017 11:31:09 AM - Found installed product - Microsoft Visual Studio 
Professional 2013
10/03/2017 11:31:09 AM - Found installed product - Microsoft Visual Studio 2013 
Shell (Integrated)
10/03/2017 11:31:09 AM - Found installed product - Microsoft Visual Studio 
Professional 2015
10/03/2017 11:31:09 AM - Found installed product - Microsoft Visual Studio 
Community 2015
10/03/2017 11:31:09 AM - Found installed product - Microsoft Visual Studio 2015 
Shell (Integrated)
10/03/2017 11:31:09 AM - Found installed product - Global Location
10/03/2017 11:31:09 AM - Found installed product - Visual Studio Professional 
2017
10/03/2017 11:31:09 AM - PKGDEF Information: Looking for master PkgDef file, 
Path: C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Professional\Common7\IDE\master.pkgdef

10/03/2017 11:31:09 AM - PKGDEF Information: Creating PkgDefCacheNonVolatile
10/03/2017 11:31:09 AM - PKGDEF Information: Double-checking master pkgdef file
10/03/2017 11:31:09 AM - PKGDEF Information: PkgDefManagement initialized
10/03/2017 11:31:09 AM - PKGDEF Information: RootFolder, Path: C:\Program Files 
(x86)\Microsoft Visual Studio\2017\Professional\

10/03/2017 11:31:09 AM - PKGDEF Information: ShellFolder, Path: C:\Program 
Files (x86)\Microsoft Visual Studio\2017\Professional\

10/03/2017 11:31:09 AM - PKGDEF Information: PkgDefSearchPath, Path: C:\Program 
Files 

Re: [Interest] Creating a QVariant of QList<QObject*> knowing only the class name

[Henry Skoglund]

Den 2017-02-23 kl. 00:26, skrev Ch'Gans:

On 23 February 2017 at 05:42, Thiago Macieira  wrote:

On quarta-feira, 22 de fevereiro de 2017 02:40:37 PST Ch'Gans wrote:

[...]

Tanks for all your inputs, but I'm still puzzled, I can't believe this
is not achievable in a generic way...


It is achievable. I'm saying that the Qt metatype system doesn't do what you
want and that the way you tried was UB.


May I ask what UB stands for? There seems to be zillion of definitions for "UB".




Hi, bet you a buck he meant "undefined behavior".

/Rgrds Henry



--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

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




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

Re: [Interest] What don't you like about Qt?

[Henry Skoglund]

Ok here's my number #1 complaint:

the MaintenanceTool app, when you start it, why is the default selected 
choice to remove Qt??? It should be to update Qt of course.


(Such a design could get you fired if you worked for say, Microsoft. :=)

Rgrds Henry


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

Re: [Interest] FortuneServer/client doesnt work across 2 different Devices

[Henry Skoglund]

Hi, just tested a fortune/client from my iPhone to my Debian Linode 
fortune/server, works like a charm.


If you want to try from your android phone, I'm leaving the server 
running for you until Monday:


Server name: 176.58.122.118
Server port: 42815

Rgrds Henry

Thiago Macieira skrev den 2016-09-02 17:39:

Em sexta-feira, 2 de setembro de 2016, às 20:16:33 CEST, Nilesh Kokane
escreveu:

On Fri, Sep 2, 2016 at 8:08 PM, Henry Skoglund <fro...@tungware.se> wrote:

Hmm just guessing, but perhaps try switching your PC network from wired to
wireless (to the same Wi-Fi network that your phone is on).


Indeed. I have the same wifi for my laptop(192.168.0.3) and
Phone(192.168.0.2) and my router address is 192.168.0.1 . And i don't
use wired.

I'm really bewildered as a simple example doesn't work. Whats wrong?


I still think it's a firewall. Are you sure your phone has no firewall on? How
are you sure?




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

Re: [Interest] FortuneServer/client doesnt work across 2 different Devices

[Henry Skoglund]

Hmm just guessing, but perhaps try switching your PC network from wired 
to wireless (to the same Wi-Fi network that your phone is on).


Nilesh Kokane skrev den 2016-09-02 15:54:

On Fri, Sep 2, 2016 at 7:20 PM, Reinhardt Behm  wrote:

On Friday 02 September 2016 19:10:41 Nilesh Kokane wrote:

Hello,

I'm trying to run fortuneServer(qt example) on my host PC and deploy
fortuneclient on the android phone. I made sure that they are in the
same network ( server : 192.168.0.3, client : 192.168.0.2) but then
client complains "connection timed out" and after some time I get
QAbstractSocket::ConnectionRefusedError (The connection was refused by
the peer..).

And the same program works if I run the server/client on the same
machine. I conform that I have given the right port number, and the
servers IP(192.168.0.3) is given in the clients pgm (server Name)
part.

Am i missing something? Any clue?


Firewall ?


No..!




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

Re: [Interest] Sending mail with line breaks using QDesktopServices::openUrl

[Henry Skoglund]

On 2016-08-16 09:56, Viktor Engelmann wrote:

I tried

xdg-open "mailto:?to=t...@test.com=test=line1%0D%0Aline2;

this opened kmail with the recipient, subject and body being set
correctly (with line break)

thunderbird "mailto:?to=t...@test.com=test=line1%0D%0Aline2;

also worked. I'm using Linux Mint 17.3 with KDE 4.14.2.

Viktor



Just to confirm, I also tested on Linux Mint 17.3 and Qt works fine as 
there as well (with line break).

Screen shot: http://www.tungware.com/kmail.png

But what Linux flavor is the culprit/wreaking havoc on the line breaks, 
so far Ubuntu and Mint seems out of the picture.


Rgrds Henry


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

Re: [Interest] Sending mail with line breaks using QDesktopServices::openUrl

[Henry Skoglund]

On 2016-08-16 00:14, Bernhard Lindner wrote:

I can't confirm that it works. I tried on the command-line with xdg-open and
by directly clicking the link above in KMail. Neither time was the body
present at all.


When using the link in the mail, it doesn't work for me too.
When clicking the same link in a local html file it works.

Very strange.

I also tried Qt 5.7. No change... body visible but no line break.

Well, seems that is getting complicated.

Any ideas?


Well at least Qt does something right, I just tested on my Mac, Qt 5.7 
and Thunderbird, "line1" and "line2" show nice line breaks. So far, I 
tested on Ubuntu 14.04, 16.04 and now OSX, all ok with "line1" and 
"line2" on separate lines.

But in all cases the email client is Thunderbird, perhaps that matters...

Rgrds Henry


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

Re: [Interest] Sending mail with line breaks using QDesktopServices::openUrl

[Henry Skoglund]

On 2016-08-15 20:29, Bernhard Lindner wrote:

Hi!

I tried to send an e-mail with a prepared subject, receiver and body
using Qt. The mail shall open in the system default mail client. I am
testing on Linux with KMail and Qt 5.5.

This is the code I intended to use:

QDesktopServices::openUrl(QUrl("mailto:?
to=t...@test.com=Test=line1%0D%0Aline2",
QUrl::TolerantMode));

The mail window opens, subject and receiver are ok. Unfortunately the
line breaks in the body do not work. I also tried , \n, \r\n but
none of these worked. I also tried other ways of constructing a QUrl
but it only get worse.

It seems not to be an KMail issue because when writing the following
into a HTML document, opening it in Firefox and clicking the link in
the browser, it does exactly what I want (including line breaks in
the body text):

mailto:?to=t...@test.com=test=line1%0D%0Aline2;>test

 Any idea how to solve the line break problem?


Hi, I just did a quick test on my Linux with Thunderbird and Qt 5.7,
constructed a vanilla Widgets app, pasted in your line 
"QDesktopServices::..".
When I run it, "line1" and "line2" appears on separate lines, ok. 
Perhaps try upgrading to 5.7?


Rgrds Henry

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

Re: [Interest] Unicode code points in Vusual Studio. Output differs from MinGW

[Henry Skoglund]

On 2016-08-11 19:53, Mark Gaiser wrote:

On Thu, Aug 11, 2016 at 6:29 PM, Thiago Macieira
> wrote:

On quinta-feira, 11 de agosto de 2016 11:40:46 PDT Mark Gaiser wrote:
> Is there any way that i can use a string with unicode code points within
> tr(...) that works on MSVC 2010 (as that is my setup), but it would be
> great if it also works under MSVC 2015 and MinGW.

There's no way to make that work with MSVC 2010. If you want this to
work,
your options are:


..
..

The only option i seem to have left for 2010 are apparently:
- Making sure the source files are UTF-8 formatted (most is ascii at the
moment)
- Using tr("Coördinaat"); as opposed to tr("Co\u00F6rdinaat");, that
does work, but is not preferred.


Actually it's possible to use unicode code points in tr(...) you just 
have to know how to play hardball with the compiler :-)


Instead of trying to play nice with tr("Co\u00F6rdinaat"); you use
tr("Co\xC3\xB6rdinaat");

Yes \uC3B6 is the UTF-8 encoding of the Unicode code point U+00F6
(if you type in tr("Coördinaat") and then hexdump the .exe file you'll 
see those bytes.)


Effectively you're saying to the compiler: don't mind us hex bytes 
passing, we're not the unicode characters you're looking for. This works 
as long as none of the 2, 3 or 4 UTF-8 characters are null chaps.


I've used this trick on MSVC2012 and MSVC2013, so it should work in 
MSVC2010 as well. (The reason: usually I code (Swedish) characters with 
tr("Coöordinaat"); but this is brittle, because then Notepad becomes 
your enemy. If you're tired one day and make a quick edit in Notepad on 
your mainwindow.cpp, Notepad "helps" your by inserting the BOM and 
*BOOM* tr("Coördinaat") does not longer compile correctly, but 
tr("Co\xC3\xB6rdinaat") does.)


Rgrds Henry


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

Re: [Interest] best qt class to use to detect line/polygon/region collision

[Henry Skoglund]

On 2016-08-08 18:05, maitai wrote:

Hello all,

I have a list of lines (QLineF) in 2D space. Some might represent a
closed polygon, some others are just a line or represent a non closed
polygon. Classical problem: I need to detect if another given line is
crossing one of the lines in the list. I don't need the crossing point,
just to know if it crosses or not.

For the time being, I just iterate on the list and use
QLineF::intersects(). This is of course badly slow.

I read that post (and many others):
http://stackoverflow.com/questions/9393672/intersection-point-of-qpainterpath-and-line-find-qpainterpath-y-by-x


Using a QPainterPath seems the right idea, but as it seems it does not
work with a single line, so maybe I should convert the line in a tiny
rectangle to be able to use QPainterPath::intersects(). Will that be
faster?

Before I try that, I was wondering if someone has a better idea as of
what class to use in qt to solve this? Calculation speed is the most
important thing in my case.

Thanks for pointing me in the right direction
Philippe Lelong


Isn't this some kind of sorting problem in disguise? You could try 
sorting the coords of the lines in your list to speed up the processing. 
I made a simple example using a QMap:

-
// make list of QLineFs
QList lLines;
for (int i = 0; (i < 100); ++i)
{
QLineF l(rand() / 100.0,rand() / 100.0,rand() / 100.0,rand() / 
100.0);


// make sure dx is positive (x1 <= x2)
if (l.x1() > l.x2())
// if not swap the points
l = QLineF(l.p2(),l.p1());

lLines.append(l);
}

// insert all x1 coords (and their position in the list) in a map
QMap mx1;
for (int i = 0; (i < lLines.count()); ++i)
mx1.insertMulti(lLines[i].x1(),i);

// make another list of QLineFs to test with
QList lTest;
for (int i = 0; (i < 20); ++i)
{
QLineF l(rand() / 100.0,rand() / 100.0,rand() / 100.0,rand() / 
100.0);


// make sure dx is positive (x1 <= x2)
if (l.x1() > l.x2())
// if not swap the points
l = QLineF(l.p2(),l.p1());

lTest.append(l);
}

// test simple way
int crossings1 = 0;
for (auto t : lTest)
for (auto l : lLines)
if (QLineF::BoundedIntersection == l.intersect(t,nullptr))
++crossings1;

// test with map
int crossings2 = 0;
for (auto t : lTest)
{
auto iUpper = mx1.upperBound(t.x2());
auto i = mx1.begin();
while (i != iUpper)
{
auto l = lLines[i.value()];
if (QLineF::BoundedIntersection == l.intersect(t,nullptr))
++crossings2;

++i;
}
}

// crossings1 == crossings2
-

Random access in the list from the values in QMap well not yield so good 
performance, the QlineFs should be stored in a vector instead.


Perhaps a next step could be to do a similar QMap sorting of the .x2() 
coords and do a .lowerbound(t.x1()) stepping down and then also sort the 
y coords. But I need more coffee to understand that right now..


Rgrds Henry


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

Re: [Interest] Qt 3D for VR?

[Henry Skoglund]

Excellent! I'm quite the noob re. Qt 3D, but this VR stuff could be a 
nice educational entry into it.


(When you sit in front on the computer inside Qt Creator all day, it's 
refreshing to stand up, put on the Vive and shoot some aliens :-)


Rgrds Henry


On 2016-07-06 18:26, Sean Harmer wrote:

Hey!

I just had my first play with the Vive today too. Peppe is already
looking into the SDK so that we can first get some pure Qt + OpenGL
examples working with it. Once we've gained a little experience with it
we will look at how to expose this to Qt 3D's API.

Cheers,

Sean

On 06/07/2016 16:53, Henry Skoglund wrote:

Hi, got an HTC Vive last week, it was really for my son but I've tried
it as well, I haven't enjoyed a shooter game this much since playing
Apple Invaders on my Apple II.

Anyway, I've downloaded the OpenVR SDK from Valve
https://github.com/ValveSoftware/openvr, I want to try displaying some
math graphs in 3D in the helmet, and perhaps try building and walking
in a maze.

Of course I'll be writing my test program in Qt, figure Qt 3D would be
swell for this. Are there any plans or ideas for VR using Qt 3D?

Regards Henry


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


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



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

[Interest] Qt 3D for VR?

[Henry Skoglund]

Hi, got an HTC Vive last week, it was really for my son but I've tried 
it as well, I haven't enjoyed a shooter game this much since playing 
Apple Invaders on my Apple II.


Anyway, I've downloaded the OpenVR SDK from Valve 
https://github.com/ValveSoftware/openvr, I want to try displaying some 
math graphs in 3D in the helmet, and perhaps try building and walking in 
a maze.


Of course I'll be writing my test program in Qt, figure Qt 3D would be 
swell for this. Are there any plans or ideas for VR using Qt 3D?


Regards Henry


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

Re: [Interest] Mapping widgets set using QTableWidget::setCellWidget() back to row, column

[Henry Skoglund]

Hi, you can use QSignalMapper to help you keep track of which spinbox 
got clicked on, example:


-
for (int r = 0; (r < ui->tableWidget->rowCount()); ++r)
for (int c = 0; (c < ui->tableWidget->columnCount()); ++c)
{
auto sb = new QSpinBox();
auto sm = new QSignalMapper(sb);
sm->setMapping(sb,r * ui->tableWidget->columnCount() + c);
CONNECTSRCAST(sb,int,valueChanged,sm,void,map);
CONNECTSCAST(sm,int,mapped,this,on_sb_clicked);

ui->tableWidget->setCellWidget(r,c,sb);
}
-

QSignalMapper stores the combined row*column number for you, and to 
retrieve the signal with that int, create a slot like this:

-
void MainWindow::on_sb_clicked(int rc)
{
qDebug() << " row = " << rc / ui->tableWidget->columnCount() <<
", column = " << rc % ui->tableWidget->columnCount();
}
-

Of course this assumes that the columncount is stable throughout your 
app :-)



What about CONNECT, what's that macro? I'm so old, I can barely remember 
the PMF syntax on a good day, so I wrote these macros to help me, i.e. 
getting the benefits of the new connect() syntax with more ease..

-
#define COMPOSEPMF(QOBJPTR,FUNC) \
::decay::type::FUNC

#define CONNECT(SENDER,FUNC1,RECEIVER,FUNC2) \
connect(SENDER,COMPOSEPMF(SENDER,FUNC1),RECEIVER,COMPOSEPMF(RECEIVER,FUNC2))

#define COMPOSECASTPMF(QOBJPTR,ARGS,FUNC) \
static_cast::type::*)(ARGS)> \
(COMPOSEPMF(QOBJPTR,FUNC))

#define CONNECTSCAST(SENDER,ARGS1,FUNC1,RECEIVER,FUNC2) \
connect(SENDER,COMPOSECASTPMF(SENDER,ARGS1,FUNC1),RECEIVER, \
COMPOSEPMF(RECEIVER,FUNC2))

#define CONNECTRCAST(SENDER,FUNC1,RECEIVER,ARGS2,FUNC2) \
connect(SENDER,COMPOSEPMF(SENDER,FUNC1),RECEIVER, \
COMPOSECASTPMF(RECEIVER,ARGS2,FUNC2))

#define CONNECTSRCAST(SENDER,ARGS1,FUNC1,RECEIVER,ARGS2,FUNC2) \
connect(SENDER,COMPOSECASTPMF(SENDER,ARGS1,FUNC1),RECEIVER, \
COMPOSECASTPMF(RECEIVER,ARGS2,FUNC2))
-

Rgrds Henry


On 2016-05-03 21:24, Murphy, Sean wrote:

Does anyone have any recommendations for the Right Way to map QWidgets that are 
inside QTableWidget cells - populated with QTableWidget::setCellWidget() - back 
to the cell index that holds the widget?

When populating the table, I'm putting widgets in various cells (QSpinBoxes for 
example). Based on where the QSpinBox is, it needs to be tied to a different 
variable. Right now, all the QSpinBox items' valueChanged(int) signals are 
connected to one slot, so I can tell that a QSpinBox was changed, but not 
necessary which one.

I've got a few ideas of how to get around this, but I'm just wondering if I'm 
missing something obvious.

Sean

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




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

Re: [Interest] Are slots even needed these days?

[Henry Skoglund]

Hi, I thought I was the only one disliking the PMF syntax.
But there's hope, to aid my feeble brain I wrote some macros, so that 
the new syntax resembles the old, but still catching errors in compile time:


#define COMPOSEPMF(QOBJPTR,FUNC) \
::decay::type::FUNC

#define CONNECT(SENDER,FUNC1,RECEIVER,FUNC2) \
connect(SENDER,COMPOSEPMF(SENDER,FUNC1),RECEIVER,COMPOSEPMF(RECEIVER,FUNC2))


Those macros let you write code like this:
...
CONNECT(ui->pushButton,clicked,this,buttonClicked);
...


Less horrid (!) they use std::decay to retrieve the type and prefix it 
to the function, thus setting up correct PMF syntax in all its glory.


However, it wasn't long before I stumbled upon the casting problem, like 
in QCombobox and QSignalMapper. So I had to write 3 more macros:



#define COMPOSECASTPMF(QOBJPTR,ARGS,FUNC) \
static_cast::type::*)(ARGS)> \
(COMPOSEPMF(QOBJPTR,FUNC))

#define CONNECTSCAST(SENDER,ARGS,FUNC1,RECEIVER,FUNC2) \
connect(SENDER,COMPOSECASTPMF(SENDER,ARGS,FUNC1),RECEIVER,COMPOSEPMF(RECEIVER,FUNC2))

#define CONNECTRCAST(SENDER,FUNC1,RECEIVER,ARGS,FUNC2) \
connect(SENDER,COMPOSEPMF(SENDER,FUNC1),RECEIVER,COMPOSECASTPMF(RECEIVER,ARGS,FUNC2))


With those I can write code like so:
...
ui->comboBox->addItems({"Now","is","the","time"});
CONNECTSCAST(ui->comboBox,const QString &,
currentIndexChanged,this,indexChanged);
...
auto sm = new QSignalMapper(ui->pushButton);
CONNECTRCAST(ui->pushButton,clicked,sm,void,map);
...

So yeah, the cast wreaks a bit of a havoc, but you only have to specify 
the casting argument(s), std::decay takes care of prefixing the type.
Note: the macros only support either a sending or a receiving cast, 
hopefully a cast on both sides will never be needed...


Also, beginning now with 5.6 you don't even have to specify CONFIG += 
c++11 in your .pro file, the macros work right out of the box.


Rgrds Henry


On 2016-03-16 18:24, John Weeks wrote:

Nobody's mentioned the fact that an overridden virtual slot requires an

> absolutely horrid cast in order to use the new PMF syntax.



> John Weeks
>

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




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

Re: [Interest] Windows deployment. Failed to start because of missing platform plugin...

[Henry Skoglund]

Hi,

also qwindows.dll depends on MSVCR120.DLL and MSVCP120.DLL (for 
VS2013-flavored Qt), if the target system lacks those you need to copy 
them together with your .exe file.

Rgrds Henry

On 2015-08-28 15:42, Samuel Gaist wrote:

 On 28 août 2015, at 15:20, Bo Thorsen b...@vikingsoft.eu wrote:

 Den 28-08-2015 kl. 10:01 skrev Igor Mironchik:
 I'm trying to deploy Qt Windows application. And it failed to start with
 the next message...

 This application failed to start because it could not find or load the
 Qt platform plugin windows.

 Reinstalling the application may fix this problem.

 Platform plugin is exist in ./platforms/qwindows.dll

 It has to be in plugins/platforms/qwindows.dll.

 How can I solve this problem?

 When I hit this, I copy every dll from Qt to my bin dir and every plugin
 to the plugins dir. If that runs, then you can start deleting stuff and
 see if your application still runs.

 For example, I have this:

 C:\Prog..\VikingSoftware\Pokerformance\
pokerformance.exe
Qt5Core.dll
Qt5Gui.dll
Qt5Network.dll
Qt5Sql.dll
Qt5Widgets.dll
plugins\
  platforms\
qwindows.dll
  sqldrivers\
qsqlite.dll

 This works for me with Qt 5.5.

 I hope this helps.

 Bo Thorsen,
 Director, Viking Software.

 --
 Viking Software
 Qt and C++ developers for hire
 http://www.vikingsoft.eu


 Hi,

 There's also windeployqt that can help for that matters

 Cheers
 Samuel

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



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