<<TableOfContents>>

== Introduction ==
The theme of http://simplementewiki.org/

Very simple theme, yet in a state of flux (colors will probably change, so think about it as a framework to do your own theme).

Basic ideas behind it:

 * Source ordered (better search engine optimization) and
 * skip links, customizable accesskeys and structuring hidden h1 headings for a more AccessibleMoin.
 * Completely CSS based (no tables).
 * Fluid, elastic layout.
 * Contains code for Google Analytics. ....

Works fine without display bugs on
|| || Moin1.8 ||Moin1.6 ||Moin 1.5.4 ||Moin 1.3.4 ||
||Opera9.10 on WinXP || || (./) || (./) || (./) ||
||Firefox2.002 on WinXP || || (./) || (./) || (./) ||
||IE7 on WinXP || some minor css bugs (need to be fixed) || (./) || (./) || (./) ||
||Firefox3 on Linux / windows||  (./) || || || ||
||Opera9..27 on Linux ||  (./) || || || ||

check out [[#Download]]s...

{{attachment:SimpleMente-10.jpg}}

== A few details ==
=== Logo ===
The logo is text+CSS, not an image. In order to do that, simplementewiki.py has:

{{{
 logo_string = u'<span id="simple">Simple</span><span id="mente">Mente</span><span id="wiki">Wiki</span>'
}}}
and the css specifies:

{{{
/* --------- isologo ----------------------------------- */

span#simple {
 display: block;
 text-align: right;
 font-family: 'times new roman', times, serif;
 margin: 0px;
 padding: 0px;
 font-size: 3.5em;
 color: #222;
}

span#mente {
 display: block;
 text-align: right;
 font-family: 'times new roman', times, serif;
 margin: 0px;
 padding: 0px;
 font-size: 5em;
 position: relative;
 top: 0.18em;
 color: #888;
 opacity: 0.65;
}

span#wiki {
 display: block;
 text-align: right;
 font-family: 'times new roman', times, serif;
 margin: 0px;
 padding: 0px;
 font-size: 2em;
 position: relative;
 top: 0.75em;
 color: #444;
 padding-bottom: 2em;
 opacity: 0.55;
 letter-spacing: 0.25em;
 font-style: italic;

}}}
/!\ Users of this theme are encouraged to use only text-logos instead of an image for accessibility sake's. See section on "Hidden H1 headings" for an explanation

=== Skip Links ===
Simplemente theme has a lot of hidden information for screenreaders built in including a so called skip link navigation (To see the real power of the theme turn off css and get a clue how the structure of the page appears to blind people). However this in not only a feature for users of screenreaders but for all. In IE7 and Firefox2 just press the tab key several times to see what is meant by that.

{{attachment:firefox.png}}

As you can see, hitting the tab key causes a afore hidden extra navigation link to be displayed. You can now choose where you want to jump in the page. Just press "enter" for that. Keep on "tabbing" with the tab-key through the page and you will see that there are more such hidden navigationmenus built in: Just before the editbar and also at the end of the sidepanel just before the footer.

'''Annotation:''' In the skip link menu of the page editor there is a new skip link 'Jump directly to the input field' available. This link is by default deactivated since the activation depends on your wiki's edit-conflict-policy (see HelpOnEditLocks): If edit look is activated it makes sense to activate this skip link. If only "warn about edit conflicts" is activated the (blind) users needs to read the message box first to get to know about potential conflicts so as not to run into serious trouble. In this case it is better to turn the link of.

'''Note:''' Skip link navigation does not work on Opera9... Please also test other browsers and report the results here.. You have just to figure out the shortcuts keys for "jump to the next link" and then you can test it.

=== Customizable Accesskey ===
Since skip links don't work correctly on Opera9, accessibilty has to be assured there by other means. Opera9 has a really great built-in accesskey support - the best you can find on the market, way ahead of its competitors. By pressing "shift-escape" you get a small window displayed which lists the accesskeys currently set on the page (Opera uses the link text, title and label attribute to displays this nice menu). Just press the key you want and trigger the respective action by that..

{{attachment:opera.png}}

However accesskeys are prone to a lot of problems (see MoinMoinExtensions/HotKeys for that). Mainly there a lot of collision of accesskeys with the built-in browser shortcut keys. Also conflicts with assistive technologies (such as screenreaders) and their shortcuts arise. Localization of accesskeys is also a problem (F for "File" does not work e.g. for German "Datei").

