- xwiki-devs@xwiki.org - lists.xwiki.org

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

[xwiki-devs] [Proposal] Define a set of User Experience guidelines for XWiki
by Guillaume Lerouge 01 Sep '09

01 Sep '09

Hi Devs, Following-up on Caty's email ( http://markmail.org/message/3vukpehxeiflfjfw) I'd like us to get a bit more organized when it comes to improving XWiki's User Experience. This would allow us to make the product better and to gather more feedback from the community (such as Thibaut's email, see http://markmail.org/message/3bdk4jaziuqs6zvi ). In order to make our product great I think it would be good for us to agree on a set of standards and best practices related to UX. There are 2 levels to this initiative: 1. Agree on a set of broad rules 2. Agree on the implementation specifics for each rule A broad rule is a general rule that has to be followed when designing & coding a new feature: 1. "Always design a feature with one or more specific personas in mind" 2. "Respect consistency -> all UI items in XWiki should look & behave in the same way" Specifics are details related to the implementation of any given rule: 1. Choose the style to use for all buttons (see http://incubator.myxwiki.org/xwiki/bin/view/Standards/ for examples) 2. Define the personas we're targetting (see http://dev.xwiki.org/xwiki/bin/view/Design/ImproveXWikiUserExperience for examples) I'd like to get your feedback on the following points: - Is that a good idea overall? - Do you think we can make it an integral part of our development process? If the feedback is positive I'll start a discussion about the general UX rules we should make XWiki follow, then new ones for the specifics of each rule once we've agreed on some or all of them. Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

8 11

[xwiki-devs] [Proposal] Making "Edit this attachment" an advanced feature in the advanced edit mode
by Silvia Rusu 01 Sep '09

01 Sep '09

Hi devs, I propose we make "Edit this attachment" in the "Attachments" tab an advanced feature in the advanced edit mode. When trying to use "Edit this attachment": - in IE you get the following message: "Could not initialize a required ActiveX object" - in FF 3.5.2 installing the extension delivers the following message:"FoxWiki 1.0b could not be installed because it is not compatible with Firefox 3.5.2". - installing the extension on an older version of FF requires additional configuration, which the average user may not know how to perform. Under the above circumstances I think "Edit this attachment" will cause confusion for the average user instead of providing a useful tool. WDYT? ----- Silvia Rusu Tester & Documentation Writer - XWiki http://twitter.com/silviarusu -- View this message in context: http://n2.nabble.com/Proposal-Making-Edit-this-attachment-an-advanced-featu… Sent from the XWiki- Dev mailing list archive at Nabble.com.

6 11

[xwiki-devs] [Proposal] Remove "History" from the "Choose editor" panel
by Silvia Rusu 01 Sep '09

01 Sep '09

Hi Devs, I propose we remove "History" from the "Choose editor" panel in Edit mode. If you look at the "Edit" entry in the XWiki action menu you will see the following sub-menus: - WIKI - WYSIWYG - INLINE FORM - PAGE ACCESS RIGHTS - OBJECTS - CLASS The entries in the "Choose editor" panel are all "Edit" sub-menus, except for "History". I think the "History" tab in View mode should be enough. WDYT? Silvia ----- Silvia Rusu Tester & Documentation Writer - XWiki http://twitter.com/silviarusu -- View this message in context: http://n2.nabble.com/Proposal-Remove-History-from-the-Choose-editor-panel-t… Sent from the XWiki- Dev mailing list archive at Nabble.com.

6 5

Re: [xwiki-devs] Blog Plugin Proposal
by Andreas Schaefer 01 Sep '09

01 Sep '09

