Re: [Development] Updated high-DPI support for Qt 5.14
On 2019-10-04 12:38, Morten Sørvig wrote: On 3 Oct 2019, at 09:44, Mark De Wit wrote: Is there a chance that the high-dpi work will fix the dpi-awareness of the Fusion theme as reported in https://bugreports.qt.io/browse/QTBUG-74100 ? Yes, looks like an easy fix: https://codereview.qt-project.org/c/qt/qtbase/+/276261 Hi, is there similar work done for the default Windows style? For me in Qt 5.13.1 that looks still rather broken with fractional scaling even at common values of 125% or 150%. (I know this is mentioned in the docs, still that is the default style and Fusion looks out of place in many other ways) Beside that I now collected all issues I have found with fractional scaling on X11 in extra bugs. https://bugreports.qt.io/browse/QTBUG-78962 https://bugreports.qt.io/browse/QTBUG-78963 https://bugreports.qt.io/browse/QTBUG-78964 As you can see on the screenshots on https://cullmann.io/posts/kde-qt-highdpi-scaling/ the make a current experience with fractional scaling not that nice (same on Windows). Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den fre 4 okt. 2019 12:39Morten Sørvig skrev: > > > > On 3 Oct 2019, at 09:44, Mark De Wit wrote: > > > > Is there a chance that the high-dpi work will fix the dpi-awareness of > the Fusion theme as reported in > https://bugreports.qt.io/browse/QTBUG-74100 ? > > Yes, looks like an easy fix: > https://codereview.qt-project.org/c/qt/qtbase/+/276261 > > > > > Last time I checked there was a fair amount of drawing code that didn't > check what screen a widget was on, and hence used "global" scaling (if any). > > QPainter picks up the correct factor via the paint device, so the > draw-on-widget case should work without checking the screen. But there > might be other cases such as painting on a intermediate pixmap which needs > fixing. > I also think there might be some wonkiness in generation of pixmaps from SVG icons specified via theme lookup. I think it was due to the icon theme engine possibly not using the correct overload... Something like that.. Don't have the bug number (on my phone on a train atm) and it may already have been fixed. We have some manual workaround code for that issue in our app. Been meaning to look into what the status in recent Qt is (we unfortunately must work well with the 5.9 in Ubuntu 18.04 until 20.04 is out). Elvis > Morten > > > > > Mark > > > >> -Original Message- > >> From: Development On Behalf Of > >> Christoph Cullmann > >> Sent: 01 October 2019 22:19 > >> To: development@qt-project.org > >> Subject: Re: [Development] Updated high-DPI support for Qt 5.14 > >> > >> Hi, > >> > >> actually, unrelated to how one can configure the stuff, at the moment, > I see > >> still a lot of Qt internal rendering artifacts for fractional scaling. > >> > >> See https://bugreports.qt.io/browse/QTBUG-66036 > >> > >> For some I made now hacky workarounds in KTextEditor, see > >> https://bugs.kde.org/show_bug.cgi?id=390451 > >> > >> Some still remain for factors like 1.1 and text selections... > >> > >> And one should think about if it is really a good idea to accept > factors like 1.1 > >> and not round them to some at least 1 / 2^x factor that doesn't lead to > >> interesting accumulating rounding errors. (in addition to the opt-out of > >> fractional scaling at all) > >> > >> Greetings > >> Christoph > >> > >> -- > >> Ignorance is bliss... > >> https://cullmann.io | https://kate-editor.org > >> ___ > >> Development mailing list > >> Development@qt-project.org > >> https://lists.qt-project.org/listinfo/development > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
> On 3 Oct 2019, at 09:44, Mark De Wit wrote: > > Is there a chance that the high-dpi work will fix the dpi-awareness of the > Fusion theme as reported in https://bugreports.qt.io/browse/QTBUG-74100 ? Yes, looks like an easy fix: https://codereview.qt-project.org/c/qt/qtbase/+/276261 > > Last time I checked there was a fair amount of drawing code that didn't check > what screen a widget was on, and hence used "global" scaling (if any). QPainter picks up the correct factor via the paint device, so the draw-on-widget case should work without checking the screen. But there might be other cases such as painting on a intermediate pixmap which needs fixing. Morten > > Mark > >> -Original Message- >> From: Development On Behalf Of >> Christoph Cullmann >> Sent: 01 October 2019 22:19 >> To: development@qt-project.org >> Subject: Re: [Development] Updated high-DPI support for Qt 5.14 >> >> Hi, >> >> actually, unrelated to how one can configure the stuff, at the moment, I see >> still a lot of Qt internal rendering artifacts for fractional scaling. >> >> See https://bugreports.qt.io/browse/QTBUG-66036 >> >> For some I made now hacky workarounds in KTextEditor, see >> https://bugs.kde.org/show_bug.cgi?id=390451 >> >> Some still remain for factors like 1.1 and text selections... >> >> And one should think about if it is really a good idea to accept factors >> like 1.1 >> and not round them to some at least 1 / 2^x factor that doesn't lead to >> interesting accumulating rounding errors. (in addition to the opt-out of >> fractional scaling at all) >> >> Greetings >> Christoph >> >> -- >> Ignorance is bliss... >> https://cullmann.io | https://kate-editor.org >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On 2019-10-03 13:42, Morten Sørvig wrote: On 1 Oct 2019, at 23:18, Christoph Cullmann wrote: Hi, actually, unrelated to how one can configure the stuff, at the moment, I see still a lot of Qt internal rendering artifacts for fractional scaling. See https://bugreports.qt.io/browse/QTBUG-66036 For some I made now hacky workarounds in KTextEditor, see https://bugs.kde.org/show_bug.cgi?id=390451 Some still remain for factors like 1.1 and text selections... And one should think about if it is really a good idea to accept factors like 1.1 and not round them to some at least 1 / 2^x factor that doesn't lead to interesting accumulating rounding errors. (in addition to the opt-out of fractional scaling at all) I think we can do so, if needed. Which factor, and what is the trade-off between a small or large factor? The trade-off would be how much precision you need. At the moment, you can scale with e.g. 1.1, that will lead to rounding errors even after a few computations as 1.1 is really a bad number to represent as float. This will then again lead to small rendering glitches. If we e.g. limit internal the minimal scale quant to something like 1/16 or 1/32 or similar, we will run for reasonable regions (e.g. all applications that just use 32 Bit integer coordinates) in nö real rounding errors at all. See experiments in https://bugs.kde.org/show_bug.cgi?id=412447 Using reasonable factors removes all remaining artifacts (beside the fillRect/clipping errors I reported now as extra bugs) Greetings Christoph Morten Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
> On 1 Oct 2019, at 23:18, Christoph Cullmann wrote: > > Hi, > > actually, unrelated to how one can configure the stuff, at the moment, > I see still a lot of Qt internal rendering artifacts for fractional scaling. > > See https://bugreports.qt.io/browse/QTBUG-66036 > > For some I made now hacky workarounds in KTextEditor, see > https://bugs.kde.org/show_bug.cgi?id=390451 > > Some still remain for factors like 1.1 and text selections... > > And one should think about if it is really a good idea to accept factors like > 1.1 > and not round them to some at least 1 / 2^x factor that doesn't lead to > interesting > accumulating rounding errors. (in addition to the opt-out of fractional > scaling at all) I think we can do so, if needed. Which factor, and what is the trade-off between a small or large factor? Morten > > Greetings > Christoph > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Is there a chance that the high-dpi work will fix the dpi-awareness of the Fusion theme as reported in https://bugreports.qt.io/browse/QTBUG-74100 ? Last time I checked there was a fair amount of drawing code that didn't check what screen a widget was on, and hence used "global" scaling (if any). Mark > -Original Message- > From: Development On Behalf Of > Christoph Cullmann > Sent: 01 October 2019 22:19 > To: development@qt-project.org > Subject: Re: [Development] Updated high-DPI support for Qt 5.14 > > Hi, > > actually, unrelated to how one can configure the stuff, at the moment, I see > still a lot of Qt internal rendering artifacts for fractional scaling. > > See https://bugreports.qt.io/browse/QTBUG-66036 > > For some I made now hacky workarounds in KTextEditor, see > https://bugs.kde.org/show_bug.cgi?id=390451 > > Some still remain for factors like 1.1 and text selections... > > And one should think about if it is really a good idea to accept factors like > 1.1 > and not round them to some at least 1 / 2^x factor that doesn't lead to > interesting accumulating rounding errors. (in addition to the opt-out of > fractional scaling at all) > > Greetings > Christoph > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Hi, actually, unrelated to how one can configure the stuff, at the moment, I see still a lot of Qt internal rendering artifacts for fractional scaling. See https://bugreports.qt.io/browse/QTBUG-66036 For some I made now hacky workarounds in KTextEditor, see https://bugs.kde.org/show_bug.cgi?id=390451 Some still remain for factors like 1.1 and text selections... And one should think about if it is really a good idea to accept factors like 1.1 and not round them to some at least 1 / 2^x factor that doesn't lead to interesting accumulating rounding errors. (in addition to the opt-out of fractional scaling at all) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Friday, 27 September 2019 10:51:00 PDT Morten Sørvig wrote:
> > The problem on that one is that you're forcing me to keep a value per each
> > individual monitor I connect to regularly. With the laptop's display
> > panel, that's 4 or 5. Since they are different actual monitors, each has
> > their own DPI value, which is obtained by Qt. And some monitors report
> > wildly incorrect DPI values, like a 27" monitor saying it's 160x90mm in
> > size. So what's the policy for a brand new monitor we connect to (say, a
> > projector in a conference room)? Does it:
> > a) keep the physical one from the monitor?
> > b) use 96x96?
> > c) use one of the other monitor's settings?
> > (hint: a, b and c are wrong)
> >
> > Right now, I need exactly two values: the display panel's multiplicative
> > factor of 2 and the external output's multiplicative factor of 2.
>
>
> Right, I think I see what you are doing now (maybe). But what about non-Qt
> apps? Do you configure them manually as well?
$ xdpyinfo | grep dots
resolution:217x217 dots per inch
$ cat ~/.config/plasma-workspace/env/var.sh
export CLUTTER_SCALE=2
export GDK_BACKEND=x11
#export GDK_SCALE=2
export LDAPTLS_CACERT=/etc/ssl/ca-bundle.pem
#export LD_LIBRARY_PATH=$HOME/lib
#export QT_MESSAGE_PATTERN='[%{time boot}] %{appname}(%{pid} %{threadid}):%
{if-category} %{category}:%{endif} %{message}'
export QT_SCREEN_SCALE_FACTORS='2;2'
$ cat ~/.config/startupconfig
#! /bin/sh
# kcminputrc Mouse cursorTheme 'breeze_cursors'
kcminputrc_mouse_cursortheme=breeze_cursors
# kcminputrc Mouse cursorSize ''
kcminputrc_mouse_cursorsize=''
# ksplashrc KSplash Theme Breeze
ksplashrc_ksplash_theme=Breeze
# ksplashrc KSplash Engine KSplashQML
ksplashrc_ksplash_engine=KSplashQML
# kdeglobals KScreen ScaleFactor ''
kdeglobals_kscreen_scalefactor=1
# kdeglobals KScreen ScreenScaleFactors ''
kdeglobals_kscreen_screenscalefactors=''
# kcmfonts General forceFontDPI 0
kcmfonts_general_forcefontdpi=0
$ grep -Fe '[Desktop' -e Exec ~/.local/share/applications/google-
chrome.desktop
[Desktop Action NewPrivateWindow]
Exec=/usr/bin/google-chrome-stable --incognito
[Desktop Action NewWindow]
Exec=/usr/bin/google-chrome-stable
[Desktop Entry]
Exec=/usr/bin/google-chrome-stable --force-device-scale-factor=2.25 %U
The GDK scale I had turn off because otherwise it conflict with how Qt scales.
My system is set to 216 dpi, which means fonts are the right size. But if I
set the GDK scale, it scales the fonts *again* so I get huge screens. So I'm
setting for readable GTK text with tiny icons.
Firefox seems to work fine and has right-sized icons. Google Chrome is scaled
to 225%.
> If this logic could be contained within the XCB platform plugin, and the
> result reported to QtGui via QPlatformScreen::logicalDpi(), then I would
> be happy. (And, setHighDpiScaleFactorRoundingPolicy could work as
> documented, too).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
> On 27 Sep 2019, at 17:04, Thiago Macieira wrote: > > On Friday, 27 September 2019 03:56:44 PDT Morten Sørvig wrote: >> Configuring Windows is a good example here: you set the slider to one of >> 100% - 125% - 150% - 175% - 200% depending on monitor pixel density and >> viewing distance. There’s then a single value to configure. > > Well, that's a good example: setting a factor, not the absolute value. Yes, agreed. A factor is better UI than an absolute value. We are talking about DPI at lest partly for historical reasons: the windows percentage setting has always been reported as logical DPI by QPlatformScreen::logicalDpi(), and that has not changed. > >>> Moreover, I can have two different monitors connected to the same output >>> (at different times, of course). Since they have different DPI, the >>> multiplicative factor allows me to set it once for both, but if I set a >>> DPI setting, it'll likely be wrong for at least one of them. >> >> Yes, we need per-monitor settings (DPI or scale). > > The problem on that one is that you're forcing me to keep a value per each > individual monitor I connect to regularly. With the laptop's display panel, > that's 4 or 5. Since they are different actual monitors, each has their own > DPI value, which is obtained by Qt. And some monitors report wildly incorrect > DPI values, like a 27" monitor saying it's 160x90mm in size. So what's the > policy for a brand new monitor we connect to (say, a projector in a > conference > room)? Does it: > a) keep the physical one from the monitor? > b) use 96x96? > c) use one of the other monitor's settings? > (hint: a, b and c are wrong) > > Right now, I need exactly two values: the display panel's multiplicative > factor of 2 and the external output's multiplicative factor of 2. Right, I think I see what you are doing now (maybe). But what about non-Qt apps? Do you configure them manually as well? If this logic could be contained within the XCB platform plugin, and the result reported to QtGui via QPlatformScreen::logicalDpi(), then I would be happy. (And, setHighDpiScaleFactorRoundingPolicy could work as documented, too). Morten > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Friday, 27 September 2019 03:56:44 PDT Morten Sørvig wrote: > Configuring Windows is a good example here: you set the slider to one of > 100% - 125% - 150% - 175% - 200% depending on monitor pixel density and > viewing distance. There’s then a single value to configure. Well, that's a good example: setting a factor, not the absolute value. > > Moreover, I can have two different monitors connected to the same output > > (at different times, of course). Since they have different DPI, the > > multiplicative factor allows me to set it once for both, but if I set a > > DPI setting, it'll likely be wrong for at least one of them. > > Yes, we need per-monitor settings (DPI or scale). The problem on that one is that you're forcing me to keep a value per each individual monitor I connect to regularly. With the laptop's display panel, that's 4 or 5. Since they are different actual monitors, each has their own DPI value, which is obtained by Qt. And some monitors report wildly incorrect DPI values, like a 27" monitor saying it's 160x90mm in size. So what's the policy for a brand new monitor we connect to (say, a projector in a conference room)? Does it: a) keep the physical one from the monitor? b) use 96x96? c) use one of the other monitor's settings? (hint: a, b and c are wrong) Right now, I need exactly two values: the display panel's multiplicative factor of 2 and the external output's multiplicative factor of 2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
> On 26 Sep 2019, at 04:48, Thiago Macieira wrote: > > On Wednesday, 25 September 2019 05:54:20 PDT Morten Sørvig wrote: >> I see two differences between setting the DPI vs a factor: >> >> - You set one value per screen (DPI) instead of two (DPI & factor) >> >> - Qt can compute the factor, according to policy set by the application (as >> mentioned above) > > Assume no one will ever call that function. What's the outcome? We use the default policy: RoundPreferFloor in Qt 5, PassThrough in Qt 6 (if/when https://codereview.qt-project.org/c/qt/qtbase/+/273956 lands) > > Also, DPIs are a physical property of the monitor, but they don't account for > my distance to it. Previously, I only needed one parameter to toggle, which > was either 1 or 2. Now, in order to properly configure, I need to find out > what the current DPI is and then update it. Some displays like projectors don’t have well-defined physical DPI though. In some cases like macOS configured for “more/less space” the relationship between frame buffer pixels and display pixels is not 1:1, which makes physical DPI less useful. The DPI we are using in Qt is the logical DPI; it need not correspond to any physical measurement of the monitor. Configuring Windows is a good example here: you set the slider to one of 100% - 125% - 150% - 175% - 200% depending on monitor pixel density and viewing distance. There’s then a single value to configure. > > Moreover, I can have two different monitors connected to the same output (at > different times, of course). Since they have different DPI, the > multiplicative > factor allows me to set it once for both, but if I set a DPI setting, it'll > likely be wrong for at least one of them. Yes, we need per-monitor settings (DPI or scale). > >>> Anyway, what's the correct way to specify now that one of my external >>> monitors is highdpi but the other isn’t? >> >> >> The correct way would be to configure the windowing system. Qt would then >> pick up the configuration via the platform plugin. > > Agreed, but for those of us still on X11, that's not na option. > >> In practice, the environment variables you are currently using may be your >> best option on X11. > > Ok, thanks. This becomes the recommendation for KDE Plasma Shell > configuration > for X11 then: continue using the variables as they are. > >> If possible, I’d like us to move away from relying on setting environment >> variables, and/or switch to specifying per-screen DPI instead of a scale >> factor. > > Sure, but where, on X11? I don’t know. That’s the $1M question. Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Thursday, 26 September 2019 21:07:38 CEST Thiago Macieira wrote: > On Thursday, 26 September 2019 08:03:32 PDT Edward Welbourne wrote: > > If possible, I’d like us to move away from relying on setting > > environment > > variables, and/or switch to specifying per-screen DPI instead of a > > scale > > factor. > > > > On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote: > > >>> Sure, but where, on X11? > > > > On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote: > > >> xrandr? > > > > Thiago Macieira (26 September 2019 16:47) > > > > > That's not per screen. So my question stands. > > > > For give a simple non-graphics-expert's probably dumb question: > > IIUC, xrandr is per-display (as in X DISPLAY values). > > How is that distinct from per-screen ? > > Ok, let's be specific about terms: > > * display: the X display, like :0, :1, localhost:11 > * screen: the sub-display X screen, like :0.0, :0.1. Anything besides "0" > has probably been broken for over 20 years. > * output or monitor: the multiple connections that xrandr can manipulate > > xrandr can set a lot of parameters for each output, most frequently the > video mode, refresh rate and rotation. It can set a scale factor but this > is a SW scaler that applies to all pixels. You don't get to opt out of it > and display at highdpi yourself. > > It can also set the full X's DPI mode. X only knows a single DPI for all of > its outputs. > > Note the --help output and the indentations: > usage: xrandr [options] > where options are: > --display or -d > --help > -o > or --orientation > -qor --query > -s /x or --size /x > -r or --rate or --refresh > -vor --version > -x(reflect in x) > -y(reflect in y) > --screen > --verbose > --current > --dryrun > --nograb > --prop or --properties > --fb x > --fbmm x > --dpi / > --output > --auto > --mode > --preferred > --pos x > --rate or --refresh > --reflect normal,x,y,xy > --rotate normal,inverted,left,right > --left-of > --right-of > --above > --below > --same-as > --set > --scale [x] > --scale-from x > --transform > --filter nearest,bilinear > --off > --crtc > --panning x[++[/x++[ > ]]] > --gamma [::] > --brightness > --primary > [... more ...] > > There's a "/" in the --dpi switch, but last time I tried that, it > affected both outputs. Granted, that was several years ago, as highdpi has > been working fine for me for that long, and granted it might have been > broken applications. If it's the latter, then we need to cope with them > anyway and therefore setting per-output DPI is not adviseable. > > I think we should consider HighDPI on X an evolutionary dead-end. Don't try > to innovate, just keep what's working working. Well, you can set the physical size, which relative to the resolution is what Qt uses to calculate the per-screen dpi on XCB. But, yes it is more interesting what we can do moving forward more generically. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Thursday, 26 September 2019 08:03:32 PDT Edward Welbourne wrote: > If possible, I’d like us to move away from relying on setting > environment > variables, and/or switch to specifying per-screen DPI instead of a > scale > factor. > > On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote: > >>> Sure, but where, on X11? > > On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote: > >> xrandr? > > Thiago Macieira (26 September 2019 16:47) > > > That's not per screen. So my question stands. > > For give a simple non-graphics-expert's probably dumb question: > IIUC, xrandr is per-display (as in X DISPLAY values). > How is that distinct from per-screen ? Ok, let's be specific about terms: * display: the X display, like :0, :1, localhost:11 * screen: the sub-display X screen, like :0.0, :0.1. Anything besides "0" has probably been broken for over 20 years. * output or monitor: the multiple connections that xrandr can manipulate xrandr can set a lot of parameters for each output, most frequently the video mode, refresh rate and rotation. It can set a scale factor but this is a SW scaler that applies to all pixels. You don't get to opt out of it and display at highdpi yourself. It can also set the full X's DPI mode. X only knows a single DPI for all of its outputs. Note the --help output and the indentations: usage: xrandr [options] where options are: --display or -d --help -o or --orientation -qor --query -s /x or --size /x -r or --rate or --refresh -vor --version -x(reflect in x) -y(reflect in y) --screen --verbose --current --dryrun --nograb --prop or --properties --fb x --fbmm x --dpi / --output --auto --mode --preferred --pos x --rate or --refresh --reflect normal,x,y,xy --rotate normal,inverted,left,right --left-of --right-of --above --below --same-as --set --scale [x] --scale-from x --transform --filter nearest,bilinear --off --crtc --panning x[++[/x++[ ]]] --gamma [::] --brightness --primary [... more ...] There's a "/" in the --dpi switch, but last time I tried that, it affected both outputs. Granted, that was several years ago, as highdpi has been working fine for me for that long, and granted it might have been broken applications. If it's the latter, then we need to cope with them anyway and therefore setting per-output DPI is not adviseable. I think we should consider HighDPI on X an evolutionary dead-end. Don't try to innovate, just keep what's working working. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
If possible, I’d like us to move away from relying on setting environment variables, and/or switch to specifying per-screen DPI instead of a scale factor. On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote: >>> Sure, but where, on X11? On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote: >> xrandr? Thiago Macieira (26 September 2019 16:47) > That's not per screen. So my question stands. For give a simple non-graphics-expert's probably dumb question: IIUC, xrandr is per-display (as in X DISPLAY values). How is that distinct from per-screen ? Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote: > On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote: > > > If possible, I’d like us to move away from relying on setting > > > environment > > > variables, and/or switch to specifying per-screen DPI instead of a scale > > > factor. > > > > Sure, but where, on X11? > > xrandr? That's not per screen. So my question stands. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Thursday, 26 September 2019 09:29:10 CEST Shawn Rutledge wrote: > KDE also needs to set env variables to get correct behavior, right? Which > ones does it do right? Which ones are wrong or unnecessary in 5.14? KDE sets the Qt environment variables to set the right scaling. GNOME has their own settings, and refuses to set Qt environment variables, on GTK/XCB desktops we currently just use the fallback DPI value GNOME sets for Xft applications, which is a fixed value of (96 * scaling_ratio). Beyond that there is the screen values from X11. Both physical reported screen size (from EDID I believe) and a DPI number from xrandr. It appears we only use the former now. Not sure if they recalculate based on each other, but at least some years ago GNOME used to override the latter of the two. As long as nothing else is overriding or environmental values control Qt's scaling, I believe users can change these X11 values to get Qt to scale per screen. There is also the fontconfig dpi setting, but I think everybody ignores that these days. Ideally we should implement something listening to the real GNOME settings, so we can get per screen data, and make it also works for wayland. We could also provide a better way for KDE to configure our settings without environment variables, but at least KDE is willing to set what we need, so it is less of an issue. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Sep 26, 2019, at 9:08, Allan Sandfeld Jensen wrote: > On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote: >>> If possible, I’d like us to move away from relying on setting environment >>> variables, and/or switch to specifying per-screen DPI instead of a scale >>> factor. >> >> Sure, but where, on X11? > > xrandr? > > We read the X11 setting there. Though if you use GNOME they will override the > values to something meaningless, and we don't currently read the GNOME per > screen settings. For KDE it should work though. Can you be more specific? Which values become meaningless, and what sort of values are we talking about? Which ones does KDE get right? KDE also needs to set env variables to get correct behavior, right? Which ones does it do right? Which ones are wrong or unnecessary in 5.14? Ultimately my goals are 1) figure out how to configure a plain X11/openbox session to get what I want (arbitrary scaling on each display) 2) figure out how to do it in a wayland compositor (which should probably be done in the same way that KDE does or should do it). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote: > > If possible, I’d like us to move away from relying on setting environment > > variables, and/or switch to specifying per-screen DPI instead of a scale > > factor. > > Sure, but where, on X11? xrandr? We read the X11 setting there. Though if you use GNOME they will override the values to something meaningless, and we don't currently read the GNOME per screen settings. For KDE it should work though. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Hi, Am 25.09.2019 um 12:33 hat Matthew Woehlke geschrieben: As a user, I don't want to have to know/measure/compute the DPI of my display device. I just want to make "stuff" bigger or smaller. Exactly! As a (Windows) *user* I want Qt based applications (which a user is probably not aware of because he doesn't care about toolkits) to behave like any other application on my computer. So when Firefox, Chrome, Word, Explorer etc. look good with that 125%, 150% or 175% setting in the display preferences, I expect any other application to do so as well. And when I move a window from a low DPI screen to a high DPI screen it has to be adjusted accordingly. With the work done in 5.14 (PassThrough) it is the first time that we seem to catch up with other toolkits in this regard. I hope this will finally be mature enough to replace all the nasty workarounds we have to apply today to make user experience somewhat acceptable on non-100% scaling screens. I actually consider this to be the most important feature of 5.14. Nils signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den tors 26 sep. 2019 kl 04:51 skrev Thiago Macieira : > > On Wednesday, 25 September 2019 11:08:39 PDT Elvis Stansvik wrote: > > Large parts of the world did not grow up with inches. I know I'd have > > a hard time to hold up my fingers to show an inch... > > For most people, "DPI" is an arbitrary number ranging from 72 to 288... Yep, although I'd revise that to "for most people, DPI means nothing, but for some people it's an arbitrary number ranging from 72 to 288..." :) I just wanted to argue that working in terms of a percentage of the current size is more intuitive to most people, compared to working in some arbitrary DPI number they may or may not have heard about. Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Wednesday, 25 September 2019 11:08:39 PDT Elvis Stansvik wrote: > Large parts of the world did not grow up with inches. I know I'd have > a hard time to hold up my fingers to show an inch... For most people, "DPI" is an arbitrary number ranging from 72 to 288... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Wednesday, 25 September 2019 05:54:20 PDT Morten Sørvig wrote: > I see two differences between setting the DPI vs a factor: > > - You set one value per screen (DPI) instead of two (DPI & factor) > > - Qt can compute the factor, according to policy set by the application (as > mentioned above) Assume no one will ever call that function. What's the outcome? Also, DPIs are a physical property of the monitor, but they don't account for my distance to it. Previously, I only needed one parameter to toggle, which was either 1 or 2. Now, in order to properly configure, I need to find out what the current DPI is and then update it. Moreover, I can have two different monitors connected to the same output (at different times, of course). Since they have different DPI, the multiplicative factor allows me to set it once for both, but if I set a DPI setting, it'll likely be wrong for at least one of them. > > Anyway, what's the correct way to specify now that one of my external > > monitors is highdpi but the other isn’t? > > > The correct way would be to configure the windowing system. Qt would then > pick up the configuration via the platform plugin. Agreed, but for those of us still on X11, that's not na option. > In practice, the environment variables you are currently using may be your > best option on X11. Ok, thanks. This becomes the recommendation for KDE Plasma Shell configuration for X11 then: continue using the variables as they are. > If possible, I’d like us to move away from relying on setting environment > variables, and/or switch to specifying per-screen DPI instead of a scale > factor. Sure, but where, on X11? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den ons 25 sep. 2019 kl 20:51 skrev Kai Pastor, DG0YT : > > Am 25.09.19 um 20:08 schrieb Elvis Stansvik: > > Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke > > : > >> On 25/09/2019 08.54, Morten Sørvig wrote: > >>> I see two differences between setting the DPI vs a factor: > >>> > >>> - You set one value per screen (DPI) instead of two (DPI & factor) > >>> > >>> - Qt can compute the factor, according to policy set by the > >>> application (as mentioned above) > >>> > >>> [...] > >>> > >>> If possible, I’d like us to move away from relying on setting > >>> environment variables, and/or switch to specifying per-screen DPI > >>> instead of a scale factor. > >> Has anyone considered whether or not this is *user* friendly? > >> > >> As a user, I don't want to have to know/measure/compute the DPI of my > >> display device. I just want to make "stuff" bigger or smaller. I *also* > >> don't necessarily want the same physical size of "stuff" across devices. > >> On my phone, I may want smaller "stuff", because my phone is usually > >> quite close to my eyes. On my 4K 75" television, I may want larger > >> "stuff" because I'm sitting 10' to 15' away. Maybe I have really good > >> (or really bad) eyesight. > >> > >> Fiddling with "fake DPI" as a way of adjusting things has always felt > >> like a hack. Setting display scaling "just makes sense". From a user > >> perspective, it's obvious that scaling is also going to affect icons, > >> style margins, frame thicknesses... basically, *everything*. DPI, > >> historically, only affected font sizes and *maybe* some margins. If the > >> only knob I have is DPI, how do I know (or control) what size my icons > >> will be? How am I supposed to guess what will be the relation between > >> "virtual" pixels and physical pixels, keeping in mind that I, as a user, > >> am trying to achieve a particular value for that? > >> > >> There are a few instances, such as when representing physical objects, > >> when it makes sense to try to achieve a particular physical size. In > >> almost *every other case*, which is to say *always* for interface > >> elements, there is no fixed correlation between "desirable" size and > >> actual physical size, and anyone that designs their application > >> otherwise is doing their users a disservice. > > Agree 100%. There's no reason for a user to have to fiddle around with > > a strange number like 192, 96, or whatever. > > > > As a user I want 2 things: > > > > - Sane defaults and good autodetection, so a hopefully good automatic > > scale factor that makes things reasonably sized given the physical > > dimensions of the output device and its intended viewing distance > > - ..but if I want to tune the size for whatever reason, I want to do > > that in percentages of what it is *now*. > > > > It's easy enough for most folks to judge what % of the current size > > that would get them where they want to be. It's not friendly to > > present them with say 192 DPI, and when they want say 80% of that, > > leave them to do the math. Or even asking them to relate the DPI to > > physical inches (though I guess the DPI we're talking about here is > > some intermediate virtual one?). > > > > Large parts of the world did not grow up with inches. I know I'd have > > a hard time to hold up my fingers to show an inch... > > > > Elvis > > > > PS. Nevermind that in the KDE version I'm using, it's actually not > > possible to tweak the scale factor per screen under X11 in the kscreen > > KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to > > dabble with that. But if I do want to dabble, I want to dabble in > > percent. DS. > > There is nothing wrong with preferring simplicity for the most common > case. But please provide a clear way how to get accurate sizes when > desired, e.g. for 1:1 drawing or for print preview. With "clear" > including uniform cross-platform. Yes, absolutely, I want that use case to just work too of course. I was speaking only of the "i want to change the size of buttons and text on my computer" use case, not about print preview / desktop publishing types of use cases (those are important too of course, and should just work, irregardless of the user's desktop screen scaling settings). Elvis > > Kai > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Am 25.09.19 um 20:08 schrieb Elvis Stansvik: Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke : On 25/09/2019 08.54, Morten Sørvig wrote: I see two differences between setting the DPI vs a factor: - You set one value per screen (DPI) instead of two (DPI & factor) - Qt can compute the factor, according to policy set by the application (as mentioned above) [...] If possible, I’d like us to move away from relying on setting environment variables, and/or switch to specifying per-screen DPI instead of a scale factor. Has anyone considered whether or not this is *user* friendly? As a user, I don't want to have to know/measure/compute the DPI of my display device. I just want to make "stuff" bigger or smaller. I *also* don't necessarily want the same physical size of "stuff" across devices. On my phone, I may want smaller "stuff", because my phone is usually quite close to my eyes. On my 4K 75" television, I may want larger "stuff" because I'm sitting 10' to 15' away. Maybe I have really good (or really bad) eyesight. Fiddling with "fake DPI" as a way of adjusting things has always felt like a hack. Setting display scaling "just makes sense". From a user perspective, it's obvious that scaling is also going to affect icons, style margins, frame thicknesses... basically, *everything*. DPI, historically, only affected font sizes and *maybe* some margins. If the only knob I have is DPI, how do I know (or control) what size my icons will be? How am I supposed to guess what will be the relation between "virtual" pixels and physical pixels, keeping in mind that I, as a user, am trying to achieve a particular value for that? There are a few instances, such as when representing physical objects, when it makes sense to try to achieve a particular physical size. In almost *every other case*, which is to say *always* for interface elements, there is no fixed correlation between "desirable" size and actual physical size, and anyone that designs their application otherwise is doing their users a disservice. Agree 100%. There's no reason for a user to have to fiddle around with a strange number like 192, 96, or whatever. As a user I want 2 things: - Sane defaults and good autodetection, so a hopefully good automatic scale factor that makes things reasonably sized given the physical dimensions of the output device and its intended viewing distance - ..but if I want to tune the size for whatever reason, I want to do that in percentages of what it is *now*. It's easy enough for most folks to judge what % of the current size that would get them where they want to be. It's not friendly to present them with say 192 DPI, and when they want say 80% of that, leave them to do the math. Or even asking them to relate the DPI to physical inches (though I guess the DPI we're talking about here is some intermediate virtual one?). Large parts of the world did not grow up with inches. I know I'd have a hard time to hold up my fingers to show an inch... Elvis PS. Nevermind that in the KDE version I'm using, it's actually not possible to tweak the scale factor per screen under X11 in the kscreen KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to dabble with that. But if I do want to dabble, I want to dabble in percent. DS. There is nothing wrong with preferring simplicity for the most common case. But please provide a clear way how to get accurate sizes when desired, e.g. for 1:1 drawing or for print preview. With "clear" including uniform cross-platform. Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke : > > On 25/09/2019 08.54, Morten Sørvig wrote: > > I see two differences between setting the DPI vs a factor: > > > > - You set one value per screen (DPI) instead of two (DPI & factor) > > > > - Qt can compute the factor, according to policy set by the application (as > > mentioned above) > > > > [...] > > > > If possible, I’d like us to move away from relying on setting > > environment variables, and/or switch to specifying per-screen DPI > > instead of a scale factor. > Has anyone considered whether or not this is *user* friendly? > > As a user, I don't want to have to know/measure/compute the DPI of my > display device. I just want to make "stuff" bigger or smaller. I *also* > don't necessarily want the same physical size of "stuff" across devices. > On my phone, I may want smaller "stuff", because my phone is usually > quite close to my eyes. On my 4K 75" television, I may want larger > "stuff" because I'm sitting 10' to 15' away. Maybe I have really good > (or really bad) eyesight. > > Fiddling with "fake DPI" as a way of adjusting things has always felt > like a hack. Setting display scaling "just makes sense". From a user > perspective, it's obvious that scaling is also going to affect icons, > style margins, frame thicknesses... basically, *everything*. DPI, > historically, only affected font sizes and *maybe* some margins. If the > only knob I have is DPI, how do I know (or control) what size my icons > will be? How am I supposed to guess what will be the relation between > "virtual" pixels and physical pixels, keeping in mind that I, as a user, > am trying to achieve a particular value for that? > > There are a few instances, such as when representing physical objects, > when it makes sense to try to achieve a particular physical size. In > almost *every other case*, which is to say *always* for interface > elements, there is no fixed correlation between "desirable" size and > actual physical size, and anyone that designs their application > otherwise is doing their users a disservice. Agree 100%. There's no reason for a user to have to fiddle around with a strange number like 192, 96, or whatever. As a user I want 2 things: - Sane defaults and good autodetection, so a hopefully good automatic scale factor that makes things reasonably sized given the physical dimensions of the output device and its intended viewing distance - ..but if I want to tune the size for whatever reason, I want to do that in percentages of what it is *now*. It's easy enough for most folks to judge what % of the current size that would get them where they want to be. It's not friendly to present them with say 192 DPI, and when they want say 80% of that, leave them to do the math. Or even asking them to relate the DPI to physical inches (though I guess the DPI we're talking about here is some intermediate virtual one?). Large parts of the world did not grow up with inches. I know I'd have a hard time to hold up my fingers to show an inch... Elvis PS. Nevermind that in the KDE version I'm using, it's actually not possible to tweak the scale factor per screen under X11 in the kscreen KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to dabble with that. But if I do want to dabble, I want to dabble in percent. DS. > > -- > Matthew > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On 25/09/2019 08.54, Morten Sørvig wrote: > I see two differences between setting the DPI vs a factor: > > - You set one value per screen (DPI) instead of two (DPI & factor) > > - Qt can compute the factor, according to policy set by the application (as > mentioned above) > > [...] > > If possible, I’d like us to move away from relying on setting > environment variables, and/or switch to specifying per-screen DPI > instead of a scale factor. Has anyone considered whether or not this is *user* friendly? As a user, I don't want to have to know/measure/compute the DPI of my display device. I just want to make "stuff" bigger or smaller. I *also* don't necessarily want the same physical size of "stuff" across devices. On my phone, I may want smaller "stuff", because my phone is usually quite close to my eyes. On my 4K 75" television, I may want larger "stuff" because I'm sitting 10' to 15' away. Maybe I have really good (or really bad) eyesight. Fiddling with "fake DPI" as a way of adjusting things has always felt like a hack. Setting display scaling "just makes sense". From a user perspective, it's obvious that scaling is also going to affect icons, style margins, frame thicknesses... basically, *everything*. DPI, historically, only affected font sizes and *maybe* some margins. If the only knob I have is DPI, how do I know (or control) what size my icons will be? How am I supposed to guess what will be the relation between "virtual" pixels and physical pixels, keeping in mind that I, as a user, am trying to achieve a particular value for that? There are a few instances, such as when representing physical objects, when it makes sense to try to achieve a particular physical size. In almost *every other case*, which is to say *always* for interface elements, there is no fixed correlation between "desirable" size and actual physical size, and anyone that designs their application otherwise is doing their users a disservice. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
> On 24 Sep 2019, at 17:54, Thiago Macieira wrote: > > On Monday, 16 September 2019 06:00:27 PDT Morten Sørvig wrote: >> Could KDE possibly set per-screen DPI instead of a scale factor? >> Applications can now use the >> QGuiApplication::setHighDpiScaleFactorRoundingPolicy() API to decide wether >> or not they accept fractional devicePixelRatios (in the cases where Qt >> implements the scaling), which does not match well with having a directly >> set scale factor. > > How is setting the DPI different than setting the multiplicative factor that > was applied to the DPI before? Are you expecting a lot of applications having > called that function above? Assume there's less than 0.1% of them doing that. To start with setHighDpiScaleFactorRoundingPolicy: this function is new in 5.14 so I don’t think it has many users right now. The corresponding QTBUG had a good number of votes and watchers though, so I expect it will be used. I see two differences between setting the DPI vs a factor: - You set one value per screen (DPI) instead of two (DPI & factor) - Qt can compute the factor, according to policy set by the application (as mentioned above) > > Anyway, what's the correct way to specify now that one of my external > monitors > is highdpi but the other isn’t? The correct way would be to configure the windowing system. Qt would then pick up the configuration via the platform plugin. In practice, the environment variables you are currently using may be your best option on X11. If possible, I’d like us to move away from relying on setting environment variables, and/or switch to specifying per-screen DPI instead of a scale factor. - Morten > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Monday, 16 September 2019 06:00:27 PDT Morten Sørvig wrote: > Could KDE possibly set per-screen DPI instead of a scale factor? > Applications can now use the > QGuiApplication::setHighDpiScaleFactorRoundingPolicy() API to decide wether > or not they accept fractional devicePixelRatios (in the cases where Qt > implements the scaling), which does not match well with having a directly > set scale factor. How is setting the DPI different than setting the multiplicative factor that was applied to the DPI before? Are you expecting a lot of applications having called that function above? Assume there's less than 0.1% of them doing that. Anyway, what's the correct way to specify now that one of my external monitors is highdpi but the other isn't? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
> On 16 Sep 2019, at 15:21, Florian Bruhin wrote: > > Looks like that change didn't add a changelog entry and didn't bother to > update > the documentation at all… I’ve updated https://wiki.qt.io/New_Features_in_Qt_5.14 . We’ll add similar content to the change log once it gets posted. The documentation (https://doc.qt.io/qt-5/highdpi.html) is in practice append-only at this point and needs a ground-up rewrite. I’ve pushed a minimal update with the new options here: https://codereview.qt-project.org/c/qt/qtdoc/+/275028 (Does anyone want to help updating the high-dpi docs? Let me know.) Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Monday, 16 September 2019 15:21:38 CEST Florian Bruhin wrote: > I guess with "in 2016" you mean the change this email is talking about: > https://codereview.qt-project.org/c/qt/qtbase/+/176381 > > That commit was merged for Qt 5.14 a couple of weeks ago, not in 2016: Oops! Yes, that's the change. Sorry for causing confusion. - Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Hey, On Mon, Sep 16, 2019 at 07:43:29AM +, Paul Tvete wrote: > On Friday, 13 September 2019 17:14:32 CEST Thiago Macieira wrote: > > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > > QT_AUTO_SCREEN_SCALE_FACTOR was deprecated in 2016. The recommended > replacement is QT_ENABLE_HIGHDPI_SCALING. Huh? How come the documentation (even for 5.14) still mentions that and doesn't mention QT_ENABLE_HIGHDPI_SCALING at all then? https://doc-snapshots.qt.io/qt5-5.14/highdpi.html I guess with "in 2016" you mean the change this email is talking about: https://codereview.qt-project.org/c/qt/qtbase/+/176381 That commit was merged for Qt 5.14 a couple of weeks ago, not in 2016: commit 1de8b01d2b6db8a4fe2eddd0c595d9e680964db5 Author: Morten Johan Sørvig AuthorDate: Thu Nov 10 14:17:53 2016 +0100 Commit: Morten Johan Sørvig CommitDate: Fri Aug 23 03:41:14 2019 +0200 Looks like that change didn't add a changelog entry and didn't bother to update the documentation at all... Florian -- https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
> On 13 Sep 2019, at 17:50, Thiago Macieira wrote: > > On Friday, 13 September 2019 08:35:59 PDT Elvis Stansvik wrote: >>> What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? >> >> I wonder too. I assume they've not been removed? The latter is the one that >> KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command >> line for testing. What would be the new way to set per-screen scale factors? > > I'm going to make a different request: unless the meaning has changed, keep > the same names. We already went through a round of having people migrate > their > variables from the old names to those I listed. Let's not do it again without > strong reason. Yep, nobody likes API churn. They are not going away, but do not fit well with the API structure or the way the implementation works any more, so I did not emphasize them in my email. Long term I think the migration path should be off of Qt-specific high-dpi config options, in favor of windowing system API. Which in this case probably means using Wayland instead of X11. Could KDE possibly set per-screen DPI instead of a scale factor? Applications can now use the QGuiApplication::setHighDpiScaleFactorRoundingPolicy() API to decide wether or not they accept fractional devicePixelRatios (in the cases where Qt implements the scaling), which does not match well with having a directly set scale factor. - Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den mån 16 sep. 2019 kl 09:44 skrev Paul Tvete : > > On Friday, 13 September 2019 17:14:32 CEST Thiago Macieira wrote: > > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > > QT_AUTO_SCREEN_SCALE_FACTOR was deprecated in 2016. The recommended > replacement is QT_ENABLE_HIGHDPI_SCALING. > > It looks like QT_SCREEN_SCALE_FACTORS was briefly broken, but I see there was > a fix by David Faure that was merged last week: > https://codereview.qt-project.org/c/qt/qtbase/+/273182 Phew. Thanks! Elvis > > - Paul > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Friday, 13 September 2019 17:14:32 CEST Thiago Macieira wrote: > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? QT_AUTO_SCREEN_SCALE_FACTOR was deprecated in 2016. The recommended replacement is QT_ENABLE_HIGHDPI_SCALING. It looks like QT_SCREEN_SCALE_FACTORS was briefly broken, but I see there was a fix by David Faure that was merged last week: https://codereview.qt-project.org/c/qt/qtbase/+/273182 - Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den fre 13 sep. 2019 kl 17:51 skrev Thiago Macieira : > > On Friday, 13 September 2019 08:35:59 PDT Elvis Stansvik wrote: > > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > > > > I wonder too. I assume they've not been removed? The latter is the one that > > KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command > > line for testing. What would be the new way to set per-screen scale factors? > > I'm going to make a different request: unless the meaning has changed, keep > the same names. We already went through a round of having people migrate their > variables from the old names to those I listed. Let's not do it again without > strong reason. +1 > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Friday, 13 September 2019 08:35:59 PDT Elvis Stansvik wrote: > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > > I wonder too. I assume they've not been removed? The latter is the one that > KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command > line for testing. What would be the new way to set per-screen scale factors? I'm going to make a different request: unless the meaning has changed, keep the same names. We already went through a round of having people migrate their variables from the old names to those I listed. Let's not do it again without strong reason. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den fre 13 sep. 2019 17:15Thiago Macieira skrev: > On Friday, 13 September 2019 06:43:30 PDT Morten Sørvig wrote: > > * Environment variables for development and testing: > > > > - QT_SCALE_FACTOR : enables devicePixelRatio scaling in > > QtGui, applies a global scale factor. - QT_ENABLE_HIGHDPI_SCALING [new] > : > > enables devicePixelRatio scaling in QtGui; applies per-screen scale > factors > > computed from on screen DPI. - QT_FONT_DPI [now x-platform] : > overrides > > the DPI for all screens > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > I wonder too. I assume they've not been removed? The latter is the one that KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command line for testing. What would be the new way to set per-screen scale factors? Elvis > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
On Friday, 13 September 2019 06:43:30 PDT Morten Sørvig wrote: > * Environment variables for development and testing: > > - QT_SCALE_FACTOR : enables devicePixelRatio scaling in > QtGui, applies a global scale factor. - QT_ENABLE_HIGHDPI_SCALING [new] : > enables devicePixelRatio scaling in QtGui; applies per-screen scale factors > computed from on screen DPI. - QT_FONT_DPI [now x-platform] : overrides > the DPI for all screens What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Updated high-DPI support for Qt 5.14
Hi all, We’ve recently merged several patches which improves Qt’s high-DPI support. The changes include: * Support for fractional device pixel ratios (e.g. Windows 150%) * Support per-screen DPI in more places like QStyle * Cleanup of configuration API and options. These fixes applies mostly to the AA_EnableHighDpiScaling type of high-DPI support where the device independent coordinate system is set up by QtGui. Relevant platforms include Windows, X11, and Android. The new code and and config options are cross-platform though; it should be possible to develop and test on any platform (as long as you are not working on platform plugins). The following is a summary of the most relevant configuration options and API, ignoring some of the more obscure, and now deprecated options: * Platform plugins: Scale factor computation has been moved to cross-platform code in order to support rounding policy options. Platforms now provide per-screen DPI values and any natively applied scale factor: - QPlatformScreen::logicalBaseDpi() [new] : the base DPI on the system (e.g. 96 on Windows, 72 on macOS) - QPlatformScreen::logicalDpi(): the logical DPI of the screen (e.g. 144 on Windows 150%) - QPlatformScreen::devicePixelRatio() : the scale factor applied by the OS/Windowing system (e.g. 1 or 2) [QPlatformScreen::pixelDensity() will no longer be called] * Environment variables for development and testing: - QT_SCALE_FACTOR : enables devicePixelRatio scaling in QtGui, applies a global scale factor. - QT_ENABLE_HIGHDPI_SCALING [new] : enables devicePixelRatio scaling in QtGui; applies per-screen scale factors computed from on screen DPI. - QT_FONT_DPI [now x-platform] : overrides the DPI for all screens QT_FONT_DPI was previously x11 only, and is now cross-platform. QT_ENABLE_HIGHDPI_SCALING corresponds to Qt::AA_EnableHighDpiScaling. * Scale factor rounding policy Today, Qt rounds scale factors which can result in mismatched UI sizes. We’ve now added API for setting the rounding policy: - QT_SCALE_FACTOR_ROUNDING_POLICY=Round|Ceil|Floor|RoundPreferFloor|PassThrough - QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy) Where the PassThrough option results in no scale factor rounding, which means that the visual UI size will match font sizes and also the UI sizes of other applications. Note that this policy applies only when computing a scale factor from screen DPI in QtGui; scale factors from QPlatformScreen::devicePixelRatio() or QT_SCALE_FACTOR are used as-is. * Manual test tests/manual/highdpi/highdpi —metrics This test app displays a summary of the screen/DPI/DPR configuration. Also lists relevant environment variables. No changes to Qt’s high-dpi support goes without follow-up work, so please let me know if there are regressions, or contact me if you have questions. Cheers, Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
