Created attachment 432 [details]
The patch as found on <http://raw.no/patches/openbox_theme_overrides.diff>.

It's too bad the themerc's aren't xml, that would make it a whole lot cleaner.
Regardless, I think this would be really handy.

It would probably be a lot easier to write the override stuff in the old format
and just have it in ~/.config/openbox/themeoverride or something

Yeah, I'm sure that would make things alot easier.

In addition to themeoverride, maybe you could also do themeoverride.<themename>.
This way the user wouldn't have to swap the override file when they change
themes. More global changes could go into 'themeoverride' and theme-specific
(colors, buttons) in 'themeoverride.TheBear'.

That seems sort of not worth the time, if you want per-theme overrides, just
copy the theme to your ~ and change it. The point of theme overrides is to have
something regardless of what theme you have chosen...

Is it on purpose that the themes themselves aren't in XML as well?  It should be 
easy enough to whip up a patch that uses XML based themes.

A conversion tool could also be written fairly easily.

There was some discussion on the mailing lists about xml themes a while ago, a
few different mockups and such. Not sure why it was decided to stay with the
current theme format.

August and September of 2003 there's some threads, could be some in June maybe..

http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?24:sss:796:200308:klghllbfgdicilebleie#b
http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?24:mss:1062:200309:cknnbcbpmahdangnbbma

I know there's more than this, I just can't find it.

it's probably hard to find in the ml archives since it was mostly discussed on
irc, and it's offtopic for this bug anyway. openbox will most likely not get xml
themes though.

so um, thinking about this... would anyone ever want to override anything else than the fonts? i don't think so.

> would anyone ever want to override anything else than the fonts?
Yes!  Set border=0, such that undecorated windows only renders the client and nothing else.  Or set border.color=black, such that there is no visible `separation' between two overlapping xterms.  Or set the sticky XBMs, if you've fallen in love with a particular bitmap.  Just because you're not going to use a feature doesn't mean no one else will (this sounds arrogant, but isn't).

> if you want per-theme overrides, just copy the theme to your ~ and change it.
Meh.  What if the theme shipped in the openbox-themes package is updated?  Then you'll have to twiddle with three-way merges.  Also, the data structure embodied by themerc is a mapping, not a sequence, and diff/patch doesn't understand that distinction.

>> would anyone ever want to override anything else than the fonts?
>Yes!  Set border=0, such that undecorated windows only renders the client and nothing else.

There's already the keepBorder option.

>> if you want per-theme overrides, just copy the theme to your ~ and change it.
>Meh.  What if the theme shipped in the openbox-themes package is updated?  Then you'll have to twiddle with three-way merges.

You don't HAVE to update a theme. And if it does change your overrides may not be appropriate anymore anyway.

<Mikachu> openbox will most likely not get xml themes though.

Care to explain why?  Are you just lazy (which is OK) but will accept a patch, or do you think it would actually be a bad idea?  If the latter, why?  Compatibility? XML sucks (huh)? XML sucks for this particular application?  Elaborate as seen fit.

here is the followup on the second url from #7 (unedited)

15:59  * Mikachu makes theme proposal
16:00 <merry> i'm doing one too!
16:01 <scott> Blah41, will you marry me!
16:04 <merry> we're all marrying themes!
16:04 <merry> i hope she said 'yes' scott
16:09 <Mikachu> merry: mikachu.ath.cx/themerc.xml
16:09 <Mikachu> er wait
16:11 <Mikachu> now
16:12 <Mikachu> stupidmozilla*renamefile*
16:12 <Mikachu> http://mikachu.ath.cx/xmlthemerc
16:13 <Mikachu> + .html for my vim syntax hilight
16:19 <merry> mikachu: i like it a lot
16:20 <Mikachu> :)
16:21 -!- tseng|sleep is now known as tseng
16:21 <tseng> dude that is awesome! xml w/o 60 billion tags
16:22 <tseng> i like how you use attributes instead
16:22  * merry hugs mikachu
16:23 <Mikachu> you might not want to do that, i haven't showered today
16:23 <merry> nor i
16:23 <Mikachu> ah, then it's alright
16:25 <@shrimpx> that xml is the dumbest thing i've ever seen
16:26 <@shrimpx> show it to xor
16:26 <@shrimpx> you might get kickbanned for it
16:26 <Mikachu> haha
16:27 <tseng> why, everything else is xml now
16:27 <@shrimpx> tseng: we've been through this already. the theme format will stay xrdb
16:27 <@shrimpx> the 'everything is attributes' card has been played and it's very much hated
16:28 <merry> everything else *in openbox* is in xml for parity maybe the theme file should be?
16:29 <@shrimpx> xor: the parity argument doesn't fly
16:30 <@shrimpx> s/xor/merry/
16:31 <merry> i think the theme format is ok as is, but if it were to change i think it should not just be shuffling 'round bits here and there
16:32 <@shrimpx> it's not hard to change to xml. it's just that no one's been able to put forth a convincing argument that xml is easier to read, write and edit for themes.
16:33 <@shrimpx> xml made perfect sense for menus and rc. for themes, not as much
16:34 <merry> i think my wishy washy effort on the mailing list is a weak compromise, but it's easy to read?
16:34 <@shrimpx> in the end up you have a more verbose file. that's it
16:35 <merry> maybe it should use rep or lisp :)
16:35 <Mikachu> shrimpx: isnt my xmlthemerc less verbose than the current themercs?
16:36 <@shrimpx> Mikachu: yours doesn't fly simply because you abuse attributes. xor hates that
16:36 <@shrimpx> and me too
16:36 <@shrimpx> we might as well use gtk classes if all the xml tags are basically blocks in themselves
16:37 <@shrimpx> merry: heh
16:38 <@shrimpx> Mikachu: the other thing is that the style="raised gradient crossdiagonal bevel1" needs more explanation in xml
16:39 <@shrimpx> xor played around with things like border="raised" type="gradient" etc
16:39 <Mikachu> yeah i was thinking that too
16:39 <@shrimpx> fucking blackbox it should have never existed
16:39 <Mikachu> i don't know xml so well, so i dont know what's "right" and "wrong"
16:39 <Mikachu> it's just a suggestion
16:39 <Mikachu> if you don't like it, fine
16:39 <merry> blackbox should never have been raised from the dead
16:40 <@shrimpx> i was just saying that xor already played with exactly what you're doing
16:40 <@shrimpx> and hated @ it

the theming system needs serious deliberation... this is one issue that definitely needs to be addressed. might have to do something i hate in order to get a result that i like. i'll think about it.

This may or may not satisfy people, but it is related, fonts are now going to be specified in the configuration rather than the theme... Details follow:

Fonts are now going to be configured in the rc.xml file. The format is such as

<theme>
...
  <font place="ActiveWindow">
    <name>sans</name>
    <size>8</size>
    <weight>bold</weight>
    <slant>italic</slant>
    <shadow>yes</shadow>
    <shadowOffset>1</shadowOffset>
    <shadowTint>64</shadowTint>
  </font>
</theme>

Valid place="" are ActiveWindow, InactiveWindow, MenuTitle, and MenuItem.

You can omit any fields and get the default for it. You can omit naming a font for a place="" and get the default font for it.

This is completely replacing theme-specified fonts, for better or for worse. Font shadowing may go back into the theme at some point, instead of in the rc.xml.

I'm going to mark this bug as FIXED although it's not doing exactly what was requested. What was requested is just not going to happen upstream until the day the theme format changes to xml. This may happen soon, I'd like to see that happen now. (But not until the next major release development cycle.)