December 2014 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries
by Marius Dumitru Florea 11 Dec '14

11 Dec '14

I committed my changes so that those that haven't voted yet can see it in action. Will revert if someone is against it. Thanks, Marius On Mon, Dec 8, 2014 at 11:07 PM, Guillaume Lerouge <guillaume(a)xwiki.com> wrote: > +1 > > Thanks a lot for all your effort on this Marius! > > Guillaume > > On Mon, Dec 8, 2014 at 1:18 PM, Guillaume "Louis-Marie" Delhumeau < > gdelhumeau(a)xwiki.com> wrote: > >> +1, looks good. >> >> 2014-12-08 12:59 GMT+01:00 Marius Dumitru Florea < >> mariusdumitru.florea(a)xwiki.com>: >> >> > On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle <dgl(a)softec.lu> wrote: >> > > +1, ideally with a hover feedback very similar to the one of a dropdown >> > > button. >> > >> > The color theme is responsible for the hover effect. A flat color >> > theme will probably use a single color highlight, controlled by the >> > @navbar-default-link-hover-bg LESS variable. A 3D color theme may use >> > some gradients to achieve the 3D effect on hover. A minimalistic color >> > theme (like Simplex) will just change the text color on hover, leaving >> > the background transparent. >> > >> > This proposal/vote is about agreeing on: >> > * displaying a small vertical bar between the menu label and toggle >> > (using a color derived from the menu background) to indicate the >> > separation between the two (especially for tablet devices where >> > there's no hover) >> > * hovering/activating the menu label and the toggle separately, as it >> > happens with a drop down button (e.g. the Add button). >> > >> > Thanks, >> > Marius >> > >> > > >> > > On Fri, Dec 5, 2014 at 6:59 PM, Pascal BASTIEN < >> pbasnews-xwiki(a)yahoo.fr> >> > > wrote: >> > > >> > >> May I? (you send mail at user list)... then +1 >> > >> On 6.3 I still use 6.2 menu (I modified the template on my xwiki) >> > >> >> > >> I'm agree with you the 2 side of button must be better separate (with >> > >> color on hoover or a black vertical bar?). >> > >> >> > >> IMO we must respect the same logic of actions button (an one-click >> > default >> > >> action and drop down sub menu level at the right-side-click ) >> > >> With CSS it should be possible to:- use 2 side button on big screen- >> use >> > >> GoTo menu on small screen >> > >> (with @media min-width) >> > >> >> > >> Thxs >> > >> Pascal BASTIEN >> > >> De : Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> >> > >> À : XWiki Developers <devs(a)xwiki.org>; XWiki Users <users(a)xwiki.org> >> > >> Envoyé le : Vendredi 5 décembre 2014 17h20 >> > >> Objet : [xwiki-users] [VOTE] Enable default actions for the Flamingo >> > top >> > >> menu entries >> > >> >> > >> Hi everyone, >> > >> >> > >> = Short Story = >> > >> >> > >> I propose to change the behaviour of the top level menu from Flamingo >> > >> for tablet and desktop screens (so NOT for phones) to match the >> > >> behaviour we had in 6.2 BUT improving the separation between the >> > >> navigation links and the drop down toggle. The idea is that the top >> > >> level menu entries should behave like a drop down button (e.g. the Add >> > >> button) but without looking like one. You can see some screen shots at >> > >> http://jira.xwiki.org/browse/XWIKI-11517. >> > >> >> > >> = Long Story = >> > >> >> > >> I've heard complains that the current behaviour of the top level menu >> > >> from Flamingo skin is not perfect. The issue is that you need to click >> > >> twice to navigate. Ok, with a mouse you can use the middle click >> > >> (wheel) to open the link in a new tab but still it's annoying for >> > >> simple uses and for those that use the touch pad or a tablet. >> > >> >> > >> An alternative I have investigated in >> > >> http://jira.xwiki.org/browse/XWIKI-11479 is to open the menu on hover >> > >> (on devices that support this of course). The result is quite nice and >> > >> effective but there is a problem: if you have a second horizontal menu >> > >> displayed under the top level menu then you'll have a hard time >> > >> hovering the second menu. So I decided to close XWIKI-11479 as Won't >> > >> Fix. For those that like the open-on-hover behaviour and which don't >> > >> plan to use a second menu I've published this extension >> > >> >> > >> >> > >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Hover+and+Default+Acti… >> > >> . >> > >> >> > >> The other alternative to fix the problem is to go back to the >> > >> behaviour from 6.2. Precisely, each menu has two sides: >> > >> * on the left is the label which is a link used for navigation >> > >> * on the right there is a toggle (arrow) used to open the menu. >> > >> >> > >> The problem with this, and the reason we change it in 6.3, was that >> > >> the label and the toggle were not separated very well so the user >> > >> could easily think they were doing the same action (opening the menu). >> > >> At the same time this separation felt unnatural on extra small screens >> > >> (phones) because you couldn't tap easily on the toggle (arrow). >> > >> >> > >> The solution I propose is to: >> > >> * Keep the current behaviour for extra small screens (phones). That >> > >> means the use has to tap twice to navigate: one tap to open the menu >> > >> and another one on the "Go to this XYZ". >> > >> * On desktop and tablet enable the default action (navigation link) as >> > >> in 6.2 but improve the separation so that the menu behaves as much as >> > >> possible as a drop down button (e.g. the Add button) without looking >> > >> like one. This means: >> > >> ** You should understand there are two sides without hovering >> > >> ** Separate hover and active state (e.g. the link is not hovered when >> > >> the toggle is hovered) >> > >> >> > >> I've investigated *many* ways to achieve this and the result can be >> > >> seen on http://jira.xwiki.org/browse/XWIKI-11517. This is close to >> > >> >> > >> >> > >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Enable+Default+Action+… >> > >> but not the same. >> > >> >> > >> NOTE: The way the menu behaves and looks on hover and click (text and >> > >> background color) is strictly determined by the color theme. Some >> > >> themes highlight the hovered menu items by changing their background >> > >> color, others the text color and some do both. My changes are >> > >> independent on this. We can of course improve the default color theme >> > >> to better highlight the menu items. This is a different topic though. >> > >> >> > >> I'd like to commit this changes in 6.4. Here's my +1. >> > >> >> > >> Thanks, >> > >> Marius >> > >> _______________________________________________ >> > >> users mailing list >> > >> users(a)xwiki.org >> > >> http://lists.xwiki.org/mailman/listinfo/users >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> users mailing list >> > >> users(a)xwiki.org >> > >> http://lists.xwiki.org/mailman/listinfo/users >> > >> >> > > >> > > >> > > >> > > -- >> > > Denis Gervalle >> > > SOFTEC sa - CEO >> > > _______________________________________________ >> > > users mailing list >> > > users(a)xwiki.org >> > > http://lists.xwiki.org/mailman/listinfo/users >> > _______________________________________________ >> > users mailing list >> > users(a)xwiki.org >> > http://lists.xwiki.org/mailman/listinfo/users >> > >> >> >> >> -- >> Guillaume Delhumeau (gdelhumeau(a)xwiki.com) >> Research & Development Engineer at XWiki SAS >> Committer on the XWiki.org project >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

