December 2010 - xwiki-devs@xwiki.org

[xwiki-devs] [Community] We need a wiki and volunteers for implementing the new XWiki.org
by Ecaterina Moraru (Valica) 17 Feb '11

17 Feb '11

Hi, Would be very nice to have a development wiki in order to get things going on the new XWiki.org proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2 Maybe Vincent can help with this? :) Since the redesign is quite big and lots of spaces|panels|styles need to be changed, morphing the current xwiki.org on the go would be quite difficult. So, having the development wiki would be much easier to work decentralized on different parts of it when people have time. There are lot of areas of the proposal that are not covered and would be really great to receive proposals and help from other members of the community. Also the implementation needs volunteers :) so any help is appreciated. We will also use the new xwiki.org logo proposed by the community, so having all this ideas come together and be put into action is very exciting. Thanks for the support, Caty Resources: - Original Proposal mail: http://markmail.org/message/4erqdhwuzvmtts6p - Logo Challenge mail: http://markmail.org/thread/bze35tdm4iojnafa

4 4

Re: [xwiki-devs] [Proposal] Making "Edit this attachment" an advanced feature in the advanced edit mode
by Raluca Stavro 01 Feb '11

01 Feb '11

Hello, >Sergiu Dumitriu wrote: > >>Silvia Rusu wrote: >> >>Hi devs, >> >>I propose we make "Edit this attachment" in the "Attachments" tab an advanced feature in the advanced edit mode. >> >>When trying to use "Edit this attachment": - in IE you get the following message: "Could not initialize a required ActiveX object" - in FF 3.5.2 installing the extension delivers the following message:"FoxWiki 1.0b could not be installed because it is not compatible with Firefox 3.5.2". - installing the extension on an older version of FF requires additional configuration, which the average user may not know how to perform. >> Under the above circumstances I think "Edit this attachment" will cause confusion for the average user instead of providing a useful tool. >> >>WDYT? >> > >Agreed to remove the edit button if the FF extension is not already installed and configured. The edit button is still there and the Firefox extension can't be installed because it is not compatible with newer Firefox versions. I really think that we should remove this button as soon as possible because this is a non-functionality at this point. Raluca.

2 1

[xwiki-devs] [discussion] Where to put java macros CSS?
by Anca Luca 09 Jan '11

09 Jan '11

Hi guys, Short story: Where to put the css which is needed by java macros (e.g. the columns layouting of the container macro) 1/ in colibri.css 2/ in a .css included on demand by the macro a) from platform resources (using ssfx) b) from the jar (using ssrx) c) from an object in a page with ssx 3/ refactor the skin concept and create a 'platform css' to store all these and not be affected by skin customization. Long story: I can see I've caused the web standards tests to fail for the trunk (http://hudson.xwiki.org/job/xwiki-product-enterprise-tests/org.xwiki.enterp…) because of the inline style attributes used by the columns layout of the container, whijch is now used on the main page. Now, I would like us to agree about where to store the styles needed by the java macros to work right, such as the container macro with columns layout. The options I see are: 1/ as until today (e.g. box macro, warning, error, info, etc), in colibri.css/toucan.css/otherskinwehave.css. I don't like this solution too much because it means that when another skin is used, things won't work anymore unless the person writing the new skin takes care of copying all these "things that must be there". The advantage of this is having a single .css file to load on page load, the disadvantage being that their css is loaded on all pages, regardless of it being used or not. 2/ loading of the styles on demand, each macro loads its style when it needs it a) from a .css file located in the platform resources, which the macro has to include using the ssfx plugin when is executed -- much like a wiki macro would to with a ssx. b) from a .css file located in the macro archive (using ssrx), which the macro includes when executed. c) from a ssx page c) has the advantage of being very very much more easy to change than a) and finally than b) which is the hardest to customize. But on the other side c) means the java macro depends on a page, which is not that good. Note that "cascading" customization is possible for all these choices (adding an extra css with rules to overwrite the rules in the default css for the macro) and that in my view, it's enough, since the idea is that the layout should be preserved no matter what (e.g. a user might want to add a red border to the columns, but not make the columns display as two paragraphs instead of two columns). 3/ refactoring the whole skin thing and creating a "platform" css, which contains things that should work regardless of the skin used. Pros: it's an adaptation of the current approach (1/), that solves the problem. Cons: takes longer, might be very hard to separate what's platform and what's skin. These being said, I think I prefer 2/ if 3/ is not realistic, and for the container macro at least, I would prefer to implement 2b). Thanks, Anca

5 16

[xwiki-devs] xwiki.org is down?
by Paul Libbrecht 02 Jan '11

02 Jan '11

Hello fellow developers, I can't reach http://www.xwiki.org/xwiki/bin/view/Main/WebHome while www.xwiki.org redirects properly (so the xwiki is down, not the apache). Something must be hanging wrong somewhere. That makes it that I can't commit it seems. Skol seems to be "working" since quite a while (more than an hour?). paul

2 1

Re: [xwiki-devs] [xwiki-notifications] r33714 - enterprise/trunk/wiki/src/main/resources/ColorThemes
by Sergiu Dumitriu 28 Dec '10

28 Dec '10

