Bug 420727 - digiKam-Window and all Sub-Windows are enlarged too much
Summary: digiKam-Window and all Sub-Windows are enlarged too much
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Usability-Ergonomy (show other bugs)
Version: 7.0.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-28 20:35 UTC by Kurpfaelzer
Modified: 2020-08-11 21:18 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0


Attachments
DigiKam-7-Beta3.jpg (568.44 KB, image/jpeg)
2020-04-28 20:35 UTC, Kurpfaelzer
Details
DigiKam-7-RC.jpg (343.16 KB, image/jpeg)
2020-04-28 20:36 UTC, Kurpfaelzer
Details
DigiKam-7-RC-100.jpg (533.79 KB, image/jpeg)
2020-04-28 20:36 UTC, Kurpfaelzer
Details
Settings for the TV-screen (128.85 KB, image/jpeg)
2020-04-28 21:59 UTC, Kurpfaelzer
Details
Environment (158.14 KB, image/jpeg)
2020-04-29 15:00 UTC, Kurpfaelzer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kurpfaelzer 2020-04-28 20:35:10 UTC
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).
Comment 1 Kurpfaelzer 2020-04-28 20:36:21 UTC
Created attachment 127961 [details]
DigiKam-7-RC.jpg
Comment 2 Kurpfaelzer 2020-04-28 20:36:44 UTC
Created attachment 127962 [details]
DigiKam-7-RC-100.jpg
Comment 3 Maik Qualmann 2020-04-28 20:46:54 UTC
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
Comment 4 Kurpfaelzer 2020-04-28 20:56:07 UTC
(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).
Comment 5 Kurpfaelzer 2020-04-28 20:58:23 UTC
(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.
Comment 6 Maik Qualmann 2020-04-28 21:20:46 UTC
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
Comment 7 Kurpfaelzer 2020-04-28 21:31:29 UTC
I'm using a resolution of 1920 x 1080 as recommended by my system.

Stephan
Comment 8 Maik Qualmann 2020-04-28 21:47:06 UTC
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
Comment 9 Kurpfaelzer 2020-04-28 21:59:24 UTC
Created attachment 127964 [details]
Settings for the TV-screen
Comment 10 Kurpfaelzer 2020-04-28 22:03:57 UTC
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
Comment 11 Kurpfaelzer 2020-04-28 22:10:38 UTC
https://bugs.kde.org/show_bug.cgi?id=398582#c9
Comment 12 caulier.gilles 2020-04-29 01:39:54 UTC
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
Comment 13 Maik Qualmann 2020-04-29 06:02:15 UTC
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
Comment 14 Maik Qualmann 2020-04-29 06:42:11 UTC
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
Comment 15 Kurpfaelzer 2020-04-29 07:14:05 UTC
(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
Comment 16 Maik Qualmann 2020-04-29 07:20:38 UTC
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
Comment 17 caulier.gilles 2020-04-29 07:32:33 UTC
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
Comment 18 Kurpfaelzer 2020-04-29 08:29:58 UTC
(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
Comment 19 Kurpfaelzer 2020-04-29 15:00:57 UTC
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
Comment 20 Maik Qualmann 2020-04-29 15:06:39 UTC
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
Comment 21 Kurpfaelzer 2020-04-29 15:33:20 UTC
(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 :-)
Comment 22 Maik Qualmann 2020-04-29 18:12:49 UTC
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
Comment 23 Kurpfaelzer 2020-04-30 15:47:11 UTC
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
Comment 24 caulier.gilles 2020-04-30 16:00:05 UTC
yes, Maik rock while Covid containment (:=)))...
Comment 25 Peter Eszlari 2020-05-01 20:08:35 UTC
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
Comment 26 Maik Qualmann 2020-05-02 15:17:10 UTC
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
Comment 27 Andrius 2020-05-11 14:25:53 UTC
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
Comment 28 Andrius 2020-05-11 17:00:53 UTC
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
Comment 29 Maik Qualmann 2020-05-11 17:10:20 UTC
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
Comment 30 Andrius 2020-05-11 17:23:10 UTC
(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.
Comment 31 Maik Qualmann 2020-05-11 18:05:42 UTC
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
Comment 32 Andrius 2020-05-11 18:46:58 UTC
(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
Comment 33 Maik Qualmann 2020-05-12 05:56:11 UTC
I tested the setting of the environment variable again under 2 different Windows installations, it works perfectly.

Maik
Comment 34 Maik Qualmann 2020-06-18 10:57:25 UTC
*** Bug 423146 has been marked as a duplicate of this bug. ***
Comment 35 Maik Qualmann 2020-07-27 19:48:13 UTC
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
Comment 36 Maik Qualmann 2020-08-11 21:18:16 UTC
*** Bug 425238 has been marked as a duplicate of this bug. ***