xwiki-devs May 2014

xwiki-devs@xwiki.org

28 participants
73 discussions

[xwiki-devs] [Proposal] Display the extension ID on e.x.o

by Denis Gervalle

Hi devs, I know this have been removed and considered too technical, but I am sure this is a bad idea because: - we display it in EM, so is it less technical there ? - this is the only way to be sure you talk about the same extension, and there are couple of extension with very similar names - it allows finding the right extension for sure (using advance search), which could avoid ambiguities while working remotely with an end user Ok, it should not be the title of the document, but it should be there somewhere to be copy pasted. Here is my +1 to put it back. -- Denis Gervalle SOFTEC sa - CEO

10 years, 7 months

[xwiki-devs] [CONTRIB] New contrib project for realtime-wysiwyg

by Caleb James DeLisle

Hi, I'm working on the realtime wysiwyg extension and it's working fairly well but it's still a bit rough around the edges, some issues I'm aware of and others I am not so I would like to #1 move it to xwiki-contrib git repository and #2 have a bugtracker project to keep track of issues for this project. I'm thinking RTWYSIWYG as a project name on the xwiki.org bugtracker, does this make sense? Thanks, Caleb

10 years, 7 months

[xwiki-devs] About Bootstrap and Color Themes

by Guillaume "Louis-Marie" Delhumeau

Yesterday, I was talking to some of you on IRC, and I realized that we do not have the same expectations about our Bootstrap usage. So I would like to write a brief summary of my thoughts. Benefits of using Bootstrap ====== * Good-looking and practicals components to re-use. * A responsive CSS grid * Supported by a great community * Newcomers on XWiki will find a tool they might already know. That's already some good reasons to use it! What it cannot do for us ===== * Out-of-the box usage of a compiled Bootstrap CSS with different colors. Why? * The images URL needs to be rewritten (/xwiki/bin/resources/etc...) * A compiled Bootstrap CSS does not allow us to use the mix-ins (ie 'functions') that we can use with the Bootstrap sources. So it's less powerful. * There will always be a need to write some 'fixs' to not break the existing XWiki applications. Moreover, the kits that we can find on the internet, in my opinion, do not only change the parameters of Bootstrap. But they should also add their own CSS classes with an example of use in a HTML template. It will never auto-magically fit with XWiki. What I have in mind ===== Write a color theme editor, inspired by what there is for Bootstrap, that allows us to set values for bootstrap variables we decide to expose (there are more than 300, so I guess we should make a choice). We can take inspiration from http://stylebootstrap.info/ (but it should be less technical IMO). Plus add a textarea that lets the user enter some LESS code. So they could set other bootstrap variables and create their own CSS classes. So integrating a theme kit bought on the web would be possible without too much effort as soon as the LESS files are provided within the kit. Example: integrating a theme from Bootswatch ( http://bootswatch.com/ ) ==== Let say we want to integrate http://bootswatch.com/slate/ into XWiki, using the Flamingo skin. Steps: 1 - Create a new Color Theme for Flamingo 2 - In http://bootswatch.com/slate/ , download variables.less and bootswatch.less 3 - Paste the content of these 2 files in the textarea at the bottom of the Color Theme Editor. 4 - If some problem occurs, add some fixes in the textarea. Results: http://tof.canardpc.com/view/73dd64b9-2023-4839-8dcc-47880d823591.jpg Not perfect, so we need some fixes (about the glyphicons). After removing from the textarea the following line: @icon-font-path: "../fonts/"; We get: http://tof.canardpc.com/view/cd25fc9f-921f-4582-b2c7-05680dd6d284.jpg Looks quite simple, maybe not enough for a basic user, but still good for web integrators. WDYT? Thanks Guillaume

10 years, 7 months

[xwiki-devs] Separate GET/POST submits to filter spam for anonymous comments

by Valdis Vītoliņš

Another idea which couldn't bother normal users for anonymous XWiki comments would be separation between GET/POST submits, because spammers mostly use GET instead of POST. I couldn't find how added comment request is handled on server side though. I suspect, it is not handled with velocity scripts. Can you provide some directions? Thanks! Valdis

10 years, 7 months

[xwiki-devs] [contrib] proposal to move xwiki-tools into contrib repo.

by Caleb James DeLisle

