GNOME Bugzilla – Bug 363129
Including a directory in a gtkrc
Last modified: 2012-01-26 04:58:01 UTC
It would be useful if gtk+ could read an entire directory for gtkrc files to parse. The following are possible use cases for this behaviour: * The original gtkrc is large and could be usefully split into smaller files. These could be included individually, but it would be more convenient to be able to specify a directory to keep them in. * Third party applications would like to extend certain themes with their own style rules. This is currently not possible without modifying the original gtkrc (either to include a new file or otherwise).
Created attachment 74944 [details] [review] Patch #1 This patch allows a directory to be used in a gtkrc include statement, and parses any files with the suffix ".gtkrc" that are found in the specified directory.
Created attachment 74950 [details] [review] Patch #2 The previous patch included some other unrelated changes. This patch improves on the previous by fixing a small leak and preventing a call to parse the directory.
(In reply to comment #0) > * Third party applications would like to extend certain themes with their own > style rules. This is currently not possible without modifying the original > gtkrc (either to include a new file or otherwise). I'd think for this it would be more practical to make gtk attempt to load application specific gtkrc files under the theme directory. Something like $datadir/themes/$themename/gtk-2.0/nautilus.gtkrc Then the contents of that application specific theme file could determine whether to replace (when using only custom widgets) or extend (include "gtkrc") the general theme. This would be comparable to the gnome extension for loading ~/.gnome2/<applicationname>rc with the added benefit of being able to write a gtkrc that is tailored both for the application and the theme.
One of the rationales which went into the report Thomas filed was to allow this ability not just for applications, but also libraries. The name of an application can be deduced at runtime, so "$datadir/themes/$themename/gtk-2.0/$app.gtkrc" works pretty well there. But I'm not aware of a good method to query what library contributed a particular GObject definition, so producing a backward mapping like "$datadir/themes/$themename/gtk-2.0/$library.gtkrc" would be difficult.
Good point. I would, however, prefer not to load a directory full of gtkrc files "just in case." I know it is not such a big problem on average desktop (the largest gtkrc I've seen is around 1-2k lines) but on 770 we have gtkrc an order of magnitude larger including ~500 image references, and all references consume memory (gtkrc has been identified as one of the biggest contributors to startup memory consumption.) So all applications taking a memory hit just because the media player needs custom theming makes little sense IMHO. I do agree the suggested implementation would probably be good in general, but maybe not for solving this problem. For the $library.gtkrc case I'd think that foo_init() functions could add some extra gtkrc files to look for in addition to the normal gtkrc and the $app.gtkrc I'm hoping for.
Those are some interesting observations about the memory footprint. A couple of counterpoints: (1) I would think that the theme writer has the ability to prevent this nightmare situation simply by refraining from putting using an "include /path/to/dir" statement in the master gtk-2.0/gtkrc file. If the writer of a theme wants to elect for this increased functionality at the possible expense of more resources, then let him suffer the consequences. (2) (Just to clarify) I think that your suggestion is the better approach for end-level applications. Aside from resource considerations, there's no reason to risk collisions in the theme space of every program just for one app's need. About installing the extra RC files during lib_init(): this doesn't work if you need to switch among themes. Once you call gtk_rc_parse() that stuff is there for the duration. This is a pretty big deal; I'd like to use Gtk+ themes to switch from intense colors during daytime to muted ones at nighttime. In fact, there doesn't seem to be any other reasonable way to coordinate such a switch among numerous applications running simultaneously on a device.
(In reply to comment #6) > About installing the extra RC files during lib_init(): this doesn't work if you > need to switch among themes. Once you call gtk_rc_parse() that stuff is there > for the duration. This is a pretty big deal; I'd like to use Gtk+ themes to > switch from intense colors during daytime to muted ones at nighttime. In fact, > there doesn't seem to be any other reasonable way to coordinate such a switch > among numerous applications running simultaneously on a device. In gtk 2.10 I think you can use XSettings for defining logical colors. Otherwise you're right. However, as gtk already support theme switching just fine (for the implicit $datadir/themes/$themename/gtk-2.0/gtkrc) I see no reason why you couldn't plug in more files into the same logic and things would "just work." (I have a patch which tries to do exactly that for $appname.gtkrc files) Sorry for bloating this bug with off-topic, I need to file a bug for the application themes.
gtkrc has been superseded by css in gtk3, so closing this