Instead of having built-in accesskeys, the solution is the have customizalbe accesskeys. I.e. the user can define his own set of accesskeys according to his browser, language, screenreader he uses. With Simplemente theme installed you can simply upload a shortcuts definition file to your homepage. It must be named "shortcuts.js" and look like this:

{{attachment:shortcuts.js}}

To set an accesskey you have just to figure out by looking in the html-code which 'id' or 'name' Moin uses for a certain element, e.g. the searchinput field is referenced by an 'id' and named 'searchinput', the preview button is referended as 'name' and called 'button_preview'. To set an accesskey for these elements just write id#searchinput=s if you want to have s as shortcut for search, name#button_preview=p if you want to have p for preview..

Here's a list of the most important id and names (built-in as well as enhanced ones by Simplemente):

 * name#metanav : main skiplink navigation at the beginning of the page
 * name#page_content : for the beginning of the page content (including pagetitle and potential message boxes)
 * id#top : for the top of the page
 * id#bottom : for the bottom of the page
 * name#edit : for the edit and actions menu (name#texteditlink, name#guieditlink, name#info, name#attachments, name#action for the "More actions" box)
 * name#nav : for the navigation menu (name#!PageName for the pages there, name#navbar_current_page for the current page to quickly return to the page after e.g. viewing a diff)
 * name#user : for the users menu
 * name#trail : for the page trail (and name#trail00, name#trail01... for the pages in the trail)
 * id#searchinput : for the searchinput field
 * name#save_button : for the edit save
 * name#preview_button : for the page preview
 * name#button_spellcheck : for the spell check
 * name#button_cancel : for cancel
 * id#editor-textarea : for the large input field to quickly set focus back on the edit box and return to editing
As already mentioned accesskeys should be only customized by the users. However you can also preset some default keys by a wikiconfig.py var

