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

[xwiki-devs] ParseGroovyFromPage and XWiki Syntax 2.0

by Vincent Massol

Hi, I've seen some IRC discussion about this yesterday. We need to decide what's the canonical way of doing it in 2.0: Here's the idea that I currently have: Step 1(works today) * Use syntax = plain/1.0 to write the groovy page (you can remove the / * #* */ hack) * Use $xwiki.parseGroovyFromPage() Step 2 (future) * Same as solution 1 but in addition use the future Document Type to type the groovy page as a "Groovy Class Page", which means we could offer a default stylesheet for it that would underneath use the {{code language="groovy"}} macro to color it for example + add some info at the top explaining why this page exists. Step 3 (future) * Deprecate the $xwiki.parseGroovyFromPage() api to move it to a proper place, either in the script module (if it can be generified for all scripting languages) or in script-groovy submodule of xwiki-script and accessed through the new Services proposal (see http://markmail.org/thread/g4z56pl734lng2ym ). WDYT? Thanks -Vincent

16 years

1
0
0 0

[xwiki-devs] JBoss HornetQ

by Vincent Massol

Just noticed this project http://www.infoq.com/news/2009/08/hornetq And wondered if if could be useful for us, especially for the distributed event part. Anyway this is mostly a FYI message. Thanks -Vincent

16 years

1
0
0 0

[xwiki-devs] JBoss HornetQ

by Vincent Massol

Just noticed this project http://www.infoq.com/news/2009/08/hornetq And wondered if if could be useful for us, especially for the distributed event part. Anyway this is mostly a FYI message. Thanks -Vincent

16 years

1
0
0 0

[xwiki-devs] [Colibri Skin] [Proposal] Move Jump action

by Ecaterina Valica

Hi, I was talking to Marta and we came across the "Jump" action (*Jump to any page in the wiki (Meta+G)*) The problem is that it has low visibility and it's not well placed in the "Quick Links" panel. *A.* First solution - make a "Keyboard Shortcuts" panel with different shortcuts taken from http://platform.xwiki.org/xwiki/bin/view/Features/KeyboardShortcuts But (Meta+G) is still operating system dependent and with an advanced user target. *B. *How about we put it near the Search input, in the right corner? You can see a mockup at http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/jump.… This will be not the final version of the UI for the jump, but just to get the point. Thanks, Caty

16 years

4
5
0 0

[xwiki-devs] [Survey about XWiki Features] The poll will be closed soon

by Guillaume Lerouge

Hi XWikiers, we've had a poll running at http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures for the past weeks. Thanks to all of you who castes your votes already! Since the work on the next XWiki roadmap will start soon I'd like to close the poll and get the final results published. I will do that at the end of the week. If you haven't done it so far, please cast your votes before friday! Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

16 years

1
0
0 0

[xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor

by Guillaume Lerouge

Hi Devs, Anca asked me to finalize the overall look of dialog boxes in the WYSIWYG so that she can work on it and polish it for the 2.0 release. Right now the issue is that we're using a different look for the link, image & macro dialog boxes which poses a consistency problem. I've been working with Cati on a proposal for the look of the overall box - not for the inner part of the box. Proposals for the standardization of the inner part of the box will come later. The dialog box uses a wizard-like look and follows the vertical form principles proposed by Cati in a previous email (thus the primary action button at the bottom left, to follow the user's eye flow). Its "hidden" features are: - Buttons can be in an enabled or disabled mode depending of what the current step is - All buttons are displayed all the time so that they don't move from one screen to the next - Buttons' labels are configurable - There is no "Cancel" button, the cross at the top right of the dialog box plays that role - The title in the top bar doesn't change and its name is the same as the associated toolbar button (clicking on "Link" opens a dialog box called "Link") - The "Wizard Step Title" reflects what's happening at the current step: "Page Selection" , "Code Macro" , "Image Selection" - The description tells the user what to do at the current step: "Select the page to link to" , "Select the image to insert" , "Fill in macro parameters" - Double-clicking on an item (an image, a page name) acts in the same fashion as selecting it and clicking the "Next" button. If the "Next" button is disabled at the current step, double-clicking works as the primary action ("Insert" , "Create") The mockups are located at: http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog WDYT? Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

16 years

9
41
0 0

Re: [xwiki-devs] [xwiki-notifications] r22869 - platform/core/trunk/xwiki-shared-tests

by Vincent Massol

Hi Thomas, I don't think you can remove this one. I tried it and it failed for me: reason this is a dep on scope = compile while the deps in core parent are on scope = test Thanks -Vincent On Aug 24, 2009, at 12:26 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-08-24 12:26:32 +0200 (Mon, 24 Aug 2009) > New Revision: 22869 > > Modified: > platform/core/trunk/xwiki-shared-tests/pom.xml > Log: > [cleanup] Remove useless dependency (already in core parent) > > Modified: platform/core/trunk/xwiki-shared-tests/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-shared-tests/pom.xml 2009-08-24 > 10:25:03 UTC (rev 22868) > +++ platform/core/trunk/xwiki-shared-tests/pom.xml 2009-08-24 > 10:26:32 UTC (rev 22869) > @@ -36,21 +36,6 @@ > <description>Test framework classes shared between functional test > modules</description> > <dependencies> > <dependency> > - <groupId>junit</groupId> > - <artifactId>junit</artifactId> > - <version>4.5</version> > - </dependency> > - <dependency> > - <groupId>jmock</groupId> > - <artifactId>jmock</artifactId> > - <version>1.2.0</version> > - </dependency> > - <dependency> > - <groupId>jmock</groupId> > - <artifactId>jmock-cglib</artifactId> > - <version>1.2.0</version> > - </dependency> > - <dependency> > <groupId>org.xwiki.platform</groupId> > <artifactId>xwiki-core-context</artifactId> > <version>${pom.version}</version> > @@ -70,6 +55,7 @@ > <artifactId>ant</artifactId> > <version>1.7.0</version> > </dependency> > + >  > <dependency> > <groupId>org.slf4j</groupId>

16 years

2
1
0 0

[xwiki-devs] Status on 2.0 skin?

by Vincent Massol

Hi Cati/everyone, How is it going on the new skin work? Do we have something ready to integrate for RC1 (which was supposed to be released yesterday but is late apparently)? I think we really need something for RC1 or we'll have a big risk of not being able to test it enough for the final release. Thanks -Vincent

16 years

2
1
0 0

[xwiki-devs] Blog Plugin

by Andreas Schaefer

I am not far from finalizing the Blog Plugin together with the changes to the Blog Application. I updated nearly all Velocity code and remove all code from Blog.BlogCode2 which are now handled by the Blog Plugin. The last thing left to do is to add the check that the plugin is available. That said I am wondering if there is a way to make Velocity to fail when a method is not defined. This would make it easier to make sure all the Velocity code is up to date. Thanks - Andreas Schaefer

16 years, 1 month

2
1
0 0

[xwiki-devs] [Proposal] Macro categories names

by Guillaume Lerouge

Hi Devs, we need a list of macro categories to get started with. One of the current requirements is that each category name has to be one-word long for technical reasons for now. Here's my initial list: - All (all macros listed in this one) - Presentation - Error - Warning - Information - Code - Box - Code - HTML - Script - Velocity - Groovy - Include - Wiki (Wiki Content, Internal content would be better but it's 2 words long) - User avatar - Footnote - Navigation - Table of Contents - Id - Maths - Formula - Chart - External Content (can't find a one-word name for this one) - RSS - Other (for new macros and unclassified macros) I'm looking for your feedback / improvement ideas. Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

16 years, 1 month

5
6
0 0

[xwiki-devs] [XOO] XOO Progress

by Cristina Scheau

Hi devs! If you want to know about the XOO Status, please check my blog post: http://gsoc.myxwiki.org/xwiki/bin/view/XWiki+Integration+With+Open+Office/X… I mentioned there the features, known issues and an executable if you want to test it. The issues list form Jira is not yet complete. Thank you, Cristina

16 years, 1 month

1
0
0 0

[xwiki-devs] [GSoC] Google Gadget and OpenSocial Integration Progress

by Anamaria Stoica

Hi all, As a progress update, I wrote 2 blog posts on myxwiki: - one containing some screenshots of the application (OpenSocial improved XEnterprise version): http://gsoc.myxwiki.org/xwiki/bin/view/Google+Gadget+and+OpenSocial+Integra… - the other listing some of the modifications (modules/classe/docs/files/modifications) required by the integration: http://gsoc.myxwiki.org/xwiki/bin/view/Google+Gadget+and+OpenSocial+Integra… Implemented features (what works): - Friends (add/remove) - Dashboard (simple display, no drag&drop) - Application Directory (list/add new) - Application Info Page (from directory) - Listing friends which have the same application installed - Install application from the directory (also Remove and Manage) - Manage(edit) applications page (list all names with edit/remove actions on the side) - Canvas view of applications (own application/others' applications) - Persistently storing User Preferences for each application and user (almost works, 1bug) - Displaying users and application on user pages - Rendering of simple(plain) Gadgets - My Friends Panel - My Apps Panel More details in the above mentioned blog posts. To be implemented (what will work :) ): - fix access to DocumentBridgeAccess from Shindig Services implementations for XWiki, see discussion here: http://markmail.org/thread/zxlnu7q67fxzrjmk . Please, if you have any new ideas regarding this matter let me know ! The communication to XWiki's data store still doesn't work as it is. - OAuth support for gadget authentication - Create Updates Pages (Activity Stream) - Allow drag&drop on the Dashboard page - Design improvements, especially the Profile page - bugs :| Many Applications/Gadgets won't work as the communication to XWiki's datastore isn't put in place yet. Other reasons would be that they require authentication or saving user preferences (saving UserPrefs is implemented, but has a bug), or configuring settings from the canvas view (right now it's possible only on the Dashboard). I think I'll better add them to JIRA here [http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10221…] next to the others, both implemented and future improvements/tasks. If you would like to quickly test, I put up a distribution (the one I've been working on) here: http://dl.getdropbox.com/u/1119078/xwiki-enterprise-jetty-hsqldb-2.0-SNAPSH… . (I thought this would be a preferred way compared to having to apply a patch on xwiki-platform-web, building it, building enterprise with the freshly build xwiki-platform-web from offline repository and installing a .XAR application). So, once you download it, you can login as: Alice, password: alice Visit some of the pages: http://localhost:8080/xwiki/bin/view/OpenSocial/Dashboard - Dashboard http://localhost:8080/xwiki/bin/view/OpenSocialApplication/OpenSocialAppInf… - Full App page - canvas view http://localhost:8080/xwiki/bin/view/OpenSocialApplication/OpenSocialAppInf… - Full App page - canvas view http://localhost:8080/xwiki/bin/view/OpenSocialApplication/MyApps - Managing edit/delete applications http://localhost:8080/xwiki/bin/view/OpenSocialAppInfo/ - Apps Directory - install apps from here; Also add(submit) apps TO the directory http://localhost:8080/xwiki/bin/view/OpenSocialAppInfo/OpenSocialDevApp08 - application page in the Directory and friends with the same app http://localhost:8080/xwiki/bin/view/OpenSocialApplication/OpenSocialAppInf… - Some Other's Person Application 2 Panels: My Friends and My Apps Thanks a lot, Anamaria

16 years, 1 month

1
0
0 0

[xwiki-devs] [Wiki Importer] [GSOC]

by Arun Reddy

Hi devs, The first and simple version of Wiki Importer is now available. Check it out at http://gsoc.myxwiki.org/xwiki/bin/view/WikiImporter+SNAPSHOT-1/0 [ Sandbox Release ] Kindly leave your comments. Thanks and Best Regards, Arun Reddy

16 years, 1 month

1
0
0 0

[xwiki-devs] [Proposal] XWiki 2.0 Skin

by Ecaterina Valica

Hi devs, You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :) Thanks, Caty

16 years, 1 month

12
55
0 0

[xwiki-devs] XWiki Firefox extension

by Alexandru Cismaru

Hi. If you are interested in the XWiki Firefox extension please check the following link: http://gsoc.myxwiki.org/xwiki/bin/view/XWiki+Widget+and+Firefox+extension+/… Thanks, Alexandru Cismaru

16 years, 1 month

5
8
0 0

[xwiki-devs] [Proposal] WYSIWYG - Get out of inline style when hitting Return

by Guillaume Lerouge

*Hi Devs,* *I'm coming back from a meeting with a corporate XWiki user.* *The project manager there reported a "bug" to me: when hitting Return while at the end of the link, she was still in the link. The item she created after hitting return was a title and due to style settings she couldn't see it was still a link. Then she hit Return again and after her title the text was still a link. She felt confused and didn't understand why the link was still there.* *This is due to the fact that right now, when the caret is at the end of an element with an inline style applied, it keeps applying that style upon hitting Return. This applies to bold, italics, underlined, strikethrough, color, background color and links (all inline elements). I've talked about this with Anca a number of times, saying that it was wrong for links to be kept when hitting enter (since users very rarely want links that span 2 paragraphs). Her answer was that all inline styles should be treated the same for technical reasons.* *After giving it more thought and gathering feedback from our project managers it appears that the use case of willing the current inline style to be kept after hitting Return is actually less frequent than wanting the new line to be "clean". Moreover, it's extremely confusing for users when the link is kept.* *Thus I'd like to suggest that hitting Return (= generating a new paragraph) should get the caret out of the current inline style in the WYSIWYG editor. Here are a couple more reasons why I believe this to be the best option:* - There are shortcuts available in the WYSIWYG for most inline styles (CTRL-B, CTRL-I) thus it's easy for the user to activate it again on a new line - It's very easy to select a wide area of text with the mouse and then apply an inline style to it, thus styling can conveniently be done after the actual writing - Hitting SHIFT-Return will keep the user in the same paragraph and thus will keep the current inline styles - It's very rare that users want to apply an inline style to several paragraphs in a row since bold, italics are most often used to create contrast with surrounding text To summarize, I think hitting Return should generate "virgin" new lines. The only thing that should be kept is the alignment. WDYT? Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

16 years, 1 month

4
9
0 0

[xwiki-devs] Our strategy for Design docs already implemented

by Vincent Massol

Hi, As you know I like clean stuff (some could call it an obsession ;)). While browsing the Design/Idea spaces on dev.xwiki.org I noticed several pages containing stuff already implemented. I'd like to propose the following strategy: * Once a design has been implemented, document it (for example in the Modules space on code.xwiki.org) * When both the new design has been implemented and documented, delete the wiki page in the Design space. WDYT? For example I'd like to remove this page: http://dev.xwiki.org/xwiki/bin/view/Design/XWikiSyntaxMapping I'd also like to document the xwiki-component module in Modules and then remove this page: http://dev.xwiki.org/xwiki/bin/view/Design/ArchitectureV2 Thanks -Vincent

