xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [GSoC] Deadline approaching

by Sergiu Dumitriu

Hello GSoC students, The suggested 'pencils down' date is 5 days away, and the firm deadline is in less than 2 weeks (http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline). Therefore,* at the beginning of next week*, all students should have a *working application* that they should make available to the community for testing. The week of August 10-17 will be used for finalizing the project. Please discuss with your mentors the remaining work that needs to be done before Monday. Good luck, -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 6 months

[xwiki-devs] [Proposal] Work left for 2.0 final + Dates rescheduling

by Vincent Massol

Hi, Today is supposed to be the 2.0M3 release date but since we've had lots of delays on 2.0M2 there's no point in releasing M3 today. I've reviewed some of the important tasks we wanted to do in the 2.0 release and that are not done yet: - section editing in 2.0 syntax - JV - XAR in 2.0 syntax (at least for some pages) - All - new skin - Guillaume + Laurent + someone to implement it (?) - macro categories (this one was decided late and wasn't planned initially so I don't think it's a blocker but I'm still listing it here) - Asiri - clustering/distributed events - Thomas - captcha - Jerome - watch list bug fixes (+ activity stream refactoring) - JV - new blog UI - Caty - new User profile UI - Caty Are there any more? The conclusion is that we're very late. We need to decide what we want to skip. From the list I think we should skip the following since the work hasn't been started on them: - new user profile - activity stream refactoring We need to know from each person listed above when he can have finished his part ASAP in order to define new dates (and hoping to preserve the final 2.0 release date). Right now I'd suggest we postpone M3 by one week, i.e. to the 10th of August and move RC1 to 24th of Aug. This would mean a final for the 31st or a RC2 for the 31st and a final for the 7th of Sep. WDYT? Thanks -Vincent

15 years, 6 months

Re: [xwiki-devs] [xwiki-users] It's time to tell us what you're looking for!

by Guillaume Lerouge

Hi XWikiers, the first batch of results from the survey is available at: http://www.xwiki.org/xwiki/bin/view/Blog/CurrentSurveyResults It's meant to give you an idea of what the results look like after 50+ answers to the survey. I'll publish detailed results later on, once the survey has been officially closed (in a week or so). Thanks to all of you for your time! Guillaume On Wed, Jul 29, 2009 at 11:51 AM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote: > Hi Ricardo, > > On Tue, Jul 28, 2009 at 11:38 PM, [Ricardo Rodriguez] Your EPEC Network ICT > Team <webmaster(a)environmentalchange.net> wrote: > >> First of all, congratulations to the whole community for the XWiki's 5th >> birthday! >> >> Guillaume Lerouge wrote: >> > Hi fellow XWikiers, >> > While celebrating XWiki's 5th birthday last week, we spent a couple days >> > brainstorming with the full team about where XWiki stands today and what >> its >> > future holds. We came up with a long list of features and ideas and we'd >> > love to get community feedback before deciding in which direction we're >> > going to move forward once our 2.0 release is out. >> > >> > To this aim, we've built a survey that we'd like our users and >> developers to >> > take. It's a bit long though definitely worth the pain. We're eagerly >> > waiting for your feedback to start working on new and existing features. >> > >> > You can access and fill the survey at the following address: >> > http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures >> > >> > Thanks a lot for your time, >> > >> > Guillaume on behalf of the XWiki Team >> > >> > >> >> Please, is there any way of following the results of the survey on-line? > > > Not in real time. We ran another poll internally that used another format > and I need to gather the various results and make all of them follow the > same format before publishing the data. > > The data will be made available in a publicly viewable Google Spreadsheet > as soon as I'm done. > > Guillaume > > After hitting the submit button I've been forwarded to http://xwiki.org. >> Is this te expected behavior? >> >> Thanks! >> >> -- >> Ricardo Rodríguez >> Your EPEC Network ICT Team >> >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > > > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

15 years, 6 months

[xwiki-devs] Support for Google Gadgets in pages in panels

by Ludovic Dubost

Hi devs, I've implemented support for Google Gadgets for pages and for panels. http://incubator.myxwiki.org/xwiki/bin/view/Gadgets/ It is possible to browse the Google Gadget Directory and select a gadget, set it's parameters and either: - insert a call to a gadget macro in a wiki page - create a panel with this gadget It's basically working, except for a few Gadget translations issues in the gadget settings page (for some gadgets). To integrate in XE this requires: - a slight modification to the PanelClass and the displaypanel macro (to support a gadgeturl and gadgetprefs field) - a few pages including a Gadget Groovy page (which requires programming rights) I think we should transform the Gadget Groovy to a plugin to avoid the need for programming rights. We can also from there create a special page type to make a display of gadgets or panels like iGoogle or NetVibes. It would store gadgets or panel lists in a special class with some position parameters. And with some JS we can reposition the panels or gadgets and save the config in the wiki page. This would be an easy way to make some portal like experience in the wiki. Who wants to takeover this from the dev team ? Do you think we can have this in 1.8 ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

