After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 643704 - Add helper class for tracking DPI
Add helper class for tracking DPI
Status: RESOLVED FIXED
Product: gnome-desktop
Classification: Core
Component: libgnome-desktop
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-03-02 18:52 UTC by Giovanni Campagna
Modified: 2018-02-19 10:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Introduce GnomeDPIManager to track the DPI (15.01 KB, patch)
2011-03-02 18:53 UTC, Giovanni Campagna
reviewed Details | Review
schemas: Add "text-scaling-factor" key (1.27 KB, patch)
2011-03-03 12:59 UTC, Bastien Nocera
committed Details | Review
xsettings: Remove use of the DPI settings key (13.43 KB, patch)
2011-03-03 13:17 UTC, Bastien Nocera
committed Details | Review
universal-access: Use "text-scaling-factor" instead of "dpi" (7.54 KB, patch)
2011-03-03 13:24 UTC, Bastien Nocera
committed Details | Review
xsettings: Hard-code the default DPI (4.49 KB, patch)
2011-03-03 17:19 UTC, Bastien Nocera
committed Details | Review

Description Giovanni Campagna 2011-03-02 18:52:22 UTC
As discussed in IRC, we want to share some code between gnome-settings-daemon, gnome-control-center and gnome-shell.
Comment 1 Giovanni Campagna 2011-03-02 18:53:01 UTC
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.
Comment 2 Bastien Nocera 2011-03-02 19:00:13 UTC
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.
Comment 3 Matthias Clasen 2011-03-02 19:04:04 UTC
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
Comment 4 Bastien Nocera 2011-03-02 19:19:43 UTC
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.
Comment 5 Bastien Nocera 2011-03-02 19:21:26 UTC
If nobody complains, I'll start working on that tomorrow (gsettings-desktop-schemas and g-s-d to start with).
Comment 6 Federico Mena Quintero 2011-03-02 22:15:16 UTC
*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.
Comment 7 Bastien Nocera 2011-03-02 23:12:40 UTC
(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.
Comment 8 Federico Mena Quintero 2011-03-02 23:34:23 UTC
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)?
Comment 9 Bastien Nocera 2011-03-03 12:39:04 UTC
(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.
Comment 10 Bastien Nocera 2011-03-03 12:59:37 UTC
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.
Comment 11 Bastien Nocera 2011-03-03 13:17:59 UTC
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.
Comment 12 Bastien Nocera 2011-03-03 13:24:57 UTC
Created attachment 182343 [details] [review]
universal-access: Use "text-scaling-factor" instead of "dpi"
Comment 13 Federico Mena Quintero 2011-03-03 15:43:30 UTC
(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.
Comment 14 Bastien Nocera 2011-03-03 15:54:58 UTC
(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 15 Federico Mena Quintero 2011-03-03 16:29:35 UTC
Comment on attachment 182286 [details] [review]
Introduce GnomeDPIManager to track the DPI

Marking Giovanni's patch as obsolete as Bastien's replace it.
Comment 16 Bastien Nocera 2011-03-03 17:18:49 UTC
Comment on attachment 182338 [details] [review]
schemas: Add "text-scaling-factor" key

Attachment 182338 [details] pushed as 0ca632d - schemas: Add "text-scaling-factor" key
Comment 17 Bastien Nocera 2011-03-03 17:19:14 UTC
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.
Comment 18 Bastien Nocera 2011-03-03 17:19:29 UTC
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
Comment 19 Bastien Nocera 2011-03-03 17:20:50 UTC
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"
Comment 20 Nicolas Mailhot 2011-03-04 08:30:05 UTC
(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
Comment 21 StrongOp 2018-02-19 10:35:40 UTC
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?