| Summary: | digiKam-Window and all Sub-Windows are enlarged too much | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Kurpfaelzer <Stephan.Kranz> |
| Component: | Usability-Ergonomy | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aegoreev, andsh716, caulier.gilles, metzpinguin, peter.eszlari, slipry79 |
| Priority: | NOR | ||
| Version: | 7.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/kde/digikam/commit/f6cbcb76171afa3de2bf184837f7c204156c43d1 | Version Fixed In: | 7.0.0 |
| Sentry Crash Report: | |||
| Attachments: |
DigiKam-7-Beta3.jpg
DigiKam-7-RC.jpg DigiKam-7-RC-100.jpg Settings for the TV-screen Environment |
||
Created attachment 127961 [details]
DigiKam-7-RC.jpg
Created attachment 127962 [details]
DigiKam-7-RC-100.jpg
The behavior is normal, the GUI must scale if you have set 150% under Windows. This is the prerequisite that digiKam is not too "small" on a HiDPI screen. The digikam GUI scales in the same factor as the Windows GUI. We added that the digiKam automatically scales, it could also be set manually using an environment variable. But many users do not know it and have problems with digiKam on HiDPI screens. Did you connect 2 screens? Maik (In reply to Maik Qualmann from comment #3) > The behavior is normal, the GUI must scale if you have set 150% under > Windows. This is the prerequisite that digiKam is not too "small" on a HiDPI > screen. The digikam GUI scales in the same factor as the Windows GUI. We > added that the digiKam automatically scales, it could also be set manually > using an environment variable. But many users do not know it and have > problems with digiKam on HiDPI screens. Did you connect 2 screens? > > Maik No, there is only one screen (my TV-device). (In reply to Maik Qualmann from comment #3) > The behavior is normal, the GUI must scale if you have set 150% under > Windows. This is the prerequisite that digiKam is not too "small" on a HiDPI > screen. But I can't understand why this behaviour has been seen for the first time since the beta3-version I mentioned in my post. We have activated automatic scaling. With this commit: https://invent.kde.org/kde/digikam/-/commit/06323140566c5cfc8350a9149a77a24ce0291153 I tested digiKam under Windows on 4k screens and the GUI has now the right size depending on the scaling factor set in Windows. What resolution have you set? Maik I'm using a resolution of 1920 x 1080 as recommended by my system. Stephan At 1920 x 1080, the 150% is too much, because the Windows GUI is huge. A scaling factor of 150-200% (1.5-2.0) is used with a resolution of 3840 x 2160 (4k). Maik Created attachment 127964 [details]
Settings for the TV-screen
Attached you will find the settings for my TV-screen. But nevertheless, all versions before including the beta3-version mentioned in my starting post had no problems with these settings. Probably you changed some things to fulfill the requirements of the Microsoft store as described in another bug-post. Sorry, but I can't find it in short. Stephan No, compiling digiKam under Windows with MSVC do not include rules for the Windows store. In fact digikam is not yet published to the store. I suspect a changes done in common KF5 framework for all KDE applications, aka with KXmlGui, since we switch from KF5 5.65 to 5.69... Gilles Caulier No, no change in KF5. We have added "qputenv("QT_AUTO_SCREEN_SCALE_FACTOR","1") so that Qt adapts to the scaling factor of Windows. Other projects do the same. Have a look at your screenshot of the Windows dialog, it is just as big as the digikam GUI. We also cannot make it configurable, since this setting must be made before creating a QApplication. If digiKam were a native Windows app, the GUI would always be as large with a scaling factor of 150%.
Maik
What we can do is check whether the environment variable "QT_AUTO_SCREEN_SCALE_FACTOR" is already set and then not overwrite it. You then have to set this variable to "0" in the Windows environment editor. Maik (In reply to Maik Qualmann from comment #13) > We have added > "qputenv("QT_AUTO_SCREEN_SCALE_FACTOR","1") so that Qt adapts to the scaling > factor of Windows. But this has been added after "20200312T152249"? Stephan The change (see comment 6) was added on March 1st. Gilles probably didn't create any new bundles for a few days. This change is definitely the cause. If you compare the screenshots of Beta3 and RC, you will also see that the icon size is now identical to the Windows taskbar icons. As I said, I'll add a workaround for you tonight. Maik During march, the Internet network connection become stochastic here, for few weeks, with a low level bandwidth using gitlab repository. Building bundles was impossible without to wait 4-5 days. But all is back in the normal now, and all bundles are recompiled everyday. Gilles (In reply to Maik Qualmann from comment #16) > The change (see comment 6) was added on March 1st. Gilles probably didn't > create any new bundles for a few days. This change is definitely the cause. > If you compare the screenshots of Beta3 and RC, you will also see that the > icon size is now identical to the Windows taskbar icons. As I said, I'll add > a workaround for you tonight. > > Maik OK. Thank for the clarification and the workaround you would add. Until then, stay healthy! Stephan Created attachment 127992 [details]
Environment
Thank you for the new version.
After installing the program, I proceeded as you described in your comment:
I added the environment variable "QT_AUTO_SCREEN_SCALE_FACTOR" and set this variable to "0" in the Windows environment editor. (see the attachment).
Unfortunately, the GUI is still scaled to 150%.
Stephan
You are far too fast. ((:-)) I will only program the changes in the code in 2 hours and tomorrow new bundles will be available. Maik (In reply to Maik Qualmann from comment #20) > You are far too fast. ((:-)) I will only program the changes in the code in > 2 hours and tomorrow new bundles will be available. > > Maik Ähhh, sorry :-) Git commit f6cbcb76171afa3de2bf184837f7c204156c43d1 by Maik Qualmann. Committed on 29/04/2020 at 18:10. Pushed by mqualmann into branch 'master'. accept user setting for "QT_AUTO_SCREEN_SCALE_FACTOR" FIXED-IN: 7.0.0 M +2 -1 NEWS M +6 -2 core/app/main/main.cpp M +6 -2 core/showfoto/main/main.cpp https://invent.kde.org/kde/digikam/commit/f6cbcb76171afa3de2bf184837f7c204156c43d1 Hurra! It works. The GUI shows the (expected) behaviour. Many thanks for the workaround and your kind assistance. Great work. Have a nice weekend! Stephan yes, Maik rock while Covid containment (:=)))... Why not use C++ instead? QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); Krita makes this configurable through the GUI: https://invent.kde.org/kde/krita/-/blob/ae915410fea8ce5a6024689dd19df763b08386d4/krita/main.cc#L239 The attribute Qt::AA_EnableHighDpiScaling must be set before a QApplication has been created. Since the shared KConfig is not yet available, we would have to save these settings in an extra QSetting file. I will do it after the release of digiKam-7.0.0. Maik Does not work for me even with "QT_AUTO_SCREEN_SCALE_FACTOR" set to 0. For now I have to change scaling in Windows 10 from 150%(recommended) to 100% for digikam. https://drive.google.com/open?id=1YQgvYNIsZlSf3OhoNHn657iPWUBRPiAn dk7-b3 http://commits.kde.org/digikam/3d6d334956bef0aa04ca430235229c7d6ae63a48 Here is my screenshots with 100%, 125% and 150% scaling. I tried adding QT_AUTO_SCREEN_SCALE_FACTOR as both user variable or system variable. I also tried both 0 and 1 value of that variable. https://drive.google.com/file/d/116IPj9IoZuvJWbIm3PEpN8X5mTOtvapZ/view?usp=sharing,%20 https://drive.google.com/file/d/1yR5IpfpTzGHi1QFyGWWuE58otv_OpnIm/view?usp=sharing,%20 https://drive.google.com/file/d/1ziPXELCuVxbcqYSbWn8kXEJVxGA2-DZn/view?usp=sharing The variable QT_AUTO_SCREEN_SCALE_FACTOR definitely works. Post a screenshot of the variable editor. However, we have no authorization for the images in the GDrive. And explain to me why you set the Windows GUI to 150% but asks digiKam not to adapt. Maik (In reply to Maik Qualmann from comment #29) > The variable QT_AUTO_SCREEN_SCALE_FACTOR definitely works. Post a screenshot > of the variable editor. However, we have no authorization for the images in > the GDrive. And explain to me why you set the Windows GUI to 150% but asks > digiKam not to adapt. > > Maik Maik, Let me try again. Scale 100 https://drive.google.com/open?id=1ziPXELCuVxbcqYSbWn8kXEJVxGA2-DZn Scale 125 https://drive.google.com/open?id=1yR5IpfpTzGHi1QFyGWWuE58otv_OpnIm Scale 150 https://drive.google.com/open?id=116IPj9IoZuvJWbIm3PEpN8X5mTOtvapZ Variables (I tried user variables only first, then I tried both user and system variables) https://drive.google.com/open?id=1_rfFEEjUgl-31R_JPWb6hgG9Zt13f3i8 When you open the screenshot for 150% scaling (which is default by the way) you will see why I don't want digikam to scale. Although if most users want that scaling please leave it as is. It is no big deal for me to switch scaling back and forth. It takes seconds and does not require re-login or reboot. You restarted digiKam after adding the variable? Unfortunately the variable cannot be read in full, what I see is correct. The user variable is sufficient. A scaling of 150% is not the standard for Windows, but 100%. I wonder how you work with the Windows GUI at 150%, because it is also so fat with an HD resolution? Otherwise yes, digiKam has to scale like the Windows GUI because otherwise it would be much too small on 4K screens / resolutions. Maik (In reply to Maik Qualmann from comment #31) > You restarted digiKam after adding the variable? Unfortunately the variable > cannot be read in full, what I see is correct. The user variable is > sufficient. A scaling of 150% is not the standard for Windows, but 100%. I > wonder how you work with the Windows GUI at 150%, because it is also so fat > with an HD resolution? Otherwise yes, digiKam has to scale like the Windows > GUI because otherwise it would be much too small on 4K screens / resolutions. > > Maik I did restart digiKam after changing the variables for sure. My windows sets scaling to 150% by default. It also says "150% (Recommended)" Maybe that is because of the resolution which is 1920x1080. The screen size is 13.3". At scaling 100% everything definitely looks too small for me. Maybe I just got used to 150. To be honestly I have never looked at the scaling option until I got this problem with digiKam. I actually set scaling to 125% now and I kind of like how both windows GUI and digiKam look like at this scaling. OS Name: Microsoft Windows 10 Pro OS Version: 10.0.17134 N/A Build 17134 I tested the setting of the environment variable again under 2 different Windows installations, it works perfectly. Maik *** Bug 423146 has been marked as a duplicate of this bug. *** Git commit 94fcd66749d0a6c33f717c11de1a5b7cacb2a03c by Maik Qualmann. Committed on 27/07/2020 at 19:44. Pushed by mqualmann into branch 'master'. add hardware / system settings Since the settings have to be carried out before a QApplication is created, we use an extra settings file based on QSettings. M +20 -13 core/app/main/main.cpp M +3 -0 core/utilities/setup/CMakeLists.txt M +14 -0 core/utilities/setup/setupmisc.cpp M +2 -1 core/utilities/setup/setupmisc.h A +78 -0 core/utilities/setup/system/systemsettings.cpp [License: GPL (v2+)] C +22 -23 core/utilities/setup/system/systemsettings.h [from: core/utilities/setup/setupmisc.h - 054% similarity] A +115 -0 core/utilities/setup/system/systemsettingswidget.cpp [License: GPL (v2+)] C +15 -23 core/utilities/setup/system/systemsettingswidget.h [from: core/utilities/setup/setupmisc.h - 057% similarity] https://invent.kde.org/graphics/digikam/commit/94fcd66749d0a6c33f717c11de1a5b7cacb2a03c *** Bug 425238 has been marked as a duplicate of this bug. *** |
Created attachment 127960 [details] DigiKam-7-Beta3.jpg The last version of digikam, which shows a regular or expected behaviour (which I'm used to), was installed with digiKam-7.0.0-beta3-20200312T152249-Win64.exe All later versions show a behaviour where all windows and views are enlarged too much. To give you an idea of what I'm talking about, I have attached some screenshots. The first screenshot (DigiKam-7-Beta3.jpg) shows the behaviour with the beta3-version, while the next screenshot (DigiKam-7-RC.jpg) is the result after installing digiKam-7.0.0-rc-20200428T165414-Win64. Due to the fact, that my computer is connected to a TV-device in my living-room, the recommended scaling for the Windows-desktop is set to 150%. After switching to a scaling-value of 100%, the digiKam behaviour seems to be as expected (see DigiKam-7-RC-100.jpg).