September 2009 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme
by PERINAUD Christophe 02 Sep '09

02 Sep '09

+1 for (4) > -----Message d'origine----- > De : devs-bounces(a)xwiki.org [mailto:[email protected]] > De la part de Ecaterina Valica > Envoyé : mercredi 2 septembre 2009 16:38 > À : XWiki Users; XWiki Mailinglist > Objet : Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme > > Hi, > > So the final decision is between (2), (4), (B).* > > (2)* > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Pr > oposal2/Proposal2.png > > *(4)* > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Pr > oposal4/Proposal4.png > > *(B) * > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BC > olorTheme/SchemeB.png > * * > > > I preserved the existing votes: > > (4) +1 Caty, +1 Vincent, +1 Ricardo R, +1 Florin, +1 Silvia, > +0.5 Trevor, +1 > Marius > (B) +1 Oana, +1 Thomas M, +1 Sergiu, +0.5 Vincent G, +1 > Philipp, +1 Martijn, > +0.5 Trevor > (2) +1 Lucien, +0.66 Marta, +0.5 Jean C, +1 Gaëtan, +0.66 Raluca, +0.5 > Vincent G, +1 Emilie, > > > For the ones that changed their mind and want to change their > vote just > reply again and reset your vote. > > Thanks, > Caty > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

2 1

[xwiki-devs] [VOTE] Rename xwiki-bridge in xwiki-model
by Vincent Massol 02 Sep '09

02 Sep '09

Hi, Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki-model so that we can start this model module. Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module. Here's my +1 Thanks -Vincent

2 1

[xwiki-devs] [VOTE] Add the IRC Bot application to SVN
by Guillaume Lerouge 02 Sep '09

02 Sep '09

Hi, On Wed, Sep 2, 2009 at 11:02 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > [Ricardo Rodriguez] Your EPEC Network ICT Team wrote: > > Hi, Vincent, > > > > Vincent Massol wrote: > >> Hi, > >> > >> I've rewritten the IRC Bot application to make it more generic and > >> using XWiki 2.0 syntax and the new Observation mechanism. I'm looking > >> for a place where to save the sources. > >> > >> I'd like to propose to put it in platform/applications/ircbot > >> > >> Rationale: > >> * Since we use it it'll be actively maintained > >> * It could be useful for others too > >> > >> It would have its own JIRA project and its own release cycles of course. > >> > >> Here's my +1 > >> > I might be misunderstanding something about our process, but aren't new projects supposed to spend some time in the sandbox before they get their own SVN branch? Other than that I'm +1 with having it in our repo, Guillaume > >> Thanks > >> -Vincent > >> > >> > > Thanks for this initiative. We are considering the use of IRC or Jabber > > chat rooms for virtual meetings and this application will help us to > > avoid losing discussions and having the chat room "warned" about what is > > going on in the wiki. > > > > As far as I've understood, you, XWiki devs, are considering to move to > > Jabber. Please, will this or a similar application work with Jabber? > > Yes, we will make it also work with Jabber at some time. > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

2 1

[xwiki-devs] [Vote] Make the colibri skin the default one in XE 2.0 RC1
by Guillaume Lerouge 02 Sep '09

02 Sep '09

