On Sun, 27 Mar 2005 21:03:10 +0200, Steven Wittens <steven@acko.net> wrote:
Adrian Rossouw schreef:
On 27 Mar 2005, at 2:25 PM, Moshe Weitzman wrote:
perhaps disable all blocks beside navigation while in admin. that would guarantee that a 3 column site collapse into a 2, thus giving more breathing room ... i didn't attend that session so perhaps more sophisticated proposals were made.
Certain themes like kubrick and co. are still completely unusable when this happens.
The idea is to get a clean consistent admin interface that works for everyone, regardless of theme .. and then allow the designer to override it with his own theme / look.. IF THEY KNOW WHAT THEY ARE DOING.
I thought we were going to leave this up to the themer, as it's mostly a theme issue. Really, CSS positioning issues appear on more than just the admin, so it's not an ideal solution.
I would default it to 'off' for most core themes, as they have a very usable admin section.
Steven Wittens
This is really not the "wording" that I would advocate, although the result is essentially the same as what you're going after. Drupal should ship with a default /admin theme, which provides a consistent backend UI for all Drupal installs. This should be part of a new default theme, which has yet to be designed (I'm suggesting that we replace Blue Marine as the default with something totally new and much improved -- to set the bar for and motivate new themers). This /admin theme can be overridden in individual themes if there is an /admin directory provided which contains the appropriate styles, etc. This means that Kubrick themes would use the default Drupal /admin theme but other themes, notably ones shipped w/ Drupal could provide their own /admin themes. I wrote up a reply to the CiviCRM guys about some questions they had w/r/t to remotely theming their application, which will eventually ship with CivicSpace. The general idea is that we can extend the /admin theme idea to other third-party components, so if your theme comes with a /civicrm directory, you can override the defaults, allowing Drupal distros to better customize the complete look and feel of the package. My reply:
For this release it would mean we integrate with Drupal's themeing system and provide a user a choice between CiviCRM's stylesheet and Drupal's theme.
If you want a seperate style sheet for the civiCRM output, you *could* include a separate sheet in the drupal theme - but you will have to make sure that there are no naming collisions with other element's classes or IDs.
This is actually a very interesting discussion that I can shed some light on. It was decided at DrupalCon to rip out the site admin UI from the community admin UI and make administering your site occur in a visually isolated environment. There were a number of reasons for this, but I'll speak more directly to the technical implementation that CiviCRM can benefit from. In particular, Drupal will now ship with a default admin theme. This theme will be used for all pages generated in /admin (i.e. /admin/block/) so that theme developers need not worry about the look and feel of the admin area (since more and more themes, like the ported Kubrick theme, don't deal with the wide tables of the admin UI). However, if a theme comes with an /admin directory then those styles will override the default Drupal admin theme. The purpose of this is to allow designers to control all the visual aspects of a site if they desire, but makes it optional so that they can focus on the frontend without worrying about mucking up the backend. CiviCRM could follow a similar approach, where a default theme is provided, but if a theme comes with a /civicrm directory, the selected theme would override the defaults. This would make it very easy for CivicSpace or any other CMS to apply its own styles or themes to CiviCRM while making it possible for CiviCRM to have its own identity when shipped independently. Anyway, I thought that this would help move the discussion along. I'd be interested to hear your thoughts, ideas, opinions or concerns about this approach. Chris