On Monday, August 31, 2009, at 12:46AM, "Vincent Massol" <vincent(a)massol.net> wrote: > >On Aug 31, 2009, at 9:28 AM, Guillaume Lerouge wrote: > >> Hi Andreas, >> >> On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <schaefera(a)me.com> >> wrote: >> >>> My try to deploy the Blog Plugin together with the updated Blog >>> Application failed miserably today and my dislike of Velocity reach a >>> new high. >>> >>> Because I see the value of the scripting nature of the Blog allowing >>> users to customize their Blog to a quite large degree I don't want to >>> ditch that but I have a lot of problems with Velocity and the way is >>> plastering over issues. I rather fail fast than late with hardly a >>> trail to understand what is going on. >>> >> >> My personal experience with velocity is more of a try & fail, try & >> fail, >> try and succeed one than anything else. > >This is not really related to velocity which is the simplest language >on earth. It's related to any language you type without an IDE to help >you. Try using groovy in wiki pages you'll have the same problem (I >know I have it, I need to preview 10 times to get something right). > >That said, there are some velocity editing support in IntellilJ IDEA >and I think there's also a plugin for Eclipse which might help. You >can also use XEclipse which has syntax highlighting and some >autocompletion for velocity (you'd need to use the 1.2RC1 version). I can agree with that. Velocity might be the simplest language for you but for started I could not find a good Velocity language tutorial. Even though the support I get from IntelliJ is really helpful the strange syntax is making it difficult to code (return values through parameters for example) but the real difficulty comes from the fact that I cannot debug velocity in any efficient way but the real thing I cannot stand is the fact that Velocity just ignore any problems. This might be good for a simple web site but for an application like a blog this is not good in my view. At least with Groovy I have a fairly well defined language and some mailing lists that can help me with problems and it ensures that NPEs, undefined methods etc are handled. >> What I found out is that I was msot >> of the time better off rewriting stuff starting with small chunks >> rather >> than trying to take existing code and reuse it all at once. The >> current blog >> is a fairly complex piece of velocity code (that is, given the lack of >> debugging tools when coding in velocity in the wiki). This is one of >> the >> reasons I think Sergiu's argument that "devs will be able to look at >> the >> code and learn from it" is not entirely true ;-) >> >> What's really important for the blog is that it can be customized >> easily at >> 2 levels: >> >> - Look: an user should be able to use the panels she wants for her >> blog >> - Deployment: an user should be able to create a new space blog or >> global >> wiki blog in any space she wants >> >> Besides that the way the blog is code doesn't matter much for the >> end user. >> >> That said I still think that it might be a good idea to convert the >>> scripted part of the Blog over to Groovy and keep the rest in the >>> Blog >>> Plugin. I don't have any experience with Groovy inside XWiki but for >>> sure the documentation of Groovy outside is excellent compared to >>> Velocity. I will use the next week to get up to speed and try to >>> convert a piece of the Blog over to Groovy. >> >> >> Then go ahead and give it a go :-) >> >> One thing you need to be aware of when using Groovy inside the wiki >> is that >> your pages will haveto be saved using programming rights. This can >> cause a >> number of issues, don't forget to code with an user that has them, >> it will >> save yo ua lot of hassle ;-) > >Yes and we might not be able to include it in the default distribution >since our rule so far was only velocity in the default XE XAR. I rather have a good, robust and reliable Blog application even if I would have to download it separately. But first I need to see how well a Blog in Groovy would work and what the limitations (like the programming rights) mean. To keep it easy I think I will start with implementing what we have in BlogSheet/BlogCode to just list the current entries in a blog. If I can then create a Blog Post Entry with Groovy I should pretty much be able to compare the two. Personally I am more interested to get the stuff going well for my own Blog but I am willing to go the extra mile to provide it to the community. Cheers - Andy

2 1

[xwiki-devs] [VOTE] Use PNG instead of GIF for the silk icons
by Sergiu Dumitriu 01 Sep '09

01 Sep '09

Hi devs, Short version: we need to replace GIFs with transparent PNGs for the Silk icon set. 3 options: A. use "filter: AlphaImageLoader" in our CSS, time consuming for our devs B. serverside content negotiation to send GIFs only to IE6, doesn't really fix the problem for IE6 C. use a third party library that handles this for us, but does not work under certain security restrictions Long version: Originally, silk icons are PNGs, with alpha transparency. The problem with them is that in IE6 they don't display nice, since they have a gray background. So, instead we're currently using GIFs, but this approach has some big issues: - GIFs are indexed, so they have at most 256 colors out of the millions possible in PNGs. This is not such a big issue, since most icons don't use so many colors. - PNGs are smaller (in bytes) than GIFs. - Since gifs don't have alpha transparency, they have an almost-white border around the colored pixels, which makes them ugly on non-white backgrounds (this is obvious on really dark backgrounds). This is a real blocker for using darker themes in Colibri. Now, switching to PNGs directly is not a good option, since most of our end users are (forced to be) using IE6. Some tricks are possible: A. Change the CSSs to contain a filter which enables the PNG transparency. This can be done in several ways: A1 - manually (hard for developers, breaks CSS validity) A2 - automatically at build time (breaks CSS validity) A3 - dynamically in the SkinAction (won't work if the CSS is served by the container) The advantage is that we can control which images are transformed. The disadvantage is that it might not work under certain security restrictions. B. Implement a kind of content-negotiation trick that sends PNGs or GIFs depending on the user agent. This is easy to do with a few Apache HTTPD settings, but it's not cross-platform at all. We can also do it in the SkinAction, but again, doesn't work if the request does not pass through it. The advantage is that it always works, since it's always an image. The disadvantage is that icons will continue to look ugly in IE6, since they are GIFs. C. Use http://www.twinhelix.com/css/iepngfix/ which automatically fixes all images in IE. The advantages are that it is the most easy solution to implement, with the least amount of effort, it fixes most problems, and requires little maintenance. The disadvantage is that it won't work under certain security restrictions, and that a clean and fast integration will requirer to add some mechanism of identifying which images to fix (it can be incompatible with other tools that do their own PNG fix, like Google Maps). None of the alternatives is perfect, but my personal preference goes to C. -- Sergiu Dumitriu http://purl.org/net/sergiu/

