Re: [xwiki-users] What would you like to see in the XWiki 7.x cycle?

[Hamster]

What I would like to see in XWiki 7.x:

- A standard way of navigating the Wiki (I know there a several Extensions
available, but this needs to be a basic feature of XWiki). This is my no. 1
complaint ;-).
- Better layout, with numbered headers. This is the no. 1 complaint from our
users. They are used to the way MS Word is able to format their documents.
Numbered lists with blank lines for example.
- A standard "Table of Contents", which displays the headers on a
(large)page. This TOC should be "dockable"/"collapsable", iow always
available to the users.
- Automatic Update/Upgrade to latest XWiki version.




--
View this message in context: 
http://xwiki.475771.n2.nabble.com/What-would-you-like-to-see-in-the-XWiki-7-x-cycle-tp7593349p7593387.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] Query external MSSQL DB in a wiki page

[Jason Clemons]

Hello,

Can anyone point me in the right direction?  I'm trying to query and external 
Microsoft SQL database from a wiki page.  My current wiki runs on MSSQL just 
fine using sqljdbc4.jar configured with hibernate.  The DB I want to query is 
actually on the same server, I can actually make it appear in the same DB if 
that makes things easier.  

I've looked at SQL Tools extension --> 
http://extensions.xwiki.org/xwiki/bin/view/Extension/SQL+Tools  and I can get 
that to work just fine even querying the other database, but I don't know how 
to make the results of a query from that tool appear in a separate page I've 
created for use in Velocity for example.  

I've tried to get the example on the "Execute SQL" page here --> 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Execute+SQL to work but I 
get a Groovy error on the second snippet and nothing at all appears on the page 
using the first snippet (but no error).

I've also looked at this plugin --> 
http://xwikisql.gradsoft.ua/docs/XWikiSqlPluginGuide.html  but it hasn't been 
updated since 2008, so I'm not really sure that's a good idea from a 
sustainability perspective in a production environment.

Ultimately, I will have a flat table in some database, really any database 
(e.g..it can be the XWIKI DB)..and I need to be able to get the rows and 
columns from the table and expose them as an HTML table in my wiki page.  Once 
I figure out how to get the data making it into a table is easy enough, but I 
can't even figure out how to get an object or array with the data in it to 
iterate.

All help is greatly appreciated.

Thanks in advance,

Jason
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries

[Guillaume Lerouge]

+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 <
gdelhum...@xwiki.com> wrote:

> +1, looks good.
>
> 2014-12-08 12:59 GMT+01:00 Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com>:
>
> > On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle  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-xw...@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 
> > >>  À : XWiki Developers ; XWiki Users 
> > >>  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+Action+for+Flamingo+Menu
> > >> .
> > >>
> > >> 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. t

Re: [xwiki-users] What would you like to see in the XWiki 7.x cycle?

[Danilo Oliveira]

Hello,

Well, there are two main feedbacks usability that I have received about
XWiki:


   - Difficult to insert images on the page ( The copy and paste of does
   not work). Some user preferred to write the page on Word and after that
   import the page in XWiki.
   - +1 - Better tables!  Its hard to structure information on tables
   inside XWiki pages.


+1
+10 to thanks Xwiki task force team


DAnilo


2014-12-08 15:25 GMT-02:00 Jeremie BOUSQUET :

