• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Create a context identifier for WysiwygPlugin, and switch on it in the template.

CC

Done, and documented the practice in Func so other plugins authors can follow suit, if they want to.

SVN 6238

CC


'Wysiwig' is a too cryptic for 'normal' users. "Rich edit" is also not it. Looking for a descriptive short name...

But 2 edit buttons on the View page is disturbing.

I am thinking of a new scenario:

  • Keep one "Edit" button on the View page
  • When the user first goes to the edit screen, he gets the option to choose the "Traditional edit screen" or the "Word-like edit screen"
  • The selected option is stored in a cookie
  • Subsequent visits to the Edit screen leads the user directly to the formerly chosen screen mode, but with a link to change if necessary
  • If the user does not have javascript on, the "Traditional edit screen" is shown

AC


The trend of JotSpot and others in this regards is:

  • One Edit link in view targeted to basic users which leads to Wysiwyg.
  • TML tab or link within edit view labeled "script" or TML or whatever - they all communicate "advanced edit".

I know we don't (yet) have capibility of quick-switching between modes, but a one-way link from Wysiwyg to TML might be adequate. Then also, its easy enough for advanced users to have a direct TML edit link in their side bar.

Personally, I don't think I'd want the cookie mechanism because I anticipate switching between modes, depending on circumstance.

LB

How about so that Topic Settings goes along side: Edit | Attachments | Settings, and the edit leads to types of edit and defaults to "Colours and Fonts" and can be switched to "View Markup".

This arrangement will also lead to Create Topic defaulting to "Colours and Fonts" instead of TML.

Incidently any lines written in the Topic Settings that don't comply to " * Set " are silently lost.

MC


What does "Colours and Fonts" mean? -- AC

--

I was hoping that "Colours and Fonts" would be a sufficiently intention revealing!

  • Still not... -- AC

Google gmail call the different modes "rich formatting" and "plain text", perhaps we can adopt the same?

  • Except that we don't have plain text but "TWiki markup" -- AC
    • How about rich formatting vs. Markup -- MC?

MC


How about making the type of edit used a "user option"

  • Set globally as system default

  • Can be set on a per user basis in user topic.

  • * Set RICHEDIT = on/off

- TWiki:Main.AntronAylward

Please take further discussion into Codev. This specific enhancement is closed.

CC

ItemTemplate
Summary Create a control for Wysiwyg editing
ReportedBy CrawfordCurrie
Codebase

AppliesTo Extension
Component WysiwygPlugin
Priority Enhancement
CurrentState Closed
WaitingFor

Checkins 6238 6239
Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2005-11-08 - CrawfordCurrie
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback