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
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.
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
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
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/
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
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/
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?
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