create new tag
, view all tags
Enhancing the skin handling is one focus of the BeijingRelease. This is currently a brainstorming idea.

One idea is to offer a TWikiSkinBrowser, so that users can see what skins are currently installed and select their favorite skin. This could be done like the plugins, i.e. offer a %ACTIVATEDSKINS% variable that lists activated Skins by name; and a %SKINDESCRIPTIONS% variable that displays a bullet list with a one-line description of each active Skin, possibly including a small screen shot.

Another idea is to offer a SetOfSkins that appeals to users with different needs, i.e. a BareBoneSkin, a ReadOnlySkin, a ClassicWikiWikiSkin, a GraphicalSkin.

-- PeterThoeny - 17 Dec 2001

How about %AVAILABLESKINS% instead of %ACTIVATEDSKINS%? To me, activated means "in operation" in contrast to something available but not being used.

Looking at it more generally, i've seen requests for an enhanced plug-in api, and maybe this is one thing that could be added to it:

Each plugin would have a type which, possibly along with a version number, would define additional apis that this plugin responds to. In this particular case, a plugin that responds with "SKIN_TYPE" to the PluginType() call would indicate that it can respond to the SkinDescription() and SkinName() calls. This does imply that there is a handler for this type of plugin/object. This might imply a different architecture for TWiki too...

This was something I partly addressed in the SessionPlugin and something we have at work as a consequence. To me the first issue is how to pick up the skin, if the user doesn't login you have to either use a cookie, a session (i.e. a cookie that can do skin + other settings) or URL re-write for all subsequent TWiki accesses. Incidentally, the session plugin uses the %SKINS% variable. Auto discovery would be possible based on template names, but I thought this might be a bit expensive.

-- JohnTalintyre - 20 Dec 2001

Has no-one else got any thoughts about this?

-- JohnTalintyre - 03 Jan 2002

I've a lot of random thoughts on this topic, and I've come to view the problem from the user's perspective rather than from an implementation perspective, after having developed umpteen skins for our site.

If you give the user a drop-down list in a form somewhere, maybe in their user topic, that allows the user to select a default skin, the only thing you have to solve is where to store the skin setting, and how to store it. It could easily be done by having a cgi-script edit the user topic and substitute or insert a skin setting when the dropdown list is invoked.

Reguardless of the implementation behind EnhancedSkinHandling, this also brings up another subject: UserAccountManagement; I think a user management interface is extremely important to develop; Users want to see a ManageMyAccount link at the top of each topic that takes them to another topic that allows them to change their skin, their info, etc, using a form. I've seen this used at JGuru, and www.themes.org. They don't necessarily want to edit their homepage just to change their skin; It's too much work wink (we have lazy engineers who believe in conservation of energy).

I'm also interested in implementing skins on a topic-by-topic or group-of-topics basis (not for a whole web), for implementing presentation slides within a web. This might be a good case for implementing a SlidePresentationPlugin

-- PeterNixon - 04 Jan 2002

How about putting the various user account parameters into a TWikiForm, as part of the user's home page? That way they can be edited using the normal form interface. Or perhaps they could be put into a Main.FredBloggsSettings page, linked from the home page, with the link text saying ManageMyAccount perhaps (although http://slashdot.org seems to just use the user name to access settings and home page).

It would be useful to have a quick link to the user's home page (or settings page) as part of the default skin (or perhaps a new usability-focused skin).

-- RichardDonkin - 04 Jan 2002

Good to see some thoughts. However, I still wonder if people share my concern that TWiki without sessions can't use a skin when viewing topics - which isn't much good. TWiki does have the facility to remember a user based on IP address, but I just don't trust this approach (effects of NAT etc).

I think forms would be good for user preferences. My thoughts is to continue to support the existing mechanism (button with property=value) but also allow some comonly used options to be specified via the form, with some information in the form definition indicating a field defines a preference value.

-- JohnTalintyre - 04 Jan 2002

Yep, IP address is not particularly functional, except for simple static IP, single user workstations. That stuffs up home users, DHCP networks (most busineses), and those of us who like multi-user OS's ;). I natruly like my UserCookiePlugin because i don't want to forse users to login just to view pages..

-- SvenDowideit - 06 Jan 2002

The only reason we force folks to log in before viewing is that some material should not be viewed by everyone (it's confidential, or under non-disclosement agreement). Typical healthy big-company paranoia. For situations where that's not necessary, a LogIn link could be placed somewhere on the page that sets a cookie via the UserCookiePlugin, maybe towards the top, near the ManageMyAccount link. This would work sort of like Skinz.org.

-- PeterNixon - 06 Jan 2002

Has anyone thought about modularizing the skins? On my site I made a topic with the main menu (NavMainMenu) which includes the navigational links to main topics on my site. I then had to hack at view.tmpl to include it. How about making this much easier by defining the layout like this:

| logo  TWiki . Main . YourTopic                      list of webs|
|       Home | Changes | ....                                     |
|     |   Your Topic                                        |     |
|     |                                                     |     |
|     |   blah, blah, blah                                  |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
|     |                                                     |     |
| Topic YourTopic  Edit | Attach | ....                           |

This would appear as a table, and each table cell gets %INLCUDEs

| INCLUDE NavTop                       |
| NavLeft   |               | NavRight |
| INCLUDE NavBottom                    |

The default install defines NavTop and NavBottom, but leaves NavLeft and NavRight empty. This makes it easy for admins to change the appearance of the site, including what links appear at top and bottom. Of course, these 4 topics should only be editable by AdminGroup.

This also means that a skin is essentially loading in these 4 topics, which should make skin creation and distribution simple.


-- ChrisRiley - 04 Mar 2002


I like your modular approach. My guess is if we had this, we would see an emergence of new skins as it would be easier to create them.

Personally Im dying for a skin that looks something like http://openeeg.sourceforge.net/.

-- JohnCavanaugh - 15 Aug 2002

John says 'if we had this' - well, we already can do it - WITHOUT touching the core - by making a custom skin.

Just make a skin that defines those 4 areas and include the four other topics around the main %TEXT%. Actually in my new skin I'm doing this (partly) for a sidebar. The sidebar is just another topic that gets included by the view.tmpl. Using e.g. CSS you can then include this sidebar in a particular 'div', placing it a the right position in the page.

-- JeroenVanDongen - 15 Aug 2002


This is great. Maybe what I think is missing (perhaps it already exists??) is a generic custom skin template for people to work from. Basically a starting block for all new skins. If this exists somewhere, please point me at it.

-- JohnCavanaugh - 15 Aug 2002

Most ideas in this topic are currently being built into PatternSkin:

  • Modularizing layout blocks: top bar, left bar, bottom bar in individual topics
  • Custom CSS layout defined in a topic, so users can set a skin in their home topic

Postponed to DakarRelease:

  • Webform to choose or create a skin; some sort of generator or wizard.

Further ideas for PatternSkin:
Make a distinction between layout and style, so layout can change with the same style and vice versa.

-- ArthurClemens - 20 Apr 2004

Removed from CairoRelease, as it is not specific enough to track. If there are features documented here that require code changes in Cairo these must be tracked using thier own specific patch topics.

-- CrawfordCurrie - 08 Jul 2004

A TWikiSkinBrowser has been added to CairoRelease.

-- PeterThoeny - 26 Jul 2004

Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r21 - 2004-07-26 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.