16 years, 1 month

7
13
0 0

[xwiki-devs] Testing new public xwiki open source community chat on jabber

by Vincent Massol

Hi everyone, Till now we were using IRC (and we still are) but there are a few issues with it and the biggest one is that you don't get to see messages sent to you when you're offline. Thus we're trying a new solution using Jabber/XMPP. If it works well we'll then switch from IRC to it. If you want to participate in the test and join us you can log in on xwiki(a)conference.jabber.org name: xwiki server: conference.jabber.org Note that you can log with your gmail id if you don't have a jabber id. See you there. Thanks -Vincent

16 years, 1 month

1
0
0 0

Re: [xwiki-devs] [xwiki-users] Hello to the XWiki community

by Vincent Massol

Hi Silvia, Good to have you on board. Just for the record, Silvia is an employee of XWiki Lasi (romanian branch of XWiki SAS, see http://xwiki.com and http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource for those who want to know the relationship between XWiki SAS and the XWiki open source project). From the open source point of view, Silvia is not a committer, she's just a contributor like anyone can be. Silvia this means that for anything important you'd like to change, you'll need to propose it here on this mailing list for agreement. Obviously there's no need to propose anything for creating JIRA issues about bugs found... ;) However if you want to reorganize xwiki.org for example and make some substantial changes you'll need to make a proposal here first and get some agreement first since this is how the XWiki open source project works. Guys let's not completely rely on Silvia though! It's everyone's job to help by improving the doc on xwiki.org and by discovering/fixing bugs. Silvia is a bonus. Thanks and again, welcome on board! -Vincent On Aug 20, 2009, at 10:34 AM, Silvia Rusu wrote: > Hi, > > I am Silvia Rusu (http://www.xwiki.org/xwiki/bin/view/XWiki/ > SilviaRusu) > and I have joined the XWiki Iasi team this week as a tester and > documentation writer. > > As a tester my role will be to uncover any issues and inconsistencies > that might affect the products you love developing/using. > I will also be talking to our project managers, product manager and > mailing list users in order to find out more about our customers > expectations and needs. Taking this into consideration I will come up > with suggestions on how to improve user experience. > > As a documentation writer I will make sure users who aren't familiar > with XWiki discover what the products do in order to take advantage of > their features. In the process I will be making sure all user-facing > features are well documented on XWIki.org, writing user guides, > creating > videos explaining how to use features, etc. > > I am happy to be joining XWiki and hope this will develop into a very > successful collaboration. > > You can find me online on Twitter at http://twitter.com/silviarusu. > Should you have any suggestions regarding testing and documentation > please feel free to contact me by email at silvia.rusu(a)xwiki.com. > > Thanks, > Silvia

16 years, 1 month

1
1
0 0

Re: [xwiki-devs] [Proposal] XWiki 2.0 Skin

by Thibaut DEVERAUX

Sorry here is a link version : http://www.design-platform.org/sourcefiles/XWiki%20users%20com%20board%20co… 2009/8/20 Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com>: > Ok, it just take a little more time to reproduce (completly or just a > part to get the feeling) any image to svg/ai yet it is not the best to > collaborate. > > Can have a look at the design platform story on Flickr : > http://www.flickr.com/photos/evalica/3761778569/ > > > > 2009/8/19 Ecaterina Valica <valicac(a)gmail.com>: >> Sorry, we currently don't have a especially place for SVG files. :) >> >> On Wed, Aug 19, 2009 at 18:37, Thibaut DEVERAUX >> <thibaut.deveraux(a)gmail.com>wrote: >> >>> Thanks. >>> >>> Where can I find the svg files in the futur ? >>> >>> 2009/8/19 Ecaterina Valica <valicac(a)gmail.com>: >>> > Usually I use Inkscape, but for the skin mockups it's not a mockup, but >>> the >>> > actually site modified with CSS. I worked on a local XE instance on my >>> > computer. >>> > >>> > On Wed, Aug 19, 2009 at 14:04, Thibaut DEVERAUX >>> > <thibaut.deveraux(a)gmail.com>wrote: >>> > >>> >> Nice ! >>> >> I can't wait to see it. ;-) >>> >> >>> >> >>> >> >> Also I'd love to make propositions of architecture modifications to >>> >> visauy >>> >> >> show my means. Yet I have not many time. Is there a place where >>> source >>> >> >> files >>> >> >> can be downloaded to speed the process ? >>> >> >> >>> >> > >>> >> > The new skin will be available in it's first version with the RC1 on >>> 24 >>> >> > august. >>> >> >>> >> >>> >> I was speaking of the design source files, not code. :-) >>> >> >>> >> Photoshop, Gimp, Illustrator, Inkscape or whatever you use. >>> >> >>> >> -- Yet I will wait to see your skin and think I will not make mockup >>> >> then. Yet in general cases we found having design files open source >>> >> too can help as we experienced in the design platform project. >>> >> _______________________________________________ >>> >> devs mailing list >>> >> devs(a)xwiki.org >>> >> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >>> > _______________________________________________ >>> > devs mailing list >>> > devs(a)xwiki.org >>> > http://lists.xwiki.org/mailman/listinfo/devs >>> > >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> >

16 years, 1 month

1
0
0 0

Re: [xwiki-devs] trying to make warning macro work in 2.0

by Henk Schouten

Hello, In April there was a discussion on the list with this subject. This discussion ends without a solution. Does anyone know if this problem has been solved. It seems I am having the same problem here when running 1.9.3 on a Oracle OC4J container. Thanks, Henk == Henk F. Schouten, ICT-architect, Dienst ICT room: SL 2.32, phone (31) 70 4457611, email: H.F.Schouten(a)hhs.nl De Haagse Hogeschool, Johanna Westerdijkplein 75, 2521 EN the Hague (NL)

16 years, 1 month

3
2
0 0

[xwiki-devs] [Proposal] Refactoring of DevGuide

by Vincent Massol

Hi, I've started a refactoring of DevGuide today: * Removed the Tutorial page and put everything on DevGuide.WebHome. It was too hard to decide what was a tutorial from what wasn't. * Reordered stuff on DevGuide.WebHome. Notably I've put XWiki Architecture on top and I've started to improve it, see http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture * All Reference docs should go in a Module on code:Modules.WebHome * Module doc should contain: - general architecture - features of the module - quick examples where it makes sense - link to tutorials that should be written in the DevGuide WDYT? What am I missing? Thanks -Vincent

16 years, 1 month

2
3
0 0

[xwiki-devs] [XOO] Rendering module - XHTML - HTML compatibility

by Cristina Scheau

Hi devs! I've just noticed that OpenOffice Web/Writer doesn't work properly for "<br/>" element. (With "<br />" works fine). The answer can be the compatibility problems between XHTML1.0 and HTML. http://www.w3.org/TR/xhtml1/guidelines.html - Appendix - C2 My question is should I change the rendering module or I solve this problem locally , at my client? Best regards, Cristina

16 years, 1 month

1
0
0 0

[xwiki-devs] Update parent on document rename.

by Caleb James DeLisle

Hello all, I noticed that when a document is renamed, it's "child" documents don't have their parent values updated. It looks like just a few lines of code, maybe an hql ALTER XWikiDocument doc WHERE doc.parent = '"+oldName+"' SET doc.parent = '"+newName+"' Is this too messy? I think a loop with doc.doc.setParent(newName) and doc.save() would be too resource intensive with databases which fsync every transaction. Should we bother to even ask the user the way it asks to update links? Should we update #includeForm, #includeInContext, and #includeTopic as well? What are your thoughts? ~Caleb James DeLisle I'm new here, let me know if I posted in the wrong section

16 years, 1 month

3
3
0 0

[xwiki-devs] [Proposal] XWiki 2.0 Skin

by Guillaume Lerouge

Forwarded to get past the list. Begin forwarded message: > From: Guillaume Lerouge <me(a)guillaumelerouge.com> > Date: 16 août 2009 13:22:49 HAEC > To: XWiki Developers <devs(a)xwiki.org> > Subject: Re: [xwiki-devs] [Proposal] XWiki 2.0 Skin > > Hi Thibaut, > > Thanks a lot for your feedback! > > About the tabbed mockups: thanks for the personas, they're useful > and we should use the concept more when working on our designs. > > Jean-Vincent had concerns similar to yours about tabs and we > explored another option that made more use of buttons located close > to the content area last Friday. We will definitely keep exploring > options for a new skin / UX in the coming months and we'll be > looking for your feedback during that time. > > On 16 août 2009, at 12:48, ThibautDeveraux <thibaut.deveraux(a)gmail.c > om> wrote: > >> >> Sorry 3 mail... >> >> I missed the last post. about this skin : >> >> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa… >> >> Well, it is obviously the same architecture as currently. I >> understand that >> there is not much time. > > We've got only 2 weeks to change XWiki's look before 2.0 and we > won't realistically be able to do much more than freshen it up a bit > and make the logo easier to change. > > >> >> I hope it is not definitve. I'd really prefer a skin with page >> related >> actions located near page. >> > We'll keep working on it during our next releases I promise :-) > > >> >> Also I'd love to make propositions of architecture modifications to >> visauy >> show my means. Yet I have not many time. Is there a place where >> source files >> can be downloaded to speed the process ? >> > I'll let Caty / JV answer about this. > > Thanks for your help, > > Guillaume > > >> Have a nice day >> >> Thibaut >> -- >> View this message in context: http://n2.nabble.com/-Proposal--XWiki-2.0-Skin-tp3405623p3453159.html >> Sent from the XWiki- Dev mailing list archive at Nabble.com. >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs

16 years, 1 month

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs