Difference between revisions of "Talk:GNOME"

From ArchWiki
Jump to navigation Jump to search
(resurrect tear free video discussion from May 2015)
Line 106: Line 106:
::Resurrecting this discussion as the workaround was removed again with [https://wiki.archlinux.org/index.php?title=GNOME&type=revision&diff=398420&oldid=394073]. I added an accuracy notice to the Cinnamon article as the same workaround is documented there and it has generated a response, see [[Talk:Cinnamon#Video tearing]]. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 14:08, 17 September 2015 (UTC)
::Resurrecting this discussion as the workaround was removed again with [https://wiki.archlinux.org/index.php?title=GNOME&type=revision&diff=398420&oldid=394073]. I added an accuracy notice to the Cinnamon article as the same workaround is documented there and it has generated a response, see [[Talk:Cinnamon#Video tearing]]. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 14:08, 17 September 2015 (UTC)
:::I've re-added the fix, with a note stating that it may have side effects/may not work in all cases.[https://wiki.archlinux.org/index.php?title=GNOME&type=revision&diff=402984&oldid=402338]. I've also given each workaround its own title. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 15:13, 3 October 2015 (UTC)

Revision as of 15:13, 3 October 2015

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:
 * 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:

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)

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)
Well yes thats right. I think the paragraph actually does a lot of linking. A more centralised article about logind.conf would be nice though. How can we start one? --PMay (talk) 14:22, 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)
This is what I've come up with, but probably expanding this information in Power management would be an even better solution. — Kynikos (talk) 04:41, 12 September 2015 (UTC)
That looks good to me. -- Chazza (talk) 10:22, 12 September 2015 (UTC)
Great. Thats a very good change. Sharp and short. Wish I would be a native spreaker too. --PMay (talk) 12:38, 12 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.

No reasons are given. Has anyone got any evidence to back this up? -- Chazza (talk) 10:23, 15 May 2015 (UTC)

There's evidence to the contrary, e.g [3], so I've removed the template. Thanks, closing. -- Alad (talk) 16:30, 20 May 2015 (UTC)
Resurrecting this discussion as the workaround was removed again with [4]. I added an accuracy notice to the Cinnamon article as the same workaround is documented there and it has generated a response, see Talk:Cinnamon#Video tearing. -- Chazza (talk) 14:08, 17 September 2015 (UTC)
I've re-added the fix, with a note stating that it may have side effects/may not work in all cases.[5]. I've also given each workaround its own title. -- Chazza (talk) 15:13, 3 October 2015 (UTC)