xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [VOTE] Put XWiki Invitation Manager Plugin jira project in XWiki Retired Projects section

by Thomas Mortagne

Hi devs, Since the new invitation application is not based on it doubt we will ever work on this plugin. WDYT ? Here is my +1 -- Thomas Mortagne

14 years, 7 months

[xwiki-devs] Modify page creation details without causing an update.. :S

by JoannaD

Hi all Is there any way of modifying the creation details (or any other property) of a page/doc without really causing/trigerring an update? What I intend to do is modify the creator and the creation date as they were messed up during import but I need the author and the date to remain unchanged.. Any ideas? Thank you! Joanna D. ----- Joanna -- Please consider the environment -- -- View this message in context: http://xwiki.475771.n2.nabble.com/Modify-page-creation-details-without-caus… Sent from the XWiki- Dev mailing list archive at Nabble.com.

14 years, 7 months

Re: [xwiki-devs] [VOTE] (Results) Apply code style to imports

by Denis Gervalle

4 +1, 1 +0, 0 -1; applied XTVERIFICATIONS-10 in r29627 Denis On Tue, Jun 22, 2010 at 10:07, Vincent Massol <vincent(a)massol.net> wrote: > +0 > > Thanks > -Vincent > > On Jun 22, 2010, at 9:17 AM, Denis Gervalle wrote: > > > Well, > > > > Based on your feedback, the easiest and probably best solution is to keep > > the default for Eclipse (so, no need for a special config file) and to > > configure IntelliJ code style (it is the same file for all) to do the > same > > as Eclipse, which will avoid confusion: > > > > import java.* > > > > import javax.* > > > > import org.* > > > > import com.* > > > > This choice already have a +1 from Marius, a +1 from Sergiu and here is > my > > +1. > > I do not think we need long discussion on this, just an agreement, please > > could you cast your vote on this. > > > > Denis > > > > On Mon, Jun 21, 2010 at 16:13, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > > > >> On 06/21/2010 04:04 PM, Marius Dumitru Florea wrote: > >>> On 06/21/2010 02:36 PM, Denis Gervalle wrote: > >>>> On Mon, Jun 21, 2010 at 13:24, Marius Dumitru Florea< > >>>> mariusdumitru.florea(a)xwiki.com> wrote: > >>>> > >>>>> Hi Denis, > >>>>> > >>>>> On 06/21/2010 01:55 PM, Denis Gervalle wrote: > >>>>>> Hi Devs, > >>>>>> > >>>>>> Currently we do not have any code style specification for imports. > To > >>>>>> improve clarity of our commits, I propose that we decide once for > all > >> how > >>>>> we > >>>>>> would like to have imports. Of course, normalisation of existing > code > >>>>> will > >>>>>> come with normal commit, I do not intend to update it only for that. > >>>>> > >>>>> Are you saying that > >>>>> > >>>>> > >> > http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-verific… > >>>>> doesn't include information about import styles? > >>>>> > >>>> > >>>> Sorry, I do not have Eclipse, maybe Thomas could precise this point. > >>>> What I am saying is that we do not have any written code style for > that, > >> and > >>>> we use the default of the IDE. > >>>> > >>>>> > >>>>>> > >>>>>> Currently, > >>>>>> > >>>>>> Eclipse does java.*, org.*, com.* separated by blank lines > >>>>>> IntelliJ IDEA does com.*,org.* together, than a blank line and > java.* > >>>>> > >>>>> So you're saying that codestyle-eclipse.xml and codestyle-idea.xml > are > >>>>> not consistent? > >>>>> > >>>> > >>>> There are not, probably because we have never look at it and their > >> defaults > >>>> differ. > >>> > >>> I see. It's clear now. > >>> > >>>> > >>>> > >>>>> > >>>>>> Old existing code has there own ordering... > >>>>>> > >>>>>> I propose the following style: > >>>>>> > >>>>>> import java.* > >>>>>> > >>>>>> import org.* > >>>>>> import com.* > >>>>>> import<anything else> > >>>>>> > >>> > >>>>>> import org.xwiki.* > >>>>>> import com.xpn.* > >>> > >>> I don't think separating this imports from org.* and com.* makes them > >>> much more visible. Also, for classes that don't depend on the old core > >>> (com.xpn.*) moving org.xwiki.* out of org.* breaks the order. Since > >>> we'll eventually drop the com.xpn.* package in favor of org.xwiki.* I > >>> think we should keep XWiki's imports under org.* and com.* . > >>> > >>> I'm +1 for enforcing a style for imports. I'm -0 for separating > >>> org.xwiki.* and com.xpn.* from org.* and com.* respectively. > >>> > >> > >> Same as Marius. > >> > >>> > >>>>>> > >>>>>> import static<any> > >>>>>> > >>>>>> If we agree on this, necessary IDE setup for both Eclipse and > IntelliJ > >>>>>> should be prepare/updated. I will take IntelliJ in charge, a > volunteer > >>>>> for > >>>>>> Eclipse is welcome (Thomas?) > >>>>> > >>>>> You mean update codestyle-eclipse.xml and codestyle-idea.xml ? > >>>>> > >>>> > >>>> Yes, and if this is not part of codestyle-eclipse, provide what is > >> required > >>>> to have both IDE in sync. > >>>> > >>>> Denis > >>>> > >>>> > >>>>> > >>>>> Thanks, > >>>>> Marius > >>>>> > >>>>>> > >>>>>> WDYT ? > >>>>>> > >>>>>> Denis > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