> Hi,
>
> I'd add some stuff, based on feedbacks from my (advanced) users:
>
> - they usually consider that readability of titles and sub-titles
> (headings) inside wiki pages is not very good, difficult to differentiate
> them
> - when they create new pages (by putting [[new page>>newpage]]), once new
> page created, they find difficult to add links to this same new page from
> other pages (have to remember the name). It seems they didn't know about
> the corresponding feature in wysiwyg editor ...
> - a smarter TOC macro, that would optionally include in TOC, content from
> child pages (child meaning here, linked from current page). The macro would
> in this case, update headings levels of included (linked) pages, so their
> min level correspond to current TOC level + 1 (not sure I'm clear ... but
> let's say that it would generate a coherent TOC, without having to renumber
> child pages headings)
>
> Not very new: some people have difficulties really understanding concepts
> of Space, page, how to name them, what happens when they enter a new page
> name, etc ... I added "Space Hierarchy" panel, but they seem even more
> confused :)
>
> (feedbacks based on 5.x)
>
> BR,
> Jeremie
>
>
> 2014-12-05 18:19 GMT+01:00 Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com>:
>
> > On Fri, Dec 5, 2014 at 2:34 PM, Daniel Lundh  wrote:
> > > Hello.
> > >
> > > New XWiki user here.
> > >
> > > First, a big thanks, we are enjoying XWiki. :)
> > >
> > > We have a fairly common use case, using the wiki for documenting
> servers
> > > and systems, trying to build an SKMS ala ITIL.
> > >
> > > What i'd like to see is better formatting of text being cut & pasted
> from
> > > (mainly) Word.
> > > The single biggest issue I have heard complaints about is formatting.
> > > We are moving away from a Lotus Domino environment and here too the
> > > formatting is mangled (this may have everything to do with Domino and
> > > nothing with XWiki however) when doing copy/paste.
> > >
> > > I'd like tables to work like they do in Excel. When I press the tab
> key I
> > > want to move to the next field.
> > > I want to be able to size the table with my mouse in real-time.
> > > I want the columns to be plainly visible, not just the rows.
> > >
> > > I want numbered lists to be a core feature.
> > >
> >
> > > Making text different colors and/or fonts should work like in a regular
> > > word processor, with a menu item in the WYSIWYG editor.
> >
> > This is already possible.
> >
> >
> http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor#HQuickReference
> > . You need to enable it from the WYSIWYG editor section in the wiki
> > administration. It's not very straightforward but this
> >
> >
> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor#HPluginsandFeatures
> > can help.
> >
> > The rest is very good feedback.
> >
> > Thanks,
> > Marius
> >
> > >
> > > That's from the top of my head, anyway.
> > >
> > > Have a great weekend.
> > >
> > > Regards,
> > > Daniel
> > >
> > >
> > >
> > > On Fri, Dec 5, 2014 at 1:17 PM, vinc...@massol.net  >
> > > wrote:
> > >
> > >> Dear XWiki users,
> > >>
> > >> We’re getting close to the end of the XWiki 6.x cycle (6.4 is planned
> > for
> > >> the end of December) and in January we’ll start developing the XWiki
> 7.x
> > >> cycle (which will last the whole 2015 year), starting with XWiki 7.0.
> > >>
> > >> Thus it’s time for the XWiki devs to start defining the global roadmap
> > for
> > >> XWiki 7.x.
> > >>
> > >> As XWiki users, I’d like to know if you have some needs for XWiki 7.x.
> > >> What would you be interested in seeing in XWiki 7.x?
> > >>
> > >> I’d like to start some proposal on the xwiki devs list (for the XWiki
> > 7.x
> > >> cycle) around end of December so it would be nice if you could shoot
> > your
> > >> suggestion ideas fast so that we can take them into account in the
> > >> discussion! :)
> > >>
> > >> Thanks a lot for your help and I hope you’re enjoying using XWiki!
> > >>
> > >> -Vincent Massol
> > >> XWiki Committer
> > >>
> > >>
> > >> ___
> > >> users mailing list
> > >> users@xwiki.org
> > >> http://lists.xwiki.org/mailman/listinfo/users
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > Regards/Mvh
> > > Daniel Lundh
> > > ___
> > > users mailing list
> > > users@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/users
> > ___
> > users mailing list
> > users@xwiki

Re: [xwiki-users] What would you like to see in the XWiki 7.x cycle?

[Jeremie BOUSQUET]

Hi,

I'd add some stuff, based on feedbacks from my (advanced) users:

- they usually consider that readability of titles and sub-titles
(headings) inside wiki pages is not very good, difficult to differentiate
them
- when they create new pages (by putting [[new page>>newpage]]), once new
page created, they find difficult to add links to this same new page from
other pages (have to remember the name). It seems they didn't know about
the corresponding feature in wysiwyg editor ...
- a smarter TOC macro, that would optionally include in TOC, content from
child pages (child meaning here, linked from current page). The macro would
in this case, update headings levels of included (linked) pages, so their
min level correspond to current TOC level + 1 (not sure I'm clear ... but
let's say that it would generate a coherent TOC, without having to renumber
child pages headings)

Not very new: some people have difficulties really understanding concepts
of Space, page, how to name them, what happens when they enter a new page
name, etc ... I added "Space Hierarchy" panel, but they seem even more
confused :)

(feedbacks based on 5.x)

BR,
Jeremie