15 years, 6 months

[xwiki-devs] [ANN] XWiki Enterprise 2.0 Milestone 2 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Milestone 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download The main goal of 2.0 is to make XWiki fully XWiki 2.0 syntax. Main changes from 2.0 Milestone 1: * Lots of improvements and new features in the new WYSIWYG editor * Lots of improvements and bugfixes in the rendering engine and the syntax converter * Improvements for the blog application * It's now possible to choose the content renderer to use when viewing a page * New Footnote macro * New xwiki-properties module * New Latvian translation * New Swedish translation * New Korean translation For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20M2 Thanks -The XWiki dev team

15 years, 6 months

[xwiki-devs] [Standars][Components] Icons

by Ecaterina Valica

There are many ways implemented in XWiki for the case when you want to attach an icon to a html element. You can see a small study for the "Delete" icon at http://incubator.myxwiki.org/xwiki/bin/view/Standards/IconsStudyDelete. You can either use CSS to assign a background-image to a <span>, <div>, <input>, <li>, <a>, etc element or you can integrate the icon in the code with <img> element. Using the icons as background images we remove the extra/unnecessarily img code in the HTML and layout problems. The main problem is that consistency of UX and development. We currently have three icons for the "Edit" action ((BlogStyle/edit.png; js/xwiki/usersandgroups/img/clear.png;) silk/pencil.gif; images/black-edit.png )). For the delete example we write the same Css code for the background-image in attachments.css, livetable.css, dataeditors.css, comments.css, etc. Everytime we add an icon, we need to see what is the icon's name and this way is very easy make a mistake in the "standard". I want to propose an *Icons Component* in * platform\web\standard\src\main\webapp\resources\icons\icons.css* . You can read more about it at http://incubator.myxwiki.org/xwiki/bin/view/Standards/CssIcons . This is just a skeleton and doesn't meet all the needs for icons usage (left-aligned icons, right-aligned icons, gifs, pngs, etc). - One problem that can be is the separation in Css files that are dependent one from the other, instead of having them in just one big file (like toucan.css that can be cached by clients). The thing is that the UI components are not dependant of the skin, so putting them in both toucan and albatross (so both benefit from the change) would be wrong. - Having them in separated files, we load them only when needed. The problem is that the files needs to be very well documented and the developers know about their existence. - Another solution (if the cached version is preferred) would be to have a general CSS that imports all the components. This way we serve in one go the CSS files, but still preserve the modularization. - The main advantage is the consistency of the icons usage and the independence of file names. - In the webapp\resources\icons\silk we have many icons that we don't use, but we serve the full silk package. Having a general CSS file, we could know what types of icons we use. This could be a valuable information if we ever would like to change the icons in XWiki. Having them linked in a special place solves the changeability problems. Thanks, Caty

15 years, 6 months

[xwiki-devs] Debugging XWiki with IntelliJ IDEA

by Andreas Schaefer

