- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] Unicode font problem
by Sergiu Dumitriu 08 Jul '08

08 Jul '08

Hi devs, I almost finished implementing http://jira.xwiki.org/jira/browse/XWIKI-1609 What remains to be done, is to find a good font to embed in XWiki. The best candidate would be the one from the StixFonts project, but that one is not yet released (delayed several years, now apparently is in the packaging stage; the expected date is August, but given the history of their release dates, it's more likely sometime in the winter or even next year). The next best candidate is FreeFont (http://savannah.gnu.org/projects/freefont/) but that one is GPL, and doesn't have complete support for asian characters. The third best candidate is an extended version of Computer Modern (http://canopus.iacp.dvo.ru/~panov/cm-unicode/) which is distributed under the X11 license, but it is less complete than FreeFont. For the moment, I'd be in favor of including the FreeFont, but we need to see if a GPL font can be redistributed or not, and maybe ask for permission to include it. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

[xwiki-devs] [GSoC]Try the Office Importer Plugin
by Wang Ning 08 Jul '08

08 Jul '08

Hi Vincent & all, I finish the clean of the plugin code and write a simple user manual. You can see it in http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart. All files needed for this plugin can be found in that page http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the openoffice install . Please give some feedback after try the plugin. Any feedback will be very appreciated. This plugin is very initial. It only put out the html code , not xwiki syntax, because the html code to xwiki syntax conversion should be done by XHTMLParser which is not ready yet. Open question: Now the plugin can handle the file which is uploaded to xwiki as a attachment. Do you think it's necessary that the office importer would have the upload feature itself or should provide a XWikiAction something like "bin/importer/Main/page"? Now the plugin can work. However it's a little complicate. If you want to convert a office document 1. you first upload the document 2. copy the attachment name(because the name of document change after upload) 3. edit the page and add the velocity code to use the importer plugin 4. save and view. I think it should be more simple. WDYT -- Sincerely, Wang Ning

4 9

[xwiki-devs] XWiki - Browser full URL in xwiki page
by Prathap Pandian 08 Jul '08

08 Jul '08

Hi, How can i print the current browser full URL in xwiki page. I tired this one $doc.getURL("view"), but it displaying the url from the application name like this */xwiki/bin/view/Main/ *Is there any other way to print the whole browser URL in xwiki page like this* http://<server>:<port>/xwiki/bin/view/Main/ *-- Prathap* *

3 3

[xwiki-devs] [GOSC] WebDav status
by Ludovic Dubost 07 Jul '08

07 Jul '08

Hi Asiri, When do you plan to deliver your milestone status ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

2 1

[xwiki-devs] [GSOC][WEBDAV] Comments & Exposed properties
by Asiri Rathnayake 07 Jul '08

07 Jul '08

Hi Ludovic & All, Two small questions, 1. According to my understanding, current design of xwiki-webdav interface<http://dev.xwiki.org/xwiki/bin/view/Design/WebDAVService>does not take document comments into account (shouldn't they be exposed via webdav ?). 2. Which xwiki specific properties are to be exposed through this interface (out of author, revision , etc. etc.) ? Thanks a lot. - Asiri

2 2

[xwiki-devs] [GSOC] [WEBDAV] MKCOL Where should it be allowed ?
by Asiri Rathnayake 07 Jul '08

07 Jul '08

Hi devs, current xwiki-webdav interface is exposed as follows, root | + - library | + - orphans | + - attachments | + - home | + - spaces My questions is, where should MKCOL (create collection) operation be allowed ? I believe it only makes sense in `spaces` view where we can allow the user to create a space (if he has appropriate access levels). Also, another doubt i have is about creating pages, should it be same as with collections where we manually add the wiki.txt and wiki.xml files into the collection once it is created ? Thanks a lot. - Asiri

2 2

[xwiki-devs] [GSOC] help choosing a js lybrary/wrapper
by Miguel Bento 07 Jul '08

07 Jul '08

First of all, hi again! I'm developing the collaborative business drawing framework to integrate on XWiki and currently need some feedback. In order to provide the abillity of drawing SVG/VML/Canvas objects in the browser, this framework has many options that i shall explain: * A) Tatami, the GWT wrapper of the Dojo Toolkit library ( http://code.google.com/p/tatami/)* This is by far the most used option, and the reasons are somewhat obvious. - It wraps up the dojo toolkit code for GWT providing access to the GFX package's functionalities and thus giving us the possibility to draw objects in SVG/VML/Canvas. This is a very important point as it provides support for Safari with canvas objects and IE with VML objects, accomplishing thus a better product. - Provides the creation of basic and advanced drawing figures from squares to paths with drag and drop, scale, rotate and parameters specification. - It has the biggest active developer's base, having a lot of activity on their forum (http://groups.google.com/group/tatami) - It gives us efficiency and usability by being well developed. Personally, this is a key point for me as i've seen a lot of svg drawing boards slow and badly done. A demo of the tatami can be found here ( http://tatami.googlecode.com/svn/trunk/site/samples/TatamiDemo/index.html ) but don't mind the slow reaction of the site as it's using aloot of dojo objects(Fisheye, etc) and it's runing from the svn. After some coding with it, i realized it can indeed be very fast. IMHO, this looks like the winner.. we should use this wrapper for the job and if necessary develop some new items on it to provide us the required functionalities, which will also be needed in any other option. *B) JSGraphic's library ( http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm) *As it's the case with Dojo Toolkit, this library can be used in GWT by including a wrapper on the project. The downsides of this alternative are obvious as, for example, it doesn't support's drag and drop or any interaction with the objects and is a one man project. It's allways good to have options heh! *C) Develop an API fit to the job* As this option might bring some (? small) benefits in efficiency and additional funcionalities, on the other hand, it's slowed by the time required to develop the API knowing that there are some fully functional good options out there. Talking about functionalities, Tatami provides every svg object and property that i remind me of and it's efficiency and usability are high, so there shouldn't be much more to do in this area. (besides implementating screw transformations, which aren't included in the latest realease of Tatami :) In the next days i'll be building a propotype of a drawing API so please give me your opinions. My vote : +1 Tatami Best Regards, Miguel Bento.

7 10

[xwiki-devs] [GSOC] Collaborative Drawing content
by Miguel Bento 07 Jul '08

07 Jul '08

As some of you know, the collaborative drawing application will use svg( http://www.w3.org/Graphics/SVG) syntax in order to draw the various objects and therefore we have to found a way to store and edit this information. Currently we have two implementation options to perform this task, the Object approach and the Attachment approach, and are trying to decide which one is the better, so, in order to perform that i've prepared a few mockups. To clarify the intent of these approachs, it's good to keep in mind that a drawing has various edition modes and privileges.More specifically, we should have 3 user modes: - Administrator: In administrator mode the drawing content will be presented by the SVG editor and the user can: - Edit the drawing - Add or remove users - Modify the drawing name and description - Editor: In the editor mode the drawing content will also be presented by the SVG editor but the user can only edit the drawing content. - Viewer: In the viewer mode the drawing will be presented as .png file using the Batik plugin and therefore the user only has rights to view the drawing. The object approach: In this perspective, the SVG content would be saved on a SVG object with the following properties: http://dl.getdropbox.com/u/47956/XWiki_SVG_Object_Description.pdf , this SVG object would be available in the page, could be accessed by the getContent() method and edited with a simple saveContent() call. In order to store the privileges and the creation date the current page should be used and to show that here's example: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/XWikipa…) Here's a example of the view mode: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/SVGObje…) And finally here's a edition mode example: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/SVGObje…) The attachment approach: In this approach, the SVG content will be stored on a attachment and so all the edition operations would be saved on it as new versions. It's identical to the object approach except in the fact that the svg content wouldn't be in the page itself(we still would need a reference to the attachment on it). When a user want's to go to edition mode, in this approach a full-screen editor will be launched like the next one: ( http://dev.xwiki.org/xwiki/bin/download/Design/CollaborativeDrawing/SVGObje…) and all the document properties would have to be stored on the attachment. Note: Obviously the full screen mode can be used in both approaches and the examples shown are possible desings for the UI which in the future will be discussed. (Refer to http://dev.xwiki.org/xwiki/bin/view/Design/CollaborativeDrawingfor a better version) So, WDYT? Best Regards, Miguel Bento

2 1

[xwiki-devs] XWiki - Dynamic Space Name In The Links
by Prathap Pandian 07 Jul '08

07 Jul '08

Hi, I tried to display the space name dynamically in the links. Example: In the new panel i have give like this [Home>*Main.WebHome*] Basically all the spaces will have WebHome page by default. So i tried to change the space name dynamically. And here what i have given in the panel... [Home>*$doc.space.WebHome*] But it seems not working for me. And it provided me the following *url*http:// <server>:<port>/xwiki/bin/edit/%24doc.space/WebHome?parent=Main.WebHome&editor=wysiwyg Is there any other way to do this...? *OR* I did it wrong...? -- Prathap

2 2

[xwiki-devs] [GSOC][WEBDAV] DAVExplorer on Linux
by Asiri Rathnayake 05 Jul '08

05 Jul '08

Hi All, I'm having a small issue with DAVExplorer on fedora 6 where i cannot put the password (for login) into password box because it doesn't accept keyboard input. I know this is something wrong with fedora (or the jdk i'm using) because it works fine on XP. This is not a big issue for me because i can simply disable authentication related code in the webdav servlet and carry on my development but i thought it is best to make a note (in case someone knows how to fix it). Up untill now i have been using nautilus's built-in webdav support for testing but for advaced functionality i need DAVExplorer. Anyway, as i said, this is not a big issue (but surely it is a big annoyance), if anyone knows how to fix it, feel free to advice :) Thanks. - Asiri

1 0