On 12/28/2010 01:22 PM, evalica (SVN) wrote: > Author: evalica > Date: 2010-12-28 13:22:42 +0100 (Tue, 28 Dec 2010) > New Revision: 33714 > > Modified: > enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeClass.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeTemplate.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/DefaultColorTheme.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/WizardPropertyMapping.xml > Log: > XE-796: Customizable "Add" menu entry from the Color Theme Wizard > > Modified: enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml 2010-12-28 12:18:23 UTC (rev 33713) > +++ enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml 2010-12-28 12:22:42 UTC (rev 33714) > @@ -1431,6 +1434,7 @@ > <div #elementMetaData('mainmenu')> > <div> > $msg.get('xe.themes.colors.wizard.mainMenu') I think it would be better to use a different text for this one, since it's supposed to be used only for the Add entry: > +<span #elementMetaData('menuaddentry')>$msg.get('xe.themes.colors.wizard.menuEntry')#$msg.get('core.menu.create')</span> > <span #elementMetaData('menuentry')>$msg.get('xe.themes.colors.wizard.menuEntry')#1</span> > <span #elementMetaData('menuentry')>$msg.get('xe.themes.colors.wizard.menuEntry')#2</span> > </div> > -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

[xwiki-devs] [Proposal] Make an UPDATE XAR of XWiki Enterprise standard XAR
by Ludovic Dubost 28 Dec '10

28 Dec '10

Hi, We have a general problem when upgrading XWiki which is to not forget to exclude certain files from the import. The manual exclusion is something that generates all sorts of problems especially when done by less experienced users. These files are: - preferences - all and admin group - admin user - invitation config file - anotation config file Either we make a FULL and an UPGRADE XAR or we make a CODE and CONFIG xar (initial install would need both xars to be imported). I'm more for the solution of one FULL and one UPGRADE xar. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

2 1

[xwiki-devs] [Vote] [Standards] Forms: Usage + Documentation page to XWiki.org
by Ecaterina Moraru (Valica) 27 Dec '10

27 Dec '10

Hi devs, A. Usage: Some time ago I made a proposal about the form usage standard: http://markmail.org/thread/5ya4iozbpl2c2kf2 Since then, the standard has been used by: - Marta and Sergiu in "Send by email" feature http://incubator.myxwiki.org/xwiki/bin/download/Standards/Forms/ShareByEmai… - Marius in "WYSIWYG Configuration in Administration" http://incubator.myxwiki.org/xwiki/bin/download/Standards/Forms/WYSIWYGConf… - the original proposal also reflected possible usage of the places where the forms new style could be applied http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal This is a vote mail to include the form standard CSS in colibri.css, in order to avoid duplication and to start using it the standard to all our forms elements. So here is my +1. B. Documentation: The documentation for the usage of the proposed form standard is at: http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormVerticalUsage If you have something to add to it, please do, otherwise, after we will add the code in the platform, the documentation will also move to xwiki.orgat http://platform.xwiki.org/xwiki/bin/view/DevGuide/FrontendResources My +1. Thanks, Caty

12 13

[xwiki-devs] [VOTE] New committer: Raluca Stavro
by Sergiu Dumitriu 25 Dec '10

25 Dec '10

Hi devs, I'd like to propose Raluca as a committer. Raluca is one of the first employees of the of the Romanian branch of XWiki SAS, with more than three years experience developing applications on top of the XWiki platform. She didn't have time to contribute that much code to the platform, but she's been active on the mailing lists, she provided several patches, and she's the main developer behind the new Activity reimplementation of the old Recent Changes feature. I trust her to bring good value to the community, so here's my +1. -- Sergiu Dumitriu http://purl.org/net/sergiu/

10 10

[xwiki-devs] [vote] Move MacroDescriptorTranslator from the wysiwyg server module to the rendering module
by Anca Luca 24 Dec '10

24 Dec '10

Hi devs, in order to be able to translate the macro descriptors to use for the gadgets (for the moment, to be able to provide the title of the gadget), I would like to move the MacroDescriptorTranslator and its implementation from the wysiwyg gwt module to the rendering module. My +1 on this. We'd also have to refactor it to use the org.xwiki.rendering.macro.descriptor.MacroDescriptor instead of the gwt, serializable clone of it. About where in the rendering to put it, we could either: 1/ create a new module for it, under xwiki-core-rendering 2/ put it in xwiki-core-rendering-api since it's about translating macro descriptors which have both the interface and implementation in the api module 3/ create a new module for it under xwiki-core-rendering-macros My +1 for 2/ WDYT?

2 2

[xwiki-devs] [Announcement] XWiki Enterprise 2.7 and XWiki Enterprise Manager 2.7 Released
by Sergiu Dumitriu 23 Dec '10

23 Dec '10

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.7 and XWiki Enterprise Manager 2.7. Go grab them at http://www.xwiki.org/xwiki/bin/Main/Download This is the last major release of the 2.x development cycle (there will still be bugfix releases on the 2.7.x branch, if needed). The next release is going to be 3.0. This is a stabilization release, with no major new features to highlight. Some minor gems: * Ability to set a color theme on each space * UNC support in XWiki Syntax 2.1 * Support search on space name in the REST API * Support for customizing the office export process For more information, see the Release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise27 and http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXEM27 Thanks -The XWiki dev team

1 0