On Sun, 06 Apr 2014 23:04:40 +0200 Raimund Steger <rs@xxxxxxxx> 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 _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
