Re: [xwiki-devs] What applications should we list in the "Applications" panel?

[Ecaterina Moraru (Valica)]

On Fri, Sep 7, 2012 at 1:06 PM, Jean-Vincent Drean  wrote:

> Ok so we had one :)
>

Hi,

The special CSS classes are listed at
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses
I've created also
http://platform.xwiki.org/xwiki/bin/view/DevGuide/StandardIconClasses to
describe in a more detailed manner the special icon classes and added links
from SpecialCSSClasses.
Would be nice if someone could review the content of the new page.

Thanks,
Caty


> I ended with a SSX for some other things anyway.
>
> On Thu, Sep 6, 2012 at 9:40 PM, Marius Dumitru Florea
>  wrote:
> > On Thu, Sep 6, 2012 at 12:25 PM, Jean-Vincent Drean 
> wrote:
> >> Following this discussion I committed a first version of this panel on
> master.
> >> It currently looks like this
> >> https://img.skitch.com/20120906-x37wmib93m2egqmtp1skeh7bqj.png
> >> I have a small issue with text/img alignment within the links, and I'd
> >> like not to have a SSX for this.
> >
> >> Caty do you think we could have a generic CSS class in colibri to
> >> handle this alignement (16x16px icons) ? Do we have one already ?
> >
> > Looks fine with .icon
> >
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-colibri/src/main/resources/colibri/colibri.css#L2144
> >
> > Thanks,
> > Marius
> >
> >>
> >> On Thu, Jul 5, 2012 at 4:01 PM, Ecaterina Moraru (Valica)
> >>  wrote:
> >>> Hi,
> >>>
> >>> For the 4.2 Roadmap there are several issues related to accessibility
> of
> >>> applications inside the wiki.
> >>> One of these issues is http://jira.xwiki.org/browse/XWIKI-7927"Create an
> >>> entry point for all available applications inside the wiki ".
> >>> There are multiple ways to represent such a place (panel, special
> >>> directory, gadget, etc.) but the most easy (not sure how scalable,
> >>> especially if the user will create lots of spaces using
> AppWithinMinutes)
> >>> is to use a panel.
> >>>
> >>> The problems remaining are:
> >>> - If we have a dedicated place to list applications what will remain
> in the
> >>> {{Spaces}} gadget on "Dashboard"? What we still consider to be a
> content
> >>> space? (Main, XWiki, Sandbox)? http://jira.xwiki.org/browse/XWIKI-7926or
> >>> we should still display visible spaces in it?
> >>> - What we consider to be an application? We list just spaces or even
> >>> feature pages like "Document Index" or "User Directory"?
> >>> http://jira.xwiki.org/browse/XWIKI-7925
> >>> - What about 'special' spaces like Scheduler, Stats? we let the entry
> point
> >>> to be just the Administration (at least for now)? What about Invitation
> >>> functionality? etc.
> >>>
> >>> So I've created a doodle and the question is what space/page do you
> think
> >>> we should have in this dedicated "Applications" panel:
> >>> http://www.doodle.com/uav7triciuf4kxpd
> >>>
> >>> You can use the doodle or you could respond in this main if you have
> other
> >>> suggestions or observations.
> >>>
> >>> Thanks,
> >>> Caty
> >>> ___
> >>> devs mailing list
> >>> devs@xwiki.org
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >>
> >>
> >> --
> >> Jean-Vincent Drean,
> >> XWiki.
> >> ___
> >> devs mailing list
> >> devs@xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Jean-Vincent Drean,
> XWiki.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Postpone 4.2 final release date to 24th of September 2012

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Wed, Sep 12, 2012 at 1:06 PM, Eduard Moraru  wrote:

> +1
>
> Thanks,
> Eduard
>
> On Wed, Sep 12, 2012 at 12:56 PM, Vincent Massol 
> wrote:
>
> > Hi devs,
> >
> > Current release dates for 4.2 are:
> >
> > - 4.2M3: 3 sep 2012
> > - 4.2RC1: 10 Sep 2012
> > - 4.2Final: 17 Sep 2012
> >
> > Since we're already the 12th of Sep (i.e. late by **9** days on M3) his
> is
> > obviously not going to happen… :(
> >
> > So I'd like to propose:
> >
> > - 4.2M3: 12th Sep 2012
> > - 4.2RC1: 19th Sep 2012
> > - 4.2Final: 24th Sep 2012
> >
> > Here's my +1
> >
> > Thanks
> > -Vincent
> >
> > PS: I'd like not to postpone 4.2 final by more than 1 week because it
> > means 4.3 will get shorter since we need to finish the 4.X cycle ASAP so
> > that we can start the 5.x one as close as possible to the beginning of
> next
> > year.
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Xwiki 4.1.4 - Admin-Presentation page is blank

[Ecaterina Moraru (Valica)]

The image you linked has obvious elements from the Toucan Skin. You need to
change the skin.

Regarding the URL, instead of
/xwiki/bin/admin/Main/WebPreferences?editor=spaceadmin§ion=Presentation&space=Main?skin=colibri

please put
/xwiki/bin/admin/Main/WebPreferences?editor=spaceadmin§ion=Presentation&space=Main&skin=colibri

"?skin=colibri" works if you have no parameters in the URL. If there are
already some parameters you concatenate them by using the '&'.

Thanks,
Caty


On Thu, Sep 13, 2012 at 4:49 PM, echocoder  wrote:

> I tried adding the ?skin=colibri but unfortuantely it had no effect.
> I have attached a screenshot of the Admin->Presentation page.
>
>
> /xwiki/bin/admin/Main/WebPreferences?editor=spaceadmin§ion=Presentation&space=Main?skin=colibri
>
>
> http://xwiki.475771.n2.nabble.com/file/n7581320/noskin.png
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/Xwiki-4-1-4-Admin-Presentation-page-is-blank-tp7581287p7581320.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Bug Fixing Day #6 on October 4 + BFD every first Thursday of the Month

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Tue, Sep 18, 2012 at 11:29 AM, Jean-Vincent Drean  wrote:

> +1
>
> On Tue, Sep 18, 2012 at 8:17 AM, Vincent Massol 
> wrote:
> > Hi devs and contributors,
> >
> > It's been a long since we last organized a Bug Fixing Day. I've
> published all our last results about XWiki Days at
> >
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDays
> >
> > I've also created a dashboard for listing all issues fixed during all
> our past Bug Fixing Days at
> > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11196
> >
> > Our total score is 97 issues. We can do better! Well done to Sergiu who
> has the high score by far with 49 issues fixed.
> >
> > I'd like to propose the 6th BFD since we're deriving quite a lot on our
> bug count. For the past 365 days 824 bugs were created and we solved 734
> which means we're behind by 90 bugs just for that rolling period…
> >
> > See
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1#Created-vs-Resolved-Chart/10470
> >
> > This means we're loosing the battle every day since every day more bugs
> are created than solved (our total unclosed bug count is 793, see
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1#Issue-Statistics/11088).
> >
> > What we should be doing instead is have the green line just slightly
> above the red bar on
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1#Created-vs-Resolved-Chart/10470This
>  would mean we're catching up slowly on the bug count.
> >
> > I'd like to propose the date of the **4th of October **for our sixth BFD
> and more generally I'd like to propose having a BFD every month on the
> first Thursday of every month, with the goal of reducing drastically this
> roving bug count!
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Jean-Vincent Drean,
> XWiki.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] New release date for 4.2 final

[Ecaterina Moraru (Valica)]

+1 Wednesday, 26 Sept 2012 :P

Thanks,
Caty

On Tue, Sep 25, 2012 at 1:13 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Mon, Sep 24, 2012 at 7:07 PM, Jerome Velociter 
> wrote:
> > Hello devs,
> >
> > I've volunteered (designated volunteer ;) for performing the 4.2 final
> > release.
> > It was supposed to be today, so we need to agree on a new date.
> Personnally
> > I can do it either Wednesday or Thursday (I'm taking a train on Friday,
> so I
> > will be less available). I have a preference for Wednesday.
> >
>
> > So, my +1 for Wednesday
>
> +1
>
> Thanks,
> Marius
>
> >
> > WDYT ?
> >
> > Jérôme
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Modify the ReleaseNotes page to have Release Notes for the whole platform

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Tue, Sep 25, 2012 at 1:34 PM, Eduard Moraru  wrote:

> +1
>
> Thanks,
> Eduard
>
> On Tue, Sep 25, 2012 at 1:12 AM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > +1
> >
> > Thanks,
> > Marius
> >
> > On Mon, Sep 24, 2012 at 7:54 PM, Vincent Massol 
> > wrote:
> > > Hi devs,
> > >
> > > Current situation:
> > > * on http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ we have
> > separated the RN into 2 parts: XE and XEM.
> > > * in the RN for XE we put all platform release notes, even release
> notes
> > for modules in platform that are not bundled with XE (IRC Bot for ex).
> > > * It's normal to have release notes for everything we release, not just
> > XE or XEM
> > >
> > > Proposal:
> > > * Have only a single release note page for each release (ie no more
> > specific XEM release notes + always make sure to document all releases
> > modules in the RN, not just what is bundled with XE). I propose to name
> > this "XWiki" instead of "XWiki Enterprise". So we would have "XWiki 4.3"
> > for ex.
> > > * The URL for 4.3M1 would be (for ex):
> > http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43M1
> > >
> > > I propose to do this ASAP for 4.2 final (I can do the refactoring).
> > >
> > > Here's my +1
> > >
> > > Thanks
> > > -Vincent
> > >
> > > ___
> > > devs mailing list
> > > devs@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] XWiki 4.3 Roadmap

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Fri, Sep 28, 2012 at 3:58 PM, Vincent Massol  wrote:

> Hi devs,
>
> Here's a proposal for the 4.3 roadmap. I'm putting names of committers
> I've discussed it with, please correct me if I'm wrong and please add any
> other items you'd like to do for 4.3 for committers not listed or even for
> committers listed if you want to work on other stuff! :)
>
> "Large Features"
> =
>
> - Improvements on Search Components SOLR Implementation - Assignee: Edy
> - Implementing Usability Action Plan: from Wysiwyg macros improvements,
> improvement dashboard look, Help center, XEM Usability - Assignee: JV
> - Improvements on AppWithinMinutes (according to the initial specs: user
> fields, suggests, validation, automated naming of pages, doc title + doc
> content, app generation quality) - Assignee: Marius with Sergiu for
> "automated page names"
> - Extension Manager Maintenance (testing, bug fixing, etc.) - Assignee:
> Thomas
> - Extension Manager Authentication - Assignee: Thomas
> - l10n module and especially automatic Registration of translation objects
> in wiki pages (similar to wiki macros) - Assignee: Thomas
> - Ludovic's Mobile Skin Patch - Assignee: Sergiu (if he gets the time)
> - Validating LibreOffice as standard Office Importer (brings pptx support)
> - Assignee: Sorin
>
> JIRAs:
> ==
>
> There are 3 important JIRAs that we should commit on:
>
> - Be able to rename a space from the UI (also Rename Application) -
> XWIKI-6722 -  Assignee:  ? (Sergiu maybe if he gets the time)
> - Improvements on Dashboard editing - XWIKI-7681- Assignee: JV
> - User picker (User field does not scale to 1000 users - User picker
> implementation) - Assignee: Sergiu
>
> Other important JIRAs (but no commitment):
> - tag suggest feature does not work if Main.WebHome is not saved with
> programming rights - XE-539
> - Tracking Active Installs - no JIRA yet - Vincent (I hope I can find the
> time)
> - Profile Improvements - XWIKI-6307
> - Lucene Search should not return HTML tags - XWIKI-8111
> - Search suggest does not use translation keys (Show all results... and No
> results!) Patch aleardy exists, it has to be applied - XWIKI-7138
> - PDF Export when CDATA section (generated by Livetable) - XWIKI-7871
> - App Within Minutes pages cannot be annotated (and any page using the
> HTML macro)- JIRA?
>
> Investigations:
> 
>
> - 4.x Skin. Assignee: Caty
> - Scalability Auditing. Assignee: Sorin
> - Mobile Skin + Mobile App investigation. Assignee: Ludovic
>
> Dates
> =
>
> - 4.3M1: 22 oct (3w)
> - 4.3M2: 5 nov (2w)
> - 4.3RC1: 12 nov (1w)
> - 4.3final: 19 nov (1w)
>
> Then 4.4 around beginning of January and 4.5 around beginning of February
> ==> 4.x cycle finished for early February.
>
> WDYT?
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Some thoughts about the new upgrade wizard

[Ecaterina Moraru (Valica)]

On Wed, Oct 3, 2012 at 4:18 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi Denis,
>
> On Wed, Oct 3, 2012 at 12:47 PM, Denis Gervalle  wrote:
> > Hi guys,
> >
> > I was just reading the release notes about the latest 4.2 release, and I
> > would like to share my thoughts about the new experimental upgrade
> wizard:
> >
> > 1) During the first step, I found the labels of the button "Skip" and
> > "Cancel" to be potentially misleading. I quickly make the analogy with a
> > typical application upgrade wizard on my Mac, which say "Skip this
> version"
> > or "Remind me later". But this is exactly the contrary, "Skip" here means
> > "Remind me later", and "Cancel" means "Skip this version". So I propose
> to
> > use more explicit labels, either those proposed above or any other that
> > avoid the confusion.
>
> I agree that these two buttons can be misleading, that's why I added a
> hint message in the first (welcome) step and also tool tips (on mouse
> hover) but I guess they can be easily overlooked. I'm open to change
> their labels. One of the reasons I didn't use a multi word label is
> because it doesn't look good in upper case, and that's the style we
> use on buttons..
>
>
Hi,


> Caty had a few ideas on how to replace these two buttons with
> something more intuitive but I wasn't fully convinced :) I'm sure
> she's eager to show them to you.
>

:) Proposal at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DistributionWizardActions

Thanks,
Caty


>
> >
> > 2) During the second step, the extensions that are incompatible but do
> not
> > have a potential update seems to not be listed. Once again, this could be
> > misleading, since you naturally expect the wizard to have proposed the
> > whole solution for your upgrade. I think that the wizard should also tell
> > you which extension has been disabled for incompatibilities during this
> > step.
>
> Me and Thomas talked about putting this in a separate step, the "clean
> up" step, where the user can view and uninstall extensions that are no
> longer supported (are invalid and don't have upgrades available). We
> decided to leave this steps for later since the 4.2 release was
> already delayed.
>
> >
> > WDYT ?
>
> Thanks for your feedback,
> Marius
>
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > eGuilde sarl - CTO
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Remove 'future' version in JIRA

[Ecaterina Moraru (Valica)]

So instead of 'future' the field is gonna be just empty, right?

Anyway +1, never used it.
Thanks,
Caty

On Wed, Oct 3, 2012 at 6:44 PM, Vincent Massol  wrote:

> Hi devs,
>
> It seems we've never really used the "future' version in jira. I'd like
> like to propose to remove it.
>
> The idea was that issues that had been reviewed and marked for later were
> supposed to use "future" but in practice we are not doing it.
>
> WDYT?
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] French translation for "Distribution Wizard"

[Ecaterina Moraru (Valica)]

'extension', 'install', 'downgrade', 'upgrade', 'flavour', 'remove', 'wiki'
... all these keywords have in common a 'version'.
How about "Version Wizard"? "Assistant de version" . although sounds
strange. Was just a thought.

Thanks,
Caty

On Thu, Oct 25, 2012 at 5:13 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Thu, Oct 25, 2012 at 4:22 PM, Vincent Massol 
> wrote:
> >
> > On Oct 25, 2012, at 3:04 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> >> On Thu, Oct 25, 2012 at 3:41 PM, Vincent Massol 
> wrote:
> >>>
> >>> On Oct 25, 2012, at 2:35 PM, Silvia Rusu 
> wrote:
> >>>
>  Hello,
> 
>  I'd like to get your opinion on what French translation we should use
>  for "Distribution Wizard". So far I've received the following
>  suggestions:
>  * Gestionnaire de distributions
>  * Assistant d'installation
>  * Assistant de distribution
> 
>  Do you prefer one of the above suggestions? Do you have other ideas?
>  Please reply to the present thread with your opinion.
> >>>
> >>> Actually I'm not very fond of the English wording: "Distribution
> Wizard". For a user it's hard to understand IMO.
> >>>
> >>
> >>> What about using "Install Wizard" instead and it's used both for first
> time installs and upgrades? (btw when it's upgrades, the button will be
> "upgrade" I believe, right?)
> >>
> >> "Install" is not accurate because you can do Install, Upgrade,
> >> Downgrade or (maybe later) switch flavour.
> >
>
> > Switch? What would it do and how would you call it ?
>
> Simply. The distribution manager already has the notion of "a
> different distribution" (
>
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-distribution/src/main/java/org/xwiki/extension/distribution/internal/DistributionManager.java#L47
> ) which is not the same as "same distribution but different version"
> (Upgrade/Downgrade). This can happen if you replace the
> xwiki-flavour-foo war with the xwiki-flavour-bar war, keeping the
> persistent directory (which contains the distribution status,
> installed extensions, etc.). In this case when you start XWiki the
> Distribution Manager detects the distribution change and displays the
> distribution wizard which suggests you to install the (new) UI
> associated with the new distribution (flavour) and to
> remove/upgrade/downgrade whatever extensions you may have installed
> (in order to work with the new distribution).
>
> The framework for all this is already in place. See
>
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/distribution.vm#L157
> .
>
> Thanks,
> Marius
>
> > I think switching would mean calling from the admin and in this case we
> could name it differently.
> >
> > Here's we're talking about the wizard that appears when you start your
> wiki and you've installed a new WAR.
> >
> > "Install Wizard" seems good to me for this use case.
> >
> > Or maybe we should just call it "Extension Wizard" since we don'treally
> have the terminology of "Distribution" ATM. Maybe in the future when we
> have the notion of "Flavors" we would call it "Flavor Wizard"...
> >
> > Thanks
> > -Vincent
> >
> >> Thanks,
> >> Marius
> >>
> >>>
> >>> In which case, we would have in French, "Assistant d'installation".
> >>>
> >>> The other French names are not very nice…
> >>>
> >>> Thanks
> >>> -Vincent
> >>> ___
> >>> devs mailing list
> >>> devs@xwiki.org
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >> ___
> >> devs mailing list
> >> devs@xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Merge feature-localization branch to master

[Ecaterina Moraru (Valica)]

+1
Thanks,
Caty

On Wed, Oct 31, 2012 at 5:46 PM, Thomas Mortagne
wrote:

> Hi devs,
>
> I would like to merge the
> https://github.com/xwiki/xwiki-platform/tree/feature-localization branch
> to
> master.
>
> Here is a summary of what it contains:
> * new localization module API following what described in
> http://markmail.org/message/blynasgz53ys345i
> * implementation of this API for ApplicationResources resources and
> document bundles listed in the preferences
> * implementation of this API for dynamically registered wiki document
> translations as described on http://markmail.org/message/bcmbhpwxnbagma3g
>
> Here is my +1.
>
> Thanks,
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] Bug Fixing Day #7, 1st of November

[Ecaterina Moraru (Valica)]

Hi devs and contributors,

According to a past vote we had [1] we are having a BFD every month on the
first Thursday of every month, with the goal of reducing drastically the
bug count.

This month the BFD is on 1st November, which means Today. This mail is a
reminder that today we are counting :)

As a practice: Once you close an issue (whether you fixed it or mark it
with "duplicate", "won't fix", etc) please ensure you label it with
"bugfixingday" so that we can easily count them at the end of the day.

You can see the current status of issues fixed during all our past Bug
Fixing Days at
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11196

Let's make a dent in this stat:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1#Created-vs-Resolved-Chart/10470

Thanks,
Caty of behalf of the XWiki Development Team

[1] http://markmail.org/thread/np65udilrwnuekyh
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Improved User Picker

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Thu, Nov 1, 2012 at 4:17 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi devs,
>
> I committed an improved User Picker in the
> feature-xclass-property-component branch. You can see some images on
> http://jira.xwiki.org/browse/XWIKI-4022 . I'd like to integrate it in the
> platform.
>
> Thanks,
> Marius
>
> [1]
>
> https://github.com/xwiki/xwiki-platform/compare/feature-xclass-property-component
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Vote] Use the Date Picker from AppWithinMinutes as the default picker for Date XClass properties

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Fri, Nov 2, 2012 at 10:20 AM, Jerome Velociter wrote:

