xwiki-devs April 2014

xwiki-devs@xwiki.org

27 participants
54 discussions

[xwiki-devs] [Proposal] Integrate LESS css in XWiki

by Guillaume "Louis-Marie" Delhumeau

Hello. In 6.0, we have released a first version of Flamingo. It uses Bootstrap and the LESS preprocessor during the build to create the final style.css file. But currently, there is a serious regression compared to Colibri: it does not support color themes. So I have started a proposal about the color theme handling in Flamingo, that you can see there: http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo My conclusion is that we need to integrate the LESS preprocesor on the runtime. This way, we can add velocity variables (corresponding to the color theme) in our LESS sources BEFORE the LESS preprocessor is launched. Doing the opposite, (process velocity after LESS) causes some problems that I have reported on the previous link. To me, it would be a good step ahead for proposing LESS to our users. Regarding this, some ideas are coming to me: - it is quite easy to integrate LESS since we can use Rhino to launch the LESS preprocessor (which is a javascript program). See: https://github.com/sandroboehme/lesscss-java - we need a cache system in order to not always compute the style.css served to the user (performances issue). - we need to add this in the "skin" action. - in the future, we also need to modify the skinx actions, to enable it for Skin Extensions. We also need to agree on the use of LESS instead of SASS. I have used LESS on Flamingo because Bootstrap has originally been written with it (although an official SASS port exists), so this choice is not based on a strong analysis. Anyway, it looks quite simple to move from one to the other and it is probably too soon to predict which of these 2 preprocessors will win on the long term. Do you think I am going in the right direction? Thanks for reading, Guillaume

11 years, 1 month

[xwiki-devs] Refresh a macro

by firmusoft.xwiki

Hi, I have a macro which displays all the objects of a class in a table. We can add a new object to the class also, using the macro. I want the newly added object listed in the table. Currently this happens only when I reload the page. Can we refresh a macro so that the table gets updated as soon as we add a new object? Please help me on this Thanks, Firmusoft

11 years, 1 month

[xwiki-devs] [Brainstorming] Applications / Skin dependence

by Ecaterina Moraru (Valica)

