[Fontconfig] Some things should not be configured through files like fonts.conf

[Wolfgang Draxinger]

On Sun, 06 Apr 2014 23:04:40 +0200
Raimund Steger <rs at mytum.de> wrote:

> (1) script something that adjusts fonts.conf dynamically depending on 
> your needs (changes are picked up automatically after the rescan
> delay). Maybe someday some distribution or clever g-s-d config comes
> up with this too, but until then, I suppose you'd have to write it
> yourself...

Doesn't work, since /home is on a network share. Any change there would
be assimilated by every system currently using it, i.e. every
fontconfig enabled active user session due to the active poll and
dynamic configuration.
 
> (2) refrain from configuring AA with fontconfig and rely on XSETTINGS 

Unfortunately this doesn't work reliably. Also things like subpixel
layout shouldn't really be configured. They should be determined at
runtime by device autoconfiguration. I understand that (for some
reason) EDID doesn't contain subpixel geometry. But then EDID contains
perfectly fine vendor and product IDs, and this would not be the first
device information database those could be used as a key into.

> (not XRDB!).

To this date nobody could tell me why XSettings was in any way superior
to Xrdb. Did you actually _read_ the Xsettings "spec"? It's self
contradictory. Oh, and technically it's still a proposal (not even a
RFC for specification).

Let me quote my favourite:

| # Existing Systems
|
| (...)
|
| - The Xrm database stores all information in a single text property on
|   the root window. This makes it difficult to determine what settings
|   have changed; it is necessary to parse the property and do string
|   comparisons.

And then later on:

| # A. Rational and Discussion
|
| (...)
|
| - Why use a single property for all settings?  Using a single property
|   has several advantages. First, retrieving all settings takes only a
|   single round-trip to the server instead of a round-trip for each
|   settings. Second, it means that when multiple settings can be
|   changed at once, only a single notification is received by clients,
|   and clients will see interrelated properties changed in an atomic
|   fashion.

So with Xrdb you have all the resources in a single text property,
while with XSettings are stored in binary. And the only reason given
is, that binary is supposedly easier and quicker to parse. WTH? There's
no difference in complexity between parsing text or parsing binary.
With binary you've to make sanity checks (header lengths, checksums) and
format conversions (endianess) involving plausibility checks. With text
you've to make you've to make sanity checks (valid keywords, proper
syntax) and format conversions (parsing numbers) involving plausibility
checks.

And then XSettings proposes 

| When a client receives a PropertyChangeNotify event for the window it
| should reread the _XSETTING_SETTINGS property.

So what exactly prevents one from selecting for a PropertyChangeNotify
event on the root window and look for changes in the RESOURCE_MANAGER
property? And in my experience trying to delta changes at runtime into
a process leads to a lot of grey hairs. Even in memory constricted
environments (think microcontrollers) I opt for full re-sets of the
effected code paths.

| It can use the 'serial' field to tell what fields have been changed.

Because diffing text is such a hard problem </sarcasm> (if you really
want to go for deltas). Or you could simply parse the whole thing and
compare on the logical level, which made much more sense anyway.

| The client must parse the entire property and read in all new
| values before taking action on changed settings such as notifying
| listeners for those settings to avoid using a mix of old and new
| data.

So it requires to the the very same as with Xrm look up, I quoted it
there. But I quote it again (it's in the effing XSettings proposal):

| (...) it is necessary to parse the property (...)

How bad must one's short term memory be, so not to think that the whole
thing is maybe a bit inconsequent.

Add to that, that in my experience XSettings is seriously broken. It
kind of works if you're using a DE like GNOME or KDE, but if you prefer
a lightweight environment or don't run a fully fledged DE at all,
starting a xsettings daemon seriously messes up one's applications.
and only a X server reset turns things back to normal, because when
the XSettings windows goes away, everything reverts to the application
default; but the Atoms linger on and anything using XSettings sees the
atoms, but no XSettings window and drops to default. BT;DT, got the
t-shirt.


Wolfgang