2014-12-05 18:19 GMT+01:00 Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com>:

> On Fri, Dec 5, 2014 at 2:34 PM, Daniel Lundh  wrote:
> > Hello.
> >
> > New XWiki user here.
> >
> > First, a big thanks, we are enjoying XWiki. :)
> >
> > We have a fairly common use case, using the wiki for documenting servers
> > and systems, trying to build an SKMS ala ITIL.
> >
> > What i'd like to see is better formatting of text being cut & pasted from
> > (mainly) Word.
> > The single biggest issue I have heard complaints about is formatting.
> > We are moving away from a Lotus Domino environment and here too the
> > formatting is mangled (this may have everything to do with Domino and
> > nothing with XWiki however) when doing copy/paste.
> >
> > I'd like tables to work like they do in Excel. When I press the tab key I
> > want to move to the next field.
> > I want to be able to size the table with my mouse in real-time.
> > I want the columns to be plainly visible, not just the rows.
> >
> > I want numbered lists to be a core feature.
> >
>
> > Making text different colors and/or fonts should work like in a regular
> > word processor, with a menu item in the WYSIWYG editor.
>
> This is already possible.
>
> http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor#HQuickReference
> . You need to enable it from the WYSIWYG editor section in the wiki
> administration. It's not very straightforward but this
>
> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor#HPluginsandFeatures
> can help.
>
> The rest is very good feedback.
>
> Thanks,
> Marius
>
> >
> > That's from the top of my head, anyway.
> >
> > Have a great weekend.
> >
> > Regards,
> > Daniel
> >
> >
> >
> > On Fri, Dec 5, 2014 at 1:17 PM, vinc...@massol.net 
> > wrote:
> >
> >> Dear XWiki users,
> >>
> >> We’re getting close to the end of the XWiki 6.x cycle (6.4 is planned
> for
> >> the end of December) and in January we’ll start developing the XWiki 7.x
> >> cycle (which will last the whole 2015 year), starting with XWiki 7.0.
> >>
> >> Thus it’s time for the XWiki devs to start defining the global roadmap
> for
> >> XWiki 7.x.
> >>
> >> As XWiki users, I’d like to know if you have some needs for XWiki 7.x.
> >> What would you be interested in seeing in XWiki 7.x?
> >>
> >> I’d like to start some proposal on the xwiki devs list (for the XWiki
> 7.x
> >> cycle) around end of December so it would be nice if you could shoot
> your
> >> suggestion ideas fast so that we can take them into account in the
> >> discussion! :)
> >>
> >> Thanks a lot for your help and I hope you’re enjoying using XWiki!
> >>
> >> -Vincent Massol
> >> XWiki Committer
> >>
> >>
> >> ___
> >> users mailing list
> >> users@xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/users
> >>
> >
> >
> >
> > --
> >
> > Regards/Mvh
> > Daniel Lundh
> > ___
> > users mailing list
> > users@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Wrong parameter for password reset

[lorconksu]

Hi all, 

Any update on this?



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Wrong-parameter-for-password-reset-tp7593310p7593382.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Attachments count problem

[patmolloy]

Thanks Marius.

 

You are right. I was fooled because the Comments count increments without a
complete page refresh so I assume the Attachments would too !

 

Thanks !

 


Pat

 

 

From: Marius Dumitru Florea [via XWiki]
[mailto:ml-node+s475771n7593379...@n2.nabble.com] 
Sent: 08 December 2014 13:54
To: patmolloy
Subject: Re: Attachments count problem

 

See http://jira.xwiki.org/browse/XWIKI-10096 . The attachment count 
should be displayed correctly if you reload the page. 

Hope this helps, 
Marius 

On Mon, Dec 8, 2014 at 1:52 PM, patmolloy <[hidden email]> wrote: 


> Hi,I am an XWiki virgin, so please forgive any apparent stupidity !I
attached 
> a couple of attachments, but the count shows as "Attachments (0)" in the 
> tab.Bug ? Something I need to tweak somewhere ? 
>  
> 
> 
> 
> -- 
> View this message in context:
http://xwiki.475771.n2.nabble.com/Attachments-count-problem-tp7593376.html
> Sent from the XWiki- Users mailing list archive at Nabble.com. 
> ___ 
> users mailing list 
> [hidden email] 
> http://lists.xwiki.org/mailman/listinfo/users

