General wiki explorer UI :
3) Three +1
4) Five +1 (WINNER)
Tree add options :
A) Four +1 (WINNER)
B) One +1
C) Three +1
JV.
On Thu, Nov 27, 2008 at 7:37 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
> On Tue, Nov 25, 2008 at 5:05 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
>> In a previous thread we've discussed about how to add a link in the
>> WYSIWYG editor, and more generally, how to browse the wiki from a
>> WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn
>> for more details).
>>
>> After some thinking and a discussion with Laurent Lunati, I'd like to
>> suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced
>> tree menu.
>>
>
> After some more thinking and discussion with Laurent Lunati I've made
> a mockup of a 4th wiki explorer :
> http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#H42…
>
> It combines the best of the tree and wizard proposals :
>
> * Easy to use: users are guided throughout the process, one action at a time
> * The dialog size is fixed, action buttons are always at the same
> position on screen
> * The dialog doesn't looked oversized compared to the WYSIWYG
> * Small footprint: can be used even on low resolution displays
> * Since it's a wizard it's highly extensible
> * Scalable : we can have multiple wikis + spaces (even a space hierarchy)
> * Allow to display parent/child relationships between pages (thus
> allowing to handle a lot of pages in a space)
> * Allows the user to see where he is currently located in the wiki
> (default selection)
>
> Here's my +1 for 4).
>
> ps: I consider that the discussion about the position of the add page
> / add spaces buttons is not over.
>
> JV.
>
Hi there,
With XE 1.7 we're going to release some features that don't have the
final planned UI (insert link, image, macro, table for example).
We're still discussing the final UI designs but I'd like that we get
started doing 2 things:
* prepare a roadmap for finishing their definition and set milestones
so that we don't drag on forever
* prepare an implementation roadmap with dates and with whom will be
able to implement them
Re the implementation roadmap I feel it would be good to (iteratively)
release the UIs in 1.7.x releases (1.7.1, 1.7.2, etc) as fast as we
can. The reason is that we initially wanted to have them in 1.7 final
and we're late since the wysiwyg implementation took longer than
planned. Waiting for 1.8 would be too long I think.
Ideally IMO it would be good if we could have most of them done before
December end.
We need to know if that's possible and define a roadmap.
WDYT?
Thanks
-Vincent
Hello xwikiers,
the page at
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Notifications
is really nice and shows a real nice pearl of XWiki.
I did similarly and my notifier seems to run smoothly.
I would like to know, however, what is the way to make sure that a
notifier (an implementation of XWikiDocChangeNotificationInterface) is
running at every restart of our XWiki.
I tried to add the fullname of either the velocity (the "starter") or
the Groovy pages into that line and restarting but my notifier didn't
seem to have been running after that.
What is the correct way?
It should definitely be documented at the pircbot page.
thanks in advance
paul
Hi,
the new WYSIWYG is still under heavy development, here are some
estimations of its features completion :
* Standard features : 75%. Implemented : bold, italics, underline,
strikethrough, subscript, superscript, unordered list, ordered list,
titles (h1,h2,etc), indent, outdent, ruler, special chars. Remaining :
alignment, verbatim, quote, definition lists, custom parameters like
(% style="color:red" %). Some bugs left too.
* Link : 90%. Allow internal/external/email link insertion. Missing
options. No automated tests.
* Image : 40%. Allow image insertion from any document, image
uploading and resizing. Still buggy. Missing options. No automated
tests.
* Table : 50%. Doesn't work with IE. Missing options. No automated tests.
* Macro : 0%.
* Import: 0%.
In its current state the WYSIWYG 2.0 :
- can't be considered as a valid replacement of the WYSIWYG 1.0
(image and table plugins deactivated by default),
- was causing IE6 crashes after a few seconds of use, this has been
fixed by the last commit from Marius a few minutes ago but has been
preventing IE6 testing for a couple of weeks.
I'm suggesting to postpone XE 1.7 release by a few days, I'll write
another email about this.
Note that the UI of all those features (buttons, dialog boxes, etc) is
not final since the discussion about their ergonomics is still
ongoing.
See the "Need roadmap for new WYSIWYG UI needed" email.
Thanks,
JV.
On Tue, Dec 2, 2008 at 11:17 PM, SVN fmancinelli <
sandbox-notifications(a)xwiki.org> wrote:
> Author: fmancinelli
> Date: 2008-12-02 18:47:06 +0100 (Tue, 02 Dec 2008)
> New Revision: 14514
>
> Added:
> sandbox/xwiki-core-rest/.classpath
> sandbox/xwiki-core-rest/.project
> sandbox/xwiki-core-rest/.settings/
> sandbox/xwiki-core-rest/.settings/org.eclipse.jdt.core.prefs
> sandbox/xwiki-core-rest/.settings/org.eclipse.wst.common.component
>
> sandbox/xwiki-core-rest/.settings/org.eclipse.wst.common.project.facet.core.xml
> sandbox/xwiki-core-rest/.settings/org.maven.ide.eclipse.prefs
I think it's not ok to commit these files. May be it's ok for sandbox ?
- Asiri
Hi everyone,
I've discussed with Asiri and seen that we're in a hurry with the 1.7
release and it's a bit late we've agreed that the best course of
action was to postpone the office importer inclusion in XE till XE
1.7.x or 1.8M1.
I hope this is fine with everyone (not that I don't see much option
apart from delaying XE 1.7).
Asiri is thus currently focusing on finishing webdav support and
fixing outstanding issues till 1.7 final.
He'll need help from committers to apply his patches.
Thanks
-Vincent
In a previous thread we've discussed about how to add a link in the
WYSIWYG editor, and more generally, how to browse the wiki from a
WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn
for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to
suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced
tree menu.
I've put the mockups and Pros/Cons on this wiki page :
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer
This wiki explorer widget would be used in the link dialogs, image
dialogs, file (attachment) dialogs.
Here's my +1 for 3) A).
+1 for 3) with filter option.
>From the implementation POV 3) is probably the most difficult proposal
and 1) the simplest one. Widget 3) would need to be a reusable (and
highly configurable) GWT component so that we could use it as our main
navigation/reorganization tool in the future. This tree would replace
our current treeview (Main.AllDocs) which is AFAIR the only page using
the YUI library in XE.
Thanks,
JV.
Hi devs,
I just finished a feature to be able to use mutiwiki without any use
of virtual host (ans so no need for a configured DNS server). It does
not replace the DNS based multiwiki it just add another way to access
subwiki so you can still use both. However all the URLs will be
generated in a way or another depending if urlpath is enabled or not.
So basically it add the possibility to access the wiki "wikiname"
using http://127.0.0.1/xwiki/subwiki/wikinname/view/Main/WebHome.
See http://jira.xwiki.org/jira/browse/XWIKI-2824
Normally I would wait for 1.8 branch to commit this but we have an
internal need for it to be included in the 1.6 branch (and if it's
included in 1.6, why not include this in 1.7 ;)).
Can we include it safely in 1.6/1.7 ? : it should be, if you don't
enable xwiki.virtual.urlpath in xwiki.cfg (and it will be disabled by
default), all will work exactly like this feature did not exists.
Here is my +1
Thanks,
--
Thomas Mortagne
For a new user will be best just to have an "Insert link" action.
If the link is external - default behavior
is internal - transparent (like an external one - but parse the URL for
advanced editing, letting user browse wikis, spaces)
After editing:
new page inserted exists - change the link
the page doesn't exist - create the page + change the link
See the image:http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterf…
The actions are just sketched, all the thinks previously discussed can be
inserted.
So, the idea is to take the URL and break it in
<wikiName>:<SpaceName>.<PageName>
if you need this format for further browsing and editing. This way you let
beginner user to insert a link in one step.
Thanks
Observation: When clicking on [Space Name > "Features"] the E dialog
appears.