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
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
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
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
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
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
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