Qt (maybe 5) became sluggish recently. Any ideas why?
-
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
Qt is a Linux-only thing.
Really?! ;-)
@JonB If it's not a linux-only thing, I couldn't know that. The Windows 10 you see above in the disk listing exists there only for 2 games that won't run properly in linux, it has only audio and video drivers and nothing else. For the past 8 years my day-to-day & gaming OS was Linux, so I couldn't know what qt is available for or not.
-
@JonB If it's not a linux-only thing, I couldn't know that. The Windows 10 you see above in the disk listing exists there only for 2 games that won't run properly in linux, it has only audio and video drivers and nothing else. For the past 8 years my day-to-day & gaming OS was Linux, so I couldn't know what qt is available for or not.
-
@JonB If it's not a linux-only thing, I couldn't know that. The Windows 10 you see above in the disk listing exists there only for 2 games that won't run properly in linux, it has only audio and video drivers and nothing else. For the past 8 years my day-to-day & gaming OS was Linux, so I couldn't know what qt is available for or not.
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
For the past 8 years my day-to-day & gaming OS was Linux, so I couldn't know what qt is available for or not.
So when drawing with MS Paint every day, you would assume Microsoft Windows is a bloated, buggy and poorly designed sketching tool? :)
Well, haha, some might say that the truth is not far off, but you'll get the point :)) -
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
For the past 8 years my day-to-day & gaming OS was Linux, so I couldn't know what qt is available for or not.
So when drawing with MS Paint every day, you would assume Microsoft Windows is a bloated, buggy and poorly designed sketching tool? :)
Well, haha, some might say that the truth is not far off, but you'll get the point :))@Pl45m4 "you would assume Microsoft Windows is a bloated, buggy and poorly designed sketching tool?"
It IS, I don't have to assume anything. I used to be a Windows sheep for 20 or so years - since 1996 until 2015. The proof that the whole Windows is bloated?Arch Linux installation with ALL the programs I need and use every day (they're about 20 or 25 programs) - 24.1 GB.
Windows installation with just audio & video drivers and nothing else - 31.1 GB.If that's not bloated, IDK what it is. :D
But that's not what I came here to discuss, so let's leave it at that.
I'm more interested to know which qt5 and qt6 packages control these dialog windows that get sluggish. Maybe if I downgrade the packages, the dialogs will return to normal performance.
-
@Pl45m4 "you would assume Microsoft Windows is a bloated, buggy and poorly designed sketching tool?"
It IS, I don't have to assume anything. I used to be a Windows sheep for 20 or so years - since 1996 until 2015. The proof that the whole Windows is bloated?Arch Linux installation with ALL the programs I need and use every day (they're about 20 or 25 programs) - 24.1 GB.
Windows installation with just audio & video drivers and nothing else - 31.1 GB.If that's not bloated, IDK what it is. :D
But that's not what I came here to discuss, so let's leave it at that.
I'm more interested to know which qt5 and qt6 packages control these dialog windows that get sluggish. Maybe if I downgrade the packages, the dialogs will return to normal performance.
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
I'm more interested to know which qt5 and qt6 packages control these dialog windows that get sluggish. Maybe if I downgrade the packages, the dialogs will return to normal performance.
There is no such "package". As @J-Hilk said here:
If not done explicitly differently by the programmer these are native Dialogs & API calls.
the OS is triggered to show an "open file dialog", like the one you would see when browsing for a file in Windows Explorer
-
@Pl45m4 "you would assume Microsoft Windows is a bloated, buggy and poorly designed sketching tool?"
It IS, I don't have to assume anything. I used to be a Windows sheep for 20 or so years - since 1996 until 2015. The proof that the whole Windows is bloated?Arch Linux installation with ALL the programs I need and use every day (they're about 20 or 25 programs) - 24.1 GB.
Windows installation with just audio & video drivers and nothing else - 31.1 GB.If that's not bloated, IDK what it is. :D
But that's not what I came here to discuss, so let's leave it at that.
I'm more interested to know which qt5 and qt6 packages control these dialog windows that get sluggish. Maybe if I downgrade the packages, the dialogs will return to normal performance.
@Valso
There are both "native" and "Qt" versions of "File Dialogs". Which one is used is determined by you in code (where available, some functionality uses only one or the other). You might start by identifying/discovering which one your code uses.If it is the "native" one then whatever problems likely lie there, not in Qt code.
-
@Valso
There are both "native" and "Qt" versions of "File Dialogs". Which one is used is determined by you in code (where available, some functionality uses only one or the other). You might start by identifying/discovering which one your code uses.If it is the "native" one then whatever problems likely lie there, not in Qt code.
@JonB They all look exactly the same way (like on the video in the first post), no matter the program, that's why I thought it was a single package that controls/renders them and also that's why I thought the cause was qt. Qt is the only thing in common these programs have. It can't be a coincidence that the dialog window looks the same way for all qt programs and is equally sluggish for all of them: kolourpaint, mkvtoolnix-gui, audacious, qbittorrent, smplayer, simplescreenrecorder, etc.
I wish there were a way to force "native" on qt programs, cuz the GTK dialogs work just fine.
Edit: I just remembered about qt5ct and qt6ct. Maybe there IS a way, after all! :D
-
@JonB They all look exactly the same way (like on the video in the first post), no matter the program, that's why I thought it was a single package that controls/renders them and also that's why I thought the cause was qt. Qt is the only thing in common these programs have. It can't be a coincidence that the dialog window looks the same way for all qt programs and is equally sluggish for all of them: kolourpaint, mkvtoolnix-gui, audacious, qbittorrent, smplayer, simplescreenrecorder, etc.
I wish there were a way to force "native" on qt programs, cuz the GTK dialogs work just fine.
Edit: I just remembered about qt5ct and qt6ct. Maybe there IS a way, after all! :D
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
I wish there were a way to force "native" on qt programs
There IS :)
QFileDialog::DontUseNativeDialogDon't use the native file dialog. By default, the native file dialog is used unless you use a subclass of QFileDialog that contains the Q_OBJECT macro, or the platform does not have a native dialog of the type that you require.
You have to force not to use the OS native file dialogs
-
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
I wish there were a way to force "native" on qt programs
There IS :)
QFileDialog::DontUseNativeDialogDon't use the native file dialog. By default, the native file dialog is used unless you use a subclass of QFileDialog that contains the Q_OBJECT macro, or the platform does not have a native dialog of the type that you require.
You have to force not to use the OS native file dialogs
@Pl45m4
"You have to force not to use the OS native file dialogs"Actually, that's exactly what I did. IDK about Windows, but here on Arch Linux there's no such a thing as "native file dialogs". The dialogs type depends entirely on the desktop environment and since I'm using Cinnamon (a fork of GNOME) with a few programs from KDE Plasma, the "native dialogs" are those of GTK. The few programs from KDE Plasma use qt (KDE Plasma runs on qt as well) but with the help of the small programs named qt5ct and qt6ct, you can force them to use the GTK file dialogs. I simply had forgotten about their existence. Now I installed these two and forced them to use the GTK file dialogs, so no more waiting for an eternity for the dialog to load. :D
-
@Pl45m4
"You have to force not to use the OS native file dialogs"Actually, that's exactly what I did. IDK about Windows, but here on Arch Linux there's no such a thing as "native file dialogs". The dialogs type depends entirely on the desktop environment and since I'm using Cinnamon (a fork of GNOME) with a few programs from KDE Plasma, the "native dialogs" are those of GTK. The few programs from KDE Plasma use qt (KDE Plasma runs on qt as well) but with the help of the small programs named qt5ct and qt6ct, you can force them to use the GTK file dialogs. I simply had forgotten about their existence. Now I installed these two and forced them to use the GTK file dialogs, so no more waiting for an eternity for the dialog to load. :D
@Valso said in Qt (maybe 5) became sluggish recently. Any ideas why?:
Now I installed these two and forced them to use the GTK file dialogs, so no more waiting for an eternity for the dialog to load.
Then it sounds like a problem of KDE and not Qt. Yes, KDE is closely related to Qt, but it also extends Qt. Most likely it provides its own "native" file dialog for Qt. There is a difference between plain Qt programs and KDE programs. And you were (almost) right initially that KDE would imply Linux as OS, but Qt actually does not (as mentioned before). (Just for completeness sake: the official KDE programs are also available on Windows. I even have Kate installed.)
