From ArchWiki
Jump to: navigation, search

GNOME applications blocking window manager keyboard shortcuts? Drawing over everything?

Seen on Fluxbox, using evince, totem, baobab.(as of 3.14.1-2, 3.14.1-1, 3.14.1-1, well, earlier) Makes these programs near-useless.Jasper1984 (talk) 15:31, 8 December 2014 (UTC)

I believe this is not just about GNOME, but all GTK+ and Qt applications [1] [2]. Haven't read through the reports, but it appears to be some flaw in Xorg. Not much we can do about this, so unless you want to discuss a workaround this can be closed. -- Alad (talk) 19:50, 8 December 2014 (UTC)
Can you confirm this with another toolkit than GTK3 ? -- Alad (talk) 17:35, 10 January 2015 (UTC)

GNOME and fontconfig settings

Since there isn't a section dedicated to fonts in GNOME 3 I was thinking about writing one, but I put it here first:

GNOME doesn't use the dpi settings set by xorg server to scale fonts, instead it uses a fixed dpi of 96 that cannot be changed unlike previous versions:

/* As we cannot rely on the X server giving us good DPI information, and
 * that we don't want multi-monitor screens to have different DPIs (thus
 * different text sizes), we'll hard-code the value of the DPI
 * See also:

The gnome-settings-daemon plugin xsettings relies on this hardcoded value for some calculations and there is currently no way of changing it beside customizing the code in abs. The dimension of text can be tweaked changing the text-scaling-factor (1.0 by default), using gnome-tweak-tool or editing the following key in dconf-editor:


The xsettings plugins will also merge some Xft values in the X resources db overwriting values set in .Xresources od .Xdefaults files. The defaults are:

Xft.antialias:	1
Xft.dpi:	96
Xft.hinting:	1
Xft.hintstyle:	hintmedium
Xft.lcdfilter:	lcddefault
Xft.rgba:	none

Some of those values can be changed using dconf-editor (org.gnome.settings-daemon.plugins.xsettings) or gnome-tweak-tool. It is possible to change this values using xrdb -merge ~/.Xresources after gnome is started but gnome will still use its values internally so it is not a good idea.

It is a good idea to configure your fonts.conf in a way consistent with the gnome settings otherwise, at least on my laptop, fonts will looks weird in some gnome apps.

The dpi setting of the Xserver can be changed to 96 following this guide, this way it will be the same for all applications, the drawback is that fonts might look too small or too big in other application if the real DPI of your monitor differs too much from 96.

For and LCD monitor it is a good idea to activate the lcd filter setting the following keys in dconf-editor:

org.gnome.settings-daemon.plugins.xsettings.antialiasing rgba
org.gnome.settings-daemon.plugins.xsettings.rgba-order rgb, bgr, vrgb or vbgr (as your monitor requires)

Since the lcdfilter is not designed to work together with autohinting it is a good idea to disable it also in fonts.conf. It is also a good idea to use the same hinting value as in your font.conf, the default in gnome is medium:

org.gnome.settings-daemon.plugins.xsettings.hinting medium

This values in fonts.conf will match the gnome settings:

<match target="font">
 <edit mode="assign" name="rgba"><const>rgb</const></edit>
 <edit mode="assign" name="autohint"><bool>false</bool></edit>
 <edit mode="assign" name="hinting"><bool>true</bool></edit>
 <edit mode="assign" name="hintstyle"><const>hintmedium</const></edit>
 <edit mode="assign" name="antialias"><bool>true</bool></edit>
 <edit mode="assign" name="lcdfilter"><const>lcddefault</const></edit>

(to be finished, please comment or fix) —This unsigned comment is by Erm67 (talk) 23:58, 8 January 2012‎. Please sign your posts with ~~~~!

I think that info must be in Font configuration, linked from there if needed -- Kycok (talk) 10:57, 3 June 2014 (UTC)
Well, it is very GNOME specific and complex at the same time. I would vote for putting it into GNOME tips and crosslink it from GNOME#Fonts as well as from Font configuration. But first: Above contribution of Erm67 is a couple of years back. Does someone know whether the instructions still work like that? --Indigo (talk) 09:04, 10 November 2014 (UTC)
Update to note: GNOME tips was cleaned up removing GNOME content after I suggested above. It does not make sense to put these instructions there anymore. --Indigo (talk) 12:41, 15 January 2015 (UTC)

GNOME on Wayland

Are we going to document GNOME on Wayland at GNOME#Wayland sessions or at Wayland#GNOME? I don't really mind which page is used but having both is surely redundant. -- Chazza (talk) 22:06, 17 December 2016 (UTC)

Given the TOC structure of Wayland overall and that Gnome now defaults on it for new installs, it seems preferable to have the info in this article to me. On the contra side, it seems useful to have Wayland related quirks easy to find in one section, at least for the transition phase of users.
I've put a merge tpl. Let's see if there are opinions, e.g. by Soloturn who contributed most of the section. --Indigo (talk) 10:25, 25 December 2016 (UTC)
i have no strong opinion on this, you guys are longer here than me. i corrected starting manual now only on this page, as florian was so kind to point to the new way how to do it here. --Soloturn (talk) 05:44, 26 December 2016 (UTC)
Ok, great (also your bug resolving). So, we can see at times to resolve the merge over here. My suggestion for disparate points like Wayland#hints would be to open a top-level GNOME/Troubleshooting subsection for "Wayland" to group such into for now (to keep Wayland related app glitches together). --Indigo (talk) 21:11, 27 December 2016 (UTC)
ah, yes the troubleshooting seems a nice place for it. i removed the gnome section now on wayland, and moved the hints to Wayland#Troubleshooting, it does not seem gnome specific. --Soloturn (talk) 12:03, 29 December 2016 (UTC)

That all looks great! Thanks Soloturn. Whilst we're on the subject of GNOME/Troubleshooting, do we want to get rid of this section? - GNOME/Troubleshooting#Setting global Wayland environment with an environment variable. We don't use --session=gnome-wayland anymore so most of this section seems to be outdated. Although perhaps the link at the bottom that talks about GDK_BACKEND is still useful in the context of individual GNOME applications? -- Chazza (talk) 17:08, 29 December 2016 (UTC)

We definetely should keep that reference. Added link. --Indigo (talk) 11:22, 2 January 2017 (UTC)

That's good. I don't think there's anything left in that section that's useful so I've marked it for deletion now [3]. I'll leave this open so that people can raise objections. -- Chazza (talk) 16:35, 2 January 2017 (UTC)