4 5

Re: [xwiki-devs] [Proposal] Remove "History" from the "Choose editor" panel
by Guillaume Lerouge 31 Aug '09

31 Aug '09

> > +1 > Guillaume > > > On Mon, Aug 31, 2009 at 11:56 PM, Jean-Vincent Drean < > jean-vincent(a)drean.org> wrote: > >> +1 >> >> JV. >> >> On Mon, Aug 31, 2009 at 8:31 PM, Sergiu Dumitriu<sergiu(a)xwiki.com> wrote: >> > Silvia Rusu wrote: >> >> Hi Devs, >> >> >> >> I propose we remove "History" from the "Choose editor" panel in Edit >> mode. >> >> >> >> If you look at the "Edit" entry in the XWiki action menu you will see >> the >> >> following sub-menus: >> >> - WIKI >> >> - WYSIWYG >> >> - INLINE FORM >> >> - PAGE ACCESS RIGHTS >> >> - OBJECTS >> >> - CLASS >> >> >> >> The entries in the "Choose editor" panel are all "Edit" sub-menus, >> except >> >> for "History". >> >> >> >> I think the "History" tab in View mode should be enough. >> >> >> >> WDYT? >> > >> > +1 >> > >> > "Edit History" is a bit misplaced. While all the other entries are about >> > real editing of the document, this is about viewing previous edits. >> > >> > -- >> > 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/ >

1 0

[xwiki-devs] [Proposal] Introduce a 'Create' entry in the menu
by Sergiu Dumitriu 31 Aug '09

31 Aug '09

Hi devs, I'd like to introduce a 'Create' entry in the XWiki action menu. This would be the first entry (it would appear before 'Edit') and would have the following sub-menus: - Page - Page from Office Document - Space The "Page from Office document" entry replaces the "Import Office Document" entry from the "Actions" menu, which IMHO does not really fit there. This allows to also get rid of the "Create" panel, and have all the features available from the menu. We could include this only in the Colibri skin for the moment, experimentally, to see how it is received by the users. -- Sergiu Dumitriu http://purl.org/net/sergiu/

6 11

[xwiki-devs] [VOTE] Upgrade to Prototype 1.6.1 RC3
by Sergiu Dumitriu 31 Aug '09

31 Aug '09

Hi devs, I'd like to propose to upgrade to Prototype 1.6.1 RC3, released on June 16, because it fixes (among other speed improvements and bug fixes) a pretty important compatibility issue with IE8, which causes http://markmail.org/thread/qp4l7hfxohnbpx7x and badly styled notifications. It also fixes some bugs with Opera and selectors that I've hit and had to work around. Normally I wouldn't include a RC dependency, but given the important bugs it fixes, and the fact that they have pretty extensive tests, I trust that this upgrade won't break anything. My +1. -- Sergiu Dumitriu http://purl.org/net/sergiu/

8 8

[xwiki-devs] [VOTE] API changes to the bridge module for 2.0RC1
by Vincent Massol 31 Aug '09

31 Aug '09

Hi, I'm implementing support for specifying jars attached to pages and using them from the script macro. see http://jira.xwiki.org/jira/browse/XWIKI-3941 for more details. (Note that my own need for this is to rewrite our IRC Bot using the 2.0 Rendering to make it more stable.) For this I need the following changes: * Introduce new CurrentDocumentNameFactory which extends DefaultDocumentNameFactory but instead of using "WebHome" if the page name is not specified, it uses the current document page name. * Introduce AttachmentNameFactory to parse syntax of the form: wiki:space.page@filename * Deprecate in DAB: "String getAttachmentURL(String documentName, String attachmentName);" and instead replace it with "String getAttachmentURL(AttachmentName attachmentName);" * Add in DAB: "List<String> getAttachmentURLs(DocumentName documentName) throws Exception;" to return all attachments * I also want to fix AttachmentName which shouldn't extend DocumentName but instead use it by composition (it's not used right now). Note: In the future, we'll also deprecate all *URL() methods in DAB since the correct way will be to write: - DocumentName (or AttachmentName) - new XWikiDocumentURL(DocumentName) (or new XWikiAttachmentURL(AttachmentName)) - DocumentNameSerializer.serialize(xwikiDocumentURL) --> URL (or AttachmentNameSerializer.serialize(xwikiAttachmentURL)) Here's my +1 to these and to add them in RC1. Note: I'd like to have this in 2.0 final because I think it's cool to have support for XWIKI-3941 but also because we'd need it on xwiki.org too in order to be able to use the IRC Bot I'm fixing. Thanks -Vincent

4 4