Hi, looks great, good job Marius! Only 1 question: how do I add/edit an existing style? Can we see a mockup of the UI for this? Thanks, Guillaume On Tue, Dec 21, 2010 at 14:58, Vincent Massol <[email protected]> wrote:

On Dec 21, 2010, at 2:45 PM, Marius Dumitru Florea wrote:

...

Hi devs,

Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig

...

. I'd like to include it in XE 3.0.

WDYT?

Looks good, +1

Question: is this per wiki, per space? (for ex the feature to only select images from the current page may not be valid wiki wide but only for a given space?)

Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 12/21/2010 03:58 PM, Vincent Massol wrote:

On Dec 21, 2010, at 2:45 PM, Marius Dumitru Florea wrote:

...

Hi devs,

Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig . I'd like to include it in XE 3.0.

WDYT?

Looks good, +1

Question: is this per wiki, per space? (for ex the feature to only select images from the current page may not be valid wiki wide but only for a given space?)

I'd like to have this configuration both at wiki and space level (maybe at user level too) but I can't do it properly because right now we don't have an inheritance mechanism to allow an administrator to overwrite at space level some of the WYSIWYG editor configuration parameters defined at wiki level. The root problem is that you can't say if an object property that has the default/empty value was explicitly set or not. Ideally I would do something like: 1. get tool bar configuration for current user. if not set then 2. get tool bar configuration for current space. if not set then 3. get tool bar configuration for current wiki. if not set then 4. get tool bar configuration for entire farm. if not set then 5. use default value Currently, overwriting one property means overwriting all the properties at the higher levels. Thanks, Marius

Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Grégory, On Tue, Dec 21, 2010 at 15:02, Gregory GUENEAU <[email protected]> wrote:

+1 it's great

could it be included in the Color Theme Editor ?

I'm not sure I understand why one would want the WYSIWYG editor configuration to be handled in the same location than the general look & feel of the wiki. Could you please elaborate on this? Thanks in advance for your feedback, Guillaume Le 21 déc. 2010 à 14:45, Marius Dumitru Florea a écrit :

...

Hi devs,

Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig

...

. I'd like to include it in XE 3.0.

WDYT?

Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 12/21/2010 03:41 PM, Gregory GUENEAU wrote:

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 color theme is big (and growing), the proposed WYSIWYG configuration has a lot of options, and I really don't think that putting all of them together in one place is going to make users happy. More but smaller pages is always better than one neverending page.

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).

I don't agree with this. Mixing all these things together is not so good, since they are very different. I'm in favor of making themes for different component, like color themes, icon themes, layout themes, but they should be kept separate.

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.

So, are you proposing to merge all the categories in the Administration back into a single page? Try using the object editor on the XWikiPreferences document, it's a huge mess.

Le 21 déc. 2010 à 15:15, Guillaume Lerouge a écrit :

...

Hi Grégory,

On Tue, Dec 21, 2010 at 15:02, Gregory GUENEAU<[email protected]> wrote:

...

+1 it's great

could it be included in the Color Theme Editor ?

I'm not sure I understand why one would want the WYSIWYG editor configuration to be handled in the same location than the general look& feel of the wiki. Could you please elaborate on this?

Thanks in advance for your feedback,

Guillaume

Le 21 déc. 2010 à 14:45, Marius Dumitru Florea a écrit :

...

...

Hi devs,

Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig

...

. I'd like to include it in XE 3.0.

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Hi Ciprian, On 12/21/2010 10:24 PM, Ciprian Amaritei wrote:

Great Marius!

One question about font-sizes. Is there any specific reason you have chosen the "pt" as unit measure and not "px". "Pt" (Points) are mainly used in print media (anything intended to be printed on paper), while the px (pixels) are for screen media .

You can configure the list of font sizes that are available on the WYSIWYG editor tool bar. You are not limited to pt unit. You should be able to remove the existing ones and add 3em or 5cm for instance. As for the default list of font sizes that we currently display on the WYSIWYG editor tool bar, I think the only reason I had to use pt is that the old editor ( http://tinymce.moxiecode.com/tryit/full.php ) was using pt so I wanted to preserve the behaviour. I see that http://ckeditor.com/demo is applying px so I guess you're right. I can easily change this. What others think?

And another suggestion would be not to allow user to change the order of font sizes, and let them appear in an ascending order.

I can't do that as long as I let users specify the unit. Note that you can use any value that is valid for the font-size CSS property http://w3schools.com/css/pr_font_font-size.asp . What would be the natural way of sorting: small larger 90% 3em 5cm 18px I think it's best to let the user choose the order. Thanks, Marius

Otherwise, +1!

On Tue, Dec 21, 2010 at 3:45 PM, Marius Dumitru Florea< [email protected]> wrote:

...

Hi devs,

Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig . I'd like to include it in XE 3.0.

WDYT?

Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 12/23/2010 10:39 AM, Marius Dumitru Florea wrote:

Hi Sergiu,

On 12/23/2010 05:14 AM, Sergiu Dumitriu wrote:

...

On 12/21/2010 02:45 PM, Marius Dumitru Florea wrote:

...

Hi devs,

Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig . I'd like to include it in XE 3.0.

WDYT?

Some nitpicking:

...

Enable or disable the WYSIWYG/Source tabs. [ ] Yes [ ] No ^ This isn't a yes/no question. How about: 1. [ ] Enable the Source tab 2. [ ] Display WYSIWYG/Source tabs 1 says that only the WYSIWYG mode is enabled, while 2 says that both modes are enabled, just that there's no UI to switch between them, but either one can still be displayed by other means (JS scripting or field configuration). Personally I prefer the wording of 1, even if 2 is the actual implementation, since it's more user friendly.

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.

Indeed, my bad. The current title is good, but the hint should be changed.

...

Inputs: I'm not sure a text input is the best element here, can't a select be used?

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.

Didn't see an autosuggest when I tried it, so I assumed there isn't one. I tried typing "a" and waited for suggestions, but nothing popped up. I tried now with "s" and indeed I got some suggestions. So, to make it better, we should try to fix the bug with the down arrow (tried that as well but it didn't work), and maybe display a "no results" when there aren't any items that match the current input.

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.

OK.

...

Lists: I think that "Drag and drop to change the order" is not a very useful tooltip, is it possible to have an item description instead? If not possible yet, something to keep in mind for the future.

I agree that this is something to add in the next iterations. Right now the editor doesn't support plugin/feature description.

...

Yes/No radio buttons: Usually checkboxes are better for this. You can see this proposed in the forms standard as well: http://incubator.myxwiki.org/xwiki/bin/Standards/FormVerticalUsage#HFormExam...

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)

This MUST be fixed in the platform.

* 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).

