January 2010 - xwiki-devs@xwiki.org

[xwiki-devs] Which skins do we want to support?
by Vincent Massol 03 Feb '10

03 Feb '10

Hi, We need to decide which skins we want to support/maintain. By support/maintain I mean fixing bugs and improving them. Right now we have 3 skins in the platform: - Albatross - Toucan - Colibri We still need to keep it in platform for now since others depend on it but the question of knowing if we support it or not is independent IMO. Several questions: * Are we still supporting the Albatross skin? * Same question for Toucan? * We could decide not to support it but to apply contributor patches for it. * We could also decide that we don't support it and close jira issues related to it with won't fix. My feeling: - Keep it in platform for now, keep jira issues, apply patches, don't break what exists (when we change template files or CSS files for ex). WDYT? Thanks -Vincent

3 3

Re: [xwiki-devs] [xwiki-notifications] r26284 - platform/skins/trunk/colibri/src/main/resources/colibri
by Vincent Massol 02 Feb '10

02 Feb '10

First commit! Yeah :) Champagne! Some questions below (hey I couldn't left the first commit go without questions ;)) On Jan 21, 2010, at 4:24 PM, evalica (SVN) wrote: > Author: evalica > Date: 2010-01-21 16:24:22 +0100 (Thu, 21 Jan 2010) > New Revision: 26284 > > Modified: > platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css > Log: > XSCOLIBRI-180: Scroll and width problems on Stats space > > Modified: platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css > =================================================================== > --- platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css 2010-01-21 14:52:45 UTC (rev 26283) > +++ platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css 2010-01-21 15:24:22 UTC (rev 26284) > @@ -1316,7 +1316,7 @@ > } > > div.panellayoutcontainer-2col .panellayoutcol { > - width: 50%; > + width: 49%; Where does this magic number come from? Is the 1% important? If so maybe this warrants some comment? > } > > div.panellayoutcontainer-3col .panellayoutcol { > @@ -1324,11 +1324,11 @@ > } > > div.panellayoutcontainer-4col .panellayoutcol { > - width: 25%; > + width: 24%; same > } > > div.panellayoutcontainer-5col .panellayoutcol { > - width: 20%; > + width: 19%; same > } > > div.panellayoutcontainer-1col, div.panellayoutcontainer-2col, div.panellayoutcontainer-3col, div.panellayoutcontainer-4col, div.panellayoutcontainer-5col { > @@ -1339,15 +1339,13 @@ > .panellayoutcol { > float: left; > height: 1%; > - overflow: auto; > - > } > > .panellayoutcol .panel { > - border: 1px solid #ddd; > - margin: 0 0 20px 5%; > + border: 1px solid $theme.borderColor; > + margin: 0 0 5% 5%; > + overflow-x: auto; > width: 90%; > - > } > > #xwikicontent .panel ul { Thanks -Vincent

3 14

[xwiki-devs] [Proposal] JIRA strategy for issues we don't plan to fix
by Vincent Massol 02 Feb '10

02 Feb '10

Hi devs, We've had a quick discussion with Thomas on IRC regarding the strategy we want to adopt for issues we don't plan to fix. Here's my POV: * We should close issues that we know we won't fix. We might not want to fix them for several reasons but one of these reason is that the issue is for an old XE version. Especially since we said that we're only supporting the last 2 versions. We = xwiki committers, but if any committer wants to fix an old issue he's free to do it of course, it's just a general rule. * An option would be to leave them open and wait for a patch but I don't think it's a good idea, because: - it sends the wrong signals that we're going to fix the issue - the issue can still be found with a search even if closed - when we close it then the reporter can explain why it's so important for him, or not. Which we wouldn't know if we hadn't closed it - contributors could reopen them and attach a patch or just create a new issue - it means that for all other issues we plan to fix them at some point WDYT? Thanks -Vincent

8 15

[xwiki-devs] approaching mild optimizations of Lucene plugin
by Paul Libbrecht 02 Feb '10

02 Feb '10

Hello devs, I'm trying a few optimizations of the Lucene plugin and try to keep this flexible and not too intergeo or curriki specialized. The fact is that this plugin uses Lucene in a very blind and heavy fashion, which gives a lot of power (but which is not used). Mostly, I'd like, in a configurable way: - to decide to store and/or index or not some objects or object properties - to decide to exclude some documents - to decide to use particular analyzers for particular fields (in particular the "token fields") I know it would be almost possible by replacing lucene by solr and letting users tune solr. But maybe it is simple to have the configurability done in xwiki. Probably the nicest way I see this would be the way the notifications are done: a central field indicates the page of a groovy source which should implement such an interface as "LuceneIndexProfile" which would add such questions (maybe even including some more such as the Data classes). Is the nicest above easy? Do we prefer and xml configuration? paul

2 5

[xwiki-devs] [Proposal] Split the wysiwyg module in order to make the editor reusable outside XWiki
by Marius Dumitru Florea 02 Feb '10

02 Feb '10

Hi devs, I'd like to split the wysiwyg module in two: xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin. xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform. All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options: (1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance. (2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT? We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT? Thanks, Marius

4 6

[xwiki-devs] Attachment file name truncation
by rushero＠inbox.ru 01 Feb '10

01 Feb '10

Hello, XWiki team! i saw this topic: http://www.xwiki.org/xwiki/bin/view/FAQ/Whenuploadtheaccessoriesatthexwiki13 versionallChinesewillbedeletedinfilename and i have the same problem, but with russian characters. When i'm adding the file with name, like "russian_word123.txt" - it is adds like "123.txt". All russian symbols are truncated. With english and numbers - all fine. Please help asap... All encoding are sets t oUTF-8 and hole Xwiki don't have problem with russian characters, except attachment thing. I'm really need russian characters in file names, how I can get this, or disable the truncation function??? BTW - my environment are: XWiki Enterprise 2.1.25683 Oracle 10gR2 Thanks!

3 2

[xwiki-devs] GWT RichTextArea questions
by Norbert Sándor 31 Jan '10

31 Jan '10

Hello, I'm experimenting with the RichTextArea (RTA) in a separate application, not in XWiki. I checked out the xwiki-gwt-dom and xwiki-gwt-user, and RTA seems to work well. (Until now I've created only a small demo application, with an RTA and some buttons to execute various commands.) My questions are: 1. Pressing ENTER creates a BR element by default, is it possible to create a P instead? (The behaviour of the ENTER key inside a P can be set by executing the insertbronreturn command, but the default document always contains a BR, and if I set the initial content to <p></p>, I cannot navigate the cursor inside the P...) 2. Is there a way to listen to selection events? (I want to enable/disable some buttons based on the current selection.) 3. Are there any extensions to the default RTA in the other parts of XWiki? (I mean for example commands and controls for editing TABLEs visually, toolbars that are enabled/disabled based on the content of the RTA, etc. - I haven't looked at all the source code yet, it's huge :) That's for a starter :) Thanks for your help in advance! Best regards: -- Norbert Sándor http://jvminside.blogspot.com/

