+1 In time we should make Colibri, Toucan and other skins to be independent of each other. By doing this, they will be more easily maintained. And Albatross is obsolete by it's design. Regards, Sorin B. On 10/10/2010 8:32 PM, Marius Dumitru Florea wrote:

On Mon, Oct 11, 2010 at 08:49, Vincent Massol <vincent(a)massol.net> wrote: In my understanding, we should distinct: 1) the velocity templates 2) CSS, pictures and so on For 1), for ease of maintenance we need to share as much as possible. For 2), we should just be able, based on 1), to fully customize the visual representation of 1). IMO, ideally, 1) should be shared by all 2). At the same time, we should keep the current behavior that allow users to customize 1) and 2) themselves more deeply, but we should avoid to maintain several 1) ourselves. Note that 1) should be driven by building an unstyled accessible (WAI compliant) document that could be properly styled in many ways to fullfil the need of 2). This why I see no point to maintain different 1). Moreover that 1) could be built conditionally when require. Maintaining several 1) is just doubling the work without much benefit IMHO. I see just one really good reason to have several 1), which is to support different level of markup, for example, we may think about starting a 1) that use HTML5 feature during a transitioning period, until its is well adopted. WDYT ? +1 for deprecating Albatros and keeping independancy of 2) and targeting unity of 1) Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

On 10/11/2010 08:49 AM, Vincent Massol wrote: We're slowly moving in this direction. Lately, we've been developing "UI components" that are skin-independent. This means moving code out of the huge core skin, which makes it easier to write a new skin from scratch. Color Themes allow us to make Colibri appear as many skins. The planned Layout Themes will make this even simpler. Skin Extensions allows adapting an existing skin very easily. We're not using them for this purpose, but we could write sample extensions that: - make the panels round - add some backgrounds and gradients here and there - change the fonts - shuffle things around Color themes + Skin extensions make it easy to develop something similar to Firefox Personas, lightweight paint jobs over Colibri. We're not doing this yet, but we could start a new section on code.xwiki.org, maybe organize a contest for people to contribute entries. That's because Wordpress skins are a real mess. The equivalent of a Wordpress skin for XWiki would mean packaging both the templates and a skin, along with some images, and we're trying to avoid encouraging people to duplicate the templates. Then, there's a huge difference in terms of features that need to be styled, since Wordpress is just a blogging tool, while XWiki is a development platform. Splitting the skin into even more parts would certainly make writing skins easier, but we're lacking the manpower to work full speed on this. -- Sergiu Dumitriu http://purl.org/net/sergiu/

Hi As someone with a level of experience there may not be such a stretch to getting to such a place. I think it isn't so much as getting the WP compatibility in the sense of them being the same. I think it is more about moving to a model whereby the content that defines the look and feel in the way a Theme in WP or a Template in Joomla are able to be a separate product from the core code. This leans that certain elements that relate to how things are displayed are done with a set of elements that are completely independent of the core. The main component of a WP them is images and css, but it can and does contain php elements. Does Xwiki want to incorporate php into its product mix for display? I build for other projects themes for WP and templates for Joomla using a tool called Artisteer. It is a good product albeit with a share of bugs, but it allows the ability to create a single look and feel in Joomla and WP if being used within a single site. Can we get a tool like Artisteer to support the Xwiki community, possibly if it is possible to build a skin that provides the sort of model that it needs to build to when creating the skin theme. Understanding what this tool is doing might help those to understand what is going to be required for a skin to support a similar them model to WP or Joomla and allow people to make a simple mod to elements that allow the product to support Xwiki. I would be more than happy to throw out somewhere a copy of the Artisteer output for a WP or Joomla site as a starting point of what they contain to help people understand what they need to work towards. So in this vein I think the first step is moving to a complete separation of CSS, JavaScript, images, HTML markup and anything else. that defines look and feel from the main code tree into a template/theme directory. Both WP and Joomla rely on only selecting a directory within the themes/templates location to define the look and feel. It is also possible in both cases to define individual parts of a site to use different look and feel. HTH Cheers Peter Quoting Andreas Hahn <ahahn(a)gmx.net>et>: -- Peter McLarty Senior Consultant, Pacific DBMS Pty Ltd peter.mclarty(a)pacificdbms.com.au 15 Barron Road Margate, QLD 4019 Australia work: 61 7 3883 1086 mobile: 61 4 0209 4238 fax: 61 7 3883 1016 IM: pameacs.cto (Skype) http://au.linkedin.com/in/pameacs Database Consultants across Asia Pacific ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Hi Ricardo I doubt it adds anything and probably complicates matters. Both the Joomla templates and WordPress themes contain .php elements. My point was to make people aware that trying to become compatible so as to be able to use WP Themes in Xwiki was likely not such a good solution. I would think a Xwiki skin/theme/template would consist of images, html, JavaScript and possibly Groovy and Velocity in the this, but that stuff needs to only be there for the display of items in your Xwiki and be able to be removed without affecting the core operation of the Xwiki. Hope this helps towards building a great solution Cheers Peter Quoting "[Ricardo Rodriguez] eBioTIC." <ricardo.rodriguez(a)ebiotic.net>et>: -- Peter McLarty Senior Consultant, Pacific DBMS Pty Ltd peter.mclarty(a)pacificdbms.com.au 15 Barron Road Margate, QLD 4019 Australia work: 61 7 3883 1086 mobile: 61 4 0209 4238 fax: 61 7 3883 1016 IM: pameacs.cto (Skype) http://au.linkedin.com/in/pameacs Database Consultants across Asia Pacific ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.