Hi, xwiki-tools is a set of command line tools and a node.js library for building and parsing parts of xwiki .xar files. It is unique in that it contains a fairly complete model of XWiki documents, objects, and classes which is not based on the original model in oldcore. It is capable of compiling a filesystem representation of an xwiki extension such as: https://github.com/xwiki-contrib/realtime-wysiwyg into either a Maven compatible directory structure or a .xar file (which can optionally be auto-posted up to the rest interface of a running wiki). Until now I have never considered moving it into xwiki-contrib because it was always "the ducttape I needed to make the real project I was doing approachable" but even if it does not enjoy API stability guarantees, it is useful even if only as a tool for facilitating better thought about the XWiki model so I would like to move it into xwiki-contrib repository and setup a bugtracker for it. Unfortunately the name xwiki-tools which is quite descriptive in the npm repository is not so helpful in xwiki-contrib so I would be willing to rename it to node-xwikimodel (in npm it would be xwikimodel) and using a jira project name NODEXWIKIMODEL. WDYT? The project: https://www.npmjs.org/package/xwiki-tools https://github.com/cjdelisle/xwiki-tools

10 years, 7 months

[xwiki-devs] adding a javascript library(PramukhIME) to a XWiki page.

by ananthakrishna

Hi all, I want to add a javascript library called PramukhIME( http://www.vishalon.net/PramukhIME/JavaScriptLibrary.aspx) into an XWiki page. The objective is to edit Kannada language text(which is already in the page) in a XWiki page.Also,as I wan't to edit multiple pages,it will be better if the library is added only once(together for all pages). As I am new to XWiki, I don't know the basics of XWiki programming and can't even find relevant documents. Can someone please help me out.. -- Thanks and Regards, Ananthakrishna

10 years, 7 months

[xwiki-devs] [Contrib] Create a repository for the Flash Message Application

by Sidali Djebloun

Hello devs, I would like a repository for the Flash Message Application on https://github.com/xwiki-contrib. The application is available on the extensions wiki here: http://extensions.xwiki.org/xwiki/bin/view/Extension/Flash+messages+applicat ion . Thanks, Sidali

10 years, 7 months

[xwiki-devs] New IntelliJ license

by vincent＠massol.net

Hi devs, Jetbrains has been kind to renew our license, it’s available here for committers: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentToolLicenses Thanks -Vincent

10 years, 7 months

[xwiki-devs] [Proposal] Roadmap for XWiki 6.1

by vincent＠massol.net

Hi devs, After brainstorming offline with several XWiki committers here’s a proposal for the 6.1 roadmap: Content ====== * Continue work on improving performances and especially page loading times - Thomas * Continue work on the Flamingo skin with ideally the goal of having it finished and ready to be used by end of 6.1 - Guillaume * First working version of the Script Signing feature - Denis * Continue work on collaborative apps (http://design.xwiki.org/xwiki/bin/view/Proposal/CollaborativeApplications), namely: - Define new features for the File Manager app (Marius) - Design for the File Manager App (Caty + Marius) - Continue implementing the Meeting Ma,ager App (Max) - Implement the File Manager App (Marius + Sofiane) Important JIRA issues defined (first is most important): * Support 2 roles for users for app within minutes: application creator and data creator - XWIKI-8757 * Scheduler / Watchlist activity shouldn't add a version to the page. Huge xwikircs table and terrible performances when reading it. * "Current wiki" wiki macros not available in the macros list in wysiwyg in path based multiwiki - XWIKI-7739 * Adding content (images, links, table, macros) is not working on WYSIWYG on IE10 - XWIKI-10283 * Make it easy to edit the dashboard on the home page - http://jira.xwiki.org/browse/XE-1382 * Welcome block is not easily editable - XE-1389 * User Directory should not show "xwiki:XWiki." for user id - XWIKI-10284 * Show date and time of the install and user who installed for an installed extension - XWIKI-10027 * Allow to force the installation of an extension even if dependencies are not satisfied - XWIKI-9827 * Add the possibility in AppWithinMinutes livetables settings to select a default sort on a column - http://jira.xwiki.org/browse/XWIKI-9659 Investigation: * Check if we need to improve the help in the Admin section of XWiki and if so make a proposal - Caty Dates ===== - 6.1M1: 19 may 2014 - 6.1M2: 9 june 2014 - 6.1RC1: 23 june 2014 - 6.1Final: 7 july 2014 Note that initially we had planned 6.1 final to be released in June so we’re already a bit late in the cycle which is why I put 6.1M1 for 19th of May. Please add the stuff you wish to work on if you’re not in the list above and with to commit to working on something for the 6.1 release! :) WDYT? Thanks -Vincent

10 years, 7 months

[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

10 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2014