3 8

[xwiki-devs] [Proposal] Evaluate javascript syntax highlighting as alternative to Jython/Pygments
by Caleb James DeLisle 31 Jan '10

31 Jan '10

Lately I have been playing with a few different javascript syntax highlighting libraries. One which I think shows some promise is google-code-prettify, used for highlighting on google code (Apache license.) Advantages of javascript highlighting: + We could remove Pygments and Jython, Jython weighs in at 8.3MB making it the largest jar in the lib folder, Pygments adds another 364K. + I understand Jython/Pygments has been responsible for recent out of permgen memory errors. + Shifts work from server to client. + Adding a js syntax highlighting library to the svn repository allows us to patch it to support xwiki syntax (switch lexers when macros are detected.) + Relatively easy compared to other performance boosters. Disadvantages: - Some users do not use Javascript. - Highlighting may be slow on old computers when lots of code is displayed. - Removing Jythion from the default build will add a step to upgrading for wiki operators who are using the {{python}} macro. - Adds another js file to download which hurts page load speed until a js bundling plan is in place. If there is significant interest, I could put up a comparison page on the incubator. Caleb

4 3

[xwiki-devs] Visual improvements for the home page of l10n.xwiki.org
by Vincent Massol 30 Jan '10

30 Jan '10

Hi UI experts, Would be up for the challenge of making the home page of http://l10n.xwiki.org even nicer than what it currently is? :) Thomas has just added best contributors. We're only missing some touch of CSS/HTML magic and the page would be great thus inviting even more people to participate. Any idea? Thanks -Vincent

6 16

Re: [xwiki-devs] [xwiki-notifications] r26548 - platform/skins/trunk/colibri/src/main/resources/colibri
by Sergiu Dumitriu 29 Jan '10

29 Jan '10

On 01/29/2010 04:41 PM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-01-29 16:41:25 +0100 (Fri, 29 Jan 2010) > New Revision: 26548 > > Modified: > platform/skins/trunk/colibri/src/main/resources/colibri/menuview.vm > Log: > XSCOLIBRI-188: Don't show the create page from office document menu entry if the office importer application isn't installed > > Modified: platform/skins/trunk/colibri/src/main/resources/colibri/menuview.vm > =================================================================== > --- platform/skins/trunk/colibri/src/main/resources/colibri/menuview.vm 2010-01-29 15:12:03 UTC (rev 26547) > +++ platform/skins/trunk/colibri/src/main/resources/colibri/menuview.vm 2010-01-29 15:41:25 UTC (rev 26548) This will fail if the document exists, but the user does not have access to it. $officeImporterMainDocument is null, so $officeImporterMainDocument.isNew() is undefined, so !undefined is true. > + #set($officeImporterMainDocument = $xwiki.getDocument('XWiki.OfficeImporter')) > + #if (!$officeImporterMainDocument.isNew()) Try: #if("$!{officeImporterMainDocument.isNew()}" == 'false') -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0