Hi I tried to debug XWiki using IntelliJ IDEA and a remote Jetty server. Everything works fine except that the source code is off. I checked out the trunk (actually http://svn.xwiki.org/svnroot/xwiki/platform/trunks/) , built it with Maven 2. After that I created an installation from enterprise/trunk and installed it, started Jetty in debug mode and started the IDE debugger. Again everything works except that much of the code was pointing to classes. I guess this is because each module uses dependencies to Maven modules that other projects. In order to fix that I downloaded the sources but now the source code lines in the debugger are off. This is because many modules still refer 1.9.2 rather than 2.0- Snapshot or 2.0-m2. Does anyone knows how to make the debugger work? Thanks - Andy

15 years, 6 months

[xwiki-devs] Fwd: [xwiki-users] LDAP subscription

by Vincent Massol

(I have pb with my mail client and XWiki mailing list server which is rejecting my email - resending) ---------- Forwarded message ---------- From: Vincent Massol <vincent(a)massol.net> Date: Sat, Aug 1, 2009 at 6:15 PM Subject: Re: [xwiki-users] LDAP subscription To: XWiki Users <users(a)xwiki.org> Hi Geoffroy, On Aug 1, 2009, at 4:32 PM, Geoffroy Carrier wrote: > Hello, > > I'm volunteering as a technician and hoster for the > design-platform.org collaborative project. > > We are seriously considering using to the XEM platform, in particular > for its internalization and multi-wiki support, and its nice WYSIWYG > editor. very cool :) > A major feature we are looking for is LDAP support; however, I didn't > find any information about LDAP subscription. > > The objective is to create LDAP accounts for all subscriptions on the > wiki, and completely avoid XWiki-only subscriptions. Is this feature > already available? > If yes, do you have any pointers to documentation and/or source code? > If not, do you have any thoughts on an efficient way to alter XE to enable it? Yes this is supported, see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HLDAPAut… Let us know if you have specific questions regarding LDAP. Thanks -Vincent

15 years, 6 months

[xwiki-devs] [PROPOSAL] Extend RESTful API

by Alexandru Cismaru

Hello. Currently I'm working at a Firefox extension for XWiki and I ran into some troubles because I can't obtain all the information I need from the current RESTful API. I've talked with Sergiu and Marta and they told me that I shouldn't use workarounds and an extension of RESTful API would be more appropiate. It would be useful to add: - a new element for every tag element from tags resource, representing the number of documents tagged with that tag; - a new element for every space element from spaces resource, representing the number of documents in that space; - two new resources: users and user. The information made available for every user could be: username, first name, last name, profile url, avatar, last modified page; - a new element for every page containing the type of the last modification (comment adding, atachment adding, content modification). Thanks, Alexandru Cismaru, gsoc student

15 years, 6 months

[xwiki-devs] performance improvement on linux using large-page-support in mysql ??

by Niels Mayer

Has anybody tried enabling "large page support" in Mysql for Xwiki? Doesn't Xwiki make use of Large pages for document attachments and other storage, and wouldn't this be useful for high-volume Xwiki based systems? (Fedora Linux has this feature enabled by default.) The improvement? "Applications that perform a lot of memory accesses may obtain performance improvements by using large pages due to reduced Translation Lookaside Buffer (TLB) misses." Is this worth doing? Would it improve performance (or are bottlenecks elsewhere that make this tweak irrelevant)? ............ http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html says: > On Linux, if the kernel is enabled for large page support, InnoDB can use > large pages to allocate memory for its buffer pool and additional memory > pool. See Section 7.5.9, “Enabling Large Page Support”. --> http://dev.mysql.com/doc/refman/5.0/en/large-page-support.html says: > 7.5.9. Enabling Large Page Support > Some hardware/operating system architectures support memory pages greater > than the default (usually 4KB). The actual implementation of this support > depends on the underlying hardware and operating system. Applications that > perform a lot of memory accesses may obtain performance improvements by > using large pages due to reduced Translation Lookaside Buffer (TLB) misses. > In MySQL, large pages can be used by InnoDB, to allocate memory for its > buffer pool and additional memory pool. > Currently, MySQL supports only the Linux implementation of large page > support (which is called HugeTLB in Linux). > Before large pages can be used on Linux, the kernel must be enabled to > support them and it is necessary to configure the HugeTLB memory pool. For > reference, the HugeTBL API is documented in the > Documentation/vm/hugetlbpage.txt file of your Linux sources. > The kernel for some recent systems such as Red Hat Enterprise Linux appear > to have the large pages feature enabled by default. To check whether this is > true for your kernel, use the following command and look for output lines > containing “huge”: > shell> cat /proc/meminfo | grep -i huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 4096 kB > The nonempty command output indicates that large page support is present, > but the zero values indicate that no pages are configured for use. > If your kernel needs to be reconfigured to support large pages, consult the > hugetlbpage.txt file for instructions. > Assuming that your Linux kernel has large page support enabled, configure > it for use by MySQL using the following commands. Normally, you put these in > an rc file or equivalent startup file that is executed during the system > boot sequence, so that the commands execute each time the system starts. The > commands should execute early in the boot sequence, before the MySQL server > starts. Be sure to change the allocation numbers and the group number as > appropriate for your system. > [...] > With this option, InnoDB uses large pages automatically for its buffer pool > and additional memory pool. If InnoDB cannot do this, it falls back to use > of traditional memory and writes a warning to the error log: Warning: Using > conventional memory pool > To verify that large pages are being used, check /proc/meminfo again: > shell> cat /proc/meminfo | grep -i huge HugePages_Total: 20 HugePages_Free: 20 HugePages_Rsvd: 2 HugePages_Surp: 0 Hugepagesize: 4096 kB Niels http://nielsmayer.com

15 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs