Difference between revisions of "Talk:GNOME"

From ArchWiki
Jump to navigation Jump to search
(move discussion from Talk:Evince)
(Undo revision 452859 by Chazza (talk) revert erroneous addition of discussion - discussion is still at Talk:GNOME/Document viewer)
Line 107: Line 107:
[[User:CuriousTommy|CuriousTommy]] ([[User talk:CuriousTommy|talk]]) 16:26, 7 April 2016 (UTC)
[[User:CuriousTommy|CuriousTommy]] ([[User talk:CuriousTommy|talk]]) 16:26, 7 April 2016 (UTC)
== Use of GNOME generic names ==
Doesn't this page need to be moved to [[GNOME/Document viewer]] in line with [[GNOME/Web]] and [[GNOME/Files]]? Evince is the old name. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 20:14, 30 September 2016 (UTC)
:Evince is known and used by many desktop environments other then gnome and having it listed as [[GNOME/Document viewer]] only will make it harder to find. -- [[User:Shedto|Shedto]] ([[User talk:Shedto|talk]]) 19:10, 02 October 2016 (UTC)
::Well there would still be a redirect. So one could search for Evince and be taken to [[GNOME/Document viewer]] in the same way that one can search for Nautilus and be taken to [[GNOME/Files]]. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 09:40, 3 October 2016 (UTC)
:::I think the page does need to be moved and a redirect added if that is indeed the name of the program now. I can't seem to find information on if it was officially changed. Everything I find still says "Evince". -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 13:00, 3 October 2016 (UTC)
::::Its desktop entry file specifies {{ic|1=Name=Document Viewer}}. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 13:53, 3 October 2016 (UTC)
:::::Okay, works for me. Feel free to move the page and add a redirect to it from [[Evince]].  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 18:45, 3 October 2016 (UTC)

Revision as of 10:04, 4 October 2016

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)

Tear-free video with Intel HD Graphics / Xorg Intel TearFree option

In the wiki article is explained, that the Xorg Intel TearFree option has the following disadvantages: "However, the way this option acts makes it redundant with the use of a compositor (it increases memory consumption and lowers performance, ..."

As far as I understand this is not true anymore.

man intel (see [3]) says the following:

".BI "Option \*qTearFree\*q \*q" boolean \*q Disable or enable TearFree updates. This option forces X to perform all rendering to a backbuffer prior to updating the actual display. It requires an extra memory allocation the same size as a framebuffer, the occasional extra copy, and requires Damage tracking. Thus enabling TearFree requires more memory and is slower (reduced throughput) and introduces a small amount of output latency, but it should not impact input latency. However, the update to the screen is then performed synchronously with the vertical refresh of the display so that the entire update is completed before the display starts its refresh. That is only one frame is ever visible, preventing an unsightly tear between two visible and differing frames. Note that this replicates what the compositing manager should be doing, however TearFree will redirect the compositor updates (and those of fullscreen games) directly on to the scanout thus incurring no additional overhead in the composited case. Also note that not all compositing managers prevent tearing, and if the outputs are rotated, there will still be tearing without TearFree enabled. .IP Default: TearFree is disabled."

At the beginning these disadvantages did exist, but later these option was improved and the description in the manpage was updatet: [[4]]

Am I right or did I understand something wrong? --Aluser1137 (talk) 15:31, 16 January 2016 (UTC)

Additional Necessary dependencies for the Printers Section in the Settings App

I noticed that Printers section needed system-config-printer in order to install the printer through the GUI but it is never mentioned in the Gnome Wiki. Without this, it will always say that it is not able to install the printer driver whenever you try to install the printer.

CuriousTommy (talk) 16:26, 7 April 2016 (UTC)