___ 
users mailing list 
[hidden email] 
http://lists.xwiki.org/mailman/listinfo/users



  _  

If you reply to this email, your message will be added to the discussion
below:

http://xwiki.475771.n2.nabble.com/Attachments-count-problem-tp7593376p759337
9.html 

To unsubscribe from Attachments count problem, click here
 .
 
 NAML 





--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Attachments-count-problem-tp7593376p7593381.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] run document skript with admin rights

[Marius Dumitru Florea]

>From http://platform.xwiki.org/xwiki/bin/view/DevGuide/API see
http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/org/xwiki/platform/xwiki-platform-oldcore/6.3/xwiki-platform-oldcore-6.3-javadoc.jar/!/com/xpn/xwiki/api/Document.html
. You have saveAsAuthor() and saveWithProgrammingRights().

Hope this helps,
Marius

On Fri, Dec 5, 2014 at 3:12 PM, Adrien Moi  wrote:
> Hello !
>
> on one wiki page I have a skript to delete a comment on another page. But 
> when a user that has no edit right tries to do it, it fails. Is there a way 
> to go around this and let the user delete the comment as if he had edit 
> rights?
>
>
> for reference here is my simplified code
>
> {{groovy}}
> yourDocReference = new 
> org.xwiki.model.reference.DocumentReference('xwiki','Main','WebHome');
> yourDoc = xwiki.getDocument(yourDocReference);
> comment = yourDoc.getComments();
> if(comment.isEmpty()){
> println("No Comment to remove!");}
> else{
> yourDoc.removeObject(comment[comment.size()-1]);
> yourDoc.save();
> println("First comment removed !")}
> {{/groovy}}
>
> thanks for the help
>
> Adrien
>
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Attachments count problem

[Marius Dumitru Florea]

See http://jira.xwiki.org/browse/XWIKI-10096 . The attachment count
should be displayed correctly if you reload the page.

Hope this helps,
Marius

On Mon, Dec 8, 2014 at 1:52 PM, patmolloy  wrote:
> Hi,I am an XWiki virgin, so please forgive any apparent stupidity !I attached
> a couple of attachments, but the count shows as "Attachments (0)" in the
> tab.Bug ? Something I need to tweak somewhere ?
> 
>
>
>
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/Attachments-count-problem-tp7593376.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries

[Guillaume "Louis-Marie" Delhumeau]

+1, looks good.

2014-12-08 12:59 GMT+01:00 Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com>:

> On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle  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 
> > 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 
> >>  À : XWiki Developers ; XWiki Users 
> >>  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+Action+for+Flamingo+Menu
> >> .
> >>
> >> 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://exte

Re: [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries

[Marius Dumitru Florea]

On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle  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 
> 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 
>>  À : XWiki Developers ; XWiki Users 
>>  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+Action+for+Flamingo+Menu
>> .
>>
>> 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+for+Flamingo+Menu
>> 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 backgro

[xwiki-users] Attachments count problem

[patmolloy]

Hi,I am an XWiki virgin, so please forgive any apparent stupidity !I attached
a couple of attachments, but the count shows as "Attachments (0)" in the
tab.Bug ? Something I need to tweak somewhere ?
 



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Attachments-count-problem-tp7593376.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries

[Marius Dumitru Florea]

On Fri, Dec 5, 2014 at 7:59 PM, Pascal BASTIEN  wrote:
> May I? (you send mail at user list)... then +1

Sure Pascal, even if your vote is non-binding it still is important
because it can influence the committers. Feedback from users is always
good.

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

That is what this proposal is about. Only the large screens are
affected (tablet and desktop).

Thanks,
Marius

>
> Thxs
> Pascal BASTIEN
>   De : Marius Dumitru Florea 
>  À : XWiki Developers ; XWiki Users 
>  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+Action+for+Flamingo+Menu
> .
>
> 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+for+Flamingo+Menu
> 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@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
>
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle  wrote:

> +1, ideally with a hover feedback very similar to the one of a dropdown
> button.
>
> On Fri, Dec 5, 2014 at 6:59 PM, Pascal BASTIEN 
> 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 
> >  À : XWiki Developers ; XWiki Users 
> >  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+Action+for+Flamingo+Menu
> > .
> >
> > 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+for+Flamingo+Menu
> > 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@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
> >
> >
> > ___
> > users mailing list
> > users@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
>