Hi Thibaut, thanks for your feedback, we need more of it even if we sometimes welcome it a bit roughly :-) On Wed, Sep 2, 2009 at 2:17 AM, Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com > wrote: > To be more precise, personas : > > Jo, > Know what is a wiki. > > "Where is the "edit button??? Ho, at the top ! " > > Mike > Don't know what is a wiki > > "What can I do now?" > Mike is looking arond the page, looking fo something logical. > Mike may not notice the edit button since he is looking near the content. > Now iimagine Mike sees the edit button. > (Interesting : If he scroll he will se that the bar is scrolling to so it > may help him to notice it) > "So there is an edit link, I gess I will edit somehing, but what?" > Mike click on the edit button. > It open the editor with the content of the page. > It take a few miliseconds to mike to understand. > "Ho ok, this is editing the content of the page." > > 9 lines for mike... > > > If the edit button btton was near the content mike would have nticed it > more > easily. > Also He would have linked it more easily with the fact it is editing the > content. > > > This is what makes the difference between the two designs... I happen to agree about the fact that the page action buttons should be located in the content area of the page. Additionally, power users can also get accustomed to keyboard shortcuts and they're even better than the non-moving top bar: 1. fingers don't need to leave the keyboard -> faster 2. always available wherever you are on the page So this global discussion could go on for ages before we come to an ideal solution :-) We'll definitely keep working on improving XWiki's UI / UX in the coming releases (XE 2.1 is scheduled for the end of the year) and sharing the work with the community in order to assess all options and come to an optimal choice. Many corporate users are not familiar with wikis at all and we'll explore all the ways to make the UI / UX easier to understand and use for them. We'll be looking for your feedback during that time and the 2 mails you just wrote will definitely be useful. Now when it comes to releasing XWiki Enterprise 2.0 with or without colibri, I'm definitely in favor of using Colibri. As Vincent stated it, the new skin: - Doesn't have drawbacks toucan doesn't already have - the action bar is in the same location - all important items are in the same location -> no new UX issues (no regressions) - Brings a lot of improvements - scrolling issue fixed - ability to change colors and select a theme - panels no longer go up to the top of the page -> allows for more flexible layouts - new visual identity which is an important part of XWiki Enterprise 2.0 - the page title is displayed automatically (we get a lot of strong feedback from our corporate users on this and they will like it a lot - even though we need to fix the double title issue on a number of pages) So I don't see a compelling reason not to use it. You're right about the fact that it means splitting XWiki's renovation in 2 (new look today, new ergonomics tomorrow) but this isn't an issue by itself as long as we keep working on improving it in the future. Thanks for your feedback, Guillaume > > > 2009/9/2 Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com> > > > Ho that's it. It is a design decision based about scrolling. I forgot > this > > point. > > > > So I understand now. Yet I still have some remarks about this because > what > > you choose now is not neutral at all. > > I don't say it is good or bad. I say everybody have to understand the > > implications. > > > > /***************************** > > Disclaimer : > > All of this is mainly theorical, UX is not an exact science when you > can't > > make tests. Also I can be biaised by my own eperience (I'm definitivly > not a > > newbee user, more probably a geek user). > > The only manner to really be sure about it is, like usual, to make tests > on > > a few real newbee users... > > *****************************/ > > > > > > Situation : > > > > Just imagine you are in a supermarket and you search for butter. > > > > First of all you assume butter is somewhere in the food aera. > > > > Then you may think that butter is with all prooducts based on milk. > > > > Also it should be in a freezer aera. > > > > So you will find easily the butter. > > > > > > Information architecture and ergonomy use a lot a methode called "card > > sorting" to create such logic aeras. They write the elements of the > > interface on paper. Then they ask people to group card they think to be > > linked. Then they make stats on groups to define an architecture of > elements > > grouped in a logic way. > > > > More information : > > French : http://www.ergolab.net/articles/tri-cartes-ergonomie-web.php > > English : > > http://www.boxesandarrows.com/view/card_sorting_a_definitive_guide > > > > > > You understand, I think, what I mean. In a "logic aeras" way the edit > > button and all what is related specifically to the content on the page > > should be near the page. (I dont mind it is moving or not, since it is in > > the content aera) > > > > > > Ok. Now, you will say me that anyone found a solution to get at the same > > time the content related links near the content and at the same time > having > > the content related links always accessible. So : "the menu becomes > > inaccessible once you scroll down". > > > > > > This is right. So they're is a deal... > > > > > > Will I choose something : > > > > * Efficient ? Quicly accessible user bar. > > > > * Newbee friendly ? Put the information where they will search it. > > > > > > > > It really depends on the targeted users : > > > > * If users know the should be an edit button somewhere, choose something > > effcient. > > * If users will use the wiki all the days choose something efficient. > > / > > * If firms have a problematic of adoption and at the same time a lot of > > people not skilled in computers choose something newbee friendly. > > * If yo want anybody can contribute quicly, even if not at ease with > > computers choose something newbee friendly. > > > > > > For my part, not knowing who are the personas, I would have choosen the > > version where the content related actions are in the content aera because > : > > * Imo and according to what I read, scrolling back to someting he has > > already noticed is not the greatest problem for casual users. > > * A newbee oriented design avoid getting people lost since a regular > users > > design only deserve regular users confort. > > > > > > Yet I guess the main clients xwiki are people who have to use regulary > the > > tool or people who know that they here to edit page and that it can be > done > > cliking on an "edit" button somewhere on the page. > > > > > > So... Imo this decision is not about a blind vote in a mailing list where > > evryone is biaised by the fact he know the tool. This decision is to : > > > > * Have its implications evaluated. Best by tests, else by brainstorming > > like we are doing. > > * Being linked with political and marketing orientations. Project leader, > > marketing personas, community... I don't know who.... > > > > > > > > > > > > > > > > > > > > 2009/9/1 Sergiu Dumitriu <sergiu(a)xwiki.com> > > > > Thibaut DEVERAUX wrote: > >> > The skin is still the provisory skin isn't it ? > >> > > >> > I would prefer to wait for the nice version being programmed. > >> > > >> > I think the provisory version has no real advantage on the old one. It > >> is > >> > the same information architecture (worst indeed) with only the > >> minimalist > >> > layout as a plus. > >> > > >> > Imo the minimalist layout is made to work with the exellent ergonomics > >> from > >> > first Caty versions. This is what makes it emotionaly coherent. So I > >> would > >> > prefer to wait the skin being developed. > >> > >> Actually, one of the main reasons why the menu had been moved (at the > >> expense of loosing permanent access to it) was to eliminate the > >> flickering effect when scrolling. Now that a community member provided a > >> nice fix for this issue, it is possible that we will end up not changing > >> the layout in that direction after all. > >> > >> As Vincent said, this skin has the great advantage of being easy to > >> change, and we need this in 2.0 . Please let us know what are the > >> specific bad points from your perspective, what you think is worse than > >> in the previous skin, and what makes the proposed layout (where the menu > >> becomes inaccessible once you scroll down) have better ergonomics than > >> the current one, where you have immediate access to the actions all the > >> time. > >> > >> Thanks in advance for a more detailed feedback. > >> > >> > > >> > > >> > I would propose : > >> > > >> > 1 - Start from the nice proposition > >> > 2 - Work on the menu UX design, wich was the discussion point. (use > >> > "advanced" button ?) > >> > 3 - Develop it... > >> > 4 - relase Colibri skin > >> > > >> > > >> > So unless I missed something and the colibri skin is not still in his > >> old > >> > provisory state, it will be -1 for my part. > >> > > >> > > >> > > >> > 2009/9/1 Th > >> > omas Mortagne <thomas.mortagne(a)xwiki.com> > >> > > >> >> On Tue, Sep 1, 2009 at 14:29, Vincent Massol<vincent(a)massol.net> > >> wrote: > >> >>> On Sep 1, 2009, at 2:28 PM, Guillaume Lerouge wrote: > >> >>> > >> >>>> Hi devs, > >> >>>> I think we should make colibri the default skin in XE 2.0 RC1 if we > >> >>>> want it > >> >>>> to be tested and ready for the release. > >> >>>> > >> >>>> Here's my +1 > >> >>> +1 but only provided we agree on the default colors. Right now I'm > -1 > >> >>> with the current colors. I've had several negative feedbacks about > >> >>> them (too light). > >> >> +1 > >> >> > >> >>> Thanks > >> >>> -Vincent > >> >>> > >> >>> _______________________________________________ > >> >>> devs mailing list > >> >>> devs(a)xwiki.org > >> >>> http://lists.xwiki.org/mailman/listinfo/devs > >> >>> > >> >> > >> >> > >> >> -- > >> >> Thomas Mortagne > >> >> _______________________________________________ > >> >> devs mailing list > >> >> devs(a)xwiki.org > >> >> http://lists.xwiki.org/mailman/listinfo/devs > >> >> > >> > _______________________________________________ > >> > devs mailing list > >> > devs(a)xwiki.org > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > > >> > >> > >> -- > >> Sergiu Dumitriu > >> http://purl.org/net/sergiu/ > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