14 years, 7 months

[xwiki-devs] [VOTE] Templates Administration Icon

by Jean-Vincent Drean

Hi, For the moment the templates administration section [1] uses the default icon. Ciprian made a bunch of proposals for it and I'd like to commit one of them asap: http://incubator.myxwiki.org/xwiki/bin/view/Ciprian/Template%20icon Here's my +1 for 5a. [1] http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication… Thanks, JV.

14 years, 7 months

[xwiki-devs] [Idea] "Modern" skin for "modern" browsers

by Ecaterina Valica

Hi, When the CSS3 fever began, Raluca Stavro came to me and asked me what I think about making a HTML5+CSS3 skin. My first answer was that is not gonna happen. We invest very much in making our skins have cross-browser support (especially old versions of IE). This is one of our strengths, but also the reason we limit ourselves from innovation. When I'm talking about a "modern" skin I'm not only referring about HTML, JS, CSS (having transparency, corners, multiple backgrounds, shadows without having to triple the code and the number of hacks), but it's about all cool/experimentation features, that boosts productivity, minimize code lines, etc. but lack all/old browser support (SVG, location awareness, CSS3 calc etc). So, in my opinion this would be an experimentation/shiny skin that by comparison would make old browsers supporters and lovers to quit their old behaviors and embrace the future :) :p So, the questions I have are: 1) would this be possible? would anyone want to do this sort of thing? I know the biggest problem is gonna be the maintenance, but could bring lots of innovation and productivity. 2) what feature/improvement/thing do you think it would be the most needed for a new "modern" "skin" (the topic somehow go beyond the skin boundaries)? Thanks, Caty

14 years, 7 months

[xwiki-devs] [PROPOSAL] Use openoffice server when its enabled to do PDF/RTF export

by Thomas Mortagne

Hi devs, Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO. So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently. That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4. The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more. WDYT ? We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover. -- Thomas Mortagne

14 years, 7 months

Re: [xwiki-devs] [Idea] "Modern" skin for "modern" browsers

by Jerome Velociter

----- "Ecaterina Valica" <valicac(a)gmail.com> wrote: > Hi, > > When the CSS3 fever began, Raluca Stavro came to me and asked me what > I > think about making a HTML5+CSS3 skin. My first answer was that is not > gonna > happen. We invest very much in making our skins have cross-browser > support > (especially old versions of IE). This is one of our strengths, but > also the > reason we limit ourselves from innovation. > > When I'm talking about a "modern" skin I'm not only referring about > HTML, > JS, CSS (having transparency, corners, multiple backgrounds, shadows > without > having to triple the code and the number of hacks), but it's about > all > cool/experimentation features, that boosts productivity, minimize > code > lines, etc. but lack all/old browser support (SVG, location awareness, > CSS3 > calc etc). > > So, in my opinion this would be an experimentation/shiny skin that by > comparison would make old browsers supporters and lovers to quit their > old > behaviors and embrace the future :) :p > > So, the questions I have are: > > 1) would this be possible? would anyone want to do this sort of thing? > I > know the biggest problem is gonna be the maintenance, but could bring > lots > of innovation and productivity. For lot of cases (that is at least everything that includes JS, and maybe more) we should be able to add such new features on top of the existing UI, i.e. without the need to create a dedicated skin. Take for example attachment Drag & Drop in the attachment footer tab. We just detect the feature and offer it if supported (do nothing if not). > > 2) what feature/improvement/thing do you think it would be the most > needed > for a new "modern" "skin" (the topic somehow go beyond the skin > boundaries)? Right now I think of - attachments D&D - upload with progress bar - growl-like client notifications (w/ WebSocket) - local drafts (with localStorage) - a profile picture sizing/cropping tool using canvas - ... I'm sure a lot more :) Jerome. > > Thanks, > Caty > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

14 years, 7 months