Hi, With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc. This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2]. In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVa… I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause. Thanks, Caty [1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo

11 years, 1 month

[xwiki-devs] [Proposal] Improve our Panels technology

by Guillaume "Louis-Marie" Delhumeau

Hi. After some discussions with Caty and Vincent, we would like to propose you new ideas about the panels technology, that replaces our previous propositions about the Flamingo Applications Bar. The proposal is there, with more explanations and screenshots: http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements Here is my +1. Louis-Marie

11 years, 1 month

[xwiki-devs] [Proposal] Also send system information when sending Active Installs pings

by vincent＠massol.net

Hi devs, I’d like to propose what I started writing in http://jira.xwiki.org/browse/XWIKI-10274 : " The idea is to send the following pieces of information too: - Java version - OS name, arch and version - Database product name and version This will allow us to know more our use base and evaluate better the consequences of moving from one version of Java to another, what are the most used DBs on XWiki, what OS is the most used for XWiki, etc. This is useful to understand where to focus our support efforts for example. See also http://design.xwiki.org/xwiki/bin/view/Proposal/ActiveInstalls2 “ WDYT? Thanks -Vincent

11 years, 1 month

[xwiki-devs] Fwd: Programmatically loading text file content with unicode characters into XWiki

by ananthakrishna

Hello, I want to load content in large number of(millions) text files into XWiki pages.The text files contain Unicode Kannada characters(as well as some English characters). Is there a way to programmatically load these text file content into a XWiki page? Also will it work for millions of pages? I am new to XWiki.Can you please help me out. Thank you, -- Regards, Ananthakrishna

11 years, 1 month

[xwiki-devs] [VOTE] Drop support for IE8 for 6.x

by Ecaterina Moraru (Valica)

Hi devs, This mail is about voting to drop support for IE8 in 6.x cycle. The issue is more complicated, since according to our 'Browser Support Strategy' [1] we are supporting IE8, IE9 and the latest versions of FF, Chrome (+ Safari5). IE8 was released in March 2009 (4 years ago) IE9 - March 2011 (2 years ago) IE10 - Sept 2012 (17 months ago) IE11 - Oct 2013 (4 month ago) With the release of IE11 some companies also dropped their support for IE9, so we should also adjust our support strategy by supporting newer browsers (IE10, IE11) and dropping the support for old ones (IE8, IE9). According to Statcounter for the last 6 month period http://gs.statcounter.com/#browser_version-ww-monthly-201309-201402-bar the most popular IE browsers are IE10 (8.48%) and IE8 (7.98%). While the market share is not neglectable there is something you need to consider: In 6.x we want to add a new skin: Flamingo. Ideally this skin should be responsive. In order to assure responsiveness we need media query support. IE8 doesn't has support for media query natively, we would need Respond.js [2] to enable it. While this solution exist, 6.x will be ready at the end of 2014 when I suspect the market share for IE8 will drop. Additional to not having media query support, there are other CSS3 properties and HTML5 elements that are not fully supported by IE8 (border-radius, box-shadow, transition, etc.). This is my +1 to drop support for IE8 in 6.x Thanks, Caty [1] http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy [2] https://github.com/scottjehl/Respond

11 years, 1 month

[xwiki-devs] [UX] Converge design of Mail Archive app with xwiki / flamingo / forum app

by Jeremie BOUSQUET

Hello, I was having a look at the proposal for Forum app design with Flamingo [1][2], and I thought it could be good to start thinking about the same for the Mail Archive app. Yes, I'm still working on this btw :) Would it be possible for me to re-use some graphical elements from this proposal ? (buttons icons, the grey icons around the boxes corners, this sort of thing). Would it be possible to somehow get close to this design even without Flamingo skin (so with colibri), as flamingo is still not a final skin ? Also I remember there were some discussions about it, but how should one proceed, keep the same app and maintain both colibri/flamingo look with distinct css (and how to switch between both ? detect the current skin of the wiki ?). Or just make a "flamingo" version that would not look too bad with colibri ? Would the ColorTheme variables still be available for a parsed ssx ? To be honest I like the proposal (and a forum app UI is the closest you could get to a mail archive app UI), except maybe for the topics / topics answers, if there's a large number of answers (occurs often with a mail thread), maybe it's not enough compact / paginated. In my most crazy dreams, the forum app and the mail archive app could share the same UI with small variants, but fed with different objects / data sources - seems very nice idea, but would be quite complex to achieve. I'm just trying to prepare myself only, because I will not work on this yet - I'm currently bugfixing and finishing some UIs. Maybe I should wait for the 6.x cycle (and flamingo) to be more mature. Thanks & regards, Jeremie [1] http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplicationDesign [2] http://xwiki.markmail.org/thread/kytpmsypd2cjemir

11 years, 1 month

[xwiki-devs] [UX][Proposal] Application: Tasks

by Ionut Maxim

Good day, One of the objectives of 6.0 is to review the existing applications on extensions.xwiki.org, improve them and see how they would integrate in the upcoming Flamingo skin (while also considering improvements suggestions). This mail covers the Flamingo integration for the Tasks Application<http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati…>. You are welcomed to review the proposal at: *http://design.xwiki.org/xwiki/bin/view/Proposal/TaskApplicationDesign <http://design.xwiki.org/xwiki/bin/view/Proposal/TaskApplicationDesign> * Any feedback is welcomed. Thank you, have a good day! -- Ionut MAXIM - - - - - - - - - - - - - - - - - - - - - - - - Web Designer @ XWiki SAS - - - - - - - - - - - - - - - - - - - - - - - - +40755120711 | www.xwiki.com

11 years, 1 month

[xwiki-devs] Continuing the search of the best directory structure for XWiki applications

by Caleb James DeLisle

Hello devs, As some of you know, about one year ago I developed a toolkit for scripting the generation and installation of .xar extensions. As of last July, my kit was really just a javascript API for crafting extensions programmatically. Recently I finished development of a directory structure for representing XWiki applications which layers on top of the toolkit. I documented it here: http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApp… I would like to hear some thoughts about this structure as I'm hoping to evolve the optimal human readable filesystem representation for XWiki applications and content so comments are most welcome. I would like to add: * simple representation of extension with all metadata necessary for uploading to extensions.xwiki.org * xardump to dump a xar file into a "cannonical" directory structure. * xarlint to check if a directory representation is cannonical, cannonicalize it, or warn if nodejs specific functions are being used. * maven job which builds xars from directory structures. WDYT? Caleb

11 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2014