2 2

[xwiki-devs] Create Quick Links list
by Martin Beseda 10 Dec '14

10 Dec '14

To Whom It May Concern, I need to make a side panel with "quick links" (links to favourite pages), where user will be able to add or remove them (ideally by a button placed on every page). But I don't know how to ideally do this. My idea was, that I will create a new section with a new property in the user template, which will contain the list of links (probably string in CSV format) and later I'll just modify this property by some macro. But, my main problem is, that I don't know if ( and if, then how :-) ) it is possible to read and change current user's properties from outside. Could you, please, help me with this one? I'd love to know some standard, or elegant solution :-) Thank you very much. Yours faithfully, Martin Beseda

1 0

[xwiki-devs] [Proposal] Addition of a new extension point (before title)
by Victor Rachieru 06 Dec '14

06 Dec '14

Hei devs, By default, the ratings app uses JS to inject an HTML element right after the #hierarchy element. This is a bit awkward since that element could be (re)moved and the ratings element would not be present or follow the position of the hierarchy (breadcrumb). As a solution I propose implementing an extension point, namely org.xwiki.platform.template.title.before which would go right before the document title. Due to the fact that in flamingo the "more actions" and "edit" buttons are now in the same place that the ratings are displayed brings us to a point where we will have to integrate the ratings in this interface as well. As a future improvement we could add more extension points and choose where to display the ratings depending on the skin. For example: before title for colibri and after the content menu (where the "edit" and "more actions" buttons are) for flamingo. This extension point would replace the JS inject thus making the code cleaner. Thanks, Victor

5 7

[xwiki-devs] [VOTE] Enable default actions for the Flamingo top menu entries
by Marius Dumitru Florea 05 Dec '14

05 Dec '14

