Re: [xwiki-devs] [Proposal] GWT WYSIWYG - Macro handling behavior

Re, looks like unexpected use of unpredictable keyboard shortcuts made my reply go out a bit too quickly :-) There are different kinds of macros and we might want to handle them differently: - Display macros (such as the infobox): they can already be identified as macros and don't need a refresh - Processing macros (such as the ToC): their text result cannot be distinguished from common text and they need to be refreshed To me, it would be better if content that belongs to a macro of which result is common text was always highlighted in a different background color, with an icon stating that this content was generated by a macro. This would make easier for an user to see where in the page she inserted macros. * Clicking on Edit Macro to edit the selected macro Following Laurent's latest proposal, this means that the user would have to click on the macro menu item, then "edit macro" (it's fine with me, it was just to let other people know about it: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wy…) > * There's a background thread running that re-renders the page (and >> thus the macro) every N seconds. We need this since the macro content >> depends on other content (for example the TOC macro will depend on >> sections, the velocity macro will depend on values set in other >> velocity macros, etc). We should also have a way to let the user >> refresh the rendering manually. Do we really need a background thread to refresh macros? Here's why I don't think so: - There aren't that many macros that require continuous refresh, so it might be overkill - Refreshing at an arbitrary interval means that sometimes the user will see the updated results as soon as he makes a change (a new line in the ToC as soon as he adds a title) and sometimes there will be lagging (and he might wonder what went wrong) - This could be avoided if the background thread runs often enough, however I'd like to know more about the potential performance issues of running the thread every second for instance - Letting users refresh the display of their macros is good enough since macro's content won't need to be refreshed that often - Another solution could be to refresh the display of the macro each time the user puts the cursor within the boundaries of that macro display (when I click on a ToC item, the ToC is automatically refreshed before I can edit it) To summarize my point: I think refreshing macros when users interact with them is better than having a background thread running. WDYT? ** Note that since there are both inline and block macros we also need >> to refresh the rendering for that reason. For ex, if you put a >> velocity macro inside a list item and then you remove the list item >> the renderer result of the macro will be different (in the second case >> an extra paragraph will be added). Is that specific to macros? Whatever the content of the list item, it would have had to be handled (the paragraph added) => how is this affecting the macro itself directly? > * We should also have a button to switch between rendering macros and >> not rendering macros. For example when a page is including another >> page with some large content the user might want to disable macro >> rendering to focus only on the content of the current page. The >> default should be to render macros. +1 for the default being to render macros. Letting users turn off macros sounds like a power user feature to me, something the common user won't bother doing often, where would it fit? In the macro drop-down menu? Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/