Well, we should use labels for all the fields anyway. It fails WCAG validation if inputs don't have an associated label. In the future we should have a {{field}} macro which generates the right syntax. For the moment I'd say that you should use the {{html}} macro, keeping in mind that once the platform advances it should be refactored.

...

Font sizes: I agree that pt is the better unit here. Even though px is the standard unit on the web, the WYSIWYG is mostly trying to emulate Office applications, where the pt is the preferred unit.

...

Overall, this looks very nice. +1 for committing it.

Referring to the other thread about committing the forms standard in the platform, I'm planning to do that in the coming days. How do we make sure we're not overlapping?

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.

OK, this is the best approach. I did the same for the sharepage feature.

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.

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Hi Caty, On 06/10/2011 06:49 PM, Ecaterina Moraru (Valica) wrote:

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.

I agree. We need http://jira.xwiki.org/jira/browse/XWIKI-6689 for this.

- 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.

I'm aware of this. We can add a documentation page in the standard XAR. The auto-complete input widgets from Scriptaculous can be patched to offer suggestions even when you press the Down key on an empty input. Right now you have to type at least one character.

- 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).

I think it's good to be able to configure a feature without enabling it. Also, you can expose a feature in multiple ways. Currently you can have a menu item or a tool bar item. This means it's not enough to have a simple check box before the font name/size configuration to enable them. I need to know how/were exactly to enable it. So for me there are two different action: (1) configure a feature and (2) expose that feature, and I don't think you can merge them. Enabling font plugin by default is not really an option because we want to encourage users to avoid in-line style. The preferred way to style text should be using predefined styles (CSS class names), but since we don't have a list of predefined styles in the standard XE the style plugin is disabled by default.

- 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).

I thought about this. A solution would be to hide the plugin configuration and compute it automatically from the features that appear on the tool bar and menu bar. The only problem is that there are plugins that don't extend the UI so you won't be able to enable them unless you edit the WYSIWYG editor configuration in object mode.

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 a lot for this feedback! Marius

Thanks, Caty

On Thu, Dec 23, 2010 at 16:49, Sergiu Dumitriu<[email protected]> wrote:

...

On 12/23/2010 10:39 AM, Marius Dumitru Florea wrote:

...

Hi Sergiu,

On 12/23/2010 05:14 AM, Sergiu Dumitriu wrote:

...

On 12/21/2010 02:45 PM, Marius Dumitru Florea wrote:

...

Hi devs,

Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig

...

. I'd like to include it in XE 3.0.

WDYT?

Some nitpicking:

...

Enable or disable the WYSIWYG/Source tabs. [ ] Yes [ ] No ^ This isn't a yes/no question. How about: 1. [ ] Enable the Source tab 2. [ ] Display WYSIWYG/Source tabs 1 says that only the WYSIWYG mode is enabled, while 2 says that both modes are enabled, just that there's no UI to switch between them, but either one can still be displayed by other means (JS scripting or field configuration). Personally I prefer the wording of 1, even if 2 is the actual implementation, since it's more user friendly.

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.

Indeed, my bad. The current title is good, but the hint should be changed.

...

...

Inputs: I'm not sure a text input is the best element here, can't a select be used?

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.

Didn't see an autosuggest when I tried it, so I assumed there isn't one. I tried typing "a" and waited for suggestions, but nothing popped up. I tried now with "s" and indeed I got some suggestions. So, to make it better, we should try to fix the bug with the down arrow (tried that as well but it didn't work), and maybe display a "no results" when there aren't any items that match the current input.

...

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.

OK.

...

...

Lists: I think that "Drag and drop to change the order" is not a very useful tooltip, is it possible to have an item description instead? If not possible yet, something to keep in mind for the future.

I agree that this is something to add in the next iterations. Right now the editor doesn't support plugin/feature description.

...

Yes/No radio buttons: Usually checkboxes are better for this. You can see this proposed in the forms standard as well:

http://incubator.myxwiki.org/xwiki/bin/Standards/FormVerticalUsage#HFormExam...

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)

This MUST be fixed in the platform.

...

* 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).

Well, we should use labels for all the fields anyway. It fails WCAG validation if inputs don't have an associated label. In the future we should have a {{field}} macro which generates the right syntax.

For the moment I'd say that you should use the {{html}} macro, keeping in mind that once the platform advances it should be refactored.

...

...

Font sizes: I agree that pt is the better unit here. Even though px is the standard unit on the web, the WYSIWYG is mostly trying to emulate Office applications, where the pt is the preferred unit.

...

Overall, this looks very nice. +1 for committing it.

Referring to the other thread about committing the forms standard in the platform, I'm planning to do that in the coming days. How do we make sure we're not overlapping?

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.

OK, this is the best approach. I did the same for the sharepage feature.

...

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.

-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs