I've been remiss in not reporting this sooner.
If foo theme defines some theme settings, those settings will be visible on the page admin/build/themes/settings/foo with the following text, “These settings only exist for the Foo theme and all the styles based on it.” (The words the styles should be changed to sub-themes, btw.)
But if a subfoo is a sub-theme of foo and it defines a couple extra theme settings of its own, the subfoo theme does not see any of its parent's theme settings when visiting admin/build/themes/settings/subfoo
The form altering logic in system_theme_settings(), which I wrote just after code freeze in July 2007, does not deal with the full level of inheritance that the rest of the theme system gives themers. It only shows the current theme's settings or, if the current theme doesn't have any settings, it shows the parent theme's settings. And it doesn't deal with multi-level inheritance.
A sub-theme's theme settings page (admin/build/themes/settings/SUBTHEME) should have all of the theme settings forms from its parent themes.
|FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch system_admin_inherit_theme_settings-481142-26.patch.|
|FAILED: [[SimpleTest]]: [MySQL] Fetch test file: failed to retrieve [issues] from project client.|
|FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch system_admin_inherit_theme_settings_v3.patch.|
|FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch system_admin_inherit_theme_settings.patch.|