[xwiki-devs] [VOTE] Apply code style to imports

by Denis Gervalle

Hi Devs, Currently we do not have any code style specification for imports. To improve clarity of our commits, I propose that we decide once for all how we would like to have imports. Of course, normalisation of existing code will come with normal commit, I do not intend to update it only for that. Currently, Eclipse does java.*, org.*, com.* separated by blank lines IntelliJ IDEA does com.*,org.* together, than a blank line and java.* Old existing code has there own ordering... I propose the following style: import java.* import org.* import com.* import <anything else> import org.xwiki.* import com.xpn.* import static <any> If we agree on this, necessary IDE setup for both Eclipse and IntelliJ should be prepare/updated. I will take IntelliJ in charge, a volunteer for Eclipse is welcome (Thomas?) WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

14 years, 7 months

Re: [xwiki-devs] [xwiki-notifications] r29596 - platform/web/trunk/standard/src/main/webapp/resources/js/prototype

by Vincent Massol

On Jun 21, 2010, at 10:24 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-06-21 10:24:46 +0200 (Mon, 21 Jun 2010) > New Revision: 29596 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js > Log: > XWIKI-4183: Improve page load speeds via parallel JavaScript download > Fixed most race condition failures occuring in IE > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js 2010-06-21 08:24:35 UTC (rev 29595) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js 2010-06-21 08:24:46 UTC (rev 29596) > @@ -4687,8 +4687,11 @@ > document.addEventListener('DOMContentLoaded', fireContentLoadedEvent, false); > } else { > document.observe('readystatechange', checkReadyState); > + // Disabled in XWiki since it conflicts with defered scripts > + /* > if (window == top) > timer = pollDoScroll.defer(); > + */ So we'll loose this change (ie we'll have to remember it) when we upgrade to a new version of prototype? Thanks -Vincent

14 years, 7 months

Re: [xwiki-devs] Gadgets & Dashboard roadmap

by Jerome Velociter

----- "Anca Luca" <lucaa(a)xwiki.com> wrote: > Hi all, > > I am now restarting the work on the gadgets & dashboard project, > documented here > http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration (however > > documentation needs to be slightly revised). > > What is done already can be summarized as: > * gadgets are implemented as macros and there is a script to import > google gadgets as xwiki macros, > * also, right now, gadgets are implemented as xwiki macros and can be > > used anywhere just like a regular wiki macro, and any wiki macro can > be > seen/used as a gadget so **there is no difference between macros and > gadgets** . WDYT about this? should we keep it like that? (A) If I understand correctly, it means XWiki will not be an OpenSocial container, but will provide a "conversion" layer to make OpenSocial gadgets work with the XWiki gadget (= macros) system. I'm not sure it's the proper approach. It will not encourage developers of XWiki application / macros etc. to write their gadgets as OpenSocial gadgets, since writing XWiki macros will be enough (so it will not be possible to display a XWiki gadget in say JIRA). Plus, if we make XWiki an OpenSocial container, it does not prevent us from writing a generic XWiki gadget that can wrap any macro thus not adding too much weight on developers. Jerome. > * there is a dashboard macro responsible with layouting a gadgets > dashboard, which also provides specific editing features in inline > mode > (gadgets can be dragged around, toolboxes for gadgets in the top > right) > * there is a minimal macros directory, where one can see all the > existing macros, descriptions, details about the parameters. > * there is an PanelMacro macro, that displays an xwiki panel inside a > > document, which can be used to display xwiki panels as gadgets in a > dashboard. > > The big picture of the roadmap is that we should: > > 1/ have a fully working dashboard, that is implement add gadget and > edit > gadget settings > 2/ implement the main dashboard (Main.Dashboard) as a dashboard and > fill > it with the appropriate gadgets by default, and also to add a user > specific dashboard ("My dashboard") where each user can configure > his/her dashboard, and is available to a user from his / her profile > or > the user menu > 3/ have a nice macros directory where a user can navigate through > existing gadgets and add one to a dashboard > 4/ have a "dashboard template", integrated with the document templates > > system to easily allow a user to create a dashboard > 5/ also, since the xwiki panels can be seen as gadgets / macros, and > can > be implemented as such, somewhere in the future a refactoring should > be > made to integrate the 2 notions > 6/ be able to publish the gadgets in the wiki such that other apps can > > integrate this in their content > > WDYT about the order above? (B) with the mention that points 5 and 6 > could eventually be infinitely postponed. > > Also, after points 1 and 2 are implemented, the feature could be > available with xwiki platform and integrated in XE by default. WDYT? > (C) > > my +1 for (A), (B) and (C). > > Happy hacking, > Anca > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

14 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs