Ok. Basically, themes are going to allow replacement of any block at all (except block_programs, because those are due to be moved to vars where they really belong) but no vars (so those last few fonts should get moved over to blocks if you want to theme your fonts).
What you normally think of for themes is a way to allow the user to change the look of a site, or sometimes the feel/layout as well. That's one of the things I want to do here.
The other is to use the themes structure to allow the admin to assign certain themes as default for certain conditions. These conditions would be: user group, browser user-agent, and site section. (If you can think of any more classes of conditions that would be useful, let me know.)
The main reason I took on the themes task was so I could make a "newbie" theme with extra help text inserted here and there with links to the relevant sections in the site howto; by the time the user figured out how to change their theme to "normal" they probably wouldn't need the extra help. (My site is geared for writers, not computer geeks; I've had a lot of people tell me scoop is hard to figure out from a user point of view.) I figured a theme engine in scoop that allowed replacing colours and fonts wasn't that far off from a theme engine that allowed replacing any and all blocks, because colours and fonts are blocks, so I decided to make a theme engine.
Anyhow - the admin can define themes so that anonymous users get one theme and logged-in users get another. Generalise it to the admin being able to define a theme for each user group. I'm sure somebody will want that eventually.
The admin can also define themes that are selected based on the visitor's browser user-agent string. No defined string will, of course, fall back on the default theme. This will allow the admin (if they're feeling really ambitious) to make a table-based layout for older browsers and NS4, a CSS-based layout for modern browsers, and a much-simplified layout for stuff like PDA browsers, all using plain old blocks admin.
Finally, the admin can also define themes based on the section a story is in. This wouldn't apply to the front page or "everything" pseudo-sections, but would apply to section indexes and individual stories. Um, for subsections I'm not sure how to work that in because I don't really know how they work.
Ok. This sounds all well and good, but what happens when you get a user in group "whatever", which has a theme defined for it; is running a browser whose user-agent has a theme defined for it; and is browsing a section which has a theme defined for it? It's entirely possible that some of those themes will have some conflicting customised blocks - like, oh, the comments block, or the box template. And if the user chooses yet another theme, then what? No more section-specific colours? A CSS theme is chosen, when the user runs NS4, and now can't use the site?
I was thinking of a simple priority list: layer the themes in this order, last one overwrites previous ones. The problem with that is that it'll be really hard to figure out which theme is causing what effect. Figuring out what's where in scoop's block system is tricky enough as it is, I don't really want to create an effect like that.
The thing is, I don't know in advance how many or which blocks you, as a site admin, are going to replace in any given theme. The system won't really care; it loads the default theme followed by the one selected, overwriting only those blocks you changed for that theme (the default theme is the only one that must have a complete set of blocks, as it is the parent to all other themes.) I also don't particularly want to restrict the admin to only defining a browser, section, or user set of default themes.
I'm also going to need to modify Blocks.pm some more. Notably, to check that the block has been given a category and a theme, because otherwise it appears to disappear after you save it. Also, to handle editing blocks in different themes.
Right now, it's set up to choose one theme, then pick and edit categories as normal, with only the blocks for that theme showing up. Just because the one theme is currently hardcoded as "default" doesn't mean the capability isn't there. I think. :-)
It also should allow you to choose one block, and see all copies of that one block for all themes.
And show you the passed-through blocks of the parent theme (marked appropriately so you know they're not part of that theme) and if you edit a parent block while in a "single-theme" view, the system creates a new block for the theme while leaving the parent block untouched.
And... and... and...
Please be patient; I'm not a particularly good (or fast) programmer. I'll muddle my way through this eventually. (But if anybody wants to help me out, I'll be more than happy to take suggestions!)