Hi everyone, = Short Story = I propose to change the behaviour of the top level menu from Flamingo for tablet and desktop screens (so NOT for phones) to match the behaviour we had in 6.2 BUT improving the separation between the navigation links and the drop down toggle. The idea is that the top level menu entries should behave like a drop down button (e.g. the Add button) but without looking like one. You can see some screen shots at http://jira.xwiki.org/browse/XWIKI-11517. = Long Story = I've heard complains that the current behaviour of the top level menu from Flamingo skin is not perfect. The issue is that you need to click twice to navigate. Ok, with a mouse you can use the middle click (wheel) to open the link in a new tab but still it's annoying for simple uses and for those that use the touch pad or a tablet. An alternative I have investigated in http://jira.xwiki.org/browse/XWIKI-11479 is to open the menu on hover (on devices that support this of course). The result is quite nice and effective but there is a problem: if you have a second horizontal menu displayed under the top level menu then you'll have a hard time hovering the second menu. So I decided to close XWIKI-11479 as Won't Fix. For those that like the open-on-hover behaviour and which don't plan to use a second menu I've published this extension http://extensions.xwiki.org/xwiki/bin/view/Extension/Hover+and+Default+Acti… . The other alternative to fix the problem is to go back to the behaviour from 6.2. Precisely, each menu has two sides: * on the left is the label which is a link used for navigation * on the right there is a toggle (arrow) used to open the menu. The problem with this, and the reason we change it in 6.3, was that the label and the toggle were not separated very well so the user could easily think they were doing the same action (opening the menu). At the same time this separation felt unnatural on extra small screens (phones) because you couldn't tap easily on the toggle (arrow). The solution I propose is to: * Keep the current behaviour for extra small screens (phones). That means the use has to tap twice to navigate: one tap to open the menu and another one on the "Go to this XYZ". * On desktop and tablet enable the default action (navigation link) as in 6.2 but improve the separation so that the menu behaves as much as possible as a drop down button (e.g. the Add button) without looking like one. This means: ** You should understand there are two sides without hovering ** Separate hover and active state (e.g. the link is not hovered when the toggle is hovered) I've investigated *many* ways to achieve this and the result can be seen on http://jira.xwiki.org/browse/XWIKI-11517. This is close to http://extensions.xwiki.org/xwiki/bin/view/Extension/Enable+Default+Action+… but not the same. NOTE: The way the menu behaves and looks on hover and click (text and background color) is strictly determined by the color theme. Some themes highlight the hovered menu items by changing their background color, others the text color and some do both. My changes are independent on this. We can of course improve the default color theme to better highlight the menu items. This is a different topic though. I'd like to commit this changes in 6.4. Here's my +1. Thanks, Marius

1 0

[xwiki-devs] [XWiki Day] BFD#73
by Thomas Mortagne 05 Dec '14

05 Dec '14

As you probably already know, today is BFD#73: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 58 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#73 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12890 Thanks and enjoy your bug fixing day! -- Thomas Mortagne

2 2

[xwiki-devs] [XWiki Day] BFD#73
by Eduard Moraru 04 Dec '14

04 Dec '14

Hi devs, As you probably already know and already started, today is BFD#73: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 60 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… I notice a slight increase in bug activity this week that we should hopefully address today, in our efforts to catch up. Here's the BFD#73 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12891 Thanks and enjoy your bug fixing day! -Eduard

1 1

[xwiki-devs] [ANN] XWiki 6.4 Milestone 1 released
by Thomas Mortagne 03 Dec '14

03 Dec '14

The XWiki development team is proud to announce the availability of XWik 6.4 Milestone 1. 6.4 branch is mainly dedicated to improvement and bugfixes on things introduced during 6.x and in general. This version also introduce some developer oriented improvements: allow wiki based skins to overwrite macro.vm template, allow filesystem skins indicating explicitly the skin they are inheriting from, allow any component to be injected with its ComponentDescriptor, Panels and UI extensions are now executed with the right of their author so among other things they can use APIs requiring Programming rights. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki64M1 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Filesystem skin properties
by Thomas Mortagne 03 Dec '14

03 Dec '14

Hi devs, I plan to introduce a skin.properties file at the root of each filesystem skin which will contain among other things the parent of this skin. The name of the property I propose "parent", when parent is set to empyt string it means not parent (i.e. it ends up directly in the WAR /templates or /resources folders). Yes I know we usually talk about "base skin" right now but I tough "parent" is more explicit when talking about inheritance (and the internal skin manager I'm working on is also using "parent" naming). Any tough ? If I don't get any reaction I will take that as a general +0 and commit it in master ;) -- Thomas Mortagne

3 3

[xwiki-devs] [Proposal] Open the "Assign issues" permissions to everyone again for the "XWiki Open" JIRA scheme?
by vincent＠massol.net 01 Dec '14

01 Dec '14

Hi committers, So far we’re allowing only committers (and some special contributors) the permission to assign themselves and others (there’s no permission to only allow someone to assign himself in JIRA!). We did this because we didn’t want people assigning issues to others. However this is causing several problems: * It would be nice that contributors working on a project in the xwiki github orgzanition be able to assign themselves to issues for which they wish to send PRs * For Contrib projects, since we allow anyone to become a committer there, it’s even more important that contrib developers be able to assign themselves to issues We could of course do this in an ad-hoc manner and wait for people to ask a committer on IRC or on the mailing list to be given the permission. However this is painful for everyone. Thus I propose to reopen again the “Assign issues” permission in JIRA for the “XWiki Open” permission scheme. WDYT? Thanks -Vincent

5 10