GNOME applications blocking window manager keyboard shortcuts? Drawing over everything?
- I believe this is not just about GNOME, but all GTK+ and Qt applications  . 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)
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: * https://bugzilla.novell.com/show_bug.cgi?id=217790• * https://bugzilla.gnome.org/show_bug.cgi?id=643704 */
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:
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> </match>
- 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)
I added a paragraph about "Hibernate when Lid is closed"
Hi, I added a paragraph about "Hibernate when Lid is closed" (GNOME#Hibernate_the_computer_when_Lid_is_closed). I hope this paragraph will not be deleted cause some might say it does not belong to gnome. Cause in Gnome it can not be set... Well - I think it belongs here cause most people will try to find it in the gnome settings to set this option.
- It's relevant to GNOME but also to other environments, standalone window managers for instance that don't have a power manager that inhibits the logind settings. I think it would be best to document the logind.conf options in one central location (if we're not doing this already) and then GNOME and other articles can link to that location. -- Chazza (talk) 10:03, 11 September 2015 (UTC)
- As a general point, see Help:Editing#Creating pages for a creating pages. Looking at this more closely though, I'm not sure this is really necessary. Power management#ACPI events covers the essentials and the logind.conf manpage provides the rest of the detail. It's still important to mention that editing logind.conf is necessary in GNOME as other DE's typically inhibit these settings with their power manager but I think this needs to be done in a more succinct fashion - I notice we now have two sections relating to the lid switch. -- Chazza (talk) 14:45, 11 September 2015 (UTC)
- Which two sections do you mean? On the GNOME article? Do you mean this GNOME#Hibernate_the_computer_when_Lid_is_closed and that GNOME#Prevent_Suspend-To-RAM_.28S3.29_when_closing_the_LID? --PMay (talk) 19:49, 11 September 2015 (UTC)
- You're doing a good job PMay, I'm not a native English speaker btw, in theory you've displayed better language skills than me in your previous revision, since I've replaced your whole section with only a couple of basic sentences :P Anyway, for the future if you find yourself in the need to summarize something that's already written elsewhere, you now know it's easier to stop and think "wait, instead of writing all this I can simply and quickly link there and move on to something else!" ;)
- Is anybody interested in merging the info to Power management#ACPI events? It seems a bit scattered at the moment. Let's leave this discussion open as a reminder.
- — Kynikos (talk) 03:28, 13 September 2015 (UTC)
- Well, thanks for the compliment. :-) Do you suggest to scan all the articles with the "HandleLidSwitch" keyword and extract those informations to Power management#ACPI events or Power management? And maybe leave short links and hints in the original articles? --PMay (talk) 18:43, 13 September 2015 (UTC)
- Personally, I think it needs to be decided on a case by case basis. As per the discussion on the GDM talk page, I think we both agree that the section in the GDM article can just be removed - there's no need for lid switch instructions on every single DM page. -- Chazza (talk) 08:08, 14 September 2015 (UTC)
- Yes, I think that HandleLidSwitch and the similar events should just be described with a little more detail directly in Power management#ACPI events. If done properly, IMO there shouldn't be the need to leave links from DE or DM pages, as also Chazza points out. — Kynikos (talk) 14:58, 15 September 2015 (UTC)
Tear-free video with Intel HD Graphics
From the deletion template: As of 2015-02-16, the following workaround doesn't solve tearing problems (e.g. fullscreen video) anymore when Intel TearFree option does.
- There's evidence to the contrary, e.g , so I've removed the template. Thanks, closing. -- Alad (talk) 16:30, 20 May 2015 (UTC)
- Removed the
CLUTTER_VBLANK=Trueline, leaving just the
CLUTTER_PAINTline. The VBLANK line wasn't in the section when the method was removed but was in the Cinnamon section which details the same workaround. According to this the
CLUTTER_VBLANK=Trueline does nothing and here,
Trueisn't listed a valid value. -- Chazza (talk) 15:24, 3 October 2015 (UTC)
- Removed the