On 12/21/2010 04:04 PM, Guillaume Lerouge wrote: There is no dedicated UI for managing WYSIWYG editor custom styles. Any CSS class defined in the skin can be used as long as it is available when viewing the page you're editing. So the easiest way to create a new WYSIWYG custom style is to create a style sheet extension with: .myCustomStyle { /* CSS properties here. */ } and "register" it in the WYSIWYG administration section: Style name: myCustomStyle Style label: My Custom Cool Style Inline style: true/false Thanks, Marius

You are right Guillaume, let me explain my thoughts We are getting more and more things as UI parameters, such as this WYSIWIG UI editor, Color Theme, etc. I was just wondering if all these presentation settings could be merged in one UI setup config panel. The goal would be to make admin's work easier, and may be to propose to make available UI predefined settings (such as color themes), that allows us to propose predefined UI settings (as a UI theme including color, Wysiwig, icons, etc., not just a Color Theme). The advanced version would be CSS scripting for custom projects. This is may be not realistic regarding the UI complexity, but as an admin i just need simple and lightspeed settings. Le 21 déc. 2010 à 15:15, Guillaume Lerouge a écrit :

On Wed, Dec 22, 2010 at 9:07 AM, Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com&gt; wrote: I understand. I didn`t figure out at first that the user has to add the unit also, I thought it will add only the number. Thinking about this it would be useful not to let the user enter a wrong unit, for eg. 3en instead of em, maybe a drop down with available units would help, or any kind of validation (which I guess it will be). You`re right. Indeed it would be difficult. -- Ciprian, Designer XWiki

Hi Sergiu, On 12/23/2010 05:14 AM, Sergiu Dumitriu wrote: The actual configuration name is "Source editor enabled". Isn't this equivalent to "Enable the Source tab" you are proposing? I avoided "tab" in configuration name because (1) it refers to an UI implementation detail and (2) it can also mean the white space "tab" character. "Enable or disable the WYSIWYG/Source tabs" is the hint. "Display the WYSIWYG/Source tabs" sounds indeed better. plugin, menu bar and tool bar inputs are autosuggest enabled. You should be able to open the list with all the suggestions by pressing down arrow key but there is a bug in scriptaculous that prevents this. I have a patch for it. I can't replace the tool bar input with a select because you can place macro shortcuts like "macro:foo" on the tool bar and "foo" macro might not be available when you configure the WYSIWYG editor. I agree that this is something to add in the next iterations. Right now the editor doesn't support plugin/feature description. Using checkboxes was my initial intent but: * display method generates a PRE tag which is a block level element thus technically invalid inside a DT (promoted by the form standard) * I wanted to write the class sheet using only wiki syntax, i.e. without HTML and for checkboxes, unlike for the rest of the input fields, the use of the LABEL HTML element is kind of required (you should be able check/uncheck by clinking on the label). I copied the form styles in a style sheet extension object. I can drop this object after you commit the form styles in the skin. Something we need to take care is the class name on the form element. In some cases the form element is not accessible (edit and inline modes) and thus we can't add the "xform" class name. I must have the form styles applied on my class sheet when in inline edit mode. Thanks, Marius

Hi Marius, Some feedback received about the WYSIWYG Administration: - some people tough that "Application" is not the best place for this settings, suggested "Content" or "Configuration" - near the "Edit mode Settings". The Idea was that the WYSIWYG is not actually an application but something that is basic to XWiki and deep embedded in it. - although they had an auto-complete for the plugins and the menu bar, they wanted a link to the documentation (something like we have for the "Registration") were they could see all the existing plugins (also mention the dependencies between plugin and toolbar). The problem was that they didn't knew what letter the plugin name was starting - so that the auto-suggest to be activate. Another solution is to automatically show the suggest if the user stagnates in the input more than 2 second. - another comment was that they expected to see the "Font-family" and "Font-size" activated (if you are able to configure it, you are able to use it - without the need to add the plugins, etc). This can be solved by enabling the features by default (someone especially said they wanted the Font-family - in order to behave more like Word). - also would be very nice - if the user selects in the toolbar "fontsize" to automatically activate the plugin, without the need to put it manually (or read the documentation). First I tough I need to restart the server in order for the changes to be activated (and wanted to suggest that you need to give me a warning that I need to restart the server - but after that I remembered that I need to combine the fields and activate the plugin). As a general feedback everyone liked the way the settings look, are organized and behave and they want to make it a standard for the other Administration sections. Thanks, Caty On Thu, Dec 23, 2010 at 16:49, Sergiu Dumitriu &lt;sergiu(a)xwiki.com&gt; wrote: