[development] Move multiple theme per site support to contrib module

[Jeremy Epstein]

On 6/7/06, Adrian Rossouw <adrian at bryght.com> wrote:
> How many people actually use user specified themes on their sites?
> This is the kind of functionality that only
> really clutters up the default interface, and confuses a lot of
> people for no good reason.

Agreed. +1 from me for moving user-specified theme stuff to contrib.
But as some people have made clear in this thread, this is a feature
that DOES get a reasonable amount of use, so if/when it moves to
contrib, it really does need to be properly maintained. I guess that
if it really is needed by some people, then those people will ensure
that it stays maintained ;-) (don't look at me).

> What I would also like to see , is that we re-organise the the admin
> as follows :
> admin
>     display
>         theme (default tab)
>         regions (tab, ie: what admin/blocks used to be)
>         settings (tab)
>
>
> Also. completely getting rid of the tiered theme setting stuff, and
> only having one set of settings, per theme (same with the block)
>
> I do believe that the block / region settings are very much a display
> issue.

My initial reaction to this was "Nooo! Not more mouse clicks! Not more
nested admin pages! Usability nightmare!" However, if this change is
absolutely needed to bring in a new "display view system" (which I'm
sure I will like, once I've worked out what it is :-p), then it
certainly becomes more justified.

Dries has indicated that the #1 priority for Drupal 4.8 is usability
improvements (esp. for admin pages), so if this adversely affects
admin usability at all, then -1 from me.

Also, I think that this discussion has made the issue of semantics one
that needs to be urgently resolved. In particular, as Adrian has
pointed out, we need to settle the use of the word "view". Here's my
take on the matter:

- The views module has become very popular. IMO, the word "view" is
'taken' by the views module, for better or for worse. When people
think of a view in Drupal, they think "custom node listing".
Therefore, giving the word "view" a second definition (associated with
themes) is a bad move, and will just lead to confusion.
- If we introduce a new "display view system", where you can associate
theme(s), block settings, etc with a particular "display view", then
we need a new name for that system.
- We should change the definition of a "theme" within Drupal (haha -
how hypocritical of me, we can change the def. of 'theme', but not of
'view'!). A "theme" can now be the name for a "display view". You will
be able to associate [what is now called a theme], and blocks /
regions / settings, to each "theme".
- What is now called a "theme" gets renamed to something else. My
suggestion is "skin".

Why change the definition of the word "theme" in Drupal? The word
"theme" is more of a general / all-encompassing word, in the
dictionary sense, and in the computer sense. In MS Windows, for
example, a "theme" is: "a background plus a set of icons, sounds, and
other elements to help you personalize your computer". The word
"skin", OTOH, is more specifically related to visual display, colours,
positioning, etc. If we add a new logical level to the display system
in Drupal, then "theme" should be the top-level general entity, and
"skin" (or some other word) should be the specific look-and-feel
entity that can be associated with one or more themes, and perhaps
configured differently per-theme.

On a related topic, if we introduce this new layer, then when the
'select different theme' option is enabled, users should be able to
select a different theme in the "new all-encompassing" sense, i.e.
they choose a theme, not a skin. So when they switch themes, all the
settings for blocks and other things change accordingly to match it.

What do other people have to say on this difficult issue of semantics
and word definitions?

Cheers,
Jaza.