Worse, xrdb indirectly runs gcc!  May even make sense splitting the downstream packages as to not drag gcc in by g-s-d RPM.

(In reply to comment #0)
> We should probably (at least) disable this by default.

Go ahead.

The Moblin guys seemed to suggest that simply caching the pre-processed gcc output gets a big chunk of the win, with ~no functionality loss [ says the lazy-ass old-time emacs user that uses Xresources to clobber the colors ;-].

And of course, we install a load of .ad files in data/ to get theming right for old apps it seems.

If we did a fairly simple programmatic substitution of our own, well-controlled 'data/*.ad' files, then presumably we could add: -nocpp to the xrdb command-line for in the case where there is no user-installed ~/.Xresources or ~/.Xdefaults - which should give a nice win; or - perhaps even mandate that our .ad files have a simple, non-pre-processed syntax, and implement xrdb ourselves for them [ xrdb.c is (I assume) at root only a lot of XChangeProperty calls, and only 1300 LOC itself ].

HTH.

I guess the main question behind all this is how long do we want to lug legacy compatibility code along? There are other places than this (e.g. the cursor font stuff Behdad pointed to). In this case, instead of sinking a lot of time into fine-tuning and micro-optimizations I'd rather advocate disabling the plugin by default and seeing if anyone complains. If you're the only one (which doesn't seem that unlikely to me), well, run xrdb using the autostart mechanism or something.

I wonder, is there a UI to enable/disable g-s-d plugins?  That feature should be added to the GUI tool we have for the session.

I almost wrote a mini-cpp using GScanner, but gave up.  I agree that GNOME shouldn't by default care about other toolkit's theming.

Created attachment 121895 [details] [review]
One line patch

2008-11-03  Behdad Esfahbod  <behdad@gnome.org>

        * data/gnome-settings-daemon.schemas.in: Disable xrdb plugin by
        default (#bug #557807)