2 1

[xwiki-devs] [Vote] Default Color Theme
by Ecaterina Valica 02 Sep '09

02 Sep '09

13 15

[xwiki-devs] [Vote] Make the colibri skin the default one in XE 2.0 RC1
by Guillaume Lerouge 02 Sep '09

02 Sep '09

Hi devs, I think we should make colibri the default skin in XE 2.0 RC1 if we want it to be tested and ready for the release. Here's my +1 Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

7 12

[xwiki-devs] jython 2.5.1 rc1 released
by Vincent Massol 01 Sep '09

01 Sep '09

for information: http://fwierzbicki.blogspot.com/2009/09/jython-251-release-candidate-1-is-o… Release notes: Jython 2.5.1rc1 New Features - Upgraded to ANTLR 3.1.3 - [ 1859477 ] Dynamically loaded ServletFilters like PyServlet - Built in JSR 223 scripting engine, with LiveTribe JSR 223 implementation for JDK 5 - Jython "-J-classpath cp_args_here" now works as expected for unix shell. Bugs Fixed - [ 645615 ] cannot import through symbolic links - [ 1366 ] parsing of lamda expression fails - [ 1365 ] continuation lines fail in interactive interpreter - [ 1377 ] Event names shadowed by a field name on Java types leads to a NPE - [ 1381 ] Redundant declarations of interface implementation hides overriden methods - [ 1189 ] MD5 hash is incorrectly calculated when string contains non-latin chars and using python md5 lib - [ 1802339 ] Problem printing unicode when stdout intercepted - [ 1145 ] Jython 2.5 compatibility problem with JSR 223 - [ 1400 ] Evaluating expression via JSR 223 ScriptEngine returns null instead of True/False - [ 1413 ] Array data type (PostgreSQL) is not supported (NPE) - [ 1434 ] Cannot get return code from a process started with os.popen with Jython 2.5 (worked in 2.2) - [ 1391 ] socket.getaddrinfo() breaks ftplib FTP client - [ 1409 ] JSR-233 engine version numbers backwards - [ 1408 ] JSR-223 engine doesn't implement I/O redirection - [ 1393 ] TypeError: _new_impl(): expected 1 args; got 0 - [ 1415 ] ast Node creation fails with no arg constructors - [ 1405 ] Executing __run__.py from .jar throws exception(SystemExit: 0) in main when sys.exit(0) is called - [ 1439 ] Can't write() array.array - [ 1139 ] crashes on isinstance - [ 1430 ] Oracle JDBC Connection close - [ 1406 ] Parsing a simple PEP 342 coroutine crashes Jython 2.5 - [ 1407 ] ClassCastException in plain Python coroutine - [ 1424 ] Relative imports do not work in some cases The JSR223 part sounds cool. Maybe we can have a jython macro at last? Thanks -Vincent

