GNOME Bugzilla – Bug 643704
Add helper class for tracking DPI
Last modified: 2018-02-19 10:35:40 UTC
As discussed in IRC, we want to share some code between gnome-settings-daemon, gnome-control-center and gnome-shell.
Created attachment 182286 [details] [review] Introduce GnomeDPIManager to track the DPI GnomeDPIManager is an helper class that tracks both GSettings and X server, to provide a value for the DPI, and a factor between what is currently used and the default. Will be shared by gnome-control-center, gnome-settings-daemon and gnome-shell.
Review of attachment 182286 [details] [review]: ::: libgnome-desktop/gnome-dpi-manager.c @@ +31,3 @@ +#include "private.h" + +#define SETTINGS_SCHEMA "org.gnome.desktop.settings-schema.plugins.xsettings" This is most likely wrong. We'd also need to move the setting to gsettings-desktop-schemas. @@ +48,3 @@ +#define DPI_HIGH_REASONABLE_VALUE 500 + +static gdouble fixed_factors[GNOME_DPI_LEVEL_LAST] = { 0.75, 1.0, 1.25, 1.5 }; Add a note to keep in sync with the enum @@ +195,3 @@ + { + g_object_ref (self->screen); + g_signal_connect_object (self->screen, "monitors-changed", G_CALLBACK (monitor_changed_cb), G_OBJECT (self), 0); The big unknown is how we should behave when using multiple screens though. As long as we don't change the DPI from the default, or X keeps on reporting 96 dpi for everything, we're fine, but we'd really need to handle multiple monitors.
I think this falls a little too short, since it still does the 'find the fixed factor back from dpi values' thing in get_fixed_factor I'd really like to store the factor separately
I think we could remove the "dpi" GSettings altogether doing that. We'd always store the factor, with a 1.0 default. We could keep the helper code to figure out the text size from the factor (that's useful for custom factors). g-s-d would then take care of setting the XSettings per screen/monitor.
If nobody complains, I'll start working on that tomorrow (gsettings-desktop-schemas and g-s-d to start with).
*Alert alert alert* DPI is meaningless and actively confusing - even programmers don't understand it. Please read this carefully: http://people.gnome.org/~federico/news-2007-01.html#31 If we are changing basic infrastructure for the benefit of users, then this is the perfect opportunity to eliminate DPI altogether. Users have no business seeing that.
(In reply to comment #6) > *Alert alert alert* > > DPI is meaningless and actively confusing - even programmers don't understand > it. Please read this carefully: > http://people.gnome.org/~federico/news-2007-01.html#31 > > If we are changing basic infrastructure for the benefit of users, then this is > the perfect opportunity to eliminate DPI altogether. Users have no business > seeing that. We never show the DPI to users in GNOME 3, and we don't intend to. We're talking about system components here.
Sorry that I missed the conversation on IRC, but why do we need to maintain a DPI value at all? Isn't it enough to store "the user wants his GUI font to be 14 pixels tall" (as configured through the easy font-size picker I described in that blog post)?
(In reply to comment #8) > Sorry that I missed the conversation on IRC, but why do we need to maintain a > DPI value at all? Comment 3. > Isn't it enough to store "the user wants his GUI font to be > 14 pixels tall" (as configured through the easy font-size picker I described in > that blog post)? Your "blog post" isn't accessible, so it really doesn't help the conversation.
Created attachment 182338 [details] [review] schemas: Add "text-scaling-factor" key Used to scale the text in the interface without changing the DPI manually, or the font size.
Created attachment 182342 [details] [review] xsettings: Remove use of the DPI settings key And use the text-scaling-factor key instead. This means removing a lot of duplicated code. The DPI is still available through the "gtk-xft-dpi" GtkSettings property for applications that need it.
Created attachment 182343 [details] [review] universal-access: Use "text-scaling-factor" instead of "dpi"
(In reply to comment #9) > (In reply to comment #8) > > Sorry that I missed the conversation on IRC, but why do we need to maintain a > > DPI value at all? > > Comment 3. Bastien, please understand that I'm not trying to be annoying. You may have the full context to this discussion, but I don't. A long time ago I massaged the DPI code to "really use the value from the X server", which seemed like the right thing to do. After people started complaining, I did more some thinking and came to the conclusions I put forth in my blog post. The summary was "DPI is useless for users, and as far as I can tell, APIs as well". The simplest thing we can do that would work, as I see it, would be to let the user choose a font size visually, and just keep that size in terms of pixels. This would minimize confusion everywhere. I more or less see what you are trying to do with this patch - keep a DPI value, and also have a text scaling factor mainly for a11y purposes. I more or less agree with the second thing, but definitely not with the first one. I'll ask again - why do we need to maintain a DPI value at all? Does some underlying API require it and so must we produce one? > Your "blog post" isn't accessible, so it really doesn't help the conversation. Sorry, I screwed up my .htaccess at exactly the wrong time. It's back up now.
(In reply to comment #13) > (In reply to comment #9) > > (In reply to comment #8) > > > Sorry that I missed the conversation on IRC, but why do we need to maintain a > > > DPI value at all? > > > > Comment 3. > > Bastien, please understand that I'm not trying to be annoying. You may have > the full context to this discussion, but I don't. > > A long time ago I massaged the DPI code to "really use the value from the X > server", which seemed like the right thing to do. After people started > complaining, I did more some thinking and came to the conclusions I put forth > in my blog post. The summary was "DPI is useless for users, and as far as I > can tell, APIs as well". The simplest thing we can do that would work, as I > see it, would be to let the user choose a font size visually, and just keep > that size in terms of pixels. This would minimize confusion everywhere. > > I more or less see what you are trying to do with this patch - keep a DPI > value, and also have a text scaling factor mainly for a11y purposes. I more or > less agree with the second thing, but definitely not with the first one. I'll > ask again - why do we need to maintain a DPI value at all? Does some > underlying API require it and so must we produce one? For one, Xft prefers to have DPI information. The fact is also that "Sans 10" at 96 dpi isn't the same as "Sans 15" at 144 dpi. We went for a particular look, and allowing users to change the font's apparent size to bigger or smaller without changing the font itself means that we can focus on one particular size look great. Which means that something like Cantarell can be used at multiple "sizes" in GNOME 3 without a problem. > > Your "blog post" isn't accessible, so it really doesn't help the conversation. > > Sorry, I screwed up my .htaccess at exactly the wrong time. It's back up now. We don't give access to font sizes any more. Just various text scaling factors.
Comment on attachment 182286 [details] [review] Introduce GnomeDPIManager to track the DPI Marking Giovanni's patch as obsolete as Bastien's replace it.
Comment on attachment 182338 [details] [review] schemas: Add "text-scaling-factor" key Attachment 182338 [details] pushed as 0ca632d - schemas: Add "text-scaling-factor" key
Created attachment 182370 [details] [review] xsettings: Hard-code the default DPI We cannot rely on the X server giving us a decent DPI value, and we do not want to change the DPI when the resolution changes, or when multiple monitors are attached.
Attachment 182342 [details] pushed as e8d1de9 - xsettings: Remove use of the DPI settings key Attachment 182370 [details] pushed as a49af89 - xsettings: Hard-code the default DPI
Changes pushed to gsettings-desktop-schemas, gnome-settings-daemon (x2) and gnome-control-center. Florian has patches for gnome-shell ready and should push them shortly. Attachment 182343 [details] pushed as f6b0ae8 - universal-access: Use "text-scaling-factor" instead of "dpi"
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #9) > > > (In reply to comment #8) > > > > Sorry that I missed the conversation on IRC, but why do we need to maintain a > > > > DPI value at all? > > > > > > Comment 3. > > > > Bastien, please understand that I'm not trying to be annoying. You may have > > the full context to this discussion, but I don't. > > > > A long time ago I massaged the DPI code to "really use the value from the X > > server", which seemed like the right thing to do. After people started > > complaining, I did more some thinking and came to the conclusions I put forth > > in my blog post. The summary was "DPI is useless for users, and as far as I > > can tell, APIs as well". The simplest thing we can do that would work, as I > > see it, would be to let the user choose a font size visually, and just keep > > that size in terms of pixels. This would minimize confusion everywhere. This will minimize confusion for people who expect a fixed pixel size. The kind of people who buy a high-res screen and run it at low-res because they have pixel values hardcoded everywhere and that's the only way they can scale things. Working with pixels fails utterly as soon as you introduce screen variability. All screens do not have the same pixel sizes. You can only define a specific pixel size for a specific screen at a specific resolution. > > I more or less see what you are trying to do with this patch - keep a DPI > > value, and also have a text scaling factor mainly for a11y purposes. I more or > > less agree with the second thing, but definitely not with the first one. I'll > > ask again - why do we need to maintain a DPI value at all? Does some > > underlying API require it and so must we produce one? > > For one, Xft prefers to have DPI information. > > The fact is also that "Sans 10" at 96 dpi isn't the same as "Sans 15" at 144 > dpi. We went for a particular look, and allowing users to change the font's > apparent size to bigger or smaller without changing the font itself means that > we can focus on one particular size look great. That's utterly braindamaged anywone working on fonts will tell you text rendering improves with dpi so forcing a low dpi negates the benefits of better hardware. > Which means that something like Cantarell can be used at multiple "sizes" in > GNOME 3 without a problem. Which means something like Cantarell will be misrendered even on nice screens
Well, text scaling factor not support float number, only integer. Now pretty hug text with normal icons. I'm wondering why don't you hard code the screen resolution?