{{{
 accesskey_defaults = u'"name#nav=1", "id#searchinput=2"'
}}}
To conclude: Drawback of this solution to customize accesskeys is, that it relys heavily on javascript. And there are guys out there working on accessibility which think of javascript being the devil himself... But as already mentioned: there is no 100% solution possible, skiplinks have their drawbacks and limitation on some browsers, accesskeys as well - especially if they are difficult to activate (a problem for physically handicaped people; Opera's sticky-key-solution is here very helpful). But customization by javascript is in my eyes a good way a solves a lot of problems. It's also a powerfull and flexible solution which needs no changes to the core code.

'''Please note:''' Firefox 2.0 tries to emulate the accesskey implementation of Opera so as to avoid conflicts in key assignment. The initial implementation was flawed: numbers were not usable as accesskeys anymore(!sic). The problem is officially said to be fixed in Firefox 2.0.0.1, however there is still trouble with this and it does not work on my Firefox2.0.0.3. Details are available at http://juicystudio.com/article/firefox2-accesskeys.php and http://juicystudio.com/article/numeric-accesskeys-fixed-firefox.php.

And IE?? Oh, well ..... and how is the weather in your country? Yeah, great.. we are doing fine..

'''Please note:''' No support for interwiki homepages yet.

'''Supplementation:''' How to reach accesskeys with your browser (not sure if the list is correct)

 . Alt + accesskey (followed by Enter to execute a link)
  * Internet Explorer for Windows
 . Alt + accesskey
  * Firefox for Windows <=1.5
  * Mozilla for Windows
  * Netscape 6+ for Windows
 . Alt + Shift + accesskey
  * Firefox for Windows 2
 . Shift + Esc + accesskey
  * Opera for Windows or Mac
 . Ctrl + accesskey
  * Internet Explorer 5.2 for Mac
  * Safari 1.2 (Mac only)
  * Firefox for Mac (including 2!)
  * Mozilla for Mac
  * Netscape 6+ for Mac
 . Not supported
  * Camino (Mac only)
  * IE<4, Netscape<6
'''Supplementation2:''' In Simplemente 0.6 you can now cause the theme to display a list a availabel accesskeys on the current page: Just write in wikiconfig.py

{{{
    show_accesskeys = True
}}}
which will cause this:

{{attachment:show_keys.png}}

In the shortcuts.js or wikiconfig.py settings you can now specified a short description text for the accesskey which is shown on the screen:

{{{
"name#nav=1!Navigation Menu", "id#searchinput=2!Search", "name#texteditlink=E!Edit Page"
}}}
In wikiconfig.py you can now also specify global, language dependent accesskey setting, i.e. you can specify here other shortcut keys and other description texts depending on the language. The theme checks for the language the user wants (by request.lang) and then tries to retrieve the accesskey_defaults_[lang_code] from wikiconfig.py. If no language specific keys defaults are found, the theme tries to get the accesskey_defaults.

{{{
    accesskey_defaults_de = u'"name#nav=1!Navigation Menü", "id#searchinput=2!Volltextsuche", "name#texteditlink=E!Seite editieren"'
    accesskey_defaults = u'"name#nav=1!Navigation Menu", "id#searchinput=2!Search", "name#texteditlink=E!Edit Page"'
}}}
=== Hidden H1 headings ===
The third way especially for people using screenreaders is to jump from h1 heading to h1 heading. Screenreader software does support this. Thus every menu has a hidden h1 heading. You can't see it on the screen, but it is there! Turn off the css to see the real and optimized page structure. Now you can also get a clue why Simplemente uses a text logo ;-) . The textlogo is a list element of the navigation menu as you can see here with CSS disabled so no image (and its explanation of the screenreader) causes a disturbance for blind users. The logotext is simply appended in front of !FrontPage:

{{attachment:navibar.png}}

Here is a sample how Simplemente looks for a screenreader user with css turned off.

{{attachment:pagestructure.jpg}}

Compare with moderne theme

{{attachment:pagestructure_modern.jpg}}

Note: To get this really work fine wikilevel one headings need to be output has html level two headings, see PageHeading. However this is out of control for theme code. This calls for patching the parser or html-formatter.

=== Navigation with link rel... ===
This is not a feature of the Simplemente theme but of Moin in general. But since most people don't know this it's worth mentioning here. Moin has a lot of built extra navigation information for the wiki, including links to the !FrontPage, !TitleIndex ... To use this for navigation, turn on e.g. in Opera the so called navigationbar (also supported in iCab, Mozilla, Netscape; for Firfox see https://addons.mozilla.org/firefox/2933/):

{{attachment:opera_metanav.png}}

=== Improved print support ===
Simplemente has an improved print support. To use it, do not call the aciton=print but simply choose in your browsers menu "Print preview" or "Print". Why improved? Because you can toggle linenumbers in codelistings on the screen as you want and this is exactly printed out has you have seleceted it but without(!) the annoying text "Toggle linenumbers" :) . See http://moinmoin.wikiwikiweb.de/MoinMoinBugs/ToggleLineNumbersInPrintPreview for more on that. So in my eyes there is no need to have an extra editbar item "printview" anymore (Depreceated with todays browsers). I would suggest to remove this menu item so as not to puzzle users with this (if you have an old browser you can still call the action=print directly).. But how to remove the item? Well..

=== Easy customization of the editbar ===
Always having been annoyed about that "Info" should rather be called "History" or "Pageproperties" or that the "More actions" menu is clutterd with actions most users won't understand let alone use them? No problem, Simplemente offers an easy way to tailor the editbar to your needs. Just put this in your wikiconfig.py

{{{
      simplemente_editbaritems = ( (u'Edit', u'edit'),
                                 (u'Show Latest Changes', u'diff'),
                                 (u'History / Page Properties', u'info'),
                                 (u'Attachments', u'attach'),
                                 (u'Create New Page', u'CreateNewPage') )
    simplemente_editbaritems_ext = ( (u'Subscribe', u'-'),
                                     (u'Quicklink', u'-'),
                                     (u'Render As Raw', u'raw'),
                                     (u'Render As Pdf', u'pdfaction'),
                                     (u'Render As Slideshow', u'Slideshow'),
                                     (u'Visual Site Map', u'VisualSiteMap'),
                                     (u'Pages Linking To This Page', u'backlink') )
    simplemente_editbaritems_de = ( (u'Editieren', u'edit'),
                                 (u'Änderungen zeigen', u'diff'),
                                 (u'Historie / Seiteneigenschaften', u'info'),
                                 (u'Dateianhänge', u'attach'),
                                 (u'Neue Seite anlegen', u'CreateNewPage') )
    simplemente_editbaritems_ext_de = ( (u'Subscribe', u'-'),
                                     (u'Quicklink', u'-'),
                                     (u'Als Raw anzeigen', u'raw'),
                                     (u'Als Pdf anzeigen', u'pdfaction'),
                                     (u'Als Präsentation anzeigen', u'Slideshow'),
                                     (u'Visuelle Seitenübersicht', u'VisualSiteMap'),
                                     (u'Auf diese Seite verweisen', u'backlink') )

}}}
which will cause this:

{{attachment:simplemente_editbar.png}}

The drop-down box was removed, since it is one accessibilty criteria - at least for the BieneAward2007 - to avoid drop-down boxes if possible. Instead of the drop-down box Simplemente has two rows of actions (CSS styles will probably change in future a little bit). The first row is for the main actions (blue links). The second row is the "more actions" row and contains the actions of minor importance (gray links).

 * Simplemente look as if it can find - depending on the selected language of the user - if there are simplemente_editbaritems_[langcode] and simplemente_editbaritems_ext_[langcode].
 * If not: Simplemente tries to get the defaults simplemente_editbaritems and simplemente_editbaritems_ext.
 * If not: Simplememte uses as fall back solution Moin's default editbar in the requested language.
Annotation: Use "Quicklink" and "Subscribe" as editbar item names if you want to use Moin's built in toggle function, i.e. if a page is already subscribed "unsubscribe" is displayed instead of "subscribe".

(!) Idea: Create two new actions "Create new page" and "Other pages linking to this page" which can be put in the editbar. This would be a great help for wiki newbies. Most newbies don't know how to create a new page let alone find the backlink search by clicking on the page name in the breadcrumbs navigation.

 * For "Pages Linking To This Page" see [[attachment:ActionMarket/backlink.py]]
 * For "Create New Page" see [[attachment:ActionMarket/CreateNewPage.py]]
 * For "Render as PDF" see ActionMarket/PdfAction, for "Render as Slideshow" see SinglePageSlideShow, for "Visuale Site Map" see VisualSiteMap (Note:VisualSiteMap is not accesible for a blind person!)

(!) Idea: group items in an "action bar" (edit, attach, etc,) and an "info bar" (versions, backlinks, raw text, etc.)?

=== Improved breadcrumbs navigation ===
Simplemente has now with version 1.0 also an improved(?) breadcrumbs navigation.

{{attachment:breadcrumbs1.jpg}}

Normal page / subpage display

{{attachment:breadcrumbs2.jpg}}

When a virtual metapage is called by an action (e.g. action "info" on FrontPage) this is explicetly stated and the virtual metapage as new virtual metalocation is added to the breadcrumb. By clicking on the pagename you can easily return from the metapage to the page itself again (often a problem for users, see UsabilityObservation/UserCannotReturnToWikiPageAfterPerformedAction).

{{attachment:breadcrumbs3.jpg}}

Crumbs showing interwiki name (if set in wikiconfig.py) and important extra information on a page (mainly done for blind users to get informed about page and page status in a compact way)

''After trying'' the new breadcrumbs ''some time'', please join the discussion below to discuss these new ideas..

=== Footer ===
Accessibillty does not only mean: have skip links, accesskeys, high contrast (like black and white)... It also means: give the user easy access to important information like contact information, privacy policy, disclaimer, imprint etc. On most of the Moin wikis out there I have visited there are nearly no footers where you can find this important piece of information. You always read there !MoinMoinPowered !DesktopPowered !PythonPowered and so on.. This is also important for our reputation, but please do state besides the so called credits also the other information like this:

{{attachment:footer.png}}

With setting

{{{
    page_footer1 = u'<div id="footer_1">This is some test text with links to the <a href="/ContactInformation">ContactInformation</a>,\
    <a href="/PrivayPolicy">PrivacyPolicy</a> and <a href="/GeneralDisclaimer">GeneralDisclaimer</a>.</div>'
    page_footer2 = u'<div id="footer_2">Even more footer customization possible...</div>'
}}}
in wikiconfig.py you can set this important information. With

{{{
   page_credits = []
}}}
or

{{{
    page_credits = [
       '<a href="http://moinmoin.wikiwikiweb.de/">MoinMoin DesktopEdition Powered</a>',
       '<a href="http://www.python.org/">Python Powered</a>', ]
}}}
you can customize the credits section and turn of the built in CC license hint, which tells the user that the wiki content is licensed under these conditions.

=== Google Analytics ===
To use the built-in Google Analytics support, add the google_analytics_account_number variable and your Google Analytics account-number to wikiconfig.py, e.g.

{{{
    google_analytics_account_number = u'1234-5'
}}}
with 1234-5 als your account-number.

/!\ When using this, please be aware of the privacy issues, see http://en.wikipedia.org/wiki/Google_Analytics.

== Translations ==
To get the theme correctly work especially the skiplink navigation please add translations for the following phrases to your local language files:

{{{
 * _('Recently viewed pages')
 * _('Jump directly to the page content')
 * _('to the edit and actions menu')
 * _('to the navigation and search menu')
 * _('to the recently viewed pages')
 * _('or to the personalization menu')
 * _('Jump to the main navigation')
 * _('to the top of the page')
 * _('Your are here:')
 * _('Main navigation')
 * _('Page content')
 * _('Edit and actions menu')
 * _('Personalization menu')
 * _('Navigation menu')
 * _('Search')
 * _('Search Titles')
 * _('Search Full Text')
 * _('Accesskeys')
 * _('Available accesskeys on this page:')
 * _('(opens in new window)'
 * _('Footer')
 * _('Message')
 * _('Jump directly to the input field')

}}}
 * In Moin versions prior 1.6 you have to add these translations manually to your [langcode].py file.
 * From Moin 1.6 onwards there will be a special support for 3rd party plugins. You have just to specify a [langcode].!SimpleMente.po file.
 * Finally: Check if all translations work correclty by disabling css in your browsers. There you can see best all the hidden extra information for screenreader users.
Some translations:
|| ||Moin 1.6 ||prior Moin 1.6 ||
||Spanish (español) || [[attachment:es.SimpleMente.po]] || [[attachment:es.py]] ||
||German (deutsch) || [[attachment:de.SimpleMente.po]] || [[attachment:de.py]] ||


== Download ==
 MoinMoin 1.8 :: [[attachment:simplemente v1-2.zip]] (ugly fixes and some css adjustments) Attention! This is just a prototyp so don't excep any miracle )
 MoinMoin 1.6 :: [[attachment:simplemente1-1.zip]]

If you want to run Simplemente on Moin1.3.4 you can download this file:

[[attachment:simplemente0-8-Moin1-3-4.zip]]

This should work, accesskey support also but the editbar items are not reachable. There are too many changes to the core code too assure backwards compatibility till there, so developmement is stopped for this Moin version. So take this as a basis for your own further adaptions, e.g. to overwrite the editbar function and provide name atributes for the links there.

== Pending tasks ==
 * Check and update translations.
 * Introduce two hidden h2 headings in the navbar to clearly separate search and quicklinks
 * Maybe add a config option to turn of display of "immutable page" in the breadcrumbs nav
 * rtl support
 * Give some more time to the print.css and projection.css. See also http://www.smashingmagazine.com/2007/02/21/printing-the-web-solutions-and-techniques/ for a lot of good hints how to do a good print.css
== Discussion ==
=== improved breadcrumb navigation ===
thanks a lot for the quick fix! would it be possible to avoid two line h1 on top completely, maybe by:

 * only display the page title big, and the other breadcrumbs small, either on the side, or on top, or bottom?
 * not display the "immutable page", or only display it in the alt text?

Hi Thurner!
 * The breadcrumb is not html h1 heading. It is just normal text which is shown big and colorful at a prominent place. Turn css off or have a look at the screenshot above which shows the theme how it looks like without css (The hidden text "You are here" is h1).
 * You can change the size of the breadcrumb, e.g. the link texts or non-link texts (like the ">" character, the text "immutable page" or "info") just by changing "#pagelocation" in the screen.css file. You can make the breadcrumb as a whole very small so that it fits in one line, provide a bottom border to separate it more clearly from content, do, whatever you like and what fits your needs best. It's just the normal css formatting stuff..
 * I have put the breadcrumb at this place, because if a screenreader starts reading a page, it it important for a user to know, where here currently is, at which level he is, what he can do with a page (immutable or not) and if he is viewing a virutal metapage of the current page (info action). Moreover he needs a quick way to navigate through the page (either by hidden h1 headings or skip links). These two things - easy page navigation and information about current page and its state (immutablilty, metapage) must be right at the start of a page in my eyes.
 * Immutability of a page has to be stated explicetly in the text, not in the alt text, so that it is clearly read to the blind. I don't like the way, Moin does it currently: Replacing the menu item "edit" by "immutable page". Menu items should be static in my eyes (therefore triggering an error message when trying to edit an immutable page) or inactivated (grayed out) but not replaced by some new text (Toggle functionalty of subscribing and quicklinking a page is an exception).
 * You can turn off this behaviour by commenting out line 377,378 in simplemente.py (V1.0). However if you do this and use at the same time simplemente's way of an easy editbar customization there is no way for the user to know about the immutability of a page.

Cheers! -- OliverSiemoneit <<DateTime(2007-08-16T18:46:39Z)>>

----

Notes about the improved breadcrumbs:
 * Page status is an important information mainly done for blind users - then make it hidden for normal users
  * If you would have tested the theme, you might have noticed, that there is not way to inform the user about the immutability of a page. Standard editbar behaviout is overridden.
   * What do you mean by "there is no way to inform the user"? You can easily check if the user can write and display whatever information anywhere on the screen. How the standard edit bar is related to this?
    * If use customize the editbar with simplement, the default edit link is overridden. It does not change anymore to "immutable page" if you have not right to write the page. The user is only informed about the immutability by adding this information in the crumbs.
     * You can change it to "Edit (needs login)" or "Edit (needs permissions)", and add a title that explain why you can't edit the page. Both options do not change the item name in a significant way (I also not happy with changing the item to immutable page), and both inform about the status without clicking the link, which is nicer to the user.
      * No I don't like the idea to change a name of a menu item e.g. by adding extra information. This is totally uncommon. Just think of OpenOficce Word or so. There menu items which can't be used are simply grayed out, deactivated. Doing this in Moin (Render "Edit" as normal text not as a link)would be quite confusing. Leading it like it is and clicking on it, triggers than an error. But to inform the user in some ways, I thought, the best ways is to add this information right behind the page name in the crumbs.

 * The "(Immutable page)" is bogus - the page is mutable, you simply don't have rights to edit it currently, maybe because you are not logged.
  * This is correct. However this is Moin standard. You should blame this to the Core Developement team that their diction is imprecise.
   * You can blame me for this; It was better than the previous behavior, I can't remember now what it was :)

 * Page status in the bread-crumbs collapse with a page named "Page Name (Immutable)". Unlikely, but show why you should not mix different things in the title.
  * This example is theoretically possible but totally crackbrained..
   * And what about "FrontPage/Info for FrontPage"? is it the sub page "Info for FrontPage" or the virtual info page?
    * If it is clickable or read as link to the screenreader user, it is a subpage. Virtual pages a renderd black and not as links. You can't do backlink search on virtual pages.

   Lets say you improve the title, and instead of the duplication "FrontPage / Info for FrontPage", you will use streamlined "FrontPage / Info". This also works nicely for other virtual pages: "FrontPage / Backlinks" "FrontPage / Similar Pages" and so on. These nice names will collapse with real sub pages names.
    Indeed, this would be better. The dublication is not nice, but I can live with that. Problem behind this: the name of a virtual page is set by each action itself with send_title. Thus it is out of control of the theme code. Reprocessing and changing the title of the virtual page would be difficult.
     It is quite easy to to get the current action name, you can see how theme code does it currently for shouldShowEditbar and similar methods. I agree that this ugly, but nice title is very important.
     Just displaying the action name is not enough. Just think of search. The seach term is only stated in the page name (of the virtual page). Replacing this just by "search" wouldn't be good. I also don't now, which page names all the actions on ActionMarket set. Page name of an action is set by the respective action, which should convey some special meaning. There is now one-best-way in the theme code to process this page name nicely. Page name of an action is out of control of theme could. Changing the page name could be considered as an violation of the integritiy of an action.

 * Add action result as "virtual sub page" - collapse with real page with the same name. The idea is great - but it should be implemented in the url space. Instead of "PageName?action=info", use "/info/PageName", and "info/PageName/SubPage". But this change cannot be done by a theme. A possible solution is to show always the page name, show the action name in the sub title, and use the page name as a link to return to the page. Currently the page name is used as a backlinks search, but this is unintuitive and confusing feature that should be killed anyway.
  * If you have "TestPage / Info on "TestPage" clicking on "TestPage" takes you back to TestPage. If you have "TestPage / SubPage " clicking on "SubPage" performs the normal backlink search. Clicking on "TestPage" takes you back there.
   * This inconsistent design. When you click on a page name - the same thing should happen - always. You don't want to surprise the user with "smart" unpredictable behaviors. I suggest that you always show the page, and move backlinks search elsewhere.
    * This is true. On the other hand - if I change this - a lot of people would complain here, that they are used to click on the page name to perform a backlink search. A solution that fits all needs of everybody, is impossible. I didn't want to go to far away from default Moin behaviour but improve in some parts. Above I have provided a new action backlink.py which allows to put backlink search in the editbar and thus in a more prominent place, which could also found and understood by wiki newbies.
     * You don't need to make everyone happy - just most of them. This is the time to kill the backlinks search in the title and use it for navigation. Showing the page is much more important and common than backlinks search. Count how many times in a day you so a backlinks search, and how many times you navigate to the page using the breadcrumbs.
      * Seldomley do I use backlink search. Often people complain, that the clicked on the page title to get a refresh but instead they got an hour lasting backlink search. Maybe it would be really better to turn this of an use for backlink search only the action (which could be put in the editbar) I have provided above.

 * From design point of view - its a mess. Compare this with [[http://trac.macosforge.org/projects/macports/browser/trunk/dports/python/py25-mako|well designed interface]]. The title in this example is clear, simple, allow you to navigate back in the hierarchy, and looks great. It does not contain additional info and "virtual components". Put additional info out of the title.
  * I like the combination of virtual components and additional info in the crumbs ;-)
----

Questions:

 * Lets say that a blind user read the half of the page, and forgot about the page immutability. Now he like to add a comment, how can he find that he can't edit the page?
  * Clicking on "edit" will trigger a normal error messasge. The blind user will find the error message easily since it is placed right at the beginning of the page and marked by a hidden h1 heading and/or easy to reach by skip links.
   * So you can drop the "(Immutable)" in the title, as the user will find this anyway when trying to edit - exactly like a regular user - both will have the same experience.
   * How the blind find the "edit" link?
    * Three possibilities:
     * By using the skiplink navigation at the top of the page to jump quickly to the editbar and then use "tab" (ie) to jump form link to link
     * To use the hidden heading h1 navigation to jump thourgh the page to the <h1>edit and actions menu</h1>. Then us "tab" ie to get the desired action
     * But best use accesskey support of SimpleMente. To avoid clashes in languages and with different assistive technologies SimpleMente has no global accesskeys. Accesskeys(Shortcuts) are definded by the users only, like they need them, like they want them, like they can remember them best. Therefore a shortcuts definition file needs to be uoploaded to the users homepage (in the longrun: should better move in userpreferences. But this is not theme code). Simplemente (i.e. some short javascript) augments every page with accesskey support now. I have changed ThemeBase in a way that you can now define accesskey for simply everything, the trail, navigation links, search field, edit, preview, save changes, go back one page (two, three) in the trail, go to the top of the page, to the bottom..

 * There are case when you have static wiki pages, that only the admin can edit. There is no point in telling users that they are immutable, they may not even look like wiki pages. This is common issue on a site based on a wiki. How do you disable the "(Immutale)" addition in the title?
  * Simplemente is not meant as an CMS theme (like ModernCmsTheme). When using it in a normal wiki, it is important to tell the user, that this page is  not writable for him.
   * You can easily add configuration that will allow using the theme for different kind of sites.  At least make sure that you can override the part that adds the "(Immutable)" in a subclass without rewriting the whole method that creates the title. Best, make it configuration option, so you don't need to subclass the theme to change it.
   * Maybe having an option to disable "Immutable page" would make some people more happy. That shouldn't be that hard to implement.

 * How do I add a "gui edit" link? I tried adding {{{(u'Edit (gui)', u'edit&editor=gui'),}}} to the simplemente_editbaritems array and found that the "&" and "=" get translated into html character codes. Is there a way to stop that? --counterpoke
  * This is currently not supported, since the gui-edit has to be considered as inaccessible. To get it work use {{{ u'Edit (gui)', u'edit'),}}} only and chance in wikiconfig.py default editor to gui and force also usage of gui there. Changing editors can nevertheless be done by the appropriate buttons in the editor window. -- OliverSiemoneit <<DateTime(2008-02-12T13:53:30+0100)>>
  * I really wanted two different links for edit (just like the modern theme). But thanks for responding back. --counterpoke
 * The CSS specifies 'bitstream serif', where it should be 'bitstream vera serif' --counterpoke

== Bugs ==

The MoinMoin release 1.6.1 raises an error like : '' Theme instance has no attribute 'linkSchemas' ''
I changed around line 826 the following code (don't know if it's correct; but it works for me). -- MarcelHäfner <<DateTime(2008-02-04T12:55:10+0200)>>

{{{
FROM (old):
for scheme in self.linkSchemas:

TO (new):
for scheme in config.url_schemas:
}}}


Same thing happened to me in 1.6.2 and Marcel's solution worked OK... what's more, Marcel's change doesn't break 1.5.8 so maybe Eduardo would be nice enough to commit the change for us -- MarianoAbsatz <<DateTime(2008-03-29T17:03:47-0300)>>

----

The css for the new 1.6 'comment' class /* which supports inline comments like this */ seems to be missing which means that when I use comments, they just appear as plain text! Other than this (and liking an edit button at the top of my pages), this is a lovely theme and extremely well documented: well done! :) - Tushar.
(..and forgot to mention that the 'comments' link which is in the edit bar in the modern theme seems to be missing altogether also)

----
=== InterWiki name ===
When using '''interwikiname''' and pages with subpages, instead of showing:
 InterWikiName: MainPage /SubPage
it shows
 MainPage``InterWikiName: /SubPage
(that is the inter wiki name sticks to the ''right'' of the main page name)

Here's an example... the interwikiname is '''Clue``Less''', the page is '''Virtual``Machines/Kvm``Qemu''':

[[http://wiki.clueless.com.ar/VirtualMachines/KvmQemu|{{attachment:simplemente_bug.png|how the bug appears|width="640"}}]]

==== workaround ====

I can remove the interwikiname altoghether by setting:
{{{
show_interwiki = 0
}}}
in the config file...

[[http://wiki.clueless.com.ar/VirtualMachines/KvmQemu|{{attachment:simplemente_workaround.png|silly workaround|width="640"}}]]

-- MarianoAbsatz <<DateTime(2008-10-29T18:47:27-0200)>>

=== Version 1.7 ===
I made a small patch to use the theme on my moinmoin 1.7 rc3, see: [[attachment:simplemente.diff]]. -- MarcelHäfner <<DateTime(2008-06-16T20:57:20+0200)>>

=== Version 1.8 ===
Ugly Fix for 1.8:
 * With Version 1.8 you receive some errors because of the {{{ self.cfg.hacks.get }}}. Well I just removed this special IEX JavaScript "handling" and for my Linux with Firefox it works :-). Maybe somebody with a bit more knowledge could fix it right... here atleast the diff to the latest official version (for 1.6) [[attachment:simplemente-v1.8rc1.py.diff]]

 The problem with this theme is, that it is some kind of prototyp, a study into accessibility and how far you can go with that in a theme. I have tried out a new approach to have accesskeys in Moin (thus being able to work quickly with the keyboard only). However this approach needed overriding large parts of theme/_init_.py . This makes it very hard to maintain the theme from version to version. I have already done a feature request to move that crucial part into the standard distribution, see FeatureRequests/BasicAccesskeySupportInsteadOfBuiltInAccesskeys. However the core team is reluctant on that. -- OliverSiemoneit <<DateTime(2008-10-06T23:45:31+0100)>>  


=== bug fix for AttributeError: 'list' object has no attribute 'render'  ===
I was getting this error:
{{{
      /usr/share/moin/devwiki/data/plugin/theme/simplemente.py in msg (self=<wikiconfig.plugin.theme.simplemente.Theme instance at 0xa3bf2ac>, d={'available_actions': ['use self.request.availableActions(page)'], 'home_page': ('Self', u'xxx'), 'last_edit_info': {'editor': u'<span title="xxx">xxx</a></span>', 'time': '2008-12-10 09:23:12'}, 'logo_string': u'<img src="/cv_logo.png" alt="Clearvision Logo">', 'msg': [(<MoinMoin.widget.dialog.Status instance at 0xa3bf16c>, 'dialog')], 'navibar': ['use self.navibar(d)'], 'page': <MoinMoin.PageEditor.PageEditor object at 0xa3bf5cc>, 'page_find_page': 'FindPage', 'page_front_page': u'DevTeam', 'page_help_contents': 'HelpContents', ...})
         1. 949 else:
         2. 950 # msg is a widget
         3. 951 html = msg.render()
         4. 952
         5. 953 return u'<div id="message">\n<h1 class="screenreader_info">%s</h1>\n%s\n</div>\n' % (_('Message'), html)
          * html undefined
          * msg = [(<MoinMoin.widget.dialog.Status instance at 0xa3bf16c>, 'dialog')]
          * msg.render undefined

AttributeError

'list' object has no attribute 'render' 
}}}

I fixed it by changing the msg() function in simplemente.py as follows (msg was being passed in as the list [(None, 'dialog')] for some reason:

{{{
    def msg(self, d):
        _ = self.request.getText
        msg = d['msg']
        if not msg:
            return u''

        if isinstance(msg, (str, unicode)):
            # Render simple strings with a close link
            close = d['page'].link_to(self.request, text=_('Clear message'))
            html = u'<p>%s</p>\n<div class="buttons">%s</div>\n' % (msg, close)
        else:
            try:                 # * FIX *
                # msg is a widget
                html = msg.render()
            except Exception, e: # * FIX *
                html = str(msg)  #  *FIX*

return u'<div id="message">\n<h1 class="screenreader_info">%s</h1>\n%s\n</div>\n' % (_('Message'), html)

}}}