1 0

Re: [xwiki-devs] [Vote] Default Color Theme
by Guillaume Lerouge 01 Sep '09

01 Sep '09

> > Hi, > +1 for 3) > > Guillaume > > > On Tue, Sep 1, 2009 at 6:28 PM, Anca Luca <ancapaula.luca(a)xwiki.com>wrote: > >> I love the Halloween theme, but it's a bit too much for a default theme, >> same as >> Bordo. >> >> +0.5 for each of current (0) & BlueSky (C) as it is. >> >> Happy styling, >> Anca >> >> Ecaterina Valica wrote: >> > Hi, >> > >> > Please vote to set the default Color Theme for XWiki. >> > >> > The existing themes were: >> > >> > *(0) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DefaultColorThe… >> > SchemeDefault.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DefaultColorThe… >> >[ >> > *Currently Default*] >> > >> > *(A) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/AColorTheme/ >> > SchemeA.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/AColorTheme/Sch… >> >[ >> > *Nature*] >> > >> > *(B) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BColorTheme/ >> > SchemeB.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BColorTheme/Sch… >> > >> > * *[*Nightfall*] >> > >> > *(C)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/CColorTheme/ >> > SchemeC.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/CColorTheme/Sch… >> >[ >> > *Blue Sky*] >> > >> > *(D) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DColorTheme/ >> > SchemeD.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DColorTheme/Sch… >> >[ >> > *Inner Dark*] >> > >> > *(E) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/EColorTheme/ >> > SchemeE.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/EColorTheme/Sch… >> >[ >> > *Bordo*] >> > >> > Since then there were added 3 more themes: >> > >> > *(F)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/FColorTheme/Pea…<http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/FColorTheme/Pea…> >> > *Peach*] >> > >> > *(G)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/GColorTheme/Cho…<http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/GColorTheme/Cho…> >> > *Choco Blues*] >> > >> > *(H)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Halloween/Hallo…<http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Halloween/Hallo…> >> > *Halloween*] >> > >> > Because Theme *(C) Blue Sky* was mentioned as a candidate for the >> Default >> > Theme, I've done some variations with those colors: >> > >> > *(1)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal1/Propo… >> > >> > *(2)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal2/Propo… >> > >> > *(3)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal3/Propo… >> > >> > *(4)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal4/Propo… >> > >> > So please cast your vote or your Theme proposal. >> > >> > Thanks, >> > Caty >> > _______________________________________________ >> > devs mailing list >> > devs(a)xwiki.org >> > http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

1 0

Re: [xwiki-devs] [Vote] Default Color Theme
by PERINAUD Christophe 01 Sep '09

01 Sep '09

+1 (3) -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

1 0

Re: [xwiki-devs] [xwiki-notifications] r23184 - platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist
by Vincent Massol 01 Sep '09

01 Sep '09

On Sep 1, 2009, at 2:25 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-09-01 14:25:49 +0200 (Tue, 01 Sep 2009) > New Revision: 23184 > > Modified: > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/ > plugin/watchlist/WatchListStore.java > Log: > Fixed wrong listener name wow, glad my log allowed to catch this! That would have caused some serious problems ;) -Vincent > Modified: platform/xwiki-plugins/trunk/watchlist/src/main/java/com/ > xpn/xwiki/plugin/watchlist/WatchListStore.java > =================================================================== > --- platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/ > xwiki/plugin/watchlist/WatchListStore.java 2009-09-01 12:21:27 UTC > (rev 23183) > +++ platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/ > xwiki/plugin/watchlist/WatchListStore.java 2009-09-01 12:25:49 UTC > (rev 23184) > @@ -92,7 +92,7 @@ > /** > * The name of the listener. > */ > - private static final String LISTENER_NAME = "rightsmanager"; > + private static final String LISTENER_NAME = "watchliststore"; > > /** > * The events to match. > @@ -619,4 +619,4 @@ > { > return LISTENER_NAME; > } > -} > \ No newline at end of file > +}

1 0