Bug 24200

Created attachment 10673 [details]
regular dpi (100% scaling), 2560x1440 resolution monitor

Created attachment 10674 [details]
badly adjusted HiDPI rendering (200% scaling, 3200x1800 laptop)

Hi Christian,
Thanks for the feed back.
I presume that the "normal" rendering is displayed at first boot, and that 200% scaling is after some settings.
What about enlarging the window manually? Is such enlarging kept after new connection?
Papoteur

Hi Christian, 
How did you apply scaling?

Hi, the scaling is applied/detected automatically by gnome (double-checked with live-iso that it auto-detects).
You can configure it in Gnome settings under monitor section.

Gnome offers 100%, 200% and 300%, with 200% being the one chosen for my display by default (and a scaling which works, 175% or similar would be even better, but that's not supported ootb) I think I reconfigured font-sizes to tune appearance a little further using gnome-tweak-tool (there you could also specify font scaling factor to modify overall scaling, but I have that at 1x)

I can manually widen the window, so that the buttons get wide enough and all text it put into single line (the buttons don't get larger vertically when increasing the height of the window.

But no, the enlarging is not kept. When closing the window and launching mageia-welcome again, it is back to the initial size, with the text wrapped to two lines/buttons not large enough to fit the text.

See attached screenshots

Created attachment 10678 [details]
gnome monitor settings/where to configure high-dpi scaling for your monitor

Created attachment 10679 [details]
gnome-tweak-tool's font-settings - there you could specify font scaling and specify default fonts

Created attachment 10680 [details]
resized the welcome window to minimum width that fits the german translation

(In reply to Christian Lohmaier from comment #5)
> Hi, the scaling is applied/detected automatically by gnome (double-checked
> with live-iso that it auto-detects).
> You can configure it in Gnome settings under monitor section.
> 
> Gnome offers 100%, 200% and 300%, with 200% being the one chosen for my
> display by default (and a scaling which works, 175% or similar would be even
> better, but that's not supported ootb) I think I reconfigured font-sizes to
> tune appearance a little further using gnome-tweak-tool (there you could
> also specify font scaling factor to modify overall scaling, but I have that
> at 1x)
Thanks,
I have not real idea of what imply this settings. Apparently, it does apply on all objects.
Next release 1.92 will include logs of 2 value I expect they will reflect some parameters of this setting.to get them, you will have to run:
QT_LOGGING_RULES=qml=true mageiwelcome
> 
> I can manually widen the window, so that the buttons get wide enough and all
> text it put into single line (the buttons don't get larger vertically when
> increasing the height of the window.
1.92 will manage the height adaptation
> 
> But no, the enlarging is not kept. When closing the window and launching
> mageia-welcome again, it is back to the initial size, with the text wrapped
> to two lines/buttons not large enough to fit the text.
> 
> See attached screenshots
I will include them in a future release.
Papoteur

1.92 in now available.

Hi Christian,
1.93 is now pushed, it has improvements to manage HiDPI.
Can you check that this release is OK, or if some  problems are are still present?

Created attachment 10692 [details]
mageia-welcome after udpate - buttons now two-row, but not vertically centered, and not wide enough

it is only a slight improvement unfortunately.
The buttons now can be two-lines high, but still the text is cutoff/the buttons are not wide enough (for German translation at least).

Also the single-line ones are not vertically centered in the button, and that also looks ugly..

Hello Christian,
Can you run in console:

 QT_LOGGING_RULES=qml=true mageiawelcome
and send here what is reported in console.

not much is reported:
$ QT_LOGGING_RULES=qml=true mageiawelcome
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qml: Screen:  1 10.811359026369166
$

Not much, but useful.
"Screen: 1"
This is the screen factor reported, which I use to scale the window. Thus, this is not what I expected. 
The second value is the density in px/mm.
It seems you are using Gnome/Wayland.
Can you try this:
QT_QPA_PLATFORM=wayland QT_LOGGING_RULES=qml=true mageiawelcome

Created attachment 10695 [details]
some other updates also had an impact, now looks OK

seems some other updates also did make a difference - now looks more reasonable, only issue left is the missing vertical alignment on single-line entries.

And FYI running with the QT_QPA_PLATFORM option just gives error about not having wayland plugin:
$ QT_QPA_PLATFORM=wayland QT_LOGGING_RULES=qml=true mageiawelcome
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Christian,
Are you using Gnome on Wayland or Gnome on Xorg?

Created attachment 10747 [details]
now single-lines are vertically centered, but not wide enough

appearance keeps changing :-)
Now the vertical alignment is correct, but the buttons are no longer wide enough. And there's a margin/padding error on the right side when resizing (see next attachment)

(I'm using Gnome w/ wayland)

Attachment 10695 is obsolete: 0 => 1
Attachment 10680 is obsolete: 0 => 1
Attachment 10692 is obsolete: 0 => 1
Attachment 10674 is obsolete: 0 => 1

Created attachment 10748 [details]
note the rightmost button having no right margin/padding

the rightmost item doesn't have any padding, no matter how wide you make the window

Created attachment 10749 [details]
when resizing it properly picks right size of buttons - minimal width to fit all in one line

Created attachment 10750 [details]
just a tiny bit smaller and it switches to two-line, with proper padding around the text

Note the "W" in the last button is not pushed out of the left of the button, but instead it decides to split the line.

So two problems remain:
* initial size
* rightmost padding/margin

Hi Christian,
For the initial size problem, I will try to get some info from gnome.
Can you provide me the value of Gdk/WindowScalingFactor ?
You can surely get it from:
 gsettings get org.gnome.settings-daemon.plugins.xsettings WindowScalingFactor

nope, that's not the way to properly set the scaling factor in gnome anymore, and even before it would be the wrong command.
the setting you mean would be in a overrides property, no direct WindowScalingFactor one...
But there's no legacy scaling factor set here:
$ gsettings get org.gnome.settings-daemon.plugins.xsettings overrides 
{'Gtk/ShellShowsAppMenu': <1>}

Gnome's hdpi mode is set to auto/default (0), and would be
$ gsettings get org.gnome.desktop.interface scaling-factor
uint32 0

which is 200% for my screen (see also the gnome settings screenshot in attachment 10678 [details] )

Thanks Christian,
The next release 1.95 is coming. It includes a reading of scaling-factor as above.
The window size is multiplied by this factor.

1.95 is released.
I installed Gnome in a Vitualbox, but the devices setting doesn't offer the ability to set scalibity.
Thus, I can't conduct any test.
What is the result for you?

(In reply to papoteur from comment #24)
> Thanks Christian,
> The next release 1.95 is coming. It includes a reading of scaling-factor as
> above.

Sorry for the confusion/if I wasn't clear that this cannot be used, as it is the user-setting, and unless the user manually sets a factor, it is 0, so you cannot distinguish between regular and hidpi screen just with that.


I looked for solution myself and have two variants for you:

* GNOME for a long time has set its base DPI to the bogus value 96, you can
  exploit that and determine the scaling factor that way:

        factor = screen.logicalDotsPerInch()/96

this can be considered a hack though, but should just fine (at least does for me)
But note that the value used here depends on the text scaling factor, but that's advanced option via gnome-tweak tool...

* use Gdk to query the factor directly using API:

        import gi
        gi.require_version('Gdk', '3.0')
        from gi.repository import Gdk
        # pre-3.22, otherwise deprecated
        #factor = Gdk.Screen.get_default().get_monitor_scale_factor(0)
        factor = Gdk.Display.get_default().get_monitor(0).get_scale_factor()


the obsolete variant in case you want to backport something to mga6 ..

https://lazka.github.io/pgi-docs/#Gdk-3.0/classes/Screen.html#Gdk.Screen.get_monitor_scale_factor (deprecated)
https://lazka.github.io/pgi-docs/#Gdk-3.0/classes/Monitor.html#Gdk.Monitor.get_scale_factor

Great thanks Christian.
I the code your propose, you use Gtk.Display, but the documentation you refers to is Gdk.Monitor.
What is the difference?
However, this is OK, I will use it.
Papoteur

Release 1.96 is coming and should solve this question.

(In reply to papoteur from comment #27)
> Great thanks Christian.
> I the code your propose, you use Gtk.Display, but the documentation you
> refers to is Gdk.Monitor.
> What is the difference?

don't get you - both are Gdk.* - and the function is on the Gdk.Monitor object, but you cannot pull that out of thin air - so the code uses Gdk.Display's get_monitor() function to get the Gdk.Monitor representing the first monitor (as IMHO stupidly get_primary_monitor() is null in single-monitor setup/when not explicity set - but getting the first monitor should be good enough.



Some remark re code style/structure:
IMHO it would make more sense to have the gnome/wayland checks in the factor function and not separated in the constructor of the config object.


Apart from that I can confirm that the size is now correct, the remaining problem is the bad padding/margin. (right button cut off, no right margin around it, while margin left to the first button is larger than the margin between the buttons)

Is there still problems in cauldron?

I consider there is no more problem.
Please reopen if this not the case.
Papoteur

Status: NEW => RESOLVED
Resolution: (none) => FIXED

FYI: found some time to update the affected system to the WIP mga9 and can confirm: much better now.