> On 11/02/2012 08:09 AM, Marius Dumitru Florea wrote:
>
>> I followed Sergiu's suggestion and moved the Date displayer in a
>> template (displayer_date.vm). I'd like to merge this before 4.3M2.
>> Anyone against it? We need to have a date picker for date properties
>> by default!
>>
>
> +1
>
> Jerome
>
>
>
>> Thanks,
>> Marius
>>
>> On Wed, Oct 24, 2012 at 7:38 PM, Marius Dumitru Florea
>> >
>> wrote:
>>
>>> Here's the commit
>>> https://github.com/xwiki/**xwiki-platform/commit/**
>>> a6f4bd499fc2b1cf3757d423205a41**9315749603
>>> . The main changes are:
>>> * Move the JS/CSS of the date picker used by AppWithinMinutes into the
>>> file system (/resources/uicomponents/**widgets/datepicker).
>>> * Apply checkstyle to DateProperty and DateClass.
>>> * Modify DateClass to use the AWM date picker when the 'picker' meta
>>> property is set.
>>> * Add back the 'picker' meta property to Date property (in
>>> DateMetaClass) to allow developers to use a different picker than the
>>> default one (or no picker at all).
>>> * Use Boolean property for 'picker' and 'emptyIsToday' meta properties
>>> (was Number property). Since a Boolean property is stored as an
>>> integer property the only difference will be visually (checkbox
>>> instead of text input).
>>>
>>> I'd like to merge this into the platform. My +1.
>>>
>>> Thanks,
>>> Marius
>>>
>> __**_
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/**mailman/listinfo/devs
>>
> __**_
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/**mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Name of the localization macro name

[Ecaterina Moraru (Valica)]

How about {{translation}} ?

l10n is very cryptic  and only developers will know what it means.

Thanks,
Caty

On Fri, Nov 2, 2012 at 1:13 PM, Thomas Mortagne
wrote:

> Hi devs,
>
> Quick vote for the macro name:
> * {{l10n}}
> * {{locallization}}
>
> localization is a bit too long for a macro so I would go for "l10n".
>
> We can also decide to maintain both aliases.
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Name of the localization macro name

[Ecaterina Moraru (Valica)]

On Fri, Nov 2, 2012 at 4:03 PM, Denis Gervalle  wrote:

> If this is effectively the replacement of msg.get(), why not {{msg}} ?
> {{translate}} would be more explicit, but a bit long IMO for everyday use.
> Your proposal to have some alias could be an idea to use it with a {{tr}}
> alias.
> WDYT ?
>
>
{{msg}} is ambiguous. Can I send a message? Can I display a message with
it? it is about a message?

{{tr}} has a html equivalent which is from table-row.

I have no problem with the length of  {{translation}} / {{translate}}.
{{velocity}}, {{attachmentSelector}}, {{messageSender}}, {{documents}},
etc. are long named macros too.
I prefer it to be more explicit than ambiguous.

Thanks,
Caty



>
> On Fri, Nov 2, 2012 at 12:59 PM, Eduard Moraru 
> wrote:
>
> > Hi,
> >
> > On Fri, Nov 2, 2012 at 1:22 PM, Ecaterina Moraru (Valica) <
> > vali...@gmail.com
> > > wrote:
> >
> > > How about {{translation}} ?
> > >
> >
> > +1 for {{translation}} if the behaviour is going to be the same as we
> used
> > to do with $msg.get(...), which is to get a translation from a key.
> >
> > Thanks,
> > Eduard
> >
> >
> > > l10n is very cryptic  and only developers will know what it means.
> > >
> > > Thanks,
> > > Caty
> > >
> > > On Fri, Nov 2, 2012 at 1:13 PM, Thomas Mortagne
> > > wrote:
> > >
> > > > Hi devs,
> > > >
> > > > Quick vote for the macro name:
> > > > * {{l10n}}
> > > > * {{locallization}}
> > > >
> > > > localization is a bit too long for a macro so I would go for "l10n".
> > > >
> > > > We can also decide to maintain both aliases.
> > > >
> > > > --
> > > > Thomas Mortagne
> > > > ___
> > > > devs mailing list
> > > > devs@xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > ___
> > > devs mailing list
> > > devs@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] merge branch 'feature-solr-search' into 'master' for 4.3M2

[Ecaterina Moraru (Valica)]

+1
I've played a bit with it and looks really nice (especially the highlight
feature and the ability to filter)

Thanks,
Caty

On Mon, Nov 5, 2012 at 12:35 PM, Jerome Velociter wrote:

> Hi Edy,
>
> This is great. I've seen you've fixed the lock issue ; I have had that
> issue when working on the 4.0 branch, I will merge it there and test the
> migration. In any case I would like to continue this migration as my time
> allows. My objective is to play with the new spatial submodule (which is
> also integrated in solr as I understand) and try and contribute a "LatLon"
> XClass property type.
>
> +1 for going forward with Solr,
>
> Jerome
>
>
> On 11/05/2012 11:26 AM, Eduard Moraru wrote:
>
>> Hi devs,
>>
>> I would like your vote on merging the 'feature-solr-search' branch with
>> 'master' for 4.3M2 as planned in the Roadmap.
>>
>> Merge Notes:
>> - A first version of the Solr search is bundled by default as experimental
>> with XE, but Lucene is still the default search engine.
>> --- Lucene has been upgraded to 3.6.1 [1] and Solr has been downgraded to
>> the same (3.6.1) version in order to achieve the peaceful cohabitation
>> between the 2 search versions. If we want Solr 4.0, we need to work a bit
>> more on the Lucene search, since Lucene 4.0 comes with a considerable
>> number of refactorings.
>> - I have just noticed Jerome's feature-lucene-4.0.0-upgrade [2]
>> branch.
>> - The admin needs to use the Search Administration to switch from Lucene
>> to
>> Solr and back. (each engine has its own index)
>> - The back-end contains a SolrIndex for add/delete operations and a
>> QueryExecutor to query the index trough XWiki's Query API using the 'solr'
>> language.
>> - Indexing is only manually performed for now, from the Search
>> Administration, blocking the request until the operation is complete.
>> - Search highlighting is available
>> - The default search looks only for Documents. Filtered/Advanced search
>> options can be used to change some of the search parameters.
>> - Lucene/Solr syntax is supported in the query string
>> - Faceted search is currently hidden because it is not yet in an usable
>> state.
>> - SearchSuggest is still using Lucene, no matter what the configuration in
>> Search Administration says
>> - The merge also contains a fix for a pretty nasty yet easily fixable
>> Lucene deadlock [3] (introduced 10 months ago) and some Search Admin UI
>> improvements [4]
>>
>> The pull requests [5][6] are available for reviewing so start shooting :)
>>
>> Thanks,
>> Eduard
>>
>> --
>> [1] 
>> http://jira.xwiki.org/browse/**XWIKI-8407
>> [2]
>> https://github.com/xwiki/**xwiki-platform/tree/feature-**
>> lucene-4.0.0-upgrade
>> [3] 
>> http://jira.xwiki.org/browse/**XWIKI-8406
>> [4] 
>> http://jira.xwiki.org/browse/**XWIKI-8408
>> [5] 
>> https://github.com/xwiki/**xwiki-platform/pull/73
>> [6] 
>> https://github.com/xwiki/**xwiki-enterprise/pull/34
>> __**_
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/**mailman/listinfo/devs
>>
>
> __**_
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/**mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [UX][Proposal] Skin 4.x

[Ecaterina Moraru (Valica)]

Hi devs,

I've been working in the 4.3 Roadmap for a new skin proposal. You can see
it at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x

I recommend looking at the "Annotations Overview" gallery in order to see
the different elements of the skin and some explanations.

I've made also separate pages for different components of the skin. For
example, you can see more information about how the menus work at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenus

For each component you can also see how the elements scale and see the
responsive layout.
For the record, the proposal is made by using Bootstrap (
http://twitter.github.com/bootstrap/).

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [UX][Proposal] Skin 4.x

[Ecaterina Moraru (Valica)]

On Thu, Nov 8, 2012 at 8:54 PM, Fabio Mancinelli  wrote:

> Wow!
>
> Visually it's stunning, where do I download it :)
>
> I don't know if the side bars have to be always be present otherwise +1
>

In http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenusslide
10 to slide 21 from the Overview Gallery, I present a mechanism to
hide the AppBar and the Panels. It was intended for phones and tablets, but
we could make it also for Desktops.

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4xMenus/menusSnapshotActivators.png
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4xMenus/menusAppBarAnnotations.png
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4xMenus/menusPanelsAnnotatios.png

Thanks,
Caty



>
> -Fabio
>
>
> On Thu, Nov 8, 2012 at 5:59 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com
> > wrote:
>
> > Hi devs,
> >
> > I've been working in the 4.3 Roadmap for a new skin proposal. You can see
> > it at
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x
> >
> > I recommend looking at the "Annotations Overview" gallery in order to see
> > the different elements of the skin and some explanations.
> >
> > I've made also separate pages for different components of the skin. For
> > example, you can see more information about how the menus work at
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenus
> >
> > For each component you can also see how the elements scale and see the
> > responsive layout.
> > For the record, the proposal is made by using Bootstrap (
> > http://twitter.github.com/bootstrap/).
> >
> > Thanks,
> > Caty
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [UX][Proposal] Skin 4.x

[Ecaterina Moraru (Valica)]

On Thu, Nov 8, 2012 at 10:00 PM, Jerome Velociter wrote:

> Caty,
>
> This is great. I'm very looking forward this.
>
> Some remarks :
>
> - The skin will break the system of panels (in particular the panel
> wizard), since there is no left panel anymore. For me this is not a
> problem, we just have to agree on that.
> - I think it would be a good time to think about the introduction of a
> pre-processor like LESS to ease the customization/derivation of such a
> skin. (BTW bootstrap itself uses LESS for that purpose).
> - This will be also be a good time to re-work and generally harmonize the
> markup of some UI components.
>
> Any timeline for the implementation ?
>

The implementation could be decided for the 5.x timeline, but we need to
find a main developer to be in charge of this and really evaluate the
amount of work needed.
There are several implementation decision that needs to be voted if we
decide to go with this skin, like you said panels, menus, administration
layout, rewriting some application's layout, etc.

Regarding LESS, Bootstrap works with LESS (both server and client side) and
there is also another project that replaces LESS with Sass to work with
Bootstrap.
This is another implementation decision, since we could adopt LESS or even
Bootstrap or just make a separation of skins, by having a really
"base"/"core"/"api" skin (that in general should contain just the basis,
like typography, grids, reset, forms, etc. and that we would need to write)
and another skin on top of it (that should define the layout, skin colors
and additional styling) that could be more easily changed. We could use
LESS or just expand our velocity macros (to have more 'mixins' like
functionality) and more "ColorThemes"/"Skin" variables.

Thanks,
Caty


>
> Definitely +1
>
> Thanks,
> Jerome
>
>
> On 11/08/2012 05:59 PM, Ecaterina Moraru (Valica) wrote:
>
>> Hi devs,
>>
>> I've been working in the 4.3 Roadmap for a new skin proposal. You can see
>> it at
>> http://incubator.myxwiki.org/**xwiki/bin/view/Improvements/**Skin4x<http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x>
>>
>> I recommend looking at the "Annotations Overview" gallery in order to see
>> the different elements of the skin and some explanations.
>>
>> I've made also separate pages for different components of the skin. For
>> example, you can see more information about how the menus work at
>> http://incubator.myxwiki.org/**xwiki/bin/view/Improvements/**Skin4xMenus<http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenus>
>>
>> For each component you can also see how the elements scale and see the
>> responsive layout.
>> For the record, the proposal is made by using Bootstrap (
>> http://twitter.github.com/**bootstrap/<http://twitter.github.com/bootstrap/>
>> ).
>>
>> Thanks,
>> Caty
>> __**_
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>>
>
> __**_
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Bug Fixing Day #7, 22 November 2012 (second try)

[Ecaterina Moraru (Valica)]

Hi,

IMO the bugfixingday #7 took place, but with a very small participation. If
we want to keep the timing as a practice, than no matter of the results, we
should stick to that day regardless if someone is on holiday or the number
of fixes we have.

Thanks,
Caty

On Mon, Nov 12, 2012 at 10:43 AM, Vincent Massol  wrote:

> Hi devs,
>
> Ok BFD #7 which was planned for the 1st of November has been cancelled
> since it was a day off in France (and I was on holiday at that time so I
> couldn't follow up on it).
>
> Hence I propose to do it on Thursday the 22nd of November (i.e. in 11 days
> from now).
>
> Let me know if you can attend it.
>
> Thanks
> -Vincent
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Bug Fixing Day #7, 1st of November

[Ecaterina Moraru (Valica)]

Hi,

The results for the #bugfixingday held on 1st of November are at
http://www.xwiki.org/xwiki/bin/view/Blog/BugFixingDay+November+2012

The next BFD is planned for 6 December 2012 (first Thursday of every
month). See you then for the next 'oficial bug count'.

Thanks,
Caty


On Fri, Nov 2, 2012 at 7:52 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Fri, Nov 2, 2012 at 12:03 PM, Guillaume Lerouge 
> wrote:
> > Hi,
> >
> > we'd better do this next week. Yesterday was off in France and thus many
> > committers could not take part.
> >
>
> > WDYT?
>
> +1, I was unfortunately busy with something else..
>
> Thanks,
> Marius
>
> >
> > Guillaume
> >
> > On Thu, Nov 1, 2012 at 11:35 AM, Ecaterina Moraru (Valica) <
> > vali...@gmail.com> wrote:
> >
> >> Hi devs and contributors,
> >>
> >> According to a past vote we had [1] we are having a BFD every month on
> the
> >> first Thursday of every month, with the goal of reducing drastically the
> >> bug count.
> >>
> >> This month the BFD is on 1st November, which means Today. This mail is a
> >> reminder that today we are counting :)
> >>
> >> As a practice: Once you close an issue (whether you fixed it or mark it
> >> with "duplicate", "won't fix", etc) please ensure you label it with
> >> "bugfixingday" so that we can easily count them at the end of the day.
> >>
> >> You can see the current status of issues fixed during all our past Bug
> >> Fixing Days at
> >> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11196
> >>
> >> Let's make a dent in this stat:
> >>
> >>
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1#Created-vs-Resolved-Chart/10470
> >>
> >> Thanks,
> >> Caty of behalf of the XWiki Development Team
> >>
> >> [1] http://markmail.org/thread/np65udilrwnuekyh
> >> ___
> >> devs mailing list
> >> devs@xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Commit a Release application into platform

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Wed, Nov 21, 2012 at 11:55 AM, Vincent Massol  wrote:

> Hi devs,
>
> I'd like to rename the "Release Plans" app (
> http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/WebHome) into "Releases"
> (i.e. remove the "plan" part) and then commit in platform as an application.
>
> Here's my +1
>
> Thanks
> -Vincent
>
> PS: This action goes in the direction of creating a list of useful
> applications/extensions for a Project Development Flavor (see other mail).
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [UX][Proposal] XWiki Mobile App

[Ecaterina Moraru (Valica)]

Hi devs,

For the Mobile App Investigation, Ludovic has been playing with a XWiki
Mobile App prototype done with jQuery Mobile (http://jquerymobile.com/).
This is a proposal for a mobile application that matches the jQuery Mobile
framework capabilities and that provides minimal XWiki functionality (like
listing wikis, spaces, pages, accessing content, viewing recent activity,
etc.)

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileApp

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Roadmap for 4.4

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Wed, Nov 28, 2012 at 10:30 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Tue, Nov 27, 2012 at 7:42 PM, Vincent Massol 
> wrote:
> >
> > On Nov 27, 2012, at 6:30 PM, Jerome Velociter 
> wrote:
> >
> >> On 11/27/2012 06:26 PM, Vincent Massol wrote:
> >>> On Nov 27, 2012, at 6:12 PM, Eduard Moraru 
> wrote:
> >>>
>  It's also about New Year's Eve. A lot o people usually take time off
> during
>  that period, as you probably know, and will not be available for
> releases
>  (stabilization, bugxifing, testfixing, etc).
> 
>  IMO, we should either pick a date that is between Christmas and New
> Year's
>  Eve (though I don`t see much success in that either), or just release
>  around them, like +/- 1 week or something, that's if we don`t want to
>  promise stuff and end up delaying due to lack of people to fix release
>  issues.
> >>> That's what I've tried to do:
> >>> * M1 before christmas
> >>> * RC1 after christmas (one week after)
> >>> * Final after new year's eve (one week after)
> >>>
> >>> That was the best dates I was able to find unless we want to postpone
> by 1 month more…
> >>>
> >>> If you can think of better dates please suggest them.
> >>
> >> I agree with Eduard that between Xmas and NYE would be better than the
> 31th.
> >>
> >> If I were to be the RM, I'm would be more likely to prefer releasing
> RC1 on the 27th/28th or 29th rather than on the 31th.
> >
> > ah indeed you're right, I had missed that :)
> >
> > So new dates:
> >
> > * 4.4M1: 10th of December (in 2 week from now)
> > * 4.4RC1: 17th of December
> > * 4.4Final: 27th of December (between Xmas and NY)
>
> +1
>
> Thanks,
> Marius
>
> >
> > Thanks!
> > -Vincent
> >
> >> Jerome.
> >>
> >>>
>  Note: I am not familiar with how previous year releases around the
> holidays
>  worked out so, if, based on experience, you still consider that it's
> still
>  a good idea, please ignore my comments.
> >>> It's probably a bit chaotic but I feel it's better than postponing by
> 1 month altogether, especially since want to be able to start the 5.x cycle
> ASAP (we're all eager to start it :)) and also to slowly align it to the
> beginning of the year.
> >>>
> >>> Thanks
> >>> -Vincent
> >>>
>  Thanks,
>  Eduard
> 
> 
>  On Tue, Nov 27, 2012 at 5:59 PM, Vincent Massol 
> wrote:
> 
> > On Nov 27, 2012, at 4:38 PM, Eduard Moraru 
> wrote:
> >
> >> Hi,
> >>
> >> On Tue, Nov 27, 2012 at 9:45 AM, Vincent Massol  >
> > wrote:
> >>> Hi devs,
> >>>
> >>> 4.4 and 4.5 are the last 2 stabilization releases for the 4.x
> cycle. As
> >>> such they are meant to be short releases (1 month per release) and
> the
> > idea
> >>> is to have:
> >>> - 4.4: December
> >>> - 4.5: January
> >>>
> >>> This will allow us to start working on 5.0 at the beginning of
> February.
> >>>
> >>> Thus for 4.4 (and 4.5) I propose to work on the following
> stabilizations
> >>> (we shouldn't work on new features):
> >>>
> >>> * AWM stabilization. Assignee: Marius
> >>> ** Remove the i18n hack and use the new localization module to
> create a
> >>> translation bundle for the application
> >>> ** Add new field types (for page, image and attachment at least,
> with
> >>> pickers)
> >>> ** Improve the title and content fields (e.g. prevent dragging
> more than
> >>> one title or content field)
> >>>
> >>> * Extension Manager. Specifically we still need to able to
> > install/upgrade
> >>> a wiki farm in a few minutes. Assignee: Thomas/Marius
> >>> ** XWIKI-8252: Migration from an older version will cause many
> merge
> >>> conflicts with the Distribution Manager
> >>> ** XWIKI-8443: When uninstalling a XAR extension a question should
> be
> >>> asked for various conflict use cases
> >>> ** Find a way to allow having each wiki admin doing upgrade
> instead of
> >>> upgrading the whole farm by a farm admin which don't always know
> how to
> > fix
> >>> conflict like in myxwiki.org for example
> >>> ** XWIKI-8173 (EM should not allow installing package exposing an
> >>> installed feature)
> >>>
> >>> * Translation module stabilizations/improvements. Assignee: Thomas
> >>> ** XWIKI-8263 (Allow providing translations in a jar extension).
> >>>
> >>> * SOLR improvements: we need to continue working on it and we can
> decide
> >>> in the course of 4.4/4.5 if it's good enough to be made the default
> > search
> >>> or if we need to wait for 5.x to make it the default. Assignee: Edy
> >>>
> >>> * Usability: small usability improvements. Assignee: Caty/JV.
> Caty/JV,
> >>> could you please list what you'd like to work on?
> >>>
> >>> * Workspace bug fixes (there are some raised by Anca for example).
> >>> Assignee: Edy
> >>>
> >>> * And a lot of bug fixes. M

Re: [xwiki-devs] [UX][Proposal] XWiki Mobile App

[Ecaterina Moraru (Valica)]

On Wed, Nov 28, 2012 at 3:52 PM, Ludovic Dubost  wrote:

> Hi Cati,
>
> Great proposals that enhances the current UI. My main comments concern
> features that are not really finished in the current prototype and would
> need some help also from a design/usability perspective:
>
> 1/ Adding a page to favorites and notifications
>   -> This has not been put in the UI and would be needed
>   -> Should it be a separate favorites than the XWiki Watch List. Right now
> I don't think so because that would be yet another list and the Server wiki
> will need to know about the favorites because it
>

IMO they are 2 different things. The problem is also our auto-watch feature
that register in the watchlist any page you made modifications to them, and
you don't quite have control over it.
Favorites are an explicit action that you do in order to later quick access
that page (similar to bookmarks), while watchlist is sort of an activity
stream for your specific range of pages, that you receive in your mail. So
IMO they should be separate.

Regarding the UI, the actions are displayed at the bottom of the page
(Edit, Syntax, Sync, etc. I've put just these actions because they were
also present in the prototype)
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MobileApp/page1.png
We will need a "More" button that would reveal additional actions, like
"Watch", "Favourite", etc. (depending on what and how many other
functionality we want to have for the Mobile App).


>   -> A design for notifications and how they should show up would be great.
> I think notifications could be a general UI item and also show up on the
> home page. A notification is sent by the server to the device. The
> notification is just a message. The XWiki Application can be activated from
> the notification but will have to contact the server to know more (I'm not
> sure if you get access to the notifications that the user clicked to
> activate the App). I think a message could be just "this doc has been
> updated" or "X documents have been modified" depending on the notifications
> settings of the user).
>

Regarding the notifications UI I think our notifications widget is just
fine http://platform.xwiki.org/xwiki/bin/view/DevGuide/XWikiNotifications
(a z-index div, with a color specific color depending on the notification
type, that is visible for a temporary period)


> 2/ Adding a page/space/applications to offline documents would be needed in
> the UI and a management UI for the page/spaces/applications being in the
> offline docs
>

What is the difference between Offlice Documents, Offline Bookmarks and
Favorites?

Again I did the page actions mockup, but I was not sure what actions to put
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MobileApp/page1.png
but I imagined "Download" to represent adding the page to our Offline
Documents.
The action bar can be put to spaces, wikis, etc.


> 3/ The offline editing features should be removed for now because they are
> far from ready
> 4/ Commenting should be added in the UI
> 5/ A "share/open" button should be added which opens a popup proposing to
> share by email/twitter/open in safari/etc..
> 6/ A configuration UI would be needed to add/update configuration for a new
> Wiki. For now a simple URL would be enough + a username and password and an
> "advanced" button. A specific service will probably be built in XE/XEM to
> provide the configuration to the mobile App.  It would be possible using
> the "advanced configuration" to not need this server based configuration to
> connect to any wiki but it will be more pratical with this configuration.
> 7/ I like the Application zone design. Now it should be reusing what is
> done in the Application Panel since 4.2 (?). Now the issue is that a
> specific REST/XWiki Page service might be needed here, as right now it's
> manual configuration. Now the service used for the configuration could
> handle that.
>
>
Regarding all the new functionality (sync, offline, bookmarks, editing, web
view, etc.) I am not really sure how they fully work (since they are not
yet complete) and I also don't know what level of other functionality you
want to add (you mentioned comments, share page, add wiki, etc.). Until now
I just focused on what was available.

Thanks for your feedback,
Caty


> Ludovic
>
>
> 2012/11/28 Ecaterina Moraru (Valica) 
>
> > Hi devs,
> >
> > For the Mobile App Investigation, Ludovic has been playing with a XWiki
> > Mobile App prototype done with jQuery Mobile (http://jquerymobile.com/).
> > This is a proposal for a mobile application that matches the jQuery
> Mobile
> > framework capabilities and that provides m

Re: [xwiki-devs] [Brainstorming] Minimal supported resolution?

[Ecaterina Moraru (Valica)]

Hi,

Right now we support 980px for the width, if we go for a smaller resolution
we get horizontal scrolls. And this is Colibri case.

I think the supported resolution should be skin-based.

For example in our future skin we will want to be responsive, meaning the
skin will need to adjust to mobile/tablet resolutions. This means lowering
the minimum.

For example Bootstrap (
http://twitter.github.com/bootstrap/scaffolding.html#responsive) considers:
Phones: 480px and below
Tablets: 768px and above
Default: 980px and up
Large Display: 1200px and up


The minimal-minimal standard resolution we should say we support is 1024 x
768px (at least for Colibri and for older versions of XWiki >= 2.0 ).

The next step would be 1280 x 1024px.

Thanks,
Caty



On Tue, Dec 4, 2012 at 12:18 PM, Vincent Massol  wrote:

> Hi devs,
>
> We've agreed on the list of databases and browser we want to support but I
> couldn't find an agreement on the screen resolutions we want to support.
>
> I had in mind the 1280x1024 as the minimal resolution for laptop/desktop
> computers.
>
> Note that it's important to know this for the following reasons:
> * When we do our tests we should do them with various resolutions but
> especially with the minimum supported resolution
> * This is true for our automated tests (we run a vnc server in a given
> resolution on the jenkins agents) but also for the manual tests done by
> Sorin/Silvia/Manuel and everyone else
>
> WDYT?
>
> Once we agree I'll post the result on xwiki.org
>
> Thanks
> -Vincent
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Reminder] Bug Fixing Day #8 this Thursday 6th of December

[Ecaterina Moraru (Valica)]

Hi,

The results for the #bugfixingday #8 held on 6 November 2012 are at
http://www.xwiki.org/xwiki/bin/view/Blog/BugFixingDay+December+2012

Great job everyone for closing 43 issues (and fixing 13).

The next #bugfixingday is planned for 3rd of January 2013 (first Thursday
of every month).

Thanks,
Caty

On Mon, Dec 3, 2012 at 9:42 PM, Vincent Massol  wrote:

> Just a reminder.
>
> See
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDays
>
> Thanks
> -Vincent
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Vote] Retire Toucan Skin

[Ecaterina Moraru (Valica)]

7 +1, vote passed.

Thanks for voting,
Caty

On Fri, Dec 7, 2012 at 1:01 PM, Eduard Moraru  wrote:

> +1
>
> Thanks,
> Eduard
>
>
> On Fri, Dec 7, 2012 at 8:59 AM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > +1
> >
> > Thanks,
> > Marius
> >
> > On Thu, Dec 6, 2012 at 6:56 PM, Ecaterina Moraru (Valica)
> >  wrote:
> > > Hi Devs,
> > >
> > > Right now we are supporting 2 skins: Toucan and Colibri (default),
> > > according to http://platform.xwiki.org/xwiki/bin/view/Features/Skins
> > >
> > > According to http://xwiki.markmail.org/thread/tyceqsfdsnq2wikh Toucan
> is
> > > not maintained, but supported since Jan 2010. That's about 3 years ago.
> > >
> > > The question is what do we plan to do with Toucan skin?
> > > +1 for retire and closing all JIRA issues
> > >
> > > This means that our only supported skin will be Colibri (added in 2.0,
> > our
> > > default since Sep 2009, base skin since Dec 2010).
> > >
> > > Thanks,
> > > Caty
> > >
> > > P.S.
> > > Dodo and Finch skins were retired in Nov 2009
> > > http://markmail.org/thread/56stmwtylwglozyh
> > > Albatross skin was retired in Oct 2010
> > > http://xwiki.markmail.org/thread/jx5vyqtrwwaidfka (< 1.3 - 2.5)
> > > ___
> > > devs mailing list
> > > devs@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Create a JIRA project for the XWiki project's infrastructure

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Wed, Dec 19, 2012 at 11:18 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Wed, Dec 19, 2012 at 10:54 AM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > I'd like to create a new JIRA project for all xwiki infra. Examples of
> component that would be in this project:
> > - Jenkins
> > - Nexus
> > - myxwiki.org
> > - xwiki.org
> > - mailing lists
> >
> > I'm also proposing to change the process for creating a new wiki on
> myxwiki.org: users who want a wiki there should now open a jira request
> on this JIRA project under the "myxwiki.org" component.
> >
> > Other example: when we want to upgrade xwiki.org to a new version it
> should be in there, etc.
> >
> > Basically the idea is to account for all infra work.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] New dates for 4.4 releases

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Fri, Dec 21, 2012 at 2:47 PM, Vincent Massol  wrote:

> Hi devs,
>
> Now that the build is back on track, Marius and I would like to propose
> the following:
> * Skip releasing 4.4M1 since we're already late. (note: We need to verify
> if we have any @since 4.4M1 and replace them with @since 4.4RC1)
> * Release 4.4RC1 on next Thursday (27th)
> * Release 4.4Final on 3rd of Jan
>
> I'm proposing myself for these releases.
>
> WDYT?
>
> Here's my +1
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] XWiki 5.x cycle theme

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Thu, Jan 3, 2013 at 1:53 PM, Vincent Massol  wrote:

> Hi everyone,
>
> We're getting close to the end of the 4.x cycle (only one more release,
> 4.5, which should be out at the end of January) and thus we need to start
> thinking about 5.x
> (see
> http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices)
>
> As a reminder here are our past themes:
> * 3.x: Theme 1: "Building Apps and Distributing them" (This means for
> example that the Extension Manager in progress is a key element of XE 3.x.
> It also means making it easier to create applications in XE.), Theme 2:
> "Polishing"
> * 4.x: Theme 1 (top priority): Ease of use, Theme 2: Quality
>
> Internally at XWiki SAS we've had a brainstorming meeting with everyone to
> discuss what could be the main themes for XWiki 5.x
>
> The result is the following:
>
> Theme: Speed and Simplicity
> -
>
> Mission:
>
> Improve XWiki's usage for new and regular users by improving Usability and
> Usage Speed
> in order to make XWiki simpler and faster both from a pure performance
> point of view
> and from are user interface point of view.
>
>
> Technical details:
>
> - Individual Feature Improvement from a Usability perspective including
> speed of access (real time updates, commenting in activity stream)
> - General Usability Improvements on XE and XEM for simplicity
> - Technical Rewrite of certain features (activity stream) for performance
> or architecture reasons
> - General Performance Improvement of XWiki (page loading, rendering time)
> - Bug Fixing in general
>
> WDYT?
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] JIRA cleanup for missing fixversion

[Ecaterina Moraru (Valica)]

For the XOFFICE we could put the next release version as fixfor. The
problem is that I don't seem to have the rights to edit the closed issues.

Vincent, do you need the fixfor field marked for statistics?

Thanks,
Caty

On Mon, Jan 7, 2013 at 4:30 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> There are a lot for XOFFICE (Florin?) and XINFRA (where we don't have
> releases)
>
> Thanks,
> Marius
>
> On Thu, Dec 27, 2012 at 9:59 AM, Vincent Massol 
> wrote:
> > Hi guys,
> >
> > Can you help me fix all those issues that are missing fixfor?
> >
> >
> http://jira.xwiki.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=status+%3D+%22Closed%22+and+fixVersion+is+empty+and+category+in+%28%22Top+Level+Projects%22%29+and+resolution+%3D+%22Fixed%22
> >
> > Thanks
> > -Vincent
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?

[Ecaterina Moraru (Valica)]

Hi,

Regarding this topic what I would propose is to have an "Administer Page"
section in the menu (just like we have for Wiki and for Space).

It will contain:
* "Look & Feel"
** "Presentation" - giving the opportunity to change the style just for one
page (maybe different layout for apps' WebHomes or different ColorTheme,
etc.)
** "Page Elements" - what this mail was initially about, I will detail later
** "Panel Wizard" - we could leave it just at space level, but could be
interesting also at page lvl
* "User & Groups"
** "Rights" - this will contain what we currently have under "Edit" ->
"Access Rights"

Having the "Administer Page" it would be very easy for someone to
Add/Remove what metadata he wants to see for a certain page. Having that
section customizable is better than hiding them programmatically without
the ability of a reverse (from the UI). Comments and attachments can be
"useless" depending on the type of the page.

Having this mechanism at a page lvl it will be very easy to define the use
cases.
For example, when creating a new app by using the AppWithinMinutes, in the
wizard we could ask the user if he wants his app pages to have "Comments",
"Attachments", "History", "Info", etc. functionality displayed by default.
He could select if he wants this features to be enabled/disabled for "All
Pages" or just for the "App's WebHome".

Like Sergiu said we could disable these features for technical pages. Right
now in XWiki we don't have the concept of technical page and this is rather
implemented with the Hidden mechanism.
Anyway our hidden/technical pages are in fact application pages. The
example Sergiu described is about the Tags app. Also User Directory,
Scheduler, Share by email, etc. are apps.
Accordingly to the example I gave we could consider SOME default XWiki apps
not to have the "Attachment", "Comments" functionality. Of course we will
have exceptions and these will be content applications like Blog, User
Profile, etc.

Depending on how we see the wrapping at a user mental model, we could
consider "User Directory" page to be the "Users" app homepage, where "User
Profile" entries are entries in this app. In this use case the homepage
could have the "Comments", "Attachments" functionality disabled, while the
rest of the pages have it enabled.

So from a technical point of view we have:
- "Page elements" at a wiki lvl
- "Page elements" at a space lvl (app lvl)
- "Page elements" at a page lvl (app's wehbome) that overrides the former
with some initial values for our default apps and with the ability for the
user to customize what we wants depending on what application he is
building.

Regarding the logic behind hidding/showing the "Comments", "Attachments"
functionality for our default apps this depends on questions like:
- is this app an internal app or these pages can be seen by users?
- does this app allows attachments?
- the content of this page is static or dynamic? should the user
improve/comment on the content of this page?
- etc.

Thanks,
Caty


On Sun, Jan 20, 2013 at 9:48 PM, Vincent Massol  wrote:

>
> On Jan 20, 2013, at 6:54 PM, Sergiu Dumitriu  wrote:
>
> > On 01/20/2013 11:31 AM, Vincent Massol wrote:
> >>
> >> On Jan 20, 2013, at 5:22 PM, Sergiu Dumitriu  wrote:
> >>
> >>> Hi devs,
> >>>
> >>> For content pages, the bottom tabs (comments, attachments, history,
> >>> information) are very useful features. But does it make sense to keep
> >>> those active for very technical pages?
> >>>
> >>> For example, when viewing details about a tag, (Main/Tags?do=viewTag),
> >>> why should people be allowed to comment? They might wrongly think that
> >>> they're commenting on a tag, but that's just one complex page that
> >>> handles almost everything about tags, so a comment like "this tag has a
> >>> typo" doesn't help at all.
> >>>
> >>> Other pages should have no bottom tabs as well: user directory, blog
> >>> category management, the whole scheduler space, share by email...
> >>>
> >>> While the homepage is a technical page (by default), it does make sense
> >>> to leave the comments active, since it's the entry point for every user
> >>> (although I think that the messaging system is a better way to send
> >>> global messages).
> >>>
> >>>
> >>> IMO, the advantage is that we're hiding actions that are rarely useful,
> >>> but could be misused. The disadvantage is that we're breaking the
> >>> universality of the UI.
> >>>
> >>> I'm +1 for hiding, fewer mis-usable features is always better.
> >>
> >> What if admins want to leave comments on a tech page modified by
> another admin to ask some question for example?
> >
> > Sending a message to another admin should be done by... sending a
> > message, not by commenting. A direct message will reach a user faster
> > than hoping that the target user will stumble upon the page and read the
> > comment.
>
> If you're saying that comments are useless then we should remove comments…
> :)
>
> >> Said differently, shouldn't bottom tabs (comme

Re: [xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?

[Ecaterina Moraru (Valica)]

On Wed, Jan 23, 2013 at 8:20 AM, Sergiu Dumitriu  wrote:

> On 01/20/2013 02:48 PM, Vincent Massol wrote:
> >
> > On Jan 20, 2013, at 6:54 PM, Sergiu Dumitriu  wrote:
> >
> >> On 01/20/2013 11:31 AM, Vincent Massol wrote:
> >>>
> >>> On Jan 20, 2013, at 5:22 PM, Sergiu Dumitriu  wrote:
> >>>
>  Hi devs,
> 
>  For content pages, the bottom tabs (comments, attachments, history,
>  information) are very useful features. But does it make sense to keep
>  those active for very technical pages?
> 
>  For example, when viewing details about a tag, (Main/Tags?do=viewTag),
>  why should people be allowed to comment? They might wrongly think that
>  they're commenting on a tag, but that's just one complex page that
>  handles almost everything about tags, so a comment like "this tag has
> a
>  typo" doesn't help at all.
> 
>  Other pages should have no bottom tabs as well: user directory, blog
>  category management, the whole scheduler space, share by email...
> 
>  While the homepage is a technical page (by default), it does make
> sense
>  to leave the comments active, since it's the entry point for every
> user
>  (although I think that the messaging system is a better way to send
>  global messages).
> 
> 
>  IMO, the advantage is that we're hiding actions that are rarely
> useful,
>  but could be misused. The disadvantage is that we're breaking the
>  universality of the UI.
> 
>  I'm +1 for hiding, fewer mis-usable features is always better.
> >>>
> >>> What if admins want to leave comments on a tech page modified by
> another admin to ask some question for example?
> >>
> >> Sending a message to another admin should be done by... sending a
> >> message, not by commenting. A direct message will reach a user faster
> >> than hoping that the target user will stumble upon the page and read the
> >> comment.
> >
> > If you're saying that comments are useless then we should remove
> comments… :)
> >
> >>> Said differently, shouldn't bottom tabs (comments, attachments, etc)
> be visible to admins for example? This could be achieved by only giving
> view rights to non admins by default on tech pages.
> >>
> >> Tech pages aren't supposed to be viewed only by admins. They're useful
> >> pages for every user, so they should be visible (view tag cloud, view
> >> documents tagged with a specific tag, view the list of users, browse
> >> blog categories...). And not having view right doesn't mean that the
> >> bottom tabs will be hidden. Just the "add comment", "add attachment"
> >> actions will be unavailable.
> >
> > ok my bad, I meant edit/comment rights, not view rights.
> >
> >> And even if adding is disabled, but why should this information be
> >> visible to any user at all? Forbidding edit still means that a user
> >> wanting to see which pages are tagged with "needsreview" will see a "Hey
> >> John, could we have an undo to tag renaming?" comment. What would you
> >> think if you saw that?
> >
> > Again if your point is that comments are useless then we should remove
> comments. I think there's a place for comments but it seems your discussion
> is actually asking us to define more precisely what is the use case/need
> for comments.
> >
> > Also I think there's a difference between a Tag Dashboard page which is
> a technical page but for end users and a technical page not for end users
> (i.e. hidden page). Both will need different solutions I think. So this
> proposal should address both needs.
> >
> >>> Another use case: imagine I'm an admin and I want to modify a tech
> page and I'd like to add an attachment to that page… IMO bottom tabs are
> still useful for admins on tech pages.
> >>
> >> This isn't about disabling attachments and comments. The bottom tabs are
> >> almost an _invitation_ to do stuff. Without them, it is still possible
> >> to go to the attachments page by clicking on the "Attachments (0)" link
> >> below the title. De-contextualizing these actions will reduce the risk
> >> of associating a comment/attachment with a particular view of the
> >> scripted page.
> >
> > If the bottom tabs are removed then those links will also need to be
> removed obviously since otherwise a user can click on them...
> >
> >>> IMO the issue is different. If a tech is not supposed to be modified
> by the user then users should have only view rights on the page and NOT
> edit rights. This will solve this issue.
> >>
> >> It's not just about changing, but also about what's visible on the
> >> screen, and the usefulness of such information vs. the number of WTFs
> >> generated.
> >
> > I don't see any WTF. For me any page that is a end user visible page can
> have comments without any WTF. For example on the tag dashboard page,
> someone may comment and say "how do I get the tag dashboard to display
> xxx?" or anything else in just the same way it's done on any other page.
> >
> > In addition I'm actually finding t

Re: [xwiki-devs] [VOTE] Have less [VOTE]s

[Ecaterina Moraru (Valica)]

On Thu, Jan 24, 2013 at 10:37 AM, Vincent Massol  wrote:

> Hi Sergiu,
>
> Indeed it's a good thing to review our voting practices and more generally
> see if we're using them the right way.
>
> Sometimes we use VOTEs when we should use PROPOSAL or DISCUSSION instead
> and possibly the other way around.
>
> I've looked at our latest VOTEs and PROPOSALs. Here they are:
>
> 1 [VOTE] Have less [VOTE]s - Sergiu, 23 jan
> 2 [VOTE] Separate the power of Veto from -1 votes - Sergiu, 23 jan
> 3 [VOTE] Reduce garbage in the log generated when a migration fails -
> Denis, 22 jan
> 4 [VOTE] Add CLIRR exclude for 1 new method in DataMigrationManager
> interface for 4.4.1 and 4.5M1 - Denis, 22 jan
> 5 [VOTE] Start using proper version in branches - Vincent, 21 jan
> 6 [VOTE] Restrict the location of skin resources inside Jars for security
> - Sergiu, 12 jan
> 7 [VOTE] ASM 3.x vs 4.x choice - 7 jan, Vincent, 7 jan
> 8 [VOTE] Merge new Markdown branch from Guillaume Laforge, Vincent, 2 jan
> 9 [VOTE] New dates for 4.4 releases, Vincent, 21 dec
> 10 [VOTE] Skip tests while building a release, Edy, 19 dec
> 11 [VOTE] Start using Mockito instead of JMock, Vincent, 8 dec
> 12 [VOTE] Make UTF-8 mandatory for a valid installation, Sergiu, 7 dec
> 13 [Vote] Retire Toucan Skin, Caty, 6 dec
> 14 [VOTE] Stop shading Rendering Standalone, Vincent, 4 dec
> 15 [VOTE] Move all lucene plugin classes to internal, Jerome, 28 nov
> 16 [VOTE] Commit a Release application into platform, 21 nov
> 17 [VOTE] Retire old query plugin, Thomas, 16 nov
>
> Let's see which of these should we have not sent as VOTEs
>
> VOTEs that I consider absolutely legit: 1, 2, 8, 9, 11, 12, 13, 14, 15,
> 16, 17
> VOTEs that are ok but could be sent as PROPOSAL or DISCUSSION instead: 3,
> 5, 6, 7, 10
>
> Now that leaves VOTE number 4. In our practices we have only a few rules
> regarding the need to VOTE:
> * Adding a new committer
> * Removing a committer
> * Breaking an API without making it legacy
>
> I really think we need to be careful when adding or removing APIs because
> they impact us all as they are extremely hard to change since we're a dev
> platform.
>
> The reason we VOTEd the need to VOTE is because we didn't want to have
> some API changes (especially API breaking) slipping by by mistake.
>
> I'm personally fine to change the VOTE in favor of a Proposal or even
> better a Notice.
>
> More generally speaking I think we could structure our email threads like
> this:
> * [VOTE]: important, others are forced to answer so to be used when needed
> only and not for asking questions when you're not sure about something
> * [PROPOSAL] or [DISCUSSION] or [BRAINSTORMING]: something quite important
> that you wish to discuss with others because there might be different
> possibilities and you wish to have opinion of others if they're free to
> help out
> * [NOTICE]: just telling others about something you're doing just so that
> they know about it. You're not expecting an answer.
>
>
+1 for voting only on the really important matters and to refine more our
mails threads in concordance with above classification.

Maybe we abused a bit the voting system, but being remote we need a way to
properly communicate and ask for feedback/validation/ideas on what we are
doing.

Thanks,
Caty



> FTR here are the last proposals we sent:
>
> * [Discussion] Should technical pages hide the bottom tabs?, Sergiu, 20 jan
> * [Proposal] Add CLA for contributions + Foundation, Vincent, 17 jan
> * [Proposal] Release XWiki 4.4.1 Monday 21, Vincent, 17 jan
> * [PROPOSAL] How to translate logs, Thomas, 16 jan
> * [proposal] 2 new xwiki-contrib projects., Caleb, 8 jan
> * [Proposal] XWiki 5.x cycle theme, Vincent, 3 jan
> * [Proposal] Use the XWiki.org JIRA project more, Vincent, 31 dec
> * FOSDEM talk proposal: "Coping with the proliferation of tools within
> your community", Sergiu, 21 dec
> * [Proposal] Create a JIRA project for the XWiki project's infrastructure,
> Vincent, 19 dec
> * [Proposal] Jenkins emails configuration, Vincent, 19 dec
> * References Section update proposal, Benjamin, 18 dec
> * [Proposal] Stopping the 4.4M1 release till tests are all passing -
> Commando mode, Vincent, 13 dec
> * [Proposal] XWiki 4.5 Roadmap dates and 4.x end of cycle, Vincent, 7 dec
> * [Proposal] Remove old info boxes/warnings for XWiki 1.x and 2.x,
> Vincent, 4 dec
> * [PROPOSAL] Include require.js in XWiki by default and make jQuery
> available through require.js., Caleb, 30 nov
> * [UX][Proposal] XWiki Mobile App, Caty, 28 nov
> * [Proposal] Roadmap for 4.4, Vincent, 26 nov
> * [DISCUSSION] Handling document translations in Solr Search, Edy, 19 nov
>
> Now what I think is working very well in our community, much better than
> in most Apache project (I've also been an Apache Member for over 10 years
> and been following lots of mailing lists there) is that we're having good
> discussions between us on the list, which allows us to share code and be
> responsible for the overall codebase. I

Re: [xwiki-devs] [VOTE] Separate the power of Veto from -1 votes

[Ecaterina Moraru (Valica)]

On Wed, Jan 23, 2013 at 8:53 PM, Sergiu Dumitriu  wrote:

> Short story:
>
> A Veto carries a lot of power [1], and it brings imbalance to a
> supposedly democratic process. For normal votes, especially those that
> ask for opinions, not for validation of a critical decision, a -1 should
> count as a normal vote. In this case, an actual Veto should be marked as
> such. Proposals:
>
>
A. Keep -1 as a Veto, but require the voter to really justify the veto
> with technical reasons. If the vetoer fails to convince other of his
> reasons, and the majority still agrees with the proposal, then the veto
> can be discarded, and the vote passes.
>
> B. Separate -1 from Veto. A -1, by default, counts just as a vote
> against the proposal, and the majority will rule. An actual Veto must be
> marked as such, but the vetoer must bring very good reasons for the veto.
>

IMO this separation is already done by '-0' and '-1'. I've seen that in [1]
we don't mention what '-0' means but we've used a lot in the past and you
explained it very well in an example below. Also from what I remember,
every time someone votes '-' he explained why he did that. True that maybe
we used more '-1' instead of using '-0' but we could change this by
explaining their purpose more.


>
> C. Just keep things as they are now, since you think that the current
> process has worked well so far, and nobody abused the right to veto.
>

I don't have any problems with the way we held our votes until now, but I
didn't submitted many votes.


>
>
> Long story:
>
> The right to Veto a VOTE means that just one participant can block a
> whole vote, even though the vast majority thinks otherwise. This is a
> very powerful right, and I for one tried to avoid using it as much as
> possible: in general I use -0 for solutions that I don't particularly
> like, but for which I don't have an actual better solution, or an
> universally acceptable reason that can convince everybody else of my
> decision.
>
> It makes sense to have the Veto power, as a way to spotlight serious
> problems with a proposal. The expected outcome in this situation is for
> the vote sender to understand and accept the outcome, and go back to
> redesigning the proposed solution, fixing the problems exposed.
>
> But when votes are just about opinions, and about choosing the version
> that most people like, it is hard to say that one opinion is more
> important than others and it can rightly prevent reaching a conclusion.
> This is particularly true about UI design and UX, but also about voting
> on processes and rules.
>
> One possible outcome is that votes (and the proposals being voted) get
> deadlocked, blocking progress. The rules say that the proponent should
> review and change the proposal and restart the vote. Sometimes the
> effort put into the original proposal is considered big enough, and if
> the vetoer failed to convince the proponent of the problems, there won't
> be any more work put into the proposal, and it will just die. I'm not
> saying that this happens too often, but it does from time to time, at
> least for me.
>
>
> So, I think that the Veto power should be used sparingly. I see two
> options:
>
> A. Keep -1 as a Veto, but require the voter to really justify the veto
> with technical reasons. Currently, the rules say that the vote sender
> must try to convince the vetoer about the rationale of the voted
> proposal. It should also be the other way around: if the majority agrees
> with the proposal, the vetoer should try to convince the others why the
> proposal is bad. If the vetoer fails to do that, and the majority still
> agrees with the proposal, then the veto can be discarded.
>
> B. Separate -1 from Veto. A -1, by default, counts just as a vote
> against, and the majority will rule. -1 keeps its power as a strong
> opinion against the proposal, and it should be justified and the voter
> should try to convince others why the proposal is bad. A -1 can still
> influence other voters and can change the outcome when the concerns
> raised in the motivation for the -1 are accepted as valid. We can put
> more weight into the -1, so for example a vote passes if (2*-1s) + (+1s)
> > 0, or (-1s) + (+1s) > 3, or another balanced variation. An actual Veto
> must be marked as such, but the vetoer must bring very good reasons for it.
>

The balance might work if we were much more committers. Right now if a vote
has 8+ voters is a popular vote (usually we have 5 people voting). In a 5
people's vote, having a -1 states that there is a 20% disagreement. IMO
that's a lot.

So I think that '+1', '+0', '-0', '-1' works very well for us and we should
just update the documentation to explain it better.

Thanks,
Caty


>
> I'm +1 for either proposal, leaning towards 2, since it's clearer when a
> vote can be passed or not. To offer the other alternative:
>
> C. Just keep things as they are now, since you think that the current
> process has worked well so far, and nobody abused the right to

Re: [xwiki-devs] [UX][Proposal] Skin 4.x

[Ecaterina Moraru (Valica)]

On Tue, Jan 29, 2013 at 12:40 PM, Denis Gervalle  wrote:

> Hi Caty,
>

Hi,


>
> I am currently making a fast adaptation of the current stable version
> (4.4.1) to a responsive skin based on bootstrap. I do not intend to
> implement your proposal in full, since I would like to minimize required
> changes to the current skin as much as possible. For example, I do not want
> to break the current panel behavior or menu organisation. I do not expect
> to have time to refine all the details or the mobile version really. But I
> am inspiring a lot on your work :)
>
> I have some questions, remarks:
>
>  1) Where are the following ? (some may be useless and my view biased by
> the fact that I adapt the current skin)
> a) the import from office menu item,
>

Could be placed here
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4x/homepageDesktopSnapshotAnnotationsMenu5.png
but I would prefer to have that entry in the menu, only if the office
server is on http://jira.xwiki.org/browse/XWIKI-8762


> b) the user network item,
> c) the user dashboard,
> d) the workgroup menu,
>

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4x/profileDesktopSnapshot.png


> e) the log in item
>

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4xLogin/loginDesktopLandscape.png
Near the Register


> f) the languages for multilingual wiki
>

Haven't integrated this yet, but could be near the Profile entry
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4x/homepageDesktopSnapshotAnnotationsMenu7.png
and the languages could be diplayed in a select, instead of a list.


> g) the annotation button
>

Haven't integrated this either, IMO in a refined version the annotation
functionality would move down with the comments.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4x/pageExample3DesktopSnapshotCommentsAnnotations.png


> h) the section edit button
>

Not represented..
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4x/pageExample1DesktopSnapshot.png
Just like it is now, near the section's title.



> i) the tags
> j) the creation date and author
> k) the footer
>

In a refined version, I would combine all this information: creation,
parents, childs, tags inside the Information Tab
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4x/pageExample3DesktopSnapshotCommentsAnnotations.png


>
>  2) On site were the wiki aspect is not exposed to visitors, we used to
> hide the main menu. I do not know if I am alone doing so, but we usually
> have separate navigation bar in the header, next or below the logo and the
> search box. With this new way to go, hiding the main menu will also hide
> the logo and the search box. I would probably like to build my navigation
> bar under that main menu, but this will not look nice for user with editing
> power to have both, and doubling the search box will cause some technical
> issue. I can think of a mixup, but the room is missing for having a single
> bar. WDYT ?
>

If you want to hide some functionality, you can only hide what you don't
need and show the rest, something like:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin4xLogin/loginTabletPortrait.png

Thanks,
Caty


>
> Regards,
>
>
>
> On Thu, Nov 8, 2012 at 5:59 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com
> > wrote:
>
> > Hi devs,
> >
> > I've been working in the 4.3 Roadmap for a new skin proposal. You can see
> > it at
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x
> >
> > I recommend looking at the "Annotations Overview" gallery in order to see
> > the different elements of the skin and some explanations.
> >
> > I've made also separate pages for different components of the skin. For
> > example, you can see more information about how the menus work at
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenus
> >
> > For each component you can also see how the elements scale and see the
> > responsive layout.
> > For the record, the proposal is made by using Bootstrap (
> > http://twitter.github.com/bootstrap/).
> >
> > Thanks,
> > Caty
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

[Ecaterina Moraru (Valica)]

Hi Denis,

When we discussed the Vertical Forms Standard [1] Thomas mentioned
something about "commons tools to follow that standard (like form related
wiki macros for example)". Some considered that having macros for standard
HTML controls will just duplicate HTML language.

One advantage of having such macros would be that for example (let's say
the macros will be defined in macros.vm) if you want to change the classes
used by the controls (like .buttonwrapper class for example), you are just
changing the macros, not all the places that call them.

This way you could easily change what classes you assign to a button for
example from span.buttonwrapper input.button.secondary to
button.btn.btn-primary (bootstrap way - of course we will also need to
standardize the usage component: input, button, a, etc.)

The example above refers mostly to standard HTML elements. Of course if you
want to use other types of components from different frameworks you will
need to rewrite the templates, and this always calls for a new skin.

I thought about new skins for XWiki and since I joined the project we
mostly deprecated old skins than creating new ones. But one problem I have
is the concept of base skin. For me the base skin should be something very
minimal.
It should contain just the typography, standard controls, the grid, the
reset, anyway elements that are not layout dependent and that will work for
any skin. I'm not sure about templates, because mostly templates refer to
layout and how you arrange things and what functionality you reveal and
where, and this usually change with a new skin. Technical the base skin
should contain the Standard, the base for things that will remain the same
no matter what. Right now Colibri covers much more than that.

And this standard is absolutely necessary also for the way we go with
extensions. We know very well that in an Open Source project, everybody
codes with his own style and having a common ground is essential from a
consistency point of view. All the applications that will be created and
published by the community members should have a common style that could
make them integrate well inside XWiki, no matter of the creator.

So the conclusion is that for this we will need a very well documented
standard and the tools to enforce it. Not sure what this means.

Also other things worth discussing is colorthemes variables and macros
against LESS variables and mixins.
Also the Bootstrap / LESS is also a direction bet, just like Prototype vs.
JQuery, and the solution we pick it would be great if it would be loosely
coupled.

Thanks,
Caty

P.S. Another discussion somehow related to extensibility is [Discussion]
Problematic ColorTheme extensibility
http://markmail.org/thread/ex6fgou6fl6vjwfr

[1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms


On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle  wrote:

> Hi Devs,
>
> As you may have noted from a previous mail, I have given a try to skin
> XWiki differently, based on Bootstrap. There is certainly many ways to get
> it done, but IMO, building over any pre-made css solution requires an
> adaptation of the HTML generated.
>
> In the early days of XWiki, the were few places were we have HTML
> generated. Most of the html produce came from three major places:
> 1) .vm templates including macros.vm
> 2) java generated (#display())
> 3) XWiki tech document
>
> While 2) and 3) either provide very basic markup or customizable one and
> are not so much, and 1) was fully customizable by skins, to work out a new
> skin was not too complex.
>
> Today however, the UI of XWiki has considerably increase its complexity,
> and the source of HTML has followed, added to the above 3:
>  4) XWiki and Java macros
>  5) JavaScript (ie: annotation UI, comments preview)
>
> Changing all these places has become really more painful. There is no
> central place, and a lot of hidden dependencies between UI components
> exists. Worse examples are those written in JS, that hook into the UI.
>
> I should admit that I have not a clear idea of the best way to improve
> that, but my feeling is that changing so much places simply to adapt our
> wiki skin to the "a la mode" skin solution (something that will happen
> again) is not nice.
>
> So this thread is now open for anyone to discuss the situation and for
> anyone interested to provide its input to the discussion.
>
> Looking at what I face building the UI with bootstrap, here is what I
> noticed:
>
> 1) Bootstrap customize standard tags, without any css class associated
> 2) Bootstrap provide standard css classes to skin a given kind of UI
> component
> 3) Bootstrap use these class and custom attribute to inject JS
> interactivity
>
> All these are really clean methods and work really well at building very
> simple html construct while providing nice looking and easy interface.
>
> Let's take a concrete example, to build a button, you may use either an a
> tag, an input tag, a button tag or whatever, 

Re: [xwiki-devs] [Brainstorming] Choose a name for our next skin

[Ecaterina Moraru (Valica)]

Hi Denis,

I just want to remember some proposals from the Skin 2.0 votes
http://markmail.org/message/gvxgks67a6q6qhmw

The second most voted name was:
Heron

Anyway, I want also to propose:
Starling
Junco
Oriole
Ibis

>From what is already proposed (names that sound clean and simple):
Jacana
Condor
Flamingo

Thanks,
Caty

On Fri, Feb 1, 2013 at 12:36 PM, Ludovic Dubost  wrote:

> I think it will be an "elegant" skin so Flamingo gets my vote
>
> Ludovic
>
>
> 2013/2/1 Guillaume Lerouge 
>
> > Hi,
> >
> > I like cockatoo very much :-)
> >
> > Guillaume
> >
> > On Fri, Feb 1, 2013 at 9:52 AM, Denis Gervalle  wrote:
> >
> > > Hi devs,
> > >
> > > Cathy has made a great proposal for a new skin based on bootstrap which
> > she
> > > call skin 4.x (
> > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x), the
> > name
> > > is already a bit outdated, and it will be in fact our 5th generation
> > skin.
> > >
> > > So after dodo -> albatross -> toucan -> colibri -> what next ?
> > >
> > > Here are some proposals:
> > > Flamingo
> > > Pelican
> > > Falcon
> > > Buzzard
> > > Eagle
> > > Bustard
> > > Trumpeter
> > > Buttonquail
> > > Jacana
> > > Gotwit
> > > Guillemot
> > > Cockatoo
> > > Cuckoo
> > > Condor
> > >
> > > feel free to propose others...
> > >
> > > Currently, my own preference is Condor which is an endangered species
> > like
> > > the Albatross, but Guillemot or Buttonquail sounds good to me as well.
> > >
> > > WDYT ?
> > >
> > >
> > > --
> > > Denis Gervalle
> > > SOFTEC sa - CEO
> > > eGuilde sarl - CTO
> > > ___
> > > devs mailing list
> > > devs@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] FOSDEM Feedback

[Ecaterina Moraru (Valica)]

Hi Ludo,

Thank for your notes on the FOSDEM talks. Would be great to have the slides
presented and also I'm gonna link the presentations' pages because I guess
they will show the recordings when the videos are gonna be made available:
Coping with the proliferation of tools within your community
https://fosdem.org/2013/schedule/event/coping_with_the_proliferation/
Combining Open Source ethics with private interests
https://fosdem.org/2013/schedule/event/combining_open_source_ethics/

Our strength is our extensibility and making it more easy to create,
collaborate and distribute extensions inside and with XWiki will be a great
thing.

Thanks,
Caty

On Mon, Feb 4, 2013 at 1:54 PM, Ludovic Dubost  wrote:

> Hi,
>
> We were 9 xwikiers at FOSDEM this week-end and I wanted to take the
> occasion to give some feedback on what I saw there.
>
> The Community Dev Room
> -
>
> First XWikiers participated in the devroom co-organized by Sergiu:
> "Community Development and Marketing". The great news is that the room was
> full quite a big amount of the time. It was not a huge room but well placed
> (in the "original" area of FOSDEM which is still quite active). I think it
> shows more and more interest of people for this subjects which are less
> usual at FOSDEM which is very technological. Kudos to Sergiu for
> co-organizing this dev room. There was also a keynote from Kohsuke
> Kawaguchi (creator of jenkins) on how the jenkins community was build which
> was on a similar subject as the dev room (I'll give some feedback on the
> talk below).
>
> Sergiu has a presentation about "how to cope with a proliferation of tools
> in your community" which presented how XWiki can be used to be a portal to
> all the contents of all the tools you have in your community (aka "the dev
> flavor). The content of the talk was great but  to my taste it was really
> missing screenshots to show practically what happens. There was a mini demo
> at the end but it was not enough to really make people realize how great
> xwiki.org is :) But the idea of the presentation is great and if we can
> spend a bit of time to not necessarly make the flavor, but publish the
> different pieces of xwiki.org as extensions, including some simple macros
> we are using (like how we integrate nabble). There was the 1M$ question of
> if we can migrate existing wikis to which we could have answered a bit
> better as we do have a few migrators for some specific wikis (Mediawiki,
> dokuwiki) but nothing fully done and fully generic. This is another area
> were we could spend some time making some specific migrators easier to use.
> If there are any contributors that would like to help out improving and
> publishing the migrators and "dev extensions" on extension.xwiki.org as
> well as document how other communities could use our tools, it would be
> very useful to help spread the XWiki work out there. Sergiu should publish
> his slides and maybe somebody can improve them with screenshots.
>
> Vincent and myself had a "devil (business) and angel (open source)"
> presentation on "Combining Open Source ethics with private interests". 20
> minutes was a bit short to cover this subject fully in details but it was
> great to be able to share our experience on this. The room was quite full
> when we did this presentation and there were a few questions which I
> believe showed the interest of participants with this subject. Vincent will
> publish the slides although it's not easy to follow without the additional
> "talking". We should definitively try to do this again.
>
> MySQL and Security
> --
>
> I attended a few MySQL presentations as well as some security
> presentations. There seems to be some interesting improvements in InnoDB in
> MySQL 5.5 and 5.6 (currently RC) and even MariaDB and Percona have some
> work that improve InnoDB (with XTraDB). As we are planning to work on
> performance we should look into testing how XWiki behaves on MySQL 5.1 to
> 5.6 and compare the performance also with Postgres. In any case we should
> follow what is happening in this area. On security there was a presentation
> about OWASP ZAP (
> https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) and attack
> proxy to test the security of Web Applications. This is something to look
> at for the Thomas D's coming work on security.
>
> Kohshuke presentation on Jenkins community
> ---
>
> On the "community" subject there was interesting presentations about "how
> to cope with assholes in your community" and the presentation of Kohshuke.
> To summarize very quickly while Kohshuke says part of the big reasons why
> jenkins has been succesful is "good software" and "being there at the right
> time" he would like to believe that the way the community is run and the
> software is architectured has a lot to do with this success. Some important
> items:
>
> 

Re: [xwiki-devs] [Proposal] Roadmap for XWiki 5.0

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Mon, Feb 4, 2013 at 1:25 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Sat, Feb 2, 2013 at 4:56 PM, Vincent Massol  wrote:
> > Hi devs,
> >
> > With XWiki 4.x cycle coming to an end soon, it's time to prepare the
> roadmap for XWiki 5.0.
> >
> > This is a proposal that comes from some internal meetings done with
> XWiki committers who are working for XWiki SAS.
> >
> > If you're interesting in participating to this release, don't hesitate
> to add yourself to the list so that everyone can have some visibility of
> what's going to be worked on during this timeframe!
> >
> > If you think some work defined below doesn't go in the interest of the
> project also feel free to raise issues.
> >
> > Features:
> >
> > * Continue SOLR implementation - Edy
> > * EM upgrade of subwikis + flavor concept (add Flavor type in
> EM/Repository)  + leftover from 4.x for EM/DW - Thomas + Marius for DW UI
> part for flavors
> > * AWM work from 4.x to finish (see
> http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome) - Marius
> > * scalable import/export - Thomas
> > * Home page improvements (XE) and usability improvements in general - JV
> > * Horizontal Menu management (add, remove pages) - JV
> > * virtual=1 by default - Edy (Edy will need to make a proposal for that
> since it's an important decision ;))
> > * l10n speed improvements - Ludovic
> >
> > Important JIRAs sorted by priority (most important first):
> >
> > * AWM Add the ability to publish an application as an extension
> XWIKI-7377 - Marius
> > * AWM Add the ability to export an application  XWIKI-7376 - Marius
> > * Unable to edit a page using the WYGIWYG editor after adding a
> dashboard macro to it   XWIKI-8495 - Need volunteer
> > * Improve AWM for it to deal with error messages made by Client when
> filling the AWM form in using special charsXWIKI-8763 - Marius
> > * Import of Office file breaks Activity Stream and Recently Modified
> Panel  XRENDERING-261 - Need volunteer
> > * Cannot change document title from "inline" mode   XWIKI-7905 - Not
> sure if we want it, to be checked with Marius
> > * When the workspace owner is changed, the new owner is not added as a
> member nor in the admin groupXWIKI-8397 - Edy
> > * Unable to upload a new attachment using the "All pages" tab in the
> WYSIWYG editor XWIKI-8465 - Marius
> > * Workspace owner and initial members not set as members (nor in admin
> group) when the workspace identifier contains an underscore  XWIKI-8394
> - Edy
> >
> > Investigations:
> >
> > * XEM Homepage / Portal - Caty
> > * Knowledge base Flavor - Caty/Ludovic
> > * New Activity Stream Investigation Part 1 - JV (he's agree to become
> our AS champion :))
> > * General Flavours Investigation - Caty + input from tech
> >
> > Regarding dates I'm proposing the following:
> >
> > * 5.0M1: 4 March 2013
> > * 5.0M2: 25 March 2013
> > * 5.0RC1: 8 April 2013
> > * 5.0Final: 15 April 2013
> >
> > Thanks
> > -Vincent
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Choose a name for our next skin

[Ecaterina Moraru (Valica)]

Hi,

Current status:

Flamingo | +1 Ludovic, +1 Caty, +1 Jerome, +1 Fabio, +1 Mircea, +1 Manuel,
+1 Guillaume L,
Pelican |
Falcon |
Buzzard |
Eagle |
Bustard |
Trumpeter |
Buttonquail | +1 Denis,
Jacana | +1 Caty,
Gotwit | +1 Mircea,
Guillemot | +1 Denis,
Cockatoo | +1 Guillaume L,
Cuckoo |
Condor | +1 Denis, +1 Caty, +1 Thomas D,
Heron | +1 Thomas M, +1 JV, 0 Denis, +1 Marius
Starling | +1 Caty,
Junco | +1 Caty,
Oriole | +1 Caty,
Ibis | +1 Caty,
Cormorant | +1 Thomas D,

Thanks,
Caty


On Fri, Feb 1, 2013 at 10:52 AM, Denis Gervalle  wrote:

> Hi devs,
>
> Cathy has made a great proposal for a new skin based on bootstrap which she
> call skin 4.x (
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x), the name
> is already a bit outdated, and it will be in fact our 5th generation skin.
>
> So after dodo -> albatross -> toucan -> colibri -> what next ?
>
> Here are some proposals:
> Flamingo
> Pelican
> Falcon
> Buzzard
> Eagle
> Bustard
> Trumpeter
> Buttonquail
> Jacana
> Gotwit
> Guillemot
> Cockatoo
> Cuckoo
> Condor
>
> feel free to propose others...
>
> Currently, my own preference is Condor which is an endangered species like
> the Albatross, but Guillemot or Buttonquail sounds good to me as well.
>
> WDYT ?
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Weekly Bug Fixing Days?

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Sat, Feb 2, 2013 at 4:55 PM, Vincent Massol  wrote:

> Hi devs,
>
> We've closing the 4.x cycle and here's the result of bugs fixed vs bugs
> created during the past 360 days:
> http://snag.gy/MZxh7.jpg
>
> As you can see:
> * More issues were created than fixed: 919 created vs 844 fixed
> * During the whole time, the red has been winning
>
> What this means is that overall we're loosing the quality war. Of course
> bugs are not evenly distributed and it may happen that created bugs are
> peripheral but they're still bugs and since they've been reported they have
> affected users…
>
> Thus I propose that for the 5.x cycle we take some drastic action and do a
> Bug Fixing Day every week in en effort to have green be the default (ie
> more bugs fixed than created).
>
> At least it would be great if we could try it for a while and see how it
> goes.
>
> If you agree, what about doing that every Thursday, starting with the 21st
> of February(since 11th is the final 4.5 release)?
>
> WDYT?
>
> Thanks
> -Vincent
>
> PS: To see past BFD events, see:
>
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDays
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] XWiki Flavors

[Ecaterina Moraru (Valica)]

Hi,

Just sharing a bit my ideas iteration process.

On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol  wrote:
> Hi Caty,
>
> On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)"  
> wrote:
>
>> Hi,
>>
>> XWiki Flavors are a set of predefined extensions having a specific use
>> case in mind. XWiki Flavors can be considered specializations of XWiki
>> instances suited for different purposes like public websites,
>> intranets, content sharing, project management, community status,
>> business intelligence, etc.
>>
>> Scenario: You want to install XWiki. The installer will propose
>> different 'flavors' and will install automatically all required
>> extensions. This way you will have a product close to your initial
>> needs. You can later refine it by installing / uninstalling other
>> extensions.
>>
>> So when I first thought about the process of installing a Flavor I
>> imagined that I could customize what I wanted from the Flavor and
>> select just the things I need. Actually for me Flavors were like
>> categories with subcategories, and more of a classification system,
>> than a packaging one.
>>
>> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/customizedInstall.png
>>
>> Also another difference in my vision is that I had a Base Package that
>> contains the common denominator for all Flavors. The Base Package
>> should contain basic mechanics for managing content and users.
>> Selecting no flavor will still result in having basic wiki features
>> (page creation, attachments, history, users, etc.).
>>
>> After some discussions with Eduard I understood that Flavors could be
>> defined as extensions and they could contain just a list of
>> dependencies on other extensions. The Extension Manager will install
>> the 'exact' list it gets from the definition without the ability to
>> exclude some dependencies.
>
> Indeed.
>
>> I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4]
>> and for me the conclusion is clear: we will never agree on what
>> starting features are the best and that will solve everybody's
>> problems. But that is ok and normal and the strength of XWiki is it's
>> extensibility.
>>
>> So the next idea was to have a Flavor Creator that will allow users to
>> create their own collections of extensions. This collection should be
>> then published to extensions.xwiki.org and could appear in the
>> installer list as suggestions.
>
> Some thoughts:
>
> * Yes, the idea is that anyone can contribute a flavor on xwiki.org, since 
> it's an extension like any other (it would just have a new type, called 
> "flavor" since we don't have this ATM). The DW will list all flavors it can 
> find from e.x.o. This is where we need some ways to bring the best flavors to 
> the top. My idea was to add ratings to the Repository app for that
>
> * Also, in the DW the user should be allowed to not install any flavor so 
> that he can then install extensions one by one if he so wishes
>
> * Re the base package there's no need to have one since extensions declare 
> their require dependencies
>

Last week I was talking about the Flavor Creator:

>> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavorCreator.png
>>
>> If Application Within Minutes let's you create your own applications,
>> the Flavor Creator would let you make packages of extensions for a
>> specific purpose. This way we strengthen XWiki's extensibility and we
>> let the users take the power and customize the solutions that are
>> perfect for them.

My big problem with Flavors is that we are lacking an extensions
classification.
We had types like applications, skins, colorthemes, etc. but now it's
just XARs and JARs.
We have a tag cloud, but that is a folksonomy and doesn't have
'standard' categories. When you look at an extension you may not
understand it's purpose and usage use case.

I've started to categorize our extensions and try to define types of
flavors and use cases, but I'm kind of running in circles. But what is
clear to me is that we will need some predefined categories and that
the Flavor Creator is a must (mainly because we don't have a finite
set of extensions and use cases that we are managing).

I also thought a bit about the process of integrating gamification in
our Extensions Repository (e.x.o) and also a way to encourage users to
create Flavors (and also extensions in general).

First of all I've revised the wireframe
http://incubator.myxwiki.org/xwiki/bin/download/Improv

Re: [xwiki-devs] [Brainstorming] Choose a name for our next skin

[Ecaterina Moraru (Valica)]

On Thu, Feb 14, 2013 at 1:05 PM, Denis Gervalle  wrote:
> Hi devs,
>
> Flamingo seems to have a largely win (with Heron and Condor behind), so if
> no one is against, we will call our next skin Flamingo. Cathy, would you
> mind to change Skin 4.x into Flamingo in your proposal, so it would be
> clear to anyone what we talk about.

Done on the incubator's page.

Thanks,
Caty

>
> Thanks,
>
>
> On Tue, Feb 5, 2013 at 3:09 PM, Silvia Rusu  wrote:
>
>> Hi,
>>
>> +1 for Flamingo.
>>
>> So current status:
>>
>> Flamingo | +1 Ludovic, +1 Caty, +1 Jerome, +1 Fabio, +1 Mircea, +1
>> Manuel, +1 Guillaume L, +1 Sorin, +1 Silvia,
>> Pelican |
>> Falcon |
>> Buzzard |
>> Eagle |
>> Bustard |
>> Trumpeter |
>> Buttonquail | +1 Denis,
>> Jacana | +1 Caty,
>> Gotwit | +1 Mircea,
>> Guillemot | +1 Denis,
>> Cockatoo | +1 Guillaume L,
>> Cuckoo |
>> Condor | +1 Denis, +1 Caty, +1 Thomas D,
>> Heron | +1 Thomas M, +1 JV, 0 Denis, +1 Marius, +1 Sorin,
>> Starling | +1 Caty,
>> Junco | +1 Caty,
>> Oriole | +1 Caty,
>> Ibis | +1 Caty,
>> Cormorant | +1 Thomas D,
>> Kiwi | +1 Eduard,
>> KoKaKo | +1 Eduard,
>> Robin | +1 Eduard,
>> Sparrow | +1 Eduard,
>> Phoenix | +1 Sorin,
>>
>> Thanks,
>> Silvia
>>
>> On Tue, Feb 5, 2013 at 2:31 PM, Ecaterina Moraru (Valica)
>>  wrote:
>> > Hi,
>> >
>> > Would be great if you could modify the status by adding your vote. Thanks
>> >
>> > Current status:
>> >
>> > Flamingo | +1 Ludovic, +1 Caty, +1 Jerome, +1 Fabio, +1 Mircea, +1
>> > Manuel, +1 Guillaume L, +1 Sorin,
>> > Pelican |
>> > Falcon |
>> > Buzzard |
>> > Eagle |
>> > Bustard |
>> > Trumpeter |
>> > Buttonquail | +1 Denis,
>> > Jacana | +1 Caty,
>> > Gotwit | +1 Mircea,
>> > Guillemot | +1 Denis,
>> > Cockatoo | +1 Guillaume L,
>> > Cuckoo |
>> > Condor | +1 Denis, +1 Caty, +1 Thomas D,
>> > Heron | +1 Thomas M, +1 JV, 0 Denis, +1 Marius, +1 Sorin,
>> > Starling | +1 Caty,
>> > Junco | +1 Caty,
>> > Oriole | +1 Caty,
>> > Ibis | +1 Caty,
>> > Cormorant | +1 Thomas D,
>> > Kiwi | +1 Eduard,
>> > KoKaKo | +1 Eduard,
>> > Robin | +1 Eduard,
>> > Sparrow | +1 Eduard,
>> > Phoenix | +1 Sorin,
>> >
>> > Thanks,
>> > Caty
>> >
>> >
>> >
>> >
>> >> On Fri, Feb 1, 2013 at 10:52 AM, Denis Gervalle  wrote:
>> >>>
>> >>> Hi devs,
>> >>>
>> >>> Cathy has made a great proposal for a new skin based on bootstrap which
>> >>> she
>> >>> call skin 4.x (
>> >>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x), the
>> name
>> >>> is already a bit outdated, and it will be in fact our 5th generation
>> skin.
>> >>>
>> >>> So after dodo -> albatross -> toucan -> colibri -> what next ?
>> >>>
>> >>> Here are some proposals:
>> >>> Flamingo
>> >>> Pelican
>> >>> Falcon
>> >>> Buzzard
>> >>> Eagle
>> >>> Bustard
>> >>> Trumpeter
>> >>> Buttonquail
>> >>> Jacana
>> >>> Gotwit
>> >>> Guillemot
>> >>> Cockatoo
>> >>> Cuckoo
>> >>> Condor
>> >>>
>> >>> feel free to propose others...
>> >>>
>> >>> Currently, my own preference is Condor which is an endangered species
>> like
>> >>> the Albatross, but Guillemot or Buttonquail sounds good to me as well.
>> >>>
>> >>> WDYT ?
>> >>>
>> >>>
>> >>> --
>> >>> Denis Gervalle
>> >>> SOFTEC sa - CEO
>> >>> eGuilde sarl - CTO
>> >>> ___
>> >>> devs mailing list
>> >>> devs@xwiki.org
>> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> >>
>> > ___
>> > devs mailing list
>> > devs@xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Notice] BFD#10

[Ecaterina Moraru (Valica)]

Hi,

+1 from my side too.

In this case I think it should not be just a day, but the whole
week-end. Could be just like we had before: the 'first' week-end of
the month.
The participation might be low, but at least we could have it as a
'rule'. If we have results over that week-end, we publish a blog post
about them.

Just as an idea, we could also monitor translations, extensions, pull
requests, etc. submitted over that week-end, so make it not just a
BugFixingDay but a "Contributions Week-end". I know it might sound
strange for an Open Source project (because contributions should
happen every day), but this means just that those contributions would
be monitored and published in a blog post, thanking our contributors
and allowing them to organize on IRC.

Thanks,
Caty

On Fri, Mar 1, 2013 at 6:54 PM, Eduard Moraru  wrote:
> Hi,
>
> The problem is pretty obvious IMO and it would be nice to experiment a few
> events during weekends and observe the participation. Who knows, maybe we
> will be pleasantly surprised :)
>
> +1 from my side.
>
> Thanks,
> Eduard
>
>
> On Fri, Mar 1, 2013 at 5:47 PM, Marta Girdea  wrote:
>
>> On Fri, Mar 1, 2013 at 10:26 AM, Vincent Massol 
>> wrote:
>> > Hi Marta,
>> >
>> > On Mar 1, 2013, at 4:17 PM, Marta Girdea  wrote:
>> >
>> >> Hi,
>> >>
>> >> Congratulations indeed, it's great to see bugs disappear. Just a
>> >> thought: have you considered scheduling some bug fixing days during
>> >> weekends (e.g. one or two every month)? In my opinion, it would make
>> >> it a lot easier for casual contributors to participate and help turn
>> >> the graph green.
>> >
>> > Are you suggesting that you may participate (with Sergiu?) if some BFD
>> were done over week ends? :)
>>
>> I am indeed suggesting this as a solution for the incompatibility
>> between my wish to participate in some of these community events and
>> my other responsibilities which usually prevent me from doing so in
>> those particular days. My guess is that other contributors with jobs
>> outside XWiki SAS may be in the same situation. All I'm saying is:
>> help us help you.
>>
>> >
>> > Thanks
>> > -Vincent
>> >
>> >> Thanks,
>> >> Marta
>> >>
>> >> On Fri, Mar 1, 2013 at 5:13 AM, Vincent Massol 
>> wrote:
>> >>> Results: http://www.xwiki.org/xwiki/bin/view/Main/Bug+Fixing+Day+10
>> >>>
>> >>> Congrats to Caty, Edy and Vincent (me :))!
>> >>>
>> >>> Let's beat the record and be in the green next time and forever
>> onwards :)
>> >>>
>> >>> Thanks
>> >>> -Vincent
>> >>>
>> >>> On Feb 28, 2013, at 10:04 AM, Vincent Massol 
>> wrote:
>> >>>
>>  I've created the jira dashboard for BFD#10:
>>  http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11491
>> 
>>  Thanks
>>  -Vincent
>> 
>>  On Feb 27, 2013, at 6:11 PM, Vincent Massol 
>> wrote:
>> 
>> > Hi devs,
>> >
>> > Tomorrow is BFD#10:
>> >
>> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDays
>> >
>> > We currently have 871 bugs fixed out of 908 created for the last 360
>> days:
>> >
>> http://jira.xwiki.org/secure/Dashboard.jspa#Created-vs-Resolved-Chart/10470
>> >
>> > We closed 19 bugs last Thursday:
>> http://www.xwiki.org/xwiki/bin/view/Main/Bug+Fixing+Day+9
>> >
>> > Let's see if we can do as well tomorrow! We "just" need to fix 37
>> bugs to be back in the green.
>> >
>> > Please join us in the bug hunt tomorrow :)
>> >
>> > Thanks
>> > -Vincent
>> >
>> > ___
>> > devs mailing list
>> > devs@xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] XWiki Flavors

[Ecaterina Moraru (Valica)]

Hi,

Some questions and thoughts about 'flavors':

What exactly is a Flavor? First I've said that is just a group of
extensions, like a 'bundle'. Another idea in the initial use case was
that the Flavor is something installable or 'stand-alone' and you
select it when you create a new wiki. Although the 'bundle' version is
included in the 'stand-alone' one, the reverse is not valid.

I liked very much the idea of a 'bundle' because it provided a way to
organize extensions in silos. A simple example, we could bundle our
old ColorThemes in a 'Default ColorThemes before 3.4 Bundle'. This
bundle has 6 dependencies to ColorThemes: OldDefault, Bordo, Nature,
etc. I've used the Repository Application [5] to define my bundle.

* Problem 1: When you create an extension the extension must not be
empty (if it's empty you don't get the 'Installable with EM'), it
cannot be just a list of dependencies. In the case of 'stand-alone'
you should have a custom homepage or other pages, but in a 'bundle'
use case you don't need to add something more. I've tricked the
Repository App and I've attached a picture with the ColorThemes in the
bundle, give it a version, declared the dependencies and it worked.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/ColorThemesBundle.png
[Talked with Edy: apparently this is not a problem is just a UI thing
for Repository App]

* Problem 2: The installation worked very well and now all the
dependencies are installed. My problem is that if I want to uninstall
this bundle, it will uninstall just the 'bundle' extension and will
not touch the dependencies (even if they are not required by any other
extension). So maybe they should not be declared as dependencies, but
as 'includes' or something. We could test at uninstall if a dependency
is not used somewhere else, we can remove it. Without the removal of
'dependencies' my bundle is useless because it cannot be uninstalled.
 [Talked with Edy: said it's normal, you can manually install
extensions and use them and wouldn't not be nice to be deleted, even
if they are not declared as dependencies by other extensions]

* Problem 3: My bundle contains the OldDefault ColorTheme. When I
install the bundle I got a conflict because now we have a new
ColorThemes.DefaultColorTheme. I've kept the new version in the
conflict resolution phase. The problem is that the conflict decisions
are not kept and remembered anywhere. Because my uninstall didn't
worked I will need to manually uninstall each ColorTheme. When I will
uninstall the OldDefault it will delete ColorThemes.DefaultColorTheme
even if is not it (because it doesn't know that I didn't selected it
in the Conflict Resolution).
What I would like is that if I uninstall an extension or a flavor, the
uninstall process would restore the wiki at the 'initial' state. And
this example I gave is for ColorThemes.DefaultColorTheme, but Flavors
will overwrite the Homepage for example. Uninstalling the Flavor will
leave the user without a Homepage, or without a UserPreferences or
without groups, etc.
 [Talked with Edy: said it's problematic :P ]

Are any of the problems mentioned something interesting and achievable with EM?
Bundles are interesting IMO and they could work for all kinds of
grouping, like the Admin Tools, Developer Tools, Content Editing
Macros, Social Features Bundle, Importers Bundle, etc.

Thanks,
Caty

[5] http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository+Application


On Wed, Feb 13, 2013 at 5:38 PM, Ecaterina Moraru (Valica)
 wrote:
> Hi,
>
> Just sharing a bit my ideas iteration process.
>
> On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol  wrote:
>> Hi Caty,
>>
>> On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)"  
>> wrote:
>>
>>> Hi,
>>>
>>> XWiki Flavors are a set of predefined extensions having a specific use
>>> case in mind. XWiki Flavors can be considered specializations of XWiki
>>> instances suited for different purposes like public websites,
>>> intranets, content sharing, project management, community status,
>>> business intelligence, etc.
>>>
>>> Scenario: You want to install XWiki. The installer will propose
>>> different 'flavors' and will install automatically all required
>>> extensions. This way you will have a product close to your initial
>>> needs. You can later refine it by installing / uninstalling other
>>> extensions.
>>>
>>> So when I first thought about the process of installing a Flavor I
>>> imagined that I could customize what I wanted from the Flavor and
>>> select just the things I need. Actually for me Fl

Re: [xwiki-devs] [Idea] Sponsoring issues

[Ecaterina Moraru (Valica)]

This seams very similar to Sergiu's ideas some time ago when we tried
with Fundry.

Thanks,
Caty

On Tue, Mar 5, 2013 at 6:13 PM, Thomas Mortagne
 wrote:
> On Tue, Mar 5, 2013 at 5:09 PM, Vincent Massol  wrote:
>>
>> On Mar 5, 2013, at 5:03 PM, Thomas Mortagne  
>> wrote:
>>
>>> Looks interesting.
>>>
>>> But who get the money exactly ?
>>
>> Anyone who implements what's asked.
>
> +1 then
>
>>
>> See http://blog.freedomsponsors.org/about/ for details.
>>
>> -Vincent
>>
>>> Can contributors be assigned to issues
>>> or is it only for the project itself (in that case it's not going to
>>> be very simple since we don't have any entity yet) ?
>>>
>>> On Tue, Mar 5, 2013 at 4:56 PM, Vincent Massol  wrote:
 Hi devs,

 WDYT of doing like Jenkins is doing and adding a "Sponsor this issue" 
 button on JIRA?

 For example:
 https://issues.jenkins-ci.org/browse/JENKINS-9030

 When you click it redirects to
 http://www.freedomsponsors.org/core/login/?next=/core/issue/sponsor%3FtrackerURL%3Dhttps%3A//issues.jenkins-ci.org/browse/JENKINS-9030

 You can check
 http://www.freedomsponsors.org/

 It could be interesting to try it and see how it goes.

 WDYT?

 Thanks
 -Vincent
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] XWiki Flavors

[Ecaterina Moraru (Valica)]

On Wed, Mar 6, 2013 at 10:33 AM, Thomas Mortagne
 wrote:
> On Tue, Mar 5, 2013 at 12:36 PM, Ecaterina Moraru (Valica)
>  wrote:
>> Hi,
>>
>> Some questions and thoughts about 'flavors':
>>
>> What exactly is a Flavor? First I've said that is just a group of
>> extensions, like a 'bundle'. Another idea in the initial use case was
>> that the Flavor is something installable or 'stand-alone' and you
>> select it when you create a new wiki. Although the 'bundle' version is
>> included in the 'stand-alone' one, the reverse is not valid.
>>
>> I liked very much the idea of a 'bundle' because it provided a way to
>> organize extensions in silos. A simple example, we could bundle our
>> old ColorThemes in a 'Default ColorThemes before 3.4 Bundle'. This
>> bundle has 6 dependencies to ColorThemes: OldDefault, Bordo, Nature,
>> etc. I've used the Repository Application [5] to define my bundle.
>>
>> * Problem 1: When you create an extension the extension must not be
>> empty (if it's empty you don't get the 'Installable with EM'), it
>> cannot be just a list of dependencies. In the case of 'stand-alone'
>> you should have a custom homepage or other pages, but in a 'bundle'
>> use case you don't need to add something more. I've tricked the
>> Repository App and I've attached a picture with the ColorThemes in the
>> bundle, give it a version, declared the dependencies and it worked.
>> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/ColorThemesBundle.png
>> [Talked with Edy: apparently this is not a problem is just a UI thing
>> for Repository App]
>
> It's not just a UI thing but it's not a big issue either, see
> https://jira.xwiki.org/browse/XWIKI-7260.
>
>>
>> * Problem 2: The installation worked very well and now all the
>> dependencies are installed. My problem is that if I want to uninstall
>> this bundle, it will uninstall just the 'bundle' extension and will
>> not touch the dependencies (even if they are not required by any other
>> extension). So maybe they should not be declared as dependencies, but
>> as 'includes' or something. We could test at uninstall if a dependency
>> is not used somewhere else, we can remove it. Without the removal of
>> 'dependencies' my bundle is useless because it cannot be uninstalled.
>>  [Talked with Edy: said it's normal, you can manually install
>> extensions and use them and wouldn't not be nice to be deleted, even
>> if they are not declared as dependencies by other extensions]
>
> Yes it should be a new kind of dependency in Extension Manager
> (probably just a property in a dependency). On Maven side we could
> reuse  dependency property probably.
>
>>
>> * Problem 3: My bundle contains the OldDefault ColorTheme. When I
>> install the bundle I got a conflict because now we have a new
>> ColorThemes.DefaultColorTheme. I've kept the new version in the
>> conflict resolution phase. The problem is that the conflict decisions
>> are not kept and remembered anywhere. Because my uninstall didn't
>> worked I will need to manually uninstall each ColorTheme. When I will
>> uninstall the OldDefault it will delete ColorThemes.DefaultColorTheme
>> even if is not it (because it doesn't know that I didn't selected it
>> in the Conflict Resolution).
>> What I would like is that if I uninstall an extension or a flavor, the
>> uninstall process would restore the wiki at the 'initial' state. And
>> this example I gave is for ColorThemes.DefaultColorTheme, but Flavors
>> will overwrite the Homepage for example. Uninstalling the Flavor will
>> leave the user without a Homepage, or without a UserPreferences or
>> without groups, etc.
>>  [Talked with Edy: said it's problematic :P ]
>
> Yea "problematic" is an euphemism. What is planned shortly is
> http://jira.xwiki.org/browse/XWIKI-8443 (in your use case you would
> get a conflict about ColorThemes.DefaultColorTheme page when
> uninstalling because it's part of another extension that is not i the
> uninstall plan).
>
>>
>> Are any of the problems mentioned something interesting and achievable with 
>> EM?
>> Bundles are interesting IMO and they could work for all kinds of
>> grouping, like the Admin Tools, Developer Tools, Content Editing
>> Macros, Social Features Bundle, Importers Bundle, etc.
>
> Bundles are how flavors among other things were planned to be
&

Re: [xwiki-devs] BFD#11 Today (RESULTS)

[Ecaterina Moraru (Valica)]

On Fri, Mar 8, 2013 at 10:15 AM, Thomas Mortagne
 wrote:
> On Fri, Mar 8, 2013 at 8:53 AM, Marius Dumitru Florea
>  wrote:
>> On Fri, Mar 8, 2013 at 9:37 AM, Vincent Massol  wrote:
>>> Hi everyone,
>>>
>>> So here are the results:
>>> http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+%2311
>>>
>>> * 29 bugs closed
>>> * 7 participants!
>>> * We're back in the green!
>>>
>>> Well done everyone, that was a great BFD!
>>>
>>> What's next
>>> ==
>>>
>>> I think we should have 2 objectives:
>>>
>>> * Objective 1: Keep being in the green as the norm, which means continue 
>>> the weekly BFD and make sure that at each BFD we close more bugs than bugs 
>>> that were created during the week since the last BFD
>>>
>>> * Objective 2: Continue to slowly catch up on the overall bug count. If you 
>>> look at http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 
>>> you'll see in the top left that we still have 626 more bugs created than 
>>> closed. So I'm proposing to take this slowly and set a new objective of 
>>> being in the green for 1.5 years instead of 1 years. That's 32 bugs more to 
>>> close to break even.
>>>
>>> Objective is a granted. WDYT of Objective 2? Should we do objective 2 or 
>>> just stay with Objective 1?
>>
>> +1 for both.
>
> Same here.

+1

Thanks,
Caty
>
>>
>> Thanks,
>> Marius
>>
>>>
>>> Thanks
>>> -Vincent
>>>
>>> On Mar 7, 2013, at 4:51 PM, Vincent Massol  wrote:
>>>

 On Mar 7, 2013, at 12:44 PM, Vincent Massol  wrote:

>
> On Mar 7, 2013, at 9:43 AM, Vincent Massol  wrote:
>
>> Today is an important BFD.
>>
>> it might be THE BFD where we go back in the green :)
>>
>> See http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
>>
>> Let's go for it! All together!
>
> 2 bugs closed so far: http://jira.xwiki.org/issues/?filter=12200

 And here's the dashboard for it:
 http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11497

 5 bugs to go…

 Thanks
 -Vincent

>>>
>>> ___
>>> devs mailing list
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Brainstorming] [Flavor] Documentation Flavor

[Ecaterina Moraru (Valica)]

Hi,

The proposal for Documentation Flavor can be found at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DocumentationFlavor

A Documentation Wiki is an information repository about a certain
topic (product, service, etc.) It needs to provide means for
information to be collected, organized, shared, searched and utilized.

I've created only the Documentation Flavor and not the Knowledge Base
Flavor because I consider the Documentation to be more strict than the
other. The main difference between the two is the Workflow
(http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DocumentationFlavor#HWorkflow)
which involves also custom Rights
(http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DocumentationFlavor#HRights)
and should provide documentation specific Export formats. Besides
these differences, the Knowledge Base and Documentation are very
similar: knowledge base encourage content collaboration in all stages,
while Documentation only in the content gathering phase, becoming
read-only after.

I encourage you to take a look at the features and give your opinion.

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Brainstorming] [Flavor] Public Website Flavor

[Ecaterina Moraru (Valica)]

Hi,

The proposal for Public Website Flavor can be found at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PublicWebsiteFlavor

The purpose of a Public Website is to share information about a
company/product and it's procedures, features, services, etc. It's the
on-line presence of a company for it's targeted audience.

I encourage you to take a look at the features and give your opinion.

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Brainstorming] [Flavor] Groupware Flavor

[Ecaterina Moraru (Valica)]

Hi,

The proposal for Groupware Flavor can be found at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/GroupwareFlavor

Collaborative software (or groupware) is designed to help people
involved in a common task achieve goals. Groupware are focused on the
usage of applications and collaboration inside teams.

I've tried to make a selection of application we currently have in our
extensions repository. An interesting discussion would be to make
proposals on applications that we currently don't have implemented,
but would be vital in such a flavor.

I encourage you to take a look at the features and give your opinion.

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Brainstorming] [Flavor] Application Development Flavor

[Ecaterina Moraru (Valica)]

Hi,

The proposal for Application Development Flavor can be found at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AppDevelopmentFlavor

Besides being a wiki, XWiki is also an application development
platform. You can build simple applications, extend the platform with
custom plugins, or even build complex Web applications.

There are 2 use cases related to Application Development:
- one targeted to Advanced Developers. I detailed this use case
because it's more complex than the other. I've made a selection of
applications from our extensions repository that I considered could be
of interest for developers in a web environment;
- the other is targeted to Simple Users that want to create
applications. For this use case, choose just the 'Mandatory' features.
A simple user will always use AppWithinMinutes and we need better
integration of created application to be the focus part of the
sub-wiki.

I encourage you to take a look at the features and give your opinion.

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Brainstorming] Default Flavors Proposals

[Ecaterina Moraru (Valica)]

Hi,

I've investigated a bit what use cases could be used inside XWiki for
and I've came up with:

- Documentation Flavor http://markmail.org/thread/cvfzvwv6dnhkimuy
- Groupware Flavor http://markmail.org/thread/mzby6ofaunrsxpun
- Public WebSite Flavor http://markmail.org/thread/fgpzoxtdw2jgrrvl
- Application Development Flavor http://markmail.org/thread/ion37cj7zb255j3d

XWiki can be used for many things and the ones above are just the ones
I've investigated recently.
This mail acts like a collection of the flavors already proposed and
should also gather other proposals/ideas for use cases you find
interesting. One thing to have in mind is the flavor's ideas should be
generic enough in order to be proposed in the sub-wiki creation
process (marginal/very specific flavors should be discussed in another
thread and would be of interest if we are gonna implement the Flavor
Creator).

The features described in the Flavors can have 5 states:
- Mandatory: the feature is mandatory for the described flavor and
needs to be installed;
- Optional: the feature could be of interest for some sub-use cases of
the described flavor. A solution to have optional features would be to
customize what extensions you install in the creation process
(http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/customizedInstall.png)
or to have Disabled/Enabled states for installed extensions
(http://jira.xwiki.org/browse/XWIKI-5704).
- Default: the feature is bundled by default in XE. This means is
tested and supported. If we are gonna create default Flavors, some
features might be present just in the related flavors (like
Annotations), and not by default, but right now they are default.
- Extension: the feature is available as an extension. If the feature
has both 'Default' and 'Extension' it means that some functionality is
available by default, while additional functionality is available
through extensions (one example is the Export: by default we can
export in PDF, HTML, etc. but there are extensions that provide
Multipage PDF Export or Export in other formats like Excel, etc.)
- Custom: Custom means that the feature will have specific differences
from the variant is available now. For example, in a Documentation
Flavor we will need some custom templates; or the Macros categories
should contain macros specially created for content creation.

Each proposal describes the contained features and also provides a
summary at the end, example
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DocumentationFlavor#HFeaturesSummary

Your feedback is welcomed.

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Mobile XWiki Client and Mobile Skin repositories on xwiki-contrib

[Ecaterina Moraru (Valica)]

I've made some style improvements: changed the icons, colors and added
missing rules.
Some screenshots
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileAppV2Improvements

Thanks,
Caty


On Thu, Feb 14, 2013 at 3:03 PM, Ludovic Dubost  wrote:

> Hi,
>
> Following the publication of the v1 prototype code on github, I've started
> working on the v2 prototype.
> I've finished creating a basic new version:
>
> - using object oriented jS
> - using jqMobi instead of JQuery Mobile
> - using a JS based network layer
>
> This version has currently much less features (no offline, etc..) than the
> previous one but the performance is already much better and it is possible
> to relogin or reload a page.
>
> I've created the following page to track the development
> http://dev.xwiki.org/xwiki/bin/view/Design/MobileClient
>
> The code of v2 is in a branch on github:
>
> https://github.com/xwiki-contrib/mobile-standardxwikiclient/tree/v2
>
> There is still a lot of work like:
>
> - editing the configuration
> - adding the XEM and other queries that were present in the v1 version
> - implement Cati's design
> - add some network recovery features (for instance when you are not
> authentified anymore)
>
> Ludovic
>
>
> 2013/2/2 Ludovic Dubost 
>
> >
> > As discussed a while ago, I'm finally made public the Mobile XWiki Client
> > code I've been working on.
> >
> > I've transfered the repository as well as the mobile skin repository to
> > xwiki-contrib
> >
> > https://github.com/xwiki-contrib/mobile-standardxwikiclient
> > https://github.com/xwiki-contrib/skin-mobile-simple
> >
> > The next step for the mobile client is a rework to be:
> >
> > 1/ More modular to allow for additional module and UI changes to allowed
> > by plugins.
> > 2/ A rework of the network layer to be able to queue requests to XWiki
> and
> > manager errors and retries as well as login.
> >
> > Ludovic
> >
> > --
> > Ludovic Dubost
> > Founder and CEO
> > Blog: http://blog.ludovic.org/
> > XWiki: http://www.xwiki.com
> > Skype: ldubost GTalk: ldubost
> >
>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Mobile XWiki Client and Mobile Skin repositories on xwiki-contrib

[Ecaterina Moraru (Valica)]

Hi,

I didn't realized the bottom buttons were functional, I though they were by
demo (since it had a magnifier icon and said Squeeze with no apparent
effect). Also no effect for Relogin, Home or Refresh so I didn't gave too
much importance on them.
I see now that the Status changes its icon, but this is not effective
enough. Instead of having just an image change, the image needs to by
animated. Also indicating the status of a page loading is not good to do in
the menu, since those should all be actions and not status indicators. When
we will have the whole functionality working we will see where to better
place them.

IMO Status functionality, refresh, resize are debug functionality that will
not make it in the "final" version since they are quite advanced and non
straight forward.

It's very good that the code is public and I will make style improvements
when we are gonna have additional functionality.

Thanks,
Caty


On Thu, Apr 4, 2013 at 12:14 PM, Ludovic Dubost  wrote:

>  Hi Caty,
>
> Changes are great. I'll continue to work on the application soon to re-add
> the features of the previous version.
>
> There are some things that don't match the current application:
>
> 1/ The search button at the bottom is actually not doing search. It's a
> "resize" button to resize the web screen manually if it failed
> automatically. This is currently needed because I could not be really sure
> to catch when the page (loaded in an iframe)  is fully loaded (images for
> instance) and therefore I needed the button in case the width is not set
> automatically. This might not be needed in the future if I can make it work
> well without it and if we can resize the iframe with the fingers which I
> could not yet make work.
>
> However let's keep the search button as having search in this toolbar is
> good. So you should make a button that means "fit to screen". We could put
> that button somewhere else (in the top bar when the page is an HTML page)
>
> 2/ The status icon had two states to show if there is activity on the
> network. It's important to have this. I could not find a better thing then
> having status + loading activity in the same place. If you have a better
> proposal shoot. In the mean time we need the 2 icons because knowing if
> there is still loading activity is important. Note that loading activity is
> fully transversal and not linked to the current page. We could also have
> information about wether the status of loading of the current page but it
> might be too much (there are four states:  in the queue - plus place in the
> queue / which queue it is in, low or high priority - , loading, finished
> with success, finished with error). The page won't get out of the queue if
> you leave the page to go to another screen (however long term this could
> move your request in the low priority queue)
>
> Next I will work on:
>
> - xem support
> - managing the settings
> - search
> - app within minutes content
>
> If there are volunteers to participate, you are welcome. Now that the code
> is public, we could have multi-developer collaboration.
>
> Ludovic
>
>
>
> 2013/4/4 Ecaterina Moraru (Valica) 
>
> > I've made some style improvements: changed the icons, colors and added
> > missing rules.
> > Some screenshots
> >
> >
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileAppV2Improvements
> >
> > Thanks,
> > Caty
> >
> >
> > On Thu, Feb 14, 2013 at 3:03 PM, Ludovic Dubost 
> wrote:
> >
> > > Hi,
> > >
> > > Following the publication of the v1 prototype code on github, I've
> > started
> > > working on the v2 prototype.
> > > I've finished creating a basic new version:
> > >
> > > - using object oriented jS
> > > - using jqMobi instead of JQuery Mobile
> > > - using a JS based network layer
> > >
> > > This version has currently much less features (no offline, etc..) than
> > the
> > > previous one but the performance is already much better and it is
> > possible
> > > to relogin or reload a page.
> > >
> > > I've created the following page to track the development
> > > http://dev.xwiki.org/xwiki/bin/view/Design/MobileClient
> > >
> > > The code of v2 is in a branch on github:
> > >
> > > https://github.com/xwiki-contrib/mobile-standardxwikiclient/tree/v2
> > >
> > > There is still a lot of work like:
> > >
> > > - editing the configuration
> > > - adding the XEM and other queries that were present in the v1 version
> > > -

[xwiki-devs] [Feedback] Activity Stream

[Ecaterina Moraru (Valica)]

Hi,

We introduced the Activity Stream macro in XE 2.6
http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Macro

We are investigating ways to improve our Activity Stream, but in order to
do that we would want to know your feedback about it (both from a
technology and an user experience pov):
- Is Activity Stream a macro you use?
- What features you most miss about it? Maybe filtering? Maybe pagination?
- Would you like to see more event types, like events generated by
applications?
- Are you using the "Send Message" functionality?
- Other opinions about it.

Your feedback will help us improve the macro by adding needed functionality
and not breaking used one.

I'll gather ideas on
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamFeedback50

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [GSOC] XWiki has been accepted as a mentoring organization for Google Summer of Code 2013

[Ecaterina Moraru (Valica)]

Hi devs and users,

I would like to announce that XWiki has been accepted as a mentoring
organization for Google Summer of Code 2013. This is our 8th year
participating in the program.

If you are an interested student, please have a look over the list of
proposed projects and feel free ask any questions on the devs@xwiki.orglist.
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HProposedProjects2829

If you plan to be a mentor this summer, don`t forget to *register* as such
on XWiki's melange page
http://www.google-melange.com/gsoc/org/google/gsoc2013/xwiki

The program's timeline is available at
http://www.google-melange.com/gsoc/events/google/gsoc2013

Additional information can be found at
http://gsoc.xwiki.org
or in the blog post
http://www.xwiki.org/xwiki/bin/view/Blog/XWiki+is+participating+in+Google+Summer+of+Code+2013

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Proposal][UX] Portal entry in menu and breadcrumbs

[Ecaterina Moraru (Valica)]

Hi devs,

A single wiki model is mostly used to demo XWiki and to test its features.
In production usually we have a multiwiki model, because of its
flexibility.

Since 5.0M2 we also have virtual mode enabled by default, meaning that is
even easier to create and manage subwikis/workspaces.

No matter if you want independent wikis or workspaces, both cases share a
Main Wiki. I propose to call the Main Wiki a 'Portal'.

The Portal purpose is to:
- both: manage the wikis/workspaces, being the point where you create new
wikis/workspaces;
- both: help the navigation between wikis/workspaces, by being the 'home'
point for them;
- workspace: manage the global users, providing access to a User Directory;
- workspace: will provide a global view of users' activities in workspaces;
- wikis: will provide a webhome (similar to what we have on myxwiki.org)
that states the purpose of the farm.

Workspace already has a custom menu in which there is present the 'Main'
wiki
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/PortalMenu/currentOverviewWorkspace453.png

I've made a proposal for the content of the menus in
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PortalMenu that we
shall discuss.

'Portal' entry is present in the menu and also in the Breadcrumbs. The
'home' icon should be always present in the breadcrumbs, followed by the
Wiki/Workspace WebHome and then should be user defined (according to a
custom parent/child relation).

By having it clearly stated in the menu and in the breadcrumb, it will
improve the navigation between workspaces (and will give a home point for
the wikis).

In single wikis, the Portal entry is skipped.

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal][UX] Portal entry in menu and breadcrumbs

[Ecaterina Moraru (Valica)]

Hi Marius,

On Wed, Apr 17, 2013 at 4:30 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi Caty,
>
> On Tue, Apr 16, 2013 at 9:28 AM, Ecaterina Moraru (Valica)
>  wrote:
> > Hi devs,
> >
> > A single wiki model is mostly used to demo XWiki and to test its
> features.
> > In production usually we have a multiwiki model, because of its
> > flexibility.
> >
> > Since 5.0M2 we also have virtual mode enabled by default, meaning that is
> > even easier to create and manage subwikis/workspaces.
> >
>
> > No matter if you want independent wikis or workspaces, both cases share a
> > Main Wiki. I propose to call the Main Wiki a 'Portal'.
>
> I'm not very convinced by the 'Portal' name because for me a portal
> (on the web) is something that aggregates information from various
> sources. The main wiki doesn't aggregate the sub wikis.
>
> >
> > The Portal purpose is to:
> > - both: manage the wikis/workspaces, being the point where you create new
> > wikis/workspaces;
> > - both: help the navigation between wikis/workspaces, by being the 'home'
> > point for them;
> > - workspace: manage the global users, providing access to a User
> Directory;
>
> > - wikis: will provide a webhome (similar to what we have on myxwiki.org)
> > that states the purpose of the farm.
> >
> > Workspace already has a custom menu in which there is present the 'Main'
> > wiki
> >
> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/PortalMenu/currentOverviewWorkspace453.png
> >
>
> > I've made a proposal for the content of the menus in
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PortalMenuthat we
> > shall discuss.
>
> The screenshots show what happens when you are on a sub wiki but what
> if you are on the main wiki? Is the 'Portal' menu 'duplicated'? If
> not, then what happens with menu entries like Watch and Document index
> that are on the 'wiki' menu. Are they moved to the 'Portal' when on
> the main wiki?
>

Right now on Workspaces we have like this:
- main wiki:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/PortalMenu/WorkspacesDirectoryCurrent.png
- sub-wiki:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/PortalMenu/MenuPortalCurrent.png

So the 'Portal' entry adds the 'Watch' and 'Document Index', and doesn't
duplicate the menus. This is how it works now. It makes a bit the
"Workspaces Directory" less visible, but maybe we can improve this.

Regarding the name, right now we don't have nothing custom done for the
'Portal', but for the workspace case I've said:
> - workspace: will provide a global view of users' activities in
workspaces;
> - workspace: manage the global users, providing access to a User
Directory;

this means the 'Portal' will contain on the homepage an "Activity Stream
allowing to follow the activity of all sub-wikis". I haven't made a
proposal for this part, but I will. The User Directory will be also located
here and will be global, so it kind of acts like a portal. Plus it will be
the central point for all the content.

We can still discuss the naming if you want. Another variant would be
"Home" - but is kind of ambiguous.

I'm still not sure if we want to keep the term separation for 'Wikis' and
'Workspaces'. In my mind now workspaces are gonna be default and the wikis
are gonna be just in the 'farm' mode when they are independent.
I know today we have:
- wikis in a farm: myxwiki.org - that are independent;
- wikis that are connected: xwiki.org, but they are not workspaces;
- workspaces - special case when normal users can create wikis.

In this proposal I made 'workspaces' as the default wiki creation mode in
'intranets' and kept 'wikis' just for the independent-'farm' mode. That's
why in my case 'Main Wiki' doesn't have sense, since it should be 'Main
Workspace' (and this actually is not correct). That's why I borrowed the
more generic term 'Portal' (from a discussion with Ludovic).

Thanks,
Caty



> Thanks,
> Marius
>
> >
> > 'Portal' entry is present in the menu and also in the Breadcrumbs. The
> > 'home' icon should be always present in the breadcrumbs, followed by the
> > Wiki/Workspace WebHome and then should be user defined (according to a
> > custom parent/child relation).
> >
> > By having it clearly stated in the menu and in the breadcrumb, it will
> > improve the navigation between workspaces (and will give a home point for
> > the wikis).
> >
> > In single wikis, the Portal entry is skipped.
> >
> > Thanks,
> > Caty
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Reminder] BFD #17 + branch

[Ecaterina Moraru (Valica)]

As filter you can check
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11508 I usually
monitor all issues fixed, not just bugs.


On Thu, Apr 18, 2013 at 9:20 AM, Thomas Mortagne
wrote:

> Branches created and Jenkins updated.
>
> On Wed, Apr 17, 2013 at 6:02 PM, Vincent Massol 
> wrote:
> >
> > On Apr 17, 2013, at 5:58 PM, Thomas Mortagne 
> wrote:
> >
> >> Not sure it's really needed but since it has to be done before a RC why
> not.
> >
> > The reason I'm mentioning this is because:
> > 1) since I won't be avail tomorrow I've started looking for some simple
> bugfixes I could still fix and some I've found I would definitely not fix
> them in a RC… Too risky
> > 2) In the past BFD we've almost always had stabilization issues for 1 or
> 2 days after the BFD and since here we're supposed to release Friday…
> >
> > In any case I think it's important that you decide Thomas since you're
> the RM. I was just mentioning this mostly to help you and ensure we're not
> going to push the release once more :)
> >
> > Thanks
> > -Vincent
> >
> >> I can take care of that if nobody is against it.
> >>
> >> On Wed, Apr 17, 2013 at 5:32 PM, Vincent Massol 
> wrote:
> >>> Hi,
> >>>
> >>> Tomorrow starts BFD#17. Since I'll be travelling I won't be able to
> participate so I wish you a good BFD! :)
> >>>
> >>> One important remark: We're currently stabilizing 5.0RC1 and I think
> it would be a bad idea to commit BFD bug fixes for RC1 tomorrow.
> >>>
> >>> I'm proposing instead that we create a stable-5.0.x branch right now
> from master and that master becomes 5.1M1 and that tomorrow we commit on
> master (and backport on the stable-5.0.x branch if we are really sure of
> the fix and we think it's needed for 5.0).
> >>>
> >>> WDYT? If agreed, who could do this?
> >>>
> >>> Thanks
> >>> -Vincent
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [UX][Iteration] Create Wiki / Space / Page step

[Ecaterina Moraru (Valica)]

Hi devs,

This is not the final proposal, but the state of an iteration.

I want to have a consistent 'Create' step across creating
wikis/workspaces/spaces/pages.

You can see some work done at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateImprovements

The 'Create Workspaces' step will contain multiple steps, just like a
wizard, but with the mention that you don't need to go across all the steps
in order to 'Create'. You can enter the name and just rely on the defaults
(default type selected, location according to the context, standard
members).
I still need to make proposals for Step 2 and Step 3.

Today I just show the consistency between Workspaces, Spaces and Pages, by
having the "Type" selector that will list Flavors, Templates, etc.

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Feedback] Search Requirements

[Ecaterina Moraru (Valica)]

Hi,

We introduced in XWiki 4.3 a new experimental search based on Apache Solr
[A] .

Right now our Solr Search [B] is marked as experimental and I don't know
how many of you got a chance to play a bit with it.

In order for it to become default we need to make sure we are covering the
major use cases. So in this mail we should provide some feedback on what is
really needed from a relevance, user experience, performance, etc. point of
view.

I am very interested also in some general feedback on the Lucene Search:
major problems you had with it and limitations.

The following questions are mostly related to Solr Search:

1) The Solr implementation adds a 'Filtered Search'. Are all filters that
are available now needed (wiki, space, type, filetype)? Are we missing
some? What is the most important one? Should we have multiple select?

>From a technical point of view we could add a lot of things (object
properties, query boost, etc.) but I'm more interested, in production, what
are some advanced or common use cases of search usage. IMO our Lucene
implementation is too simplistic, but it would be a shame to add useless
complexity to the Solr one if we really don't need it. On the other hand
having a customizable search is a really nice thing.

The customization part is kind of complex, but also the most powerful. I
want to know how much would we need the ability to explicitly mention the
types of results we want vs. excluding things, etc.

2) The Solr search adds a 'Sort' feature. What do you think about that?

3) Search result metadatas: should we display the relevance? What other
information should be displayed besides name, location, type?

4) Other mentions.

Having a generic search is more complex, than knowing exactly what your
search needs to return. We need to make sure we don't add too many niche
things while keeping the functionality satisfiable for general use cases.

Thanks,
Caty

---
[A]
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43#HExperimentalSolrbasedsearchengine
[B]
http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Application
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Rendering] Questions raised by XRENDERING-290: "Add support for linking to a user profile page in XWiki Syntax"

[Ecaterina Moraru (Valica)]

Hi,

There are a lot of things I don't understand, but I'm just curios if you
had the same problems when you added 'icon:', 'path:', 'attach:', 'mailto:',
etc. Are this words reserved now, a.k.a can not make wikis with these
names? Or maybe this case is a special one.

Thanks,
Caty


On Fri, Apr 26, 2013 at 11:11 AM, Vincent Massol  wrote:

> Hi devs,
>
> I've started implementing XRENDERING-290 (I've spent already 1 day on it
> and have most of it done) but as I progressed I've realized we need to
> decide on something.
>
> It's an interesting problem! :)
>
> So the issues asks for support a "user" prefix in links to link to user
> profiles such as in: [[label>>user:evalica]]
>
> Explanation of Problem
> ==
>
> I started with implementing a new Reference Type Parser to add support for
> the "user" prefix. I soon realized that we cannot implement this in XWiki
> Syntax 2.1 since it means if a user currently has [[label>>user:evalica]]
> it means pointing to the "user" wiki and to the page named "evalica".
>
> Thus we need to add this in a new syntax only (i.e. XWiki Syntax 2.2).
>
> Now the problem is that currently Reference Type Parsers are components
> and implementing a new component means it's going to be available to XWiki
> Syntax 2.1. So I spent a substantial amount of time to allow syntaxes to
> specifically specify the list of prefixes that they support. This is done,
> I just need to push it.
>
> Now this all looked good till I started implementing the
> UserXHTMLLinkTypeRenderer… I realized that I would need to be able to
> transform a String (supposed to represent a username) into a User reference
> and even though we don't have an API for this ATM this would normally mean
> to depend on the Platform User module… which is a big no go since Rendering
> cannot depend on Platform.
>
> Side Note:I also realized that XRENDERING-290 could also be extended to
> support displaying the user's avatar with image:user:evalica. This is
> currently done with the {{useravatar}} macro (which is also wrongly located
> in Rendering and should be in platform for the reason explained!!).
>
> So I thought I could just have the UserResourceReferenceTypeParser and
> UserXHTMLLinkTypeRenderer classes implemented in the Platform User module
> but that still meant that the XWiki Syntax 2.2 needs to reserve the "user"
> prefix.
>
> Then I realized that any time we will want to add support for a new prefix
> we would need to introduce a new Syntax version which is a huge PITA and a
> pity.
>
> I thought about several solutions.
>
> Solution 1
> 
>
> * Consider that each syntax can reserve prefix type namespaces and this
> just means that if the user wants to write a link to a document a wiki
> named after one of these prefixes then he needs to use the full format:
> [[label>>doc::….]]
> * Thus XWiki Syntax 2.2 would just add the "user" prefix to the reserved
> list of prefix type namespaces.
>
> PRO:
> * I have this code ready to be pushed on my computer
> * Doesn't change the current XWiki Syntax notation
>
> CONS:
> * Requires a new syntax whenever a new type parser is added (after a
> syntax has been released as final)
> * Creates a relationship between the syntax and implementations (the User
> module will provide an impl. for supporting the reserved "user" namespace).
>
> Solution 2
> 
>
> * Don't implement support for linking to users using resource types and
> add a {{userlink}} macro and move both macros in platform.
>
> PRO:
> * Simple, no need for a new XWiki Syntax
>
> CONS:
> * Not integrated in the syntax
> * Not very logical since as a user you would want to write:
> [[label>>user:evalica]]
>
> Solution 3
> 
>
> Force XWiki Syntax 2.2 to *ALWAYS* use the full form when creating a link,
> i.e. all links to doc would need to be written: [[label>>doc:reference]]
>
> PRO:
> * Solves all future needs for new reference types and makes the syntax
> extensible for this.
>
> CONS:
> * Harder to write links to documents and users will need to get used to it
>
> Solution 4
> 
>
> Invent a new syntax when you wish to write links using a type prefix and
> keep the current link syntax for references to documents:
> * Ref to a doc: [[label>>docref]] (e.g. [[label>>xwiki:Main.WebHome]])
> * Ref to anything but using the type prefix: [[label>>>prefix:reference]]
> (e.g. [[label>>>doc:doc:Main.WebHome]]: link to a wiki named "doc")
>
> PRO:
> * Still easy to make refs to documents
> * Makes the syntax extensible by allowing new types to be added
>
> CONS:
> * Changes the syntaxes since it means introducing a new link notation
> [[label>>>ref]]. Also means that references to docs cannot start with ">"
>  anymore (but that's not a real issue IMO)
> * A bit more complex to implement obviously since it needs a change to the
> javacc parser
>
> Conclusion
> ==
>
> My POV:
> * The more correct solution is solution 3 but it makes harder to write
> links to documents so I belie

Re: [xwiki-devs] A new idea for GSoC 2013

[Ecaterina Moraru (Valica)]

Hi,

There is some work done in the mobile direction that you can check out
"Mobile XWiki Client and Mobile Skin repositories on xwiki-contrib"
http://markmail.org/thread/ytujvmshwdeun7kv
"New version of the Mobile App
Code"
http://xwiki.markmail.org/thread/htfs3bqtj2tdpfnf

If you really like the mobile area you can check out what is currently done
and adapt your proposal according to it. Then the proposal will be review
and see if we can find a matching mentor for it.

Thanks,
Caty



On Mon, Apr 29, 2013 at 10:26 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi,
>
> On Sun, Apr 28, 2013 at 11:28 PM, Buddhiprabha Erabadda
>  wrote:
> > Hi all,
> >
> > I am Buddhiprabha Erabadda, a final year undergraduate from the
> Department
> > of Computer Science and Engineering, University of Moratuwa.  I have been
> > studying about XWiki from few days now and I have
> > downloaded the xwiki-enterprise-jetty-hsqldb-4.5.3.zip [1] and run it on
> my
> > Windows machine to understand the client side of XWiki. Now I am getting
> > familiar with the code base, referring to various documentation. [2]
> >
> > After going through XWiki site and particularly News and Blog [3], I
> > decided to come up with a new idea for GSoC 2013 for XWiki. My idea is to
> > develop a mobile news application for XWiki. This will enable users to
> view
> > news about posts, new releases, fixes, etc  through the application. In
> > particular, my proposed application will contain the following.
> >
> >
> >- News will be shown as a thumbnail list: it will contain an image of
> >the author of the news item or an image related to the news item, a
> title
> >for the news item, and a brief description about the news item.
> >- When a user clicks on the news item, user will be directed to a page
> >with full information regarding that particular news.
> >
> >
> > This application can have following features.
> >
> >
> >- The user can filter news: for example Latest news, news by a
> specific
> >author, news from a particular period, etc.
> >- Add favourite news: this will enable the user to mark his/her
> favorite
> >items and there by access them at a later point of time.
> >- Enable adding comments from the application
> >
> >
> > This is the basic outline of my proposed mobile application. I expect to
> > implement this as a PhoneGap application. Using PhoneGap to develop the
> > application will enable it to be run on multiple platforms, including
> > Android, iOS, etc. The application will be beneficial for everyone
> > including users and developers of XWiki because it will enable them to be
> > updated on the go using a mobile application.
> >
>
> > I would like to know your opinion on the idea of having the proposed
> mobile
> > news application. Please add to list of features if you have better or
> new
> > ideas for them.
>
> I'm glad that XWiki has caught your attention but I don't think your
> proposal fits into our target for GSoC because:
>
> (1) It's not related to the XWiki product. If your application can get
> the news from xwiki.org then it can get them from other sites as well.
> Even if you take the data (using REST) from the blog structure
> (objects) that is specific to XWiki, that is just a small part, the
> rest of the application (display and interaction) would still be
> generic. I'd rather see the XWiki news / blog posts integrated in an
> existing news application.
>
> (2) The blog application already supports 'exporting' the blog posts /
> news in RSS format, which can be used in any RSS aggregator, and there
> are mobile news aggregator applications that can read RSS.
>
> I hope this won't discourage you. If none of the listed
> http://gsoc.xwiki.org project ideas attract you then you can make your
> own proposal but it must be related to the XWiki product.
>
> Thanks,
> Marius
>
> >
> > I participated for GSoC 2012 under DocBook organization for the project
> > “DocBook to Word XML roundtripping XSLs” and successfully completed my
> > project. [4] [5] I would like to contribute to XWiki in GSoC 2013 and I
> > hope to know your idea about my proposed mobile application. Thank you in
> > advance.
> >
> > [1] http://enterprise.xwiki.org/xwiki/bin/view/Main/Download
> >
> > [2] http://dev.xwiki.org/xwiki/bin/view/Main/WebHome
> >
> > [3] http://www.xwiki.org/xwiki/bin/view/Main/News
> >
> > [4]
> >
> http://www.google-melange.com/gsoc/project/google/gsoc2012/buddhiprabha/15001
> >
> > [5]
> >
> https://docbook.svn.sourceforge.net/svnroot/docbook/branches/gsoc-2012/roundtrip2
> >
> >
> > --
> > *Buddhiprabha Erabadda*
> > *Department of Computer Science and Engineering*
> > *University of Moratuwa*
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs

Re: [xwiki-devs] New version of the Mobile App Code

[Ecaterina Moraru (Valica)]

Hi,

Well since we already had some different proposals and implementations,
calling it "XWiki Mobile Application" (XMOBILE) would be bad IMO.
So maybe we should have a naming policy just like we have for skins (with
the bird names) and a prefix for what is supposed to be, "Mobile" linked,
so something like:
"XWiki [Name] Mobile Application" with the key "XM[NAME]", where [Name]
could be anything (depending on the policy: cloud names [Alto, Nimbus],
butterfly names [Argus, Morpho], etc.).

Thanks,
Caty


On Mon, Apr 29, 2013 at 8:11 PM, Ludovic Dubost  wrote:

> Hi,
>
> Could I get some advice about the name of the JIRA project to create for
> the Mobile project.
> I'd like to launch an Alpha version and for this I would need the jira
> project setup
>
> Ludovic
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2

[Ecaterina Moraru (Valica)]

+1 for Proposal 2

Thanks,
Caty


On Tue, Apr 30, 2013 at 2:26 PM, Denis Gervalle  wrote:

> Hi devs,
>
> I have a very bad feeling with proposal 3, since it split the identifier,
> which makes its main part to loose its meaning when taken alone. So you
> cannot comunicate the whole information easily on different channels (think
> about copy/pasting such reference ?). This is also really verbose, sometime
> it looks odd, and I found it to be complex from a user view point.
> Moreover, it could not be easily applied in other situation than links,
> while ressource identification is not limited to links (think about a macro
> arguments ?, see MotionComposer macro that imitate image: for an example).
> I know it is hard, but I am currently -1 for this proposal.
>
> If we look at large, what we really need and intend to achieve is to have
> an extensible syntax to identify ressources in XWiki. There is obviously a
> ready made standardized syntax for such purpose: URN. Proposal 1 is really
> near that specification (but too verbose for URL), but I agree with Thomas
> that users will complains to be forced to use doc: everywhere. This is
> precisely why I made proposal 2, which will fully avoid that constrains for
> user of single wikis (a lot of our user since XE was our mostly downloaded
> distribution until now).
>
> So my vote are (sorry Vincent, but your request to have a truly single vote
> is far too restrictive for this matter)
> +1 to really conform with a URN syntax as much as possible (remove the
> useless verbosity for URL).
> Proposal 1: +0
> Proposal 2: +1
> Proposal 3: -1
>
> Thanks,
>
>
>
> On Tue, Apr 30, 2013 at 12:30 PM, Vincent Massol 
> wrote:
>
> > Typos below.
> >
> > On Apr 30, 2013, at 11:02 AM, Vincent Massol  wrote:
> >
> > > Hi devs,
> > >
> > > Following this thread http://markmail.org/thread/vw3derowozijqalr it
> > seems clear that we need to introduce a better syntax for links and
> images
> > in XWiki Syntax 2.2 (in order to cope with use cases such as
> > http://jira.xwiki.org/jira/browse/XRENDERING-290).
> > >
> > > The need is to be able to plug new reference type handlers without
> > breaking backward compatibility in XWiki Syntax 2.2 (since right now with
> > XWiki Syntax 2.0 and 2.1 adding a new type reference handler would break
> > backward compatibility).
> > >
> > > So here are various proposals to that effect for XWiki Syntax 2.2 (I've
> > only kept the interesting proposals from the previous thread). Please
> vote
> > for the one you prefer or add new solutions if you have other better
> ideas.
> > >
> > > Proposal 1
> > > =
> > >
> > > Force XWiki Syntax 2.2 to *ALWAYS* use the full form when creating a
> > link or image, i.e. all links would need to be written:
> > [[label>>type:reference]]
> > >
> > > Examples:
> > > * [[label>>doc:space.page]]
> > > * [[label>>doc:wiki:space.page]]
> > > * [[label>>path:/some/path]]
> > > * [[label>>url:http://xwiki.org]]
> > > * [[label>>user:evalica]]
> > > * [[image:doc:wiki:space.p...@image.png]]
> > > * [[image:icon:someicon.png]]
> > >
> > > CONS:
> > > * Harder to write links to documents which is the main use case
> > >
> > > Proposal 2
> > > =
> > >
> > > Same as with XWiki Syntax 2.1 but for links or images to subwikis force
> > the user to use the "doc:" notation
> > >
> > > Examples:
> > > * [[label>>space.page]] or [[label>>doc:space.page]]
> > > * [[label>>doc:wiki:space.page]]
> > > * [[label>>>path:/some/path]]
> >
> > Should be [[label>>path:/some/path]]
> >
> > > * [[label>>http://xwiki.org]] or [[label>>>url:http://xwiki.org]]
> >
> > Should be [[label>>http://xwiki.org]] or [[label>>url:http://xwiki.org]]
> >
> > > * [[label>>user:evalica]]
> > > * [[image:doc:wiki:space.p...@image.png]]
> > > * [[image:icon:someicon.png]]
> > >
> > > PRO:
> > > * Still easy to reference docs and images in the current wiki
> > > * Close to current XWiki Syntax 2.1
> > >
> > > CONS:
> > > * Harder to write links to documents in subwikis (for workspaces users
> > for example, see example of xwiki.org)
> > >
> > > Proposal 3
> > > =
> > >
> > > Always define the type as a link or image parameter, i.e. separate
> > subwiki notation from type.
> > >
> > > Examples:
> > > * [[label>>space.page]] or [[label>>space.page||type="doc"]]
> > > * [[label>>wiki:space.page]] or [[label>>wiki:space.page||type="doc"]]
> > > * [[label>>>/some/path||type="path"]]
> >
> > Should be [[label>>/some/path||type="path"]]
> >
> > > * [[label>>http://xwiki.org]] or [[label>>>http://xwiki.org
> > ||type="url"]]
> >
> > Should be [[label>>http://xwiki.org]] or [[label>>http://xwiki.org
> > ||type="url"]]
> >
> > Thanks
> > -Vincent
> >
> > > * [[label>>evalica||type="user"]]
> > > * [[image:wiki:space.p...@image.png]] or
> > [[image:wiki:space.p...@image.png||type="doc"]]
> > > * [[image:someicon.png||type="icon"]]
> > >
> > > PRO:
> > > * Still easy to reference docs
> > > * Clear separation between subwiki and types
> > >
> > > C

[xwiki-devs] [VOTE] Move XWiki Eclipse to Contrib

[Ecaterina Moraru (Valica)]

Hi devs,

There is not much activity for XWiki Eclipse since there are no current
active developers working on improving the project.

Since XWiki Eclipse is something interesting and useful, we might not want
to retire it, but instead we could mark it as Contrib. This means:

* Move JIRA's XWiki Eclipse 'XECLIPSE' project from 'Top Level Projects' in
'XWiki Contributed Projects'. This would also help us better manage the
number of open issues that are relevant and that we can work on. Right now
there are 51 issues open for this project.
http://jira.xwiki.org/browse/XECLIPSE
* Move https://github.com/xwiki/xwiki-eclipse to
https://github.com/xwiki-contrib/
* Move documentation found on http://xeclipse.xwiki.org/ on a page on
extensions.xwiki.org (Installation, User Guide, Release Notes)
* Remove xeclipse.xwiki.org
* Update xwiki.org to mark this move (menu, footer, download page, All
Projects page in order to still make the project accessible)

Tell me what you think,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [VOTE] Move XWiki Office to Contrib

[Ecaterina Moraru (Valica)]

Hi devs,

There is not much activity for XWiki Office since there are no current
active developers working on improving the project.

Since XWiki Office is something interesting and useful, we might not want
to Retire it, but instead we could mark it as Contrib. This means:

* Move JIRA's XWiki Office 'XOFFICE' project from 'Top Level Projects' in
'XWiki Contributed Projects'. This would also help us better manage the
number of open issues that are relevant and that we can work on. Right now
there are 63+1 issues open for this project.
http://jira.xwiki.org/browse/XOFFICE
* Move https://github.com/xwiki/xwiki-office to
https://github.com/xwiki-contrib/
* Move documentation found on http://xoffice.xwiki.org/ on a page on
extensions.xwiki.org (Installation, User Guide, Design, Development,
Roadmap, Release Notes)
* Remove xoffice.xwiki.org
* Update xwiki.org to mark this move (menu, footer, download page, All
Projects page in order to still make the project accessible)

Tell me what you think,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Move XWiki Eclipse to Contrib

[Ecaterina Moraru (Valica)]

Eduard had a concern about visibility and differentiation on the Contrib
repo. He said that would be interesting if we could promote some projects
there, but I don't know how we could do that.

>From my part +1

Thanks,
Caty


On Thu, May 2, 2013 at 1:06 PM, Thomas Mortagne
wrote:

> +1
>
> On Thu, May 2, 2013 at 11:20 AM, Ecaterina Moraru (Valica)
>  wrote:
> > Hi devs,
> >
> > There is not much activity for XWiki Eclipse since there are no current
> > active developers working on improving the project.
> >
> > Since XWiki Eclipse is something interesting and useful, we might not
> want
> > to retire it, but instead we could mark it as Contrib. This means:
> >
> > * Move JIRA's XWiki Eclipse 'XECLIPSE' project from 'Top Level Projects'
> in
> > 'XWiki Contributed Projects'. This would also help us better manage the
> > number of open issues that are relevant and that we can work on. Right
> now
> > there are 51 issues open for this project.
> > http://jira.xwiki.org/browse/XECLIPSE
> > * Move https://github.com/xwiki/xwiki-eclipse to
> > https://github.com/xwiki-contrib/
> > * Move documentation found on http://xeclipse.xwiki.org/ on a page on
> > extensions.xwiki.org (Installation, User Guide, Release Notes)
> > * Remove xeclipse.xwiki.org
> > * Update xwiki.org to mark this move (menu, footer, download page, All
> > Projects page in order to still make the project accessible)
> >
> > Tell me what you think,
> > Caty
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Move XWiki Office to Contrib

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty


On Thu, May 2, 2013 at 1:05 PM, Thomas Mortagne
wrote:

> +1
>
> On Thu, May 2, 2013 at 11:24 AM, Ecaterina Moraru (Valica)
>  wrote:
> > Hi devs,
> >
> > There is not much activity for XWiki Office since there are no current
> > active developers working on improving the project.
> >
> > Since XWiki Office is something interesting and useful, we might not want
> > to Retire it, but instead we could mark it as Contrib. This means:
> >
> > * Move JIRA's XWiki Office 'XOFFICE' project from 'Top Level Projects' in
> > 'XWiki Contributed Projects'. This would also help us better manage the
> > number of open issues that are relevant and that we can work on. Right
> now
> > there are 63+1 issues open for this project.
> > http://jira.xwiki.org/browse/XOFFICE
> > * Move https://github.com/xwiki/xwiki-office to
> > https://github.com/xwiki-contrib/
> > * Move documentation found on http://xoffice.xwiki.org/ on a page on
> > extensions.xwiki.org (Installation, User Guide, Design, Development,
> > Roadmap, Release Notes)
> > * Remove xoffice.xwiki.org
> > * Update xwiki.org to mark this move (menu, footer, download page, All
> > Projects page in order to still make the project accessible)
> >
> > Tell me what you think,
> > Caty
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Roadmap for XWiki 5.1

[Ecaterina Moraru (Valica)]

On Fri, May 3, 2013 at 12:53 PM, Vincent Massol  wrote:

> Hi devs,
>
> Content Proposal
> ==
>
> Here are some ideas for the XWiki 5.1 roadmap which I have already
> discussed offline with Thomas D, Thomas M, Marius, Caty, Sorin and Manuel!
>
> * Thomas D continues to work on security fixes (especially on reviewing
> Andreas' branch)
> * First usable version of SOLR implementation - Thomas M for the back end,
> Caty for the UI design, Marius for the UI implementation and Sorin/Manuel
> for ensuring the quality of the new SOLR is at least as good as our current
> Lucene search so that we could switch to the SOLR version ASAP (would be
> great to be able to do that at the end of 5.1)
> * Continue weekly BFDs - All
> * Then, by order of priority and time permitting:
> ** Horizontal menu - Marius
> ** Home Page Improvements - Marius + Caty - Needs to be defined precisely
> by Caty/Marius and jiras created
>

A bit ambiguous and I will need to collect some feedback on this item. I
will consider Search to be the priority and after that I will focus on
this.
On the other items +1

Thanks,
Caty



> ** AWM Add the ability to publish an application as an extension - Marius
> ** XWIKI-8495: Unable to edit a page using the WYGIWYG editor after adding
> a dashboard macro to it
> ** XWIKI-7905: Cannot change document title from "inline" mode
>
> Let me know if this is ok for everyone, especially for those for whom I've
> put names next to tasks! :)
>
> If other devs want to work on other stuff please mention your itch here.
>
> I'll then prepare the roadmap page on xwiki.org and ask all devs to
> create JIRA issues related to their tasks and reference them from the
> roadmap page.
>
> Date Proposal
> 
>
> * 5.1M1: 27 May
> * 5.1M2: 10 June (one week shorter than usual because we've been late by
> more than 2 weeks on 5.0 so trying to catch up a bit since we'd like to
> finish the 5.x cycle at year end if possible)
> * 5.1RC1: 24 June
> * 5.1 final: 1st of July
>
> This would mean:
> * 5.2 final: around September (counting holidays)
> * 5.3 final: November (will need to make it a small release)
> * 5.4 final: December
> * 5.5 final: January 2014
>
> WDYT?
>
> Thanks
> -Vincent
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Move XWiki Office to Contrib

[Ecaterina Moraru (Valica)]

Results: 7 "+1", 0 "0" and no -1, the vote is passed.

Vincent and I are starting the move.

Thanks
Caty


On Thu, May 2, 2013 at 2:32 PM, Denis Gervalle  wrote:

> +1
>
>
> On Thu, May 2, 2013 at 12:50 PM, Silvia Rusu 
> wrote:
>
> > Hi,
> >
> > +1
> >
> > Thanks,
> > Silvia
> >
> >
> > On Thu, May 2, 2013 at 1:29 PM, Guillaume Lerouge  > >wrote:
> >
> > > Hi,
> > >
> > > +1 as well.
> > >
> > > Thanks,
> > >
> > > Guillaume
> > >
> > > On Thu, May 2, 2013 at 12:13 PM, Ecaterina Moraru (Valica) <
> > > vali...@gmail.com> wrote:
> > >
> > > > +1
> > > >
> > > > Thanks,
> > > > Caty
> > > >
> > > >
> > > > On Thu, May 2, 2013 at 1:05 PM, Thomas Mortagne
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, May 2, 2013 at 11:24 AM, Ecaterina Moraru (Valica)
> > > > >  wrote:
> > > > > > Hi devs,
> > > > > >
> > > > > > There is not much activity for XWiki Office since there are no
> > > current
> > > > > > active developers working on improving the project.
> > > > > >
> > > > > > Since XWiki Office is something interesting and useful, we might
> > not
> > > > want
> > > > > > to Retire it, but instead we could mark it as Contrib. This
> means:
> > > > > >
> > > > > > * Move JIRA's XWiki Office 'XOFFICE' project from 'Top Level
> > > Projects'
> > > > in
> > > > > > 'XWiki Contributed Projects'. This would also help us better
> manage
> > > the
> > > > > > number of open issues that are relevant and that we can work on.
> > > Right
> > > > > now
> > > > > > there are 63+1 issues open for this project.
> > > > > > http://jira.xwiki.org/browse/XOFFICE
> > > > > > * Move https://github.com/xwiki/xwiki-office to
> > > > > > https://github.com/xwiki-contrib/
> > > > > > * Move documentation found on http://xoffice.xwiki.org/ on a
> page
> > on
> > > > > > extensions.xwiki.org (Installation, User Guide, Design,
> > Development,
> > > > > > Roadmap, Release Notes)
> > > > > > * Remove xoffice.xwiki.org
> > > > > > * Update xwiki.org to mark this move (menu, footer, download
> page,
> > > All
> > > > > > Projects page in order to still make the project accessible)
> > > > > >
> > > > > > Tell me what you think,
> > > > > > Caty
> > > > > > ___
> > > > > > devs mailing list
> > > > > > devs@xwiki.org
> > > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas Mortagne
> > > > > ___
> > > > > devs mailing list
> > > > > devs@xwiki.org
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > ___
> > > > devs mailing list
> > > > devs@xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > ___
> > > devs mailing list
> > > devs@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Move XWiki Eclipse to Contrib

[Ecaterina Moraru (Valica)]

Results: 6 "+1", 0 "0" and no -1, the vote is passed.

Vincent and I are starting the move.

Thanks
Caty


On Thu, May 2, 2013 at 2:31 PM, Denis Gervalle  wrote:

> +1
>
>
> On Thu, May 2, 2013 at 12:12 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
> > Eduard had a concern about visibility and differentiation on the Contrib
> > repo. He said that would be interesting if we could promote some projects
> > there, but I don't know how we could do that.
> >
> > From my part +1
> >
> > Thanks,
> > Caty
> >
> >
> > On Thu, May 2, 2013 at 1:06 PM, Thomas Mortagne
> > wrote:
> >
> > > +1
> > >
> > > On Thu, May 2, 2013 at 11:20 AM, Ecaterina Moraru (Valica)
> > >  wrote:
> > > > Hi devs,
> > > >
> > > > There is not much activity for XWiki Eclipse since there are no
> current
> > > > active developers working on improving the project.
> > > >
> > > > Since XWiki Eclipse is something interesting and useful, we might not
> > > want
> > > > to retire it, but instead we could mark it as Contrib. This means:
> > > >
> > > > * Move JIRA's XWiki Eclipse 'XECLIPSE' project from 'Top Level
> > Projects'
> > > in
> > > > 'XWiki Contributed Projects'. This would also help us better manage
> the
> > > > number of open issues that are relevant and that we can work on.
> Right
> > > now
> > > > there are 51 issues open for this project.
> > > > http://jira.xwiki.org/browse/XECLIPSE
> > > > * Move https://github.com/xwiki/xwiki-eclipse to
> > > > https://github.com/xwiki-contrib/
> > > > * Move documentation found on http://xeclipse.xwiki.org/ on a page
> on
> > > > extensions.xwiki.org (Installation, User Guide, Release Notes)
> > > > * Remove xeclipse.xwiki.org
> > > > * Update xwiki.org to mark this move (menu, footer, download page,
> All
> > > > Projects page in order to still make the project accessible)
> > > >
> > > > Tell me what you think,
> > > > Caty
> > > > ___
> > > > devs mailing list
> > > > devs@xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > >
> > >
> > > --
> > > Thomas Mortagne
> > > ___
> > > devs mailing list
> > > devs@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] New xwiki-platform-wiki/xwiki-platform-wiki-descriptor module

[Ecaterina Moraru (Valica)]

+0

Thanks,
Caty


On Mon, May 13, 2013 at 8:37 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +0
>
> Thanks,
> Marius
>
> On Sat, May 11, 2013 at 11:14 AM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > As you may have seen I've started working again on xwiki-platform-url
> module (http://jira.xwiki.org/browse/XWIKI-3951) and I now need to add
> wiki alias support for it. Right now wiki alias support is in oldcore and
> the url module must not depend on oldcore so I need to extract wiki alias
> support to a new module. I'm proposing to create a xwiki-platform-wiki
> module which should contain in the future all modules related to multi wiki
> handling for stuff not in the model (stuff in the model will go in
> xwiki-platform-model).
> >
> > Right now I'm proposing to have:
> >
> > xwiki-platform-wiki
> >   |_ xwiki-platform-wiki-descriptor
> >
> > where xwiki-platform-wiki-descriptor will implement description of wikis
> as xobjects in wiki pages (XWikiServerClass), i.e. what is currently in
> oldcore's XWiki#findServer.
> >
> > In the future the idea will be to rewrite xwiki-platform-wiki-manager
> and to move it to xwiki-platform-wiki/xwiki-platform-wiki-manager for
> example (or with another name).
> >
> > WDYT?
> >
> > Barring negative feedback I'll try to start working on this in the
> coming week.
> >
> > Thanks
> > -Vincent
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [UX][Iteration] Solr Search Interface

[Ecaterina Moraru (Valica)]

Hi devs,

This is an iteration based on the current work done on the Solr Search.
You can view some overview mockups at
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/SolrSearch/overviewStep8.png
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/SolrSearch/overviewStep1.png

For more detailed mockups, see the proposal
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/SolrSearch

This proposal is keeping all the implemented functionality, adds some
styling and changes a bit the facets zone.

Next step, I want to iterate a bit on some filter elements, but the layout
shouldn't suffer changes.

Let me know what you think.
Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [UX][Iteration] Solr Search Interface

[Ecaterina Moraru (Valica)]

Hi Guillaume,

- the grey background: I used the ColorThemes values;
- facets naming: I haven't iterate of the filters elements, this is not a
final proposal, just an iteration, to get feedback and see what are the
first things that pop out. Right now I listed them just as they are in the
current implementation, but yes we need to add translations keys for them
and make them more user friendly;
- Right now I'm not planning to add anything new in the administration, but
I still haven't made a final proposal for the filters and how they can be
customize (advanced + facets).
- Regarding the 'relative weight of all fields' right now this is handled
by the 'Query Boost' and is found in the 'Advanced Search' section;
- 'reset' button: I already added one in the facets zone 'Refine your
search'

Thanks,
Caty


On Tue, May 14, 2013 at 4:18 PM, Guillaume Lerouge wrote:

> Hi Caty,
>
> this looks good. The one thing I'm not sure about is the grey background
> behind result snippets, I find it a bit dark (it might be a matter of
> personal preference). Also, I think the facets should be more explicit
> ("Language" instead of "Lang", "Creation date" instead of
> "creationDate"...).
>
> I'd also like to see an interface proposal for the administration section,
> including the ability to alter the relative weight of all fields (and a
> "reset" button!).
>
> Thanks,
>
> Guillaume
>
> On Tue, May 14, 2013 at 12:01 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
> > Hi devs,
> >
> > This is an iteration based on the current work done on the Solr Search.
> > You can view some overview mockups at
> >
> >
> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/SolrSearch/overviewStep8.png
> >
> >
> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/SolrSearch/overviewStep1.png
> >
> > For more detailed mockups, see the proposal
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/SolrSearch
> >
> > This proposal is keeping all the implemented functionality, adds some
> > styling and changes a bit the facets zone.
> >
> > Next step, I want to iterate a bit on some filter elements, but the
> layout
> > shouldn't suffer changes.
> >
> > Let me know what you think.
> > Thanks,
> > Caty
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Remove all duplicated information from folders names on git repositories

[Ecaterina Moraru (Valica)]

I'm no big developer, but one of the reasons I changed from Windows to Mac
was using the cygwin (the other was testing the UI, but for me Mac was just
an over expensive thing). Actually after we migrated to git, I remember to
have many problems trying to commit something and I was really relieved to
change my OS, but kind of reluctant since we had then many users on Windows
(and in my mind I had somehow to share their environment needs).

I would be +1 in order for us to be as accessible as we can regarding
developers environments and also because it's shorter and easier to read.

I don't know how much work there is, if this is a priority and all the
things it will break. It will be very nice to hear some thoughts from other
members of our community (I would be very interested also in the opinion of
our GSOC students for example, or any other beginner contributor, not
necessarily Java and also worldwide).

Thanks,
Caty


On Thu, May 16, 2013 at 6:44 PM, Vincent Massol  wrote:

>
> On May 16, 2013, at 5:10 PM, Sergiu Dumitriu  wrote:
>
> > On 05/16/2013 10:25 AM, Vincent Massol wrote:
> >> I'm rather -0 ATM and very close to -1 because:
> >>
> >> 1) I haven't heard from a windows dev for a long time, I don't think
> that happens that often
> >
> > Maybe they weren't motivated enough to search for a solution, and just
> > gave up?
> >
> >> 2) It's a *huge* change and it should definitely not be done lightly.
> We would need to plan a period like 2 full days, all devs would need to
> stop working on what they do and help out. For example all pages on
> xwiki.org having some github links are going to be broken and will need
> to be updated (that's probably around hunded of pages overall)
> >
> > So postponing it will solve what?
>
> No
>
> >> 3) Windows devs have a simple solution which is to use cygwin so it's
> not a blocker
> >
> > Enforcing a special environment is something we try to avoid as much as
> > possible.
>
> Agreed
>
> > If the checkout doesn't work out of the box with the user's favorite
> > tool, will they have the motivation to search for an explanation, read
> > our documentation, set up the "right" tool, and learn to use a new
> > environment that's not (perceived to be) as good as what they already
> > know and are efficient with?
> >
> > This is not a "simple" solution, IMHO. XWiki Development should be
> > environment-independent.
>
> Sure but not at all cost.
>
> For example there are tons of dev environments we don't support. It's not
> because they exist that we need to support them.
>
> We need to remember that these dev envs must be first and foremost to make
> the life of those who code a lot for xwiki simpler.
>
> Supporting more env means more work. It's the same as supporting N
> databases or N browsers…
>
> Right now if we do the sam exercise as we did for the databases and the
> browsers we would never support the windows dev environment based on how
> many potential devs using windows we have or that we'll get…
>
> It's a nice to have but far from critical. Again, the only person I know
> who asked about this was Florin. And that was in 7 years….
>
> Thanks
> -Vincent
>
> >> Thanks
> >> -Vincent
> >>
> >> On May 16, 2013, at 4:14 PM, Thomas Mortagne 
> wrote:
> >>
> >>> Reviving http://markmail.org/message/hlnqke3igkbec332 for as an
> official vote.
> >>>
> >>> We have waited way too long and I think we really need to find a
> >>> solution even if none of the committers use Windows since a long time.
> >>> Every time a Windows dev even think of contributing he is very quickly
> >>> discouraged...
> >>>
> >>> As a reminder the issue is that working on XWiki source code is a pain
> >>> for MS Windows developers because of the (impossible to understand I
> >>> agree) limitation on path size.
> >>>
> >>> So the idea is to find a new logical rule to drastically shorten our
> >>> paths and Sergiu proposed the following: remove duplicated information
> >>> from our paths to maven modules.
> >>>
> >>> Here is an example:
> >>>
> >>>
> xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro
> >>> (131 chars)
> >>>
> >>> would become
> >>>
> >>> core/rendering/transformations/macro (36 chars)
> >>>
> >>> So WDYT ?
> >>>
> >>> Here is my +1
> >
> > Big +1 from me.
> >
> >>> I also find it nicer when navigating using cd and tab in a unix shell
> anyway.
> >>>
> >>> Planning to do it in 5.1 if everyone agree.
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Notice] Moving Solr search pages to a separate space

[Ecaterina Moraru (Valica)]

+1 for 3

Thanks,
Caty


On Mon, May 20, 2013 at 7:29 PM, Vincent Massol  wrote:

>
> On May 20, 2013, at 6:28 PM, Vincent Massol  wrote:
>
> > Hi Marius,
> >
> > On May 20, 2013, at 5:19 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> >> I'm going to perform the following rename.
> >>
> >> XWiki.SolrSearchAdmin -> Solr.Administration
> >> Main.SolrSearch -> Solr.WebHome
> >>
> >> and I'm going to add Solr.Translations .
> >>
> >> Let me know if you think this is a bad move,
> >
> > I don't think it's especially bad but we need to have an overall
> consistent solution for all search implementations.
> >
> > We have 3 impls:
>
> 3 impls and one Search application to be precise.
>
> Thanks
> -Vincent
>
> > * database: Main.DatabaseSearch
> > * lucene: Main.LuceneSearch, XWiki.LuceneSearchAdmin,
> XWiki.SuggestLuceneService
> > * solr: Main.SolrSearch, XWiki.SolrSearchAdmin
> >
> > We have several choices I think:
> >
> > 1) Move all pages in the XWiki space
> >
> > 2) Move each search impl in a space named after the impl:
> >
> > Possibility A:
> > ** DatabaseSearch
> > ** SolrSearch
> > ** LuceneSearch
> > Possibility B:
> > ** XWiki.DatabaseSearch
> > ** Solr.Search
> > ** Lucene.Search
> >
> > 3) Move all search impls into a Search space:
> > * Search.Solr*
> > * Search.Database*
> > * Search.Lucene*
> > * Search.Search (current Main.Search page)
> >
> > My preferences goes to either 2B) or 3) with a small preference for 3).
> >
> > The advantage of 3) is that we can we can have everything related to
> search in the Search space which makes them easy to find. Option 2) will
> mean scattered search pages in 4 spaces: one for the search app, and 2 or 3
> others for the implementations. Ideally we would have sub spaces of Search
> but in the meantime IMO it's fine to have 3).
> >
> > Another way of viewing this is that there's only 1 search app (with
> multiple SPI implementations) and thus it's logical that this app puts its
> pages into a single space (called Search).
> >
> > Thanks
> > -Vincent
> >
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Reminder] BFD #22 today (RESULT)

[Ecaterina Moraru (Valica)]

I'm ok for the +1200 goal if everyone agrees.

Another path would be to chose 3 years, keep it constant and start cleaning
improvements+ideas.

Thanks,
Caty


On Fri, May 24, 2013 at 10:11 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On May 24, 2013 9:38 AM, "Vincent Massol"  wrote:
> >
> > We've had a great BFD yesterday! 24 bugs closed!
> >
> > http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+22
> >
> > This allowed us to close the 1000 days gap :)
> >
> > What should be our next goal now? :)
> >
> > Some stats:
> > * 1095 days (ie 3 years) --> -17 !! (this means we've succeeded in
> reaching 3 years already)
> > * 1200 --> +54 (behind by 54 bugs)
> > * 1500 --> +228
> >
> > I propose that we set 1200 days as our new goal, WDYT?
>
> +1
>
> Thanks,
> Marius
>
> >
> > Thanks
> > -Vincent
> >
> > On May 23, 2013, at 8:45 AM, Vincent Massol  wrote:
> >
> > > Hi everyone,
> > >
> > > Today is BFD22. Our goal is still to have more bugs closed than created
> for the past 1000 days!
> > >
> > > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
> > >
> > > Some stats:
> > > - BFD 19: 53 bugs behind before it started
> > > - BFD 20: 36 bugs behind before it started
> > > - BFD 21: 39 bugs behind before it started
> > > - BFD 22: 20 bugs behind, so we're catching up!
> > >
> > > Let's try to close the gap during this BFD.
> > >
> > > Here's the BFD#22 dashboard to follow the progress during the day:
> > > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11593
> > >
> > > Let's close the gap, we could even close it today if we're good enough!
> > >
> > > Thanks
> > > -Vincent
> > >
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [UX][Iteration] Solr Search Proposal 2

[Ecaterina Moraru (Valica)]

Hi devs,

This is an _alternative_ proposal to what is currently implemented in our
Solr Search. For the current implementation there is another proposal [1]
that is already partially integrated.

The current Solr implementation is focused on Facets search. This means
that not all possible filters are revealed, but just those that match the
current query, letting the user narrow the results.

This alternative proposal will display all the possible filters and will
let the user make his own selections instead of auto-selecting for him.
This proposal is inspired from JIRA's filters.

Although being able to customize and to refine the filters to exactly what
you need will be great for developers and advanced users, please keep in
mind that normal users will be more comfortable with the faceted search
since it's more 'standard' in the wild (in the e-commerce and
product-related websites). Advanced user know exactly what they want in
comparison with normal users that rely on the first 3 results.

You can see a screenshot at
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/SearchProposal3/overview3.png

and read the whole proposal at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/SearchProposal3

Thanks,
Caty

[1] http://xwiki.markmail.org/thread/du4dknibbgxx6pdn
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [GSOC: mobile client] Welcome to Buddhiprabha Erabadda

[Ecaterina Moraru (Valica)]

Welcome Buddhiprabha!

Have a productive and fun summer :)

Thanks,
Caty


On Tue, May 28, 2013 at 9:46 AM, Thomas Mortagne
wrote:

> Welcome Buddhiprabha !
>
> This project looks promising.
>
> On Tue, May 28, 2013 at 8:19 AM, Ludovic Dubost  wrote:
> > Hi all,
> >
> > I'd like to welcome Buddhiprabha Erabadda to our community on the GSOC
> > Mobile Client project, which I will mentor.  Buddhiprabha Erabadda is our
> > only GSOC student this year as we were not enough satisfied with the
> > quality of the other proposals. No pressure Buddhiprabha.
> >
> > The objective of Buddhiprabha will be to help me getting the best
> possible
> > XWiki Mobile out the door on Android and iOS, with particularly
> > notifications implemented. We will also work with Caty on her proposals
> for
> > the mobile app:
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileApp
> >
> > We will also add improvements to the XWiki REST Api during the project
> > especially to improve performance. There is already a pull request to get
> > more page data in one request (
> > https://github.com/xwiki/xwiki-platform/pull/111 )
> >
> > We have a jira project to track tasks:
> http://jira.xwiki.org/browse/XMMORPHO
> >
> > Welcome Buddhiprabha to XWiki
> >
> > Ludovic
> >
> > --
> > Ludovic Dubost
> > Founder and CEO
> > Blog: http://blog.ludovic.org/
> > XWiki: http://www.xwiki.com
> > Skype: ldubost GTalk: ldubost
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Remove the GIF version of the Silk icons

[Ecaterina Moraru (Valica)]

+1
Thanks,
Caty


On Wed, May 29, 2013 at 9:26 AM, Vincent Massol  wrote:

>
> On May 29, 2013, at 4:29 AM, Sergiu Dumitriu  wrote:
>
> > Hi devs,
> >
> > Silk is officially a PNG-only icon set. We initially used a GIF version
> > of the icons so that we can have some transparency in IE6. Since we
> > dropped support a long time ago for IE6, we introduced the PNG version
> > of the Silk icons as resources in 3.4 (XWIKI-7326). We've fixed all the
> > usages of the GIF icons from the platform code, so I think it's time to
> > drop the GIF icons from the non-legacy distribution.
> >
> > Proposal: move the GIF silk icons into a a web-legacy module, merged
> > into the enterprise war only when the legacy profile is enabled.
>
> +1
>
> Thanks
> -Vincent
>
> > --
> > Sergiu Dumitriu
> > http://purl.org/net/sergiu/
> >
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Alternative Activity Stream experiment

[Ecaterina Moraru (Valica)]

On Mon, Jun 3, 2013 at 12:15 PM, Ludovic Dubost  wrote:

> Hi,
>
> While working on the mobile application I needed a notification system that
> would send enough but not to many notifications of changes in a wiki. Also
> I needed the message to be short.
>
> In the end I looked at changes every five minutes and I constructed a short
> message depending on the amount of changes (if only one page is added then
> send the page title, if multiple pages are changes in one wiki send the
> wiki names and the number of changes, etc..)
>
> After using this for a while on my mobile I found the result quite
> interesting and I thought this could also apply to the activity stream.
>
> Here comes an activity stream experiment based on this method:
>
> http://www.xwiki.org/xwiki/bin/view/Main/ActivityStreamDemo (on a multi
> wiki)
> http://incubator.xwiki.org/xwiki/bin/view/Main/ActivityStreamDemo (on a
> single wiki)
>

http://incubator.myxwiki.org/xwiki/bin/view/Main/ActivityStreamDemo


>
> Additionally this method allows to implement it quite efficiently, as you
> can see at the bottom of the page. It was possible to make this display
> with only 2 queries (plus loading of documents for the security checks,
> which could in the end be the most costly). One queries finds the intervals
> of 5 (or more) minutes in which there are data. From there we know how much
> data we need from the activity stream and can retrieve all that data in one
> query. Finally group by group we construct the message display. The fact
> that you can run this in 2 queries is very important as it means you can
> have steady performance both for very active wikis but also for wikis that
> have much less or much older activity. One of the big problems of activity
> stream displays is that you never initially know how much data you need to
> display results.
>
> By clicking on the group you can load in ajax the details of the changes.
>
> You can also change the group delay and the number of groups displayed.
> Here 60 minutes showing 40 groups
>
> http://www.xwiki.org/xwiki/bin/view/Main/ActivityStreamDemo?max=40&delay=60
>
> What is interesting with this system is that the use could decide the delay
> so that he gets a general view of the activity over a long period of time.
> You could display a couple weeks with a 24 delay and if you click on the
> day you show by groups of 30 minutes. This opens a lot of possibilities.
>
> You could also get into the details of the last hour, then be less detailed
> for the less recent changes.
>
> Food for thoughts for the redesign of the activity stream.
>
> Ludovic
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XWiki5 and IE8 support

[Ecaterina Moraru (Valica)]

Hi,

Changed position to
https://github.com/xwiki/xwiki-platform/commit/baea818ce28752aac41619e2c1779f0eb85ef258

Thanks,
Caty


On Mon, Aug 19, 2013 at 5:11 PM, Clemens Klein-Robbenhaar <
c.robbenh...@espresto.com> wrote:

>
> I tested it, and it does not work for me.
> It seems the
>
> is only effective if it is placed before the first 
> element in the head, i.e. here after the title latest.
> In its current place it simply comes too late. Moving it up should help.
>
>
> Fixing it apache-side with a header is of course an option
> that "simply works for me" now.
>
> Thanks everyone for all the pointers,
> Clemens
>
>
> > Hi,
> >
> > I've fixed this in http://jira.xwiki.org/browse/XWIKI-8907
> > Sorin when you will test 5.2M2 would be great if you could check it out.
> >
> > Thanks,
> > Caty
> >
> >
> > On Fri, Aug 16, 2013 at 6:46 PM, Dan Rodriguez 
> wrote:
> >
> >> Clemens,
> >>
> >> Manually switching to the proper IE standards mode is a quick fix, but I
> >> don't think it will solve your problem completely.  You may have to
> switch
> >> it out of Quirks mode again and again in the future. Pre IE10 versions
> will
> >> render pages in Quirks mode for many reasons (see
> >> http://hsivonen.iki.fi/doctype/ie-mode.pdf).  For instance, if there
> is an
> >> xml declaration before the doctype, it will goes straight to Quirks
> mode.
> >>  XWiki does just that:
> >>
> >> 
> >>  >>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> >>
> >> I found a fix in a sample config file provided by HTML5 Boilerplate (
> >> http://html5boilerplate.com/).  This fix ensures all IE (<10) who
> navigate
> >> to your wiki, will see pages rendered with the proper IE Standards mode.
> >>
> >> If you are using Apache HTTP, you can drop this snippet in your Apache
> >> config file, create an .htaccess file, or create a .conf file with this
> >> snippet in the conf.d folder (preferable method):
> >>
> >> #
> >>
> >>
> ##
> >> # # INTERNET EXPLORER
> >>#
> >> #
> >>
> >>
> ##
> >>
> >> #
> >>
> >>
> --
> >> # | Better website experience
> >>|
> >> #
> >>
> >>
> --
> >>
> >> # Force IE to render pages in the highest available mode in the various
> >> # cases when it may not: http://hsivonen.iki.fi/doctype/ie-mode.pdf.
> >>
> >> 
> >> Header set X-UA-Compatible "IE=edge"
> >> # `mod_headers` can't match based on the content-type, however, we
> only
> >> # want to send this header for HTML pages and not for the other
> >> resources
> >>  >>
> >>
> "\.(appcache|crx|css|eot|gif|htc|ico|jpe?g|js|m4a|m4v|manifest|mp4|oex|oga|ogg|ogv|otf|pdf|png|safariextz|svgz?|ttf|vcf|webapp|webm|webp|woff|xml|xpi)$">
> >> Header unset X-UA-Compatible
> >> 
> >> 
> >>
> >>
> >> If you're using Nginx or something else, HTML5 Boilerplate provides
> config
> >> examples for other server types here: https://github.com/h5bp
> >>
> >> Best,
> >> Dan
> >>
> >>
> >> On Fri, Aug 16, 2013 at 11:03 AM, Clemens Klein-Robbenhaar <
> >> c.robbenh...@espresto.com> wrote:
> >>
> >>>
> >>> Hello Sorin,
> >>>
>  Hello Clemens,
> 
>  Make sure you are not using IE Compatibility mode. As far as  I know,
> >> the
>  bottom tabs like comments, attachments look ugly because Compatibility
> >>> Mode
>  is enabled.
> >>>
> >>> Ahem, cough, cough, that was actually the cause of my problems :-/
> >>>
> 
>  IE8 is supported by XWiki 4 and 5, so contributions are more than
> >>> welcomed.
>  Before reporting an issue or making a pull request, please check
>  http://jira.xwiki.org if they have not been already reported.
> 
> >>>
> >>> In case I really start working on something I will better check the
> issue
> >>> tracker before ...
> >>> however for now everything looks ok from here.
> >>>
> >>> Thanks,
> >>> Clemens
> >>>
>  Best regards,
>  Sorin B.
> 
> 
>  On Thu, Aug 15, 2013 at 1:13 PM, Clemens Klein-Robbenhaar <
>  c.robbenh...@espresto.com> wrote:
> 
> >
> > I am wondering about the support for IE 8 in XWiki5.x
> >
> > There are a few layout bugs in XWiki5 (actually been there in XWiki4
> >> as
> > much as I can remember)
> > that do not directly hamper functionality but simply look ugly, like:
> >
> >  - scrollbars around the outer frame of the Editor
> >  - tabs for comments, etc at the bottom of the page
> >are stacked on top of each other instead of displayed left to
> right
> >
> > I am thinking of patching things for my instance so they look better
> >> in
> > IE8,
> > and I am wondering if IE 8 is still officially supported, and if yes,
> > if patches for such layout glitches are of any 

Re: [xwiki-devs] XWiki5 and IE8 support

[Ecaterina Moraru (Valica)]

Hi,

Thanks for testing it :)
Caty


On Tue, Aug 20, 2013 at 11:07 AM, Clemens Klein-Robbenhaar <
c.robbenh...@espresto.com> wrote:

> Hi,
>
>  just testet it again, and this time it works like a charm :)
>
> Thanks,
> Clemens
>
> > Hi,
> >
> > Changed position to
> >
> https://github.com/xwiki/xwiki-platform/commit/baea818ce28752aac41619e2c1779f0eb85ef258
> >
> > Thanks,
> > Caty
> >
> >
> > On Mon, Aug 19, 2013 at 5:11 PM, Clemens Klein-Robbenhaar <
> > c.robbenh...@espresto.com> wrote:
> >
> >>
> >> I tested it, and it does not work for me.
> >> It seems the
> >>
> >> is only effective if it is placed before the first 
> >> element in the head, i.e. here after the title latest.
> >> In its current place it simply comes too late. Moving it up should help.
> >>
> >>
> >> Fixing it apache-side with a header is of course an option
> >> that "simply works for me" now.
> >>
> >> Thanks everyone for all the pointers,
> >> Clemens
> >>
> >>
> >>> Hi,
> >>>
> >>> I've fixed this in http://jira.xwiki.org/browse/XWIKI-8907
> >>> Sorin when you will test 5.2M2 would be great if you could check it
> out.
> >>>
> >>> Thanks,
> >>> Caty
> >>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Integrate Workspaces by default in XWiki's default XAR

[Ecaterina Moraru (Valica)]

;
> Just a minor detail: when you say above "given to all users", this can be
> replaced by "given to users of a specific group" in some cases.
>
> The only issue I can see is the addition of 2 new rights in the current
> Rights UI for 5.2 final. How do you envision this?
>
> I guess there are 4 quick solutions (that do not entail a full Rights UI
> rewrite):
> A - allow horizontal scrolling to see all rights. While this is not
> perfect from a UI POV at least it allows us to progress and improve the
> Rights UI in the near future.
> B - modify a bit the Rights UI but without a full rewrite (for example by
> putting the rights in a select box and the users selects the right to
> display). Again this would be a quick fix while waiting for the full Rights
> UI rewrite.
> C - add a SubWiki Admin section in the Admin page and put those 2 new
> rights in there FTM. When we do the Rights UI rewrite, we can then move
> them there (or not).
> D -  have 2 special pages with a Rights Object attached to them to
> represent the who's allowed to add a subwiki and use users isolation and
> have the subwiki creation wizard use thoses pages. This would be while
> waiting for the new Rights UI rewrite and/or the addition of those 2 new
> rights.
>
> My preference goes to either A, C or D. I think C might be the best one
> even on the longer term since it clearly creates a section proper for
> subwiki administration.
>
> WDYT?
>

My preference goes to A or C. My first reaction was clearly A, but then
I've seen what long names the new rights have :) We surely need to remake
the Rights UI, but this is not a priority this release.
I will go with option C because the 2 new rights are related mostly to the
main wiki, will be changed by a very selected hand of people (so they are
not 'global interest' rights, so doesn't make sense to affect all the
rights tables) and I think is much more easy to implement this way (by
adding a new Administration category). The downside is that we split
related functionality. The new Rights UI need to consider the scalability
aspect.

Thanks,
Caty


>
> Thanks
> -Vincent
>
> > Regards,
> >
> > Louis-Marie
> >
> >
> >
> > 2013/8/2 Jean Coury 
> >
> >> Hello,
> >>
> >> Firstly I couldn't read everything because there is a lot of off topics
> so
> >> forgive me if some of the following should not be here. If you have no
> time
> >> go the last line directly.
> >>
> >> I've been struggling with client with all those terms wich look like the
> >> same (e.g. Main wiki, sub-wiki and then Workspace, Space) and the fact
> that
> >> Workspace have "Work" into it and so is not really friendly to the
> client's
> >> users. My first proposal would have been "Portal > Wiki > Space > Page"
> in
> >> order to keep the basics and to find an easy way to describe the main
> wiki.
> >> Then I read multiple threads and have a look to the competitors and
> >> find-out that Home as a first term would be great and less technical
> than
> >> Portal. Moreover Portal is full of connotations and do not show the
> >> possibility to customize it.
> >>
> >> "There is no place like Home" don't you think?
> >> Proposal : Home > Wiki > Space > Page
> >>
> >> Then I looked at the proposal made by Cathy on
> >>
> >>
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImprovements
> >> I would have picked B but I strongly dislike the fact that the product
> can
> >> be two things at a time and so*
> >> => I vote for* *D*.
> >>
> >> Regards,
> >>
> >>
> >> 2013/8/1 Guillaume "Louis-Marie" Delhumeau 
> >>
> >>> I vote for D (not B anymore).
> >>>
> >>> 2013/8/1 Guillaume Lerouge 
> >>>
> >>>> Hi,
> >>>>
> >>>> I like this option. Waiting for further agreement on the sister thread
> >>>> about workspaces, I think this is a good solution for XE 5.2.
> >>>>
> >>>> The downside is that we lose a bit of simplicity, but it's a tough
> >> topic.
> >>>>
> >>>> Guillaume
> >>>>
> >>>> On Wed, Jul 31, 2013 at 4:31 PM, Ecaterina Moraru (Valica) <
> >>>> vali...@gmail.com> wrote:
> >>>>
> >>>>> On Tue, Jul 30, 2013 at 5:22 PM, Vincent Massol 
> >>>>> wrote:
> >>>>>

Re: [xwiki-devs] [Brainstorming] Changing from "Wiki" to "SubWiki", is that good?

[Ecaterina Moraru (Valica)]

On Mon, Sep 2, 2013 at 1:02 PM, Vincent Massol  wrote:

> Hi devs,
>
> We've recently discussed about renaming the notion of (sub)wiki from
> "wiki" to "subwiki". We've discussed this in the context of integrating
> creation of (sub)wikis by default in the platform and in XE. So the latest
> discussion seemed to agree about:
> * Calling the whole system a "Wiki"
> * Calling each (sub)wikis a "SubWiki"
>
> Now, I was working on updating the new model branch I have created to
> align to this and to rename my Server class to a Wiki class and my existing
> Wiki class to a SubWiki class…
>
> I've realized that aligning our API on this is a huge task since we have
> tons of APIs using the word "wiki". Just to cite 3:
> * WikiReference (reference)
> * WikiComponentScope.WIKI (wiki component)
> * WikiDeletedEvent (bridge)
>
> It's a bit everywhere and changing that seems too big a task IMO.
>
> Thus we have 2 real choices IMO:
> * Agree that the UI has a different wording than the API: SubWiki for the
> UI and Wiki for the API
> * Don't use subwiki in the UI and keep using Wiki in the UI and find
> another word to represent the whole system (System/Portal/Wiki System/WMS =
> Wiki Management System/Home/etc).
>

As already stated in the previous workspace mails, I prefer the wiki + home
variant.

Thanks,
Caty


>
> WDYT?
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Postpone 5.2M2 release by 2 days

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty


On Thu, Sep 5, 2013 at 7:51 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Wed, Sep 4, 2013 at 6:13 PM, Vincent Massol  wrote:
> > Hi devs,
> >
> > As discussed with some of you on IRC I'm proposing to postpone the 5.2M2
> release till Wednesday (Marius is RM BTW).
> >
> > This should allow us to commit stuff that's on the roadmap for M2 and
> then tune them/improve them for the RC1 release.
> >
> > Thanks
> > -Vincent
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Stop supporting XWiki Manager

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty


On Wed, Sep 11, 2013 at 9:34 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Wed, Sep 11, 2013 at 12:58 PM, Guillaume "Louis-Marie" Delhumeau
>  wrote:
> > Since Enterprise embeds Workspaces by default since 5.2-m2, I think it
> does
> > not make any sense to release XWiki Manager (XEM) anymore.
> >
> > The build is currently broken (because of the XAR organization changes).
> >
> > So I propose to remove XWiki Manager:
> > - stop releasing it
> > - move the github repo to xwiki-contrib/retired
> > - update manager.xwiki.org to explain the changes in XWiki 5.2.
> > - move the manager jira to the retired category
> > - remove the build in ci.xwiki.org
> >
> > Here is my non-binding +1.
> >
> > LM
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposals] Menu improvements when Workspaces activated

[Ecaterina Moraru (Valica)]

On Thu, Sep 12, 2013 at 2:27 PM, Vincent Massol  wrote:

> You forgot one proposal which I like:
>
> == Proposal D ==
>
> * Generalize the XWiki home (the logo at the top left)
> * When you click on the logo you get to the home of the current wiki
> * The proposal is about generalizing that feature to allow navigating
> either to the wiki home, to the main wiki or to the list of other wikis
> * It could be done by showing a menu arrow when the mouse hover over the
> logo and when the mouse moves over the arrow, show a menu with first entry
> = "Main Wiki" (or "Home Wiki" if you prefer) and a second entry with "Wiki
> Index" for example.
>
> What I like with this is that the user is already used to use the logo as
> a way to navigate to the home of wiki.
>
> Thanks
> -Vincent
>
> On Sep 12, 2013, at 12:31 PM, Guillaume Louis-Marie Delhumeau <
> gdelhum...@xwiki.com> wrote:
>
> > Hi developers.
> >
> > Tuesday evening, after trying to fix all issues that integrate Workspace
> in
> > XE made, I had a bit of time to work on this JIRA:
> > http://jira.xwiki.org/browse/XWIKI-9341 "Menu improvements when
> Workspaces
> > activated".
> >
> > The idea was to quickly implement the Caty's proposal for M2 (which was
> > scheduled for the day after). I made it and I sent a pull request. I have
> > also sent a mail to Vincent to show him my work.
> >
> > == Proposal A ==
> > There is some screenshots (Proposal A):
> > Logged as admin:
> > http://xwiki.kephpage.net/proposals/workspaces-menus/new-home-menu.png
> > Not logged as admin:
> >
> http://xwiki.kephpage.net/proposals/workspaces-menus/new-home-menu-non-admin.png
> >
> > You can get it from this commit:
> >
> https://github.com/xwiki/xwiki-platform/commit/8c1c1bac2cde30f9024525e50249382e3d2c4138
> > (except that I have changed the wiki icon for this screenshot)
> >
>

So I just want to link again the 'Home Menu' full proposal
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

In your screenshot is:
* Home
** Administer Main Wiki
** Wiki Directory

What it was proposed:
* Home
** Administration
** Wikis Index
** 
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/HomeMenu/HomeMenuSubWiki.png
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/HomeMenu/HomeMenuMain.png

"Administer Main Wiki" was proposed as:
- "Administration"
or
- "Administer Home" / "Administrate Home"
depending if you were located in Home or in the (sub)wiki.


> > We though this menu was confusing and not consistent with the current
> menus:
> > - Why do we have a link to the *main wiki* administration when we are in
> a
> > (sub)wiki? Does it make sense?
>

As an administrator I think it has sense to be able to administrate both
the current (sub)wiki you are visiting and also the home (mainwiki).


> > - Why do we have the main wiki (called Home) in the left of the current
> > wiki, space and page? The fact that there is actually a "main" and
> several
> > "sub" wikis is only due to the implementation. We could imagine, in the
> > future, a new implementation where there is no distinction between "main"
> > and "sub", but where we have an independent "system" that allows the
> users
> > to create and manage their wikis. Then, it seems better to call the menu
> > "System" or "XWiki".
>

The "main" and "sub" is transformed in "home" and "wiki". The menu displays
the hierarchy: Home > Wiki > Space > Page and is also consistent with the
way our cascading works for our preferences (rights, etc.)

> - When we don't have the admin right on the main wiki, we only have a
> > single item in this menu, meanwhile wiki, space and page has more
> content.
> > It does not look good.
>

In the proposal there is
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/HomeMenu/HomeMenuSubWiki.png
Although this is not currently implemented, the idea is that we could also
list for example the "Users Index" a.k.a the "User Directory" (especially
since workspaces have only global users and the directory is located in the
main wiki). In the proposal I've used " *** Index" in order to have a
consistency between the index/directory applications naming.

So the idea is that even if now there is only one entry in the submenu, we
could have more entries (if they are related to the Home (mainwiki)).


> > - If you are in the main wiki, you have "Administer main wiki" twice:
> once
> > in the Home menu, once in the Wiki menu.
> > - The left menu has too many items.
>

If you are on the main wiki, the menu changes from
* Menu in the (sub)wiki
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/HomeMenu/HomeMenuSubWiki.png
in
* Menu in the Home (mainwiki)
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/HomeMenu/HomeMenuMain.png

The left menu contains items related to 'spatial organization of content'
inside XWiki (wikis, spaces, pages)


> >
> > == Proposal B ==
> > Vincent thought it was not good enough to be integrated in 5.2M2, so we
> > started to iterate 

Re: [xwiki-devs] [Proposals] Menu improvements when Workspaces activated

[Ecaterina Moraru (Valica)]

yes, the 'Index' was proposed in order to have consistency between the
entries: 'Documents Index', 'Users Index', 'Applications Index', 'Wikis
Index', etc. (Obs. the Applications Index is not yet implemented, but the
entry should provide a livetable that allows filtering for entries of a
certain type: documents, users, wikis, etc.)

the alternative was to have 'Documents Directory', 'Users Directory',
'Applications Directory', 'Wikis Directory'.

I think that the 'Index' version is much shorter than the 'Directory',
while having a more generic meaning. Alternatives: 'List', etc.

Just for the record, the proposal uses the "plural" form of the entities.
It would be great if an english speaker could give its opinion on the
correct form.

Thanks,
Caty


On Thu, Sep 19, 2013 at 12:57 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhum...@xwiki.com> wrote:

> 2013/9/19 Ludovic Dubost 
>
> > Hi,
> >
> > This looks good. I have a comment though on the "User index". I'm sorry
> if
> > this was already discussed.
> >
> > My first reaction was that it's not really telling me what it is. I
> suppose
> > it's the "User Directory". Maybe my english is wrong, but why not just
> > calling it "User Directory" like it is right now.
> >
> > I suppose the reason is to have "Document Index" followed by "User
> Index",
> > but I don't think it's the same thing.
> >
>
> Yes, the idea was to have a consistency between names in the menu. Is that
> true Caty?
>
> But my english is not good enough to say if it is correct or not...
>
>
> >
> > Ludovic
> >
> >
> > 2013/9/18 Guillaume "Louis-Marie" Delhumeau 
> >
> > > You can see some screenshots in the JIRA:
> > > http://jira.xwiki.org/browse/XWIKI-9475
> > >
> > > Thanks,
> > > LM
> > >
> > >
> > > 2013/9/18 Fabio Mancinelli 
> > >
> > > > On Thu, Sep 12, 2013 at 2:39 PM, Guillaume "Louis-Marie" Delhumeau
> > > >  wrote:
> > > > > Indeed, the proposal A was based on
> > > > >
> > >
> >
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PortalMenuinstead
> > > > > of
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu.
> > > > >
> > > > > Then I suggest to call your proposal: E.
> > > > >
> > > > > Let me recap:
> > > > >
> > > > > - Proposal A : Tiny "Home menu".
> > > > >
> > > > > - Proposal B : XWiki right side menu
> > > > >
> > > > > - Proposal C : Wiki crowded menu
> > > > >
> > > > > - Proposal D : Add a menu on the top-left logo.
> > > > >
> > > > > - Proposal E : The complete "Home menu" proposed by Caty.
> > > > >
> > > >
> > > > I like both B and E.
> > > >
> > > > I liked E because it keeps the left area the same. Since all the
> wikis
> > > > are equal, so it should be the area for manipulating it. But since
> the
> > > > main wiki is "more equal" than the others, it's good to show it. I
> > > > understand the problem of E but I cannot think of another place where
> > > > to put this menu.
> > > >
> > > > What I don't like of E is just the "home" label.
> > > > Home will become too overloaded. Every wiki has a home, now with that
> > > > menu there will be a home which is the home of the main wiki.
> > > >
> > > > I cannot think of a better alternative besides "Main" that suffers of
> > > > the same problem (since every wiki has a Main space).
> > > > Maybe calling it "XWiki" can really be a possible solution.
> > > >
> > > > -Fabio
> > > >
> > > >
> > > >
> > > >
> > > > > --
> > > > >
> > > > > About E:
> > > > > Some issues IMHO:
> > > > > - The amount of menus is not the same when you are in the home wiki
> > and
> > > > > when you are in the subwiki.
> > > > > - Do we really need to have a direct access to the documents, the
> > users
> > > > and
> > > > > the applications of the home wiki when you a

[xwiki-devs] [Proposal] Use Junco Skin for xwiki.org

[Ecaterina Moraru (Valica)]

Hi devs,

For the past weeks I've been working on a skin based on Bootstrap[1]. You
can read more about it and test the new Junco Skin at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin

This proposal is about using the Junco Skin (Blueberry
Theme)
for xwiki.org.
I prepared some responsive screenshots for the xwiki.org Homepage and an
Extension page.
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgJuncoHomepage

This is my +1

Please report any issues on https://github.com/evalica/bootswatch/issues

__Advantages__
- a change is always welcomed, shows the users there is activity on the
website;
- the skin is responsive;
- by using Bootstrap we have the whole framework's power to use (grids,
components, etc.);
- we have the chance to test a bit the skin in production and see the
possible bugs, in order to later integrate;
- IMO the skin looks nice :)

__Disadvantages__
- the only disadvantage is that there will be bugs and they will take some
time to be detected and fixed;

__Platform integration problems__
1. currently the new skin uses the HTML5 doctype. This is needed if we were
to use some Bootstrap JS components (carousel, menus, etc.) - which we
currently don't on xwiki.org, so I could use the old doctype (but lose some
of the testing purpose). Because of the HTML5 doctype, the HTML validation
fails. See http://jira.xwiki.org/browse/XWIKI-7552

2. Junco Skin currently doesn't  have support for changing the ColorThemes
on the fly. I would need the help of a developer to fix this problem. Is
not so much a problem for xwiki.org (I could fix them by duplicating some
code in the xwiki.org skin), but it is a problem for the integration.

3. Being build on Bootstrap, it needs LESS to compile the files into CSS.
Again I would need a developer to see how we could integrate the building
of the themes in platform. Right now this is done locally, partially manual
by using Grunt.

Tell me what you think and take some time to test the skin,
Caty

[1] http://getbootstrap.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Remove XWiki 5.0 branch

[Ecaterina Moraru (Valica)]

+1


On Fri, Sep 20, 2013 at 3:07 PM, Thomas Mortagne
wrote:

> +1
>
> On Fri, Sep 20, 2013 at 2:00 PM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > Following our agreed practice of supporting only the latest 2 branches
> (master + latest stable) I'm proposing to remove the XWiki 5.0 branch in
> git and on ci.xwiki.org
> >
> > FTR we currently have 9 issues with a fixfor of 5.0.4 in platform, 3 in
> commons, none in rendering and 1 in enterprise.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Reminder] BFD#37

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty


On Thu, Sep 26, 2013 at 10:08 AM, Thomas Mortagne  wrote:

> +1
>
> On Thu, Sep 26, 2013 at 8:49 AM, Vincent Massol 
> wrote:
> > Hi everyone,
> >
> > Tomorrow is BFD 37.
> >
> > We're currently at 3158 bugs created over 1400 days vs 3167 closed, so
> we're good for 1400 days:
> > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
> >
> > I'm proposing to increase to 1500 days which gives us:
> > * 3485 created vs 3394 closed, i.e. 91 bugs to catch up with
> >
> > This seems reasonable to reach before the end of the 5.x cycle (we could
> probably go even a bit higher later on once we reach it).
> >
> > WDYT?
> >
> > Here's the BFD#37 dashboard to follow the progress during the day:
> > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11697
> >
> > Let's crush bugs!
> >
> > Thanks
> > -Vincent
> >
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Use Junco Skin for xwiki.org

[Ecaterina Moraru (Valica)]

On Wed, Sep 25, 2013 at 11:13 AM, Ludovic Dubost  wrote:

> Great job indeed. I installed on a test wiki on a 4.5 farm and it looks
> quite nice.
>
> I have a few questions.
>
> 1/ If I understand properly we have a legacy.css where lives all CSS of
> HTML that would not have been made clean plain bootstrap compatible HTML.
> Is that so ?
>

I've took colibri.css:
- stripped it from any rules that Bootstrap already covers (reset, standard
html elements, forms, etc.);
- mapped what I could to Bootstrap components (tables, boxes, panels, etc.);
- stripped layout elements and tried to get rid of ColorThemes values (in
the end realizing that I can't, without loosing functionality);
- cleaned the remaining selectors and properties (removed IE6,7 rules;
removed rules that maybe are covered by Bootstrap; etc.)

What remained are classes that will be needed by any new skin; classes that
kind of represent the CSS API (although there are still parts that could be
moved to their specific component file).
I though that if someone makes a change in Colibri and that selector is
also in legacy.css it should be ported here (that's why I left the
selectors as original).

Everything that is in legacy.css could be rewritten in junco.css, but it
will create a bigger gap between the two skins.


> 2/ In terms of work, how much and what is needed to get to a point where
> this could become our default skin, knowing that we should not have feature
> regression, for instance users should still be able to build their color
> themes in Wysiwyg like they can with colibri.
>
> I'm sure we can find a solution to do on the fly compiling when saving
> color themes so to solve the issue of needing LESS.
>

The integration problems are presented above (__Platform integration
problems__). One is the need to be able to build LESS files and update them
'on the fly'.
Regarding ColorThemes values, there are 2 files:
- global/xwiki-colorthemes.less - which is kind of a colorThemeInit.vm
https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-colortheme.less
- /xwiki-colortheme.less - which overrides the initialization and
provide colors for a specific theme
Blueberry example:
https://github.com/evalica/bootswatch/blob/junco-themes/blueberry/xwiki-colortheme.less

So when changing ColorThemes values, we need to make sure we update this
files.


>
> 3/ How much is needed to get rid of legacy and have a fully native skin
> with the new system ?
>

As stated above, legacy.css is not a limitation. We could rename it from
legacy.css to base.css or api.css, we could maybe write some more
performant selectors or maybe write them using LESS nested selectors.
The file contains the common denominator for Colibri and Junco and some
parts of the layout could be removed from it, in order to make it a true
API file. All the selectors that will be removed from here will end up in
the xwiki-common.less
https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-common.less

If we rewrite it whole, the only problem is that it will be harder to
update both Colibri and Junco.


>
> 4/ What is the migration path for a wiki where a custom skin has been built
> on colibri
>

Because of the mapping between XWiki and Bootstrap the Colibri classes will
be covered in Junco.
The problem are base HTML elements, that may have other default values. I'm
sure tables will produce some problems, because in Colibri they didn't had
any default padding, while after mapping they do. If someone use table for
layout, there will be some extra spacing.
There is not migration path for skins like that. Although we should have
minor problems, they will need to be tested and fixed manually.


>
> 5/ What are the potential consequences on future compatibility with colibri
> based skin, particularly if we start modifying our HTML produced by
> different modules ?
>

So the current HTML structure is covered by legacy.css and
xwiki-mapping.less.

If someone will want to change the HTML structure, you need to:
- make sure that the classes you delete are not 'API', this means they are
not called in legacy or xwiki-mapping. If a class is present in these files
means it also has a significance in Colibri;
- if you find a certain class, don't delete it. Instead just append your
new class or Bootstrap class. Keeping the legacy class, it will have a
fallback if Colibri skin will be used.

Of course there will be differences between skins if we start using
Bootstrap components and that is normal (because Colibri will not know of
their existence).

Thanks,
Caty


>
> Ludovic
>
>
>
> 2013/9/20 Ecaterina Moraru (Valica) 
>
> > Hi devs,
> >
> > For the past weeks I've been working on a skin based on Bootstrap[1]. You
> > can read more about it and test the new Junco Skin at
> > http:/

Re: [xwiki-devs] [Proposal] Use Junco Skin for xwiki.org

[Ecaterina Moraru (Valica)]

Hi,

Thank you for your votes. I've integrate the Homepage changes and we are
using the Junco skin on xwiki.org

__Discussion 1__
So one of the problems is 'Clearing your Cache'. In order to see the
changes correctly you need to refresh the page and make sure the cache is
updated with the new style rules.
It would be great if someone would know how we could force the clearing of
the cache. Maybe http://jira.xwiki.org/browse/XWIKI-6073 ?

__Discussion 2__
On a related topic, Vincent thinks we should not use a 'centered' design,
instead have (just like Colibri has) a 'full width 'design.

I've made some screenshots (please take a look at them in full view):
* Centered:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgJuncoHomepage/testCentered.png
**Full width:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgJuncoHomepage/testFull.png

Why I disagree (having full width and prefer the centered version):
- xwiki.org is a documentation site so most of its content needs to be
read;
- From a readability point of view, if the line is too long it is harder
for the eye to read it, please read
http://baymard.com/blog/line-length-readability ;
- Being a responsive skin, for smaller devices the content goes full width,
so the centered width is just for large resolutions;

Let me know what you think,
Caty



On Thu, Sep 26, 2013 at 11:08 AM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

>
>
>
> On Wed, Sep 25, 2013 at 11:13 AM, Ludovic Dubost wrote:
>
>> Great job indeed. I installed on a test wiki on a 4.5 farm and it looks
>> quite nice.
>>
>> I have a few questions.
>>
>> 1/ If I understand properly we have a legacy.css where lives all CSS of
>> HTML that would not have been made clean plain bootstrap compatible HTML.
>> Is that so ?
>>
>
> I've took colibri.css:
> - stripped it from any rules that Bootstrap already covers (reset,
> standard html elements, forms, etc.);
> - mapped what I could to Bootstrap components (tables, boxes, panels,
> etc.);
> - stripped layout elements and tried to get rid of ColorThemes values (in
> the end realizing that I can't, without loosing functionality);
> - cleaned the remaining selectors and properties (removed IE6,7 rules;
> removed rules that maybe are covered by Bootstrap; etc.)
>
> What remained are classes that will be needed by any new skin; classes
> that kind of represent the CSS API (although there are still parts that
> could be moved to their specific component file).
> I though that if someone makes a change in Colibri and that selector is
> also in legacy.css it should be ported here (that's why I left the
> selectors as original).
>
> Everything that is in legacy.css could be rewritten in junco.css, but it
> will create a bigger gap between the two skins.
>
>
>> 2/ In terms of work, how much and what is needed to get to a point where
>> this could become our default skin, knowing that we should not have
>> feature
>> regression, for instance users should still be able to build their color
>> themes in Wysiwyg like they can with colibri.
>>
>> I'm sure we can find a solution to do on the fly compiling when saving
>> color themes so to solve the issue of needing LESS.
>>
>
> The integration problems are presented above (__Platform integration
> problems__). One is the need to be able to build LESS files and update them
> 'on the fly'.
> Regarding ColorThemes values, there are 2 files:
> - global/xwiki-colorthemes.less - which is kind of a colorThemeInit.vm
>
> https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-colortheme.less
> - /xwiki-colortheme.less - which overrides the initialization and
> provide colors for a specific theme
> Blueberry example:
> https://github.com/evalica/bootswatch/blob/junco-themes/blueberry/xwiki-colortheme.less
>
> So when changing ColorThemes values, we need to make sure we update this
> files.
>
>
>>
>> 3/ How much is needed to get rid of legacy and have a fully native skin
>> with the new system ?
>>
>
> As stated above, legacy.css is not a limitation. We could rename it from
> legacy.css to base.css or api.css, we could maybe write some more
> performant selectors or maybe write them using LESS nested selectors.
> The file contains the common denominator for Colibri and Junco and some
> parts of the layout could be removed from it, in order to make it a true
> API file. All the selectors that will be removed from here will end up in
> the xwiki-common.less
> https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-common.less
>
> If we rewrite it whole, the only problem is that it will 

Re: [xwiki-devs] Release 5.2 final on 2nd October

[Ecaterina Moraru (Valica)]

+1


On Mon, Sep 30, 2013 at 12:31 PM, Thomas Mortagne  wrote:

> +1
>
> On Mon, Sep 30, 2013 at 10:35 AM, Marius Dumitru Florea
>  wrote:
> > Hi devs,
> >
> > 5.2 final was planned [1] for today but since the RC1 has been delayed
> > till Friday 27 September (to be announced today) I propose to postpone
> > the final release for 3 days, till 2nd October so that we can test it.
> >
> > Let me know if you don't agree.
> >
> > Thanks,
> > Marius
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs