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

[xwiki-devs] [CONTRIB] New contrib project for realtime-wysiwyg

by Caleb James DeLisle

Hi, I'm working on the realtime wysiwyg extension and it's working fairly well but it's still a bit rough around the edges, some issues I'm aware of and others I am not so I would like to #1 move it to xwiki-contrib git repository and #2 have a bugtracker project to keep track of issues for this project. I'm thinking RTWYSIWYG as a project name on the xwiki.org bugtracker, does this make sense? Thanks, Caleb

11 years, 4 months

5
8
0 0

[xwiki-devs] About Bootstrap and Color Themes

by Guillaume "Louis-Marie" Delhumeau

Yesterday, I was talking to some of you on IRC, and I realized that we do not have the same expectations about our Bootstrap usage. So I would like to write a brief summary of my thoughts. Benefits of using Bootstrap ====== * Good-looking and practicals components to re-use. * A responsive CSS grid * Supported by a great community * Newcomers on XWiki will find a tool they might already know. That's already some good reasons to use it! What it cannot do for us ===== * Out-of-the box usage of a compiled Bootstrap CSS with different colors. Why? * The images URL needs to be rewritten (/xwiki/bin/resources/etc...) * A compiled Bootstrap CSS does not allow us to use the mix-ins (ie 'functions') that we can use with the Bootstrap sources. So it's less powerful. * There will always be a need to write some 'fixs' to not break the existing XWiki applications. Moreover, the kits that we can find on the internet, in my opinion, do not only change the parameters of Bootstrap. But they should also add their own CSS classes with an example of use in a HTML template. It will never auto-magically fit with XWiki. What I have in mind ===== Write a color theme editor, inspired by what there is for Bootstrap, that allows us to set values for bootstrap variables we decide to expose (there are more than 300, so I guess we should make a choice). We can take inspiration from http://stylebootstrap.info/ (but it should be less technical IMO). Plus add a textarea that lets the user enter some LESS code. So they could set other bootstrap variables and create their own CSS classes. So integrating a theme kit bought on the web would be possible without too much effort as soon as the LESS files are provided within the kit. Example: integrating a theme from Bootswatch ( http://bootswatch.com/ ) ==== Let say we want to integrate http://bootswatch.com/slate/ into XWiki, using the Flamingo skin. Steps: 1 - Create a new Color Theme for Flamingo 2 - In http://bootswatch.com/slate/ , download variables.less and bootswatch.less 3 - Paste the content of these 2 files in the textarea at the bottom of the Color Theme Editor. 4 - If some problem occurs, add some fixes in the textarea. Results: http://tof.canardpc.com/view/73dd64b9-2023-4839-8dcc-47880d823591.jpg Not perfect, so we need some fixes (about the glyphicons). After removing from the textarea the following line: @icon-font-path: "../fonts/"; We get: http://tof.canardpc.com/view/cd25fc9f-921f-4582-b2c7-05680dd6d284.jpg Looks quite simple, maybe not enough for a basic user, but still good for web integrators. WDYT? Thanks Guillaume

11 years, 4 months

3
2
0 0

[xwiki-devs] Separate GET/POST submits to filter spam for anonymous comments

by Valdis Vītoliņš

Another idea which couldn't bother normal users for anonymous XWiki comments would be separation between GET/POST submits, because spammers mostly use GET instead of POST. I couldn't find how added comment request is handled on server side though. I suspect, it is not handled with velocity scripts. Can you provide some directions? Thanks! Valdis

11 years, 4 months

3
2
0 0

[xwiki-devs] [contrib] proposal to move xwiki-tools into contrib repo.

by Caleb James DeLisle

Hi, xwiki-tools is a set of command line tools and a node.js library for building and parsing parts of xwiki .xar files. It is unique in that it contains a fairly complete model of XWiki documents, objects, and classes which is not based on the original model in oldcore. It is capable of compiling a filesystem representation of an xwiki extension such as: https://github.com/xwiki-contrib/realtime-wysiwyg into either a Maven compatible directory structure or a .xar file (which can optionally be auto-posted up to the rest interface of a running wiki). Until now I have never considered moving it into xwiki-contrib because it was always "the ducttape I needed to make the real project I was doing approachable" but even if it does not enjoy API stability guarantees, it is useful even if only as a tool for facilitating better thought about the XWiki model so I would like to move it into xwiki-contrib repository and setup a bugtracker for it. Unfortunately the name xwiki-tools which is quite descriptive in the npm repository is not so helpful in xwiki-contrib so I would be willing to rename it to node-xwikimodel (in npm it would be xwikimodel) and using a jira project name NODEXWIKIMODEL. WDYT? The project: https://www.npmjs.org/package/xwiki-tools https://github.com/cjdelisle/xwiki-tools

11 years, 4 months

3
3
0 0

[xwiki-devs] adding a javascript library(PramukhIME) to a XWiki page.

by ananthakrishna

Hi all, I want to add a javascript library called PramukhIME( http://www.vishalon.net/PramukhIME/JavaScriptLibrary.aspx) into an XWiki page. The objective is to edit Kannada language text(which is already in the page) in a XWiki page.Also,as I wan't to edit multiple pages,it will be better if the library is added only once(together for all pages). As I am new to XWiki, I don't know the basics of XWiki programming and can't even find relevant documents. Can someone please help me out.. -- Thanks and Regards, Ananthakrishna

11 years, 4 months

3
2
0 0

[xwiki-devs] [Contrib] Create a repository for the Flash Message Application

by Sidali Djebloun

Hello devs, I would like a repository for the Flash Message Application on https://github.com/xwiki-contrib. The application is available on the extensions wiki here: http://extensions.xwiki.org/xwiki/bin/view/Extension/Flash+messages+applicat ion . Thanks, Sidali

11 years, 4 months

2
1
0 0

[xwiki-devs] New IntelliJ license

by vincent＠massol.net

Hi devs, Jetbrains has been kind to renew our license, it’s available here for committers: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentToolLicenses Thanks -Vincent

11 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] Roadmap for XWiki 6.1

by vincent＠massol.net

Hi devs, After brainstorming offline with several XWiki committers here’s a proposal for the 6.1 roadmap: Content ====== * Continue work on improving performances and especially page loading times - Thomas * Continue work on the Flamingo skin with ideally the goal of having it finished and ready to be used by end of 6.1 - Guillaume * First working version of the Script Signing feature - Denis * Continue work on collaborative apps (http://design.xwiki.org/xwiki/bin/view/Proposal/CollaborativeApplications), namely: - Define new features for the File Manager app (Marius) - Design for the File Manager App (Caty + Marius) - Continue implementing the Meeting Ma,ager App (Max) - Implement the File Manager App (Marius + Sofiane) Important JIRA issues defined (first is most important): * Support 2 roles for users for app within minutes: application creator and data creator - XWIKI-8757 * Scheduler / Watchlist activity shouldn't add a version to the page. Huge xwikircs table and terrible performances when reading it. * "Current wiki" wiki macros not available in the macros list in wysiwyg in path based multiwiki - XWIKI-7739 * Adding content (images, links, table, macros) is not working on WYSIWYG on IE10 - XWIKI-10283 * Make it easy to edit the dashboard on the home page - http://jira.xwiki.org/browse/XE-1382 * Welcome block is not easily editable - XE-1389 * User Directory should not show "xwiki:XWiki." for user id - XWIKI-10284 * Show date and time of the install and user who installed for an installed extension - XWIKI-10027 * Allow to force the installation of an extension even if dependencies are not satisfied - XWIKI-9827 * Add the possibility in AppWithinMinutes livetables settings to select a default sort on a column - http://jira.xwiki.org/browse/XWIKI-9659 Investigation: * Check if we need to improve the help in the Admin section of XWiki and if so make a proposal - Caty Dates ===== - 6.1M1: 19 may 2014 - 6.1M2: 9 june 2014 - 6.1RC1: 23 june 2014 - 6.1Final: 7 july 2014 Note that initially we had planned 6.1 final to be released in June so we’re already a bit late in the cycle which is why I put 6.1M1 for 19th of May. Please add the stuff you wish to work on if you’re not in the list above and with to commit to working on something for the 6.1 release! :) WDYT? Thanks -Vincent

11 years, 4 months

6
7
0 0

[xwiki-devs] [Proposal] Integrate LESS css in XWiki

by Guillaume "Louis-Marie" Delhumeau

Hello. In 6.0, we have released a first version of Flamingo. It uses Bootstrap and the LESS preprocessor during the build to create the final style.css file. But currently, there is a serious regression compared to Colibri: it does not support color themes. So I have started a proposal about the color theme handling in Flamingo, that you can see there: http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo My conclusion is that we need to integrate the LESS preprocesor on the runtime. This way, we can add velocity variables (corresponding to the color theme) in our LESS sources BEFORE the LESS preprocessor is launched. Doing the opposite, (process velocity after LESS) causes some problems that I have reported on the previous link. To me, it would be a good step ahead for proposing LESS to our users. Regarding this, some ideas are coming to me: - it is quite easy to integrate LESS since we can use Rhino to launch the LESS preprocessor (which is a javascript program). See: https://github.com/sandroboehme/lesscss-java - we need a cache system in order to not always compute the style.css served to the user (performances issue). - we need to add this in the "skin" action. - in the future, we also need to modify the skinx actions, to enable it for Skin Extensions. We also need to agree on the use of LESS instead of SASS. I have used LESS on Flamingo because Bootstrap has originally been written with it (although an official SASS port exists), so this choice is not based on a strong analysis. Anyway, it looks quite simple to move from one to the other and it is probably too soon to predict which of these 2 preprocessors will win on the long term. Do you think I am going in the right direction? Thanks for reading, Guillaume

11 years, 4 months

8
25
0 0

[xwiki-devs] Migrate XWIKI content to MediaWIKI

by walid yaich

Hi, I would like to implement a tool to convert "xwiki xml dump" to "mediawiki xml dump", any help about which java lib to use ? some link if possible ;) Thanks in advance :)

11 years, 4 months

3
3
0 0

[xwiki-devs] Jira not showing Git logs anymore?

by Paul Libbrecht

Hello fellow developers, we used to see Git commits linked to jira issues (in the activity I think). I was expecting one here: http://jira.xwiki.org/browse/CURRIKI-6545 e.g that commit: https://github.com/xwiki-contrib/currikiorg/commit/b56edde328aabb19e5874fdc… Was something changed into the jira so that xwiki-contrib is not watched anymore? The feature seems to be still there for xwiki-platform. thanks in advance. paul

11 years, 4 months

2
3
0 0

[xwiki-devs] Refresh a macro

by firmusoft.xwiki

Hi, I have a macro which displays all the objects of a class in a table. We can add a new object to the class also, using the macro. I want the newly added object listed in the table. Currently this happens only when I reload the page. Can we refresh a macro so that the table gets updated as soon as we add a new object? Please help me on this Thanks, Firmusoft

11 years, 4 months

2
2
0 0

[xwiki-devs] [Brainstorming] Applications / Skin dependence

by Ecaterina Moraru (Valica)

Hi, With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc. This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2]. In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVa… I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause. Thanks, Caty [1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo

11 years, 4 months

5
10
0 0

[xwiki-devs] [ANN] XWiki 6.0 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki <version>. First version of the 6.x cycle having for main theme performances. This version marks the move to Java 7 as minimum version and comes with a new experimental Flamingo skin, new chart renderers, WebJars support and many other improvements. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki60 Thanks -The XWiki dev team

11 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] Improve our Panels technology

by Guillaume "Louis-Marie" Delhumeau

Hi. After some discussions with Caty and Vincent, we would like to propose you new ideas about the panels technology, that replaces our previous propositions about the Flamingo Applications Bar. The proposal is there, with more explanations and screenshots: http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements Here is my +1. Louis-Marie

11 years, 4 months

6
20
0 0

[xwiki-devs] Extensions documentation (was:[Proposal] New xwiki-extensions GitHub organization)

by Jeremie BOUSQUET

Hello, Regarding applications best practices, I noticed that in the list of best practices there's nothing related to documenting your extension, apart from the fact that you should publish it on e.x.o. It's better now, but I think it happened frequently to have pages created in extensions repository with only the default information and a download link, it makes difficult understanding and using the extension. For example for xar, it could be helpful to have at least the list of space(s) created by the app (if any), without having to look into the xar, or to install it with EM. Also in EM you see the pages installed, but only in the logs. After it's installed and you come back, you have no way to list the pages that belong to a specific extension. For an app you could have an entry in app panel, but for a macro for example, it makes it difficult to find the macro afterwards. Obviously for anything proposing an API, the API should be described (at least a javadoc link, better some digest in extension page IMHO). The problem with adding the documentation AFTER publishing the extension (for example, you need to deploy it in a rush, so you don't have time to write proper documentation), is that you risk that users come first when extension is published, see nothing, and never come back. So I really think to have this part of the release process of an extension (and not something added after the time). That's also a problem for example with some Maven plugins (even some officially supported), that propose only very minimal information on their site, and count on source code access and forums to provide essential infos to users... WDYT ? BR, Jeremie ---------- Forwarded message ---------- From: vincent(a)massol.net <vincent(a)massol.net> Date: 2014-05-07 8:43 GMT+02:00 Subject: Re: [xwiki-devs] [Proposal] New xwiki-extensions GitHub organization To: XWiki Developers <devs(a)xwiki.org> Hi Marius, Thanks for your reply with challenging questions ;) See below. On 7 May 2014 at 07:31:34, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote: > You mentioned 2 needs and your proposal satisfies only the second. > What about the first need? > > Who's going to be responsible for releasing these extensions? The xwiki-extensions organization is under the responsibility of the XWiki Dev Team so it’s the XWiki Dev Team who will release its extensions. > We don't > have many options when it comes to choosing a release manager for XE > so I doubt committers will jump in to release these extensions unless > they really need them. So we may end up with either > > * having long release cycles for these extensions (which is against > the second need you mentioned) because everyone has other things to do > (note that this currently happens with some of the maintained > extensions from xwiki-contrib), or > * using the XE release manager and releasing all of them at once, but > then having a separate GitHub repo for each extension is not > justified. > > In any case, the time spend on doing releases and the paper work > around them will increase and it will most probably be the time of the > XE release manager. Yes I agree about your points. We need to handle this. Now === The new xwiki-extensions organization strategy will work only if we get more committers. The idea is to get the contributors of those extensions as committers for those extensions and thus be the RM for those extensions. Said differently we need a defined RM per repo. Note that longer release cycles is not an issue if the extensions has not had any code committed for it. What’s important is to be able to get it in the hands of users when there are important bug fixes or new features. It seems logical to me that those who commit these bugs/features release them. It’s obvious that separated extensions would mean a lot more work *if* we wanted to always release them all. But this is not the case. They’ll be released when those working on them want to release them or under user pressure. What we need to decide is how we want to handle Roadmaps and Release notes. I think we should start defining roadmaps per extension on e.x.o (we already support RN on e.x.o using either the jira macro or manually). Generally speaking for each extension that we add to xwiki-extensions we need a person resonsible for it, who’ll be in charge of defining the roadmaps, release notes and do the releases (he/she can delegate but he/she will still be responsible until that responsibility is handed to someone else. I believe this will be one criteria for accepting an extension in xwiki-extensions. Future ====== When we have the notion of Flavors, I believe it will simplify things to organize releases per flavor (XE can be considered a flavor ATM BTW). When this time comes we could decide to have a RM per flavor with a Roadmap/Release notes per flavor. I have no idea how many flavors we would have but I can think of 3: - xwiki.org flavor (FAQ app, JIRA macro, IRCBot app, etc) - knowledge base flavor (…) - collaborative apps flavor (calendar, meeting manager, file manager, etc) > As for moving extensions out of xwiki-contrib to xwiki-extensions, > it's not simple. First, it's not very clear which contrib extensions > will be chosen. You said "some maintained apps" but the link you gave > is more about the functionality they provide and whether they fit in > our view of the collaborative app suite. Then in order to move an > extension you need to ask the contributors, otherwise you'll have to > fork the repo and create a new extension id. They’ll be chosen on a case by case basis with a VOTE for each. The person proposing it will put forward a maintainer for the extensions (who will be responsible of Roadmap/Releases Notes and performing releases). Note that IMO there are some conditions that we could define as base conditions: * Having had several releases already * Obeying the app best practices as defined by http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… * Having some tests and for apps, having at least one functional test (this means the functional test fwk is in place and ready to receive more tests) * Code style needs to obey http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle and generally speaking obey the practices defined on http://dev.xwiki.org > Then what happens if an > extension from xwiki-extensions stops being maintained, do we move it > back to xwiki-contrib? Yes, same as what happens currently in the xwiki organization. > I'm not fully convinced by your proposal. The real goal of this proposal is to start having nice applications that can be a showcase of XWiki. Till now we have the engine and some extensions but none of them are developed as strongly as platform and they fall short. This is an effort to make a usable XWiki *product* vs just an XWiki *platform*. Again, we should take in only extensions that we can maintain, i.e. for which we have a volunteer to maintain them. TBH I don’t know if this will succeed or not but I feel it’s worth trying :) Do you have some better idea? Thanks -Vincent > Thanks, > Marius > > On Mon, May 5, 2014 at 5:43 PM, vincent(a)massol.net wrote: > > Hi devs, > > > > Right now we have 2 organizations related to the XWiki project on Github: xwiki and xwiki-contribs. > > > > The separation is currently the following: > > * XWiki Committers maintain the code in the “xwiki” organization > > * non XWiki Committers (aka contributors) maintain the code in the “xwiki-contrib” organization in the way they want (some extensions there are not maintained, others are maintained) > > > > After brainstorming with Thomas Mortagne we’d like to propose the following changes: > > > > Need > > ===== > > > > * Be able to extract some maintained apps from xwiki-contrib to separate them from less maintained extensions. For example the top apps listed here: http://design.xwiki.org/xwiki/bin/view/Proposal/CollaborativeApplications > > * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features). > > > > Proposal > > ======= > > > > * Introduce a new xwiki-extensions organization in GitHub which would be maintained by the XWiki Dev Team (aka XWiki Committers) > > > > * For now, move out of xwiki/xwiki-platform all modules that are not bundled by default in XE. This rule will be reviewed and modified when we introduce the flavors concept in the future. The idea is that xwiki-platform will contain “core extensions” only and as we progress towards extensions, the number of core extensions will get smaller and smaller till possibly only the EM and what it requires. Everything else would be located in the xwiki-extensions organization > > > > * Have one repository per extensions in the xwiki-extensions github organization so that each extension can be released independently of each other > > > > * In order to make it simple to release, the idea would be to have Roadmaps and aggregated Release Notes per Flavor (this is what we’re doing now with the “XE” flavor BTW). > > > > * We will be able to vote in committers for specific repos located in the xwiki-extensions organization without having them voted for the xwiki organization (although, over time, they would be able to become xwiki committers for the xwiki orgnization should they wish and if they’re voted in) > > > > * Extensions from xwiki-extensions published on e.x.o would have “XWiki Development Team” as author, which means they will be officially supported by the xwiki committers. > > > > > > WDYT? > > > > Thanks > > -Vincent & Thomas _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

11 years, 4 months

2
1
0 0

[xwiki-devs] [Proposal] New xwiki-extensions GitHub organization

by vincent＠massol.net

Hi devs, Right now we have 2 organizations related to the XWiki project on Github: xwiki and xwiki-contribs. The separation is currently the following: * XWiki Committers maintain the code in the “xwiki” organization * non XWiki Committers (aka contributors) maintain the code in the “xwiki-contrib” organization in the way they want (some extensions there are not maintained, others are maintained) After brainstorming with Thomas Mortagne we’d like to propose the following changes: Need ===== * Be able to extract some maintained apps from xwiki-contrib to separate them from less maintained extensions. For example the top apps listed here: http://design.xwiki.org/xwiki/bin/view/Proposal/CollaborativeApplications * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features). Proposal ======= * Introduce a new xwiki-extensions organization in GitHub which would be maintained by the XWiki Dev Team (aka XWiki Committers) * For now, move out of xwiki/xwiki-platform all modules that are not bundled by default in XE. This rule will be reviewed and modified when we introduce the flavors concept in the future. The idea is that xwiki-platform will contain “core extensions” only and as we progress towards extensions, the number of core extensions will get smaller and smaller till possibly only the EM and what it requires. Everything else would be located in the xwiki-extensions organization * Have one repository per extensions in the xwiki-extensions github organization so that each extension can be released independently of each other * In order to make it simple to release, the idea would be to have Roadmaps and aggregated Release Notes per Flavor (this is what we’re doing now with the “XE” flavor BTW). * We will be able to vote in committers for specific repos located in the xwiki-extensions organization without having them voted for the xwiki organization (although, over time, they would be able to become xwiki committers for the xwiki orgnization should they wish and if they’re voted in) * Extensions from xwiki-extensions published on e.x.o would have “XWiki Development Team” as author, which means they will be officially supported by the xwiki committers. WDYT? Thanks -Vincent & Thomas

11 years, 4 months

7
11
0 0

[xwiki-devs] The danger of API proliferation.

by Caleb James DeLisle

Hi folks, I saw an issue to rename a method ( http://jira.xwiki.org/browse/XWIKI-10311 ) in XWikiContext. I don't want to single out the author, the commit is not an outlier, on the contrary it represents a pattern and this worries me. I've seen this same pattern in Microsoft technology and while each decision in isolation makes sense, the sum of all changes ended up making Windows an unapproachable API garbage heap which may be one reason why everyone left the desktop to develop for the web. Take for example the humble printf() function, standardized in POSIX. At some point a somebody at Microsoft noticed all of the security problems with C programs and decided to make a set of "hardened" functions which would be more secure. Some of them had excellent security features but others did just a little extra checking, each had the suffix "_s" added to the function name. Because it's not feasible to do any other checks, printf_s() just checks if the inputs are NULL and if so, raises an exception. Developers who had been using printf() were told that they were making bad insecure code and had to begin using printf_s(). Windows was being used in many countries with different alphabets and at the time, the only way to represent different languages was using the high 128 characters left undefined by the ASCII standard, but since each language needed a different 128 characters, Windows needed to know what language the string should be interpreted in so somebody invented printf_l() which took an extra parameter which was the *locale*. Of course printf_s_l() because people still need to write secure code! Eventually this silly idea of locales and code pages was replaced with Unicode (specifically UTF-16). Unicode characters being 16 bits wide needed to be handled differently from their 8 bit cousins so a new set of functions was written beginning with w prefix. wprintf() wprintf_s() and to make porting easier for programs which had been written to use "_l" functions, they added wprintf_l() and wprintf_s_l() even though they should not have been strictly necessary. Unfortunately after everyone had rewritten their programs to use the new and improved wchar_t and the w* functions, someone realized that not all computers even support Unicode! So they rushed to implement a new character type called tchar_t which is a wide character if-and-only-if the computer supports it. When tchar was invented, they had 4 printf functions to port and so came tprintf() tprintf_s() tprints_l() and tprintf_s_l(). Then some smart guy at IBM took another look at this Unicode idea and realized that with clever encoding, one could make a character representation which uses 1 byte to represent ASCII letters and more bytes only when it needed to represent different alphabets. Thus UTF-8 was born. The best part was it was fully backward compatible so you could use this with normal printf()! In the Linux world, most of this drama just never occurred, people kept on using printf() as if the rest of the world never existed and when UTF-8 was devised, Linux programs could suddenly speak Chinese. Microsoft, apparently ashamed of their 11 printf functions but still unable to take a lesson, deprecated them all and went on to create .NET which standardized around Console.WriteLine() (for now). While Linux and friends now all transparently support UTF-8 and it's alphabets, Windows is still unable to support Unicode filenames without first converting the string into wide character format and then using the old 'w' prefixed functions. Even then, UTF-8's scaling byte count supports more characters than UTF-16 so Windows *still* has a hard time with some languages! The problem with all this is you lose coherency, the community fragments and if the scary plethora of methods is not enough to scare off new developers, there are the angry old developers standing by to haze them for using insecure/unportable/deprecated functions instead of the shiny new ones. I think we should think a lot harder before either deprecating a method or adding duplicate functionality. Anyway my 2¢ Thanks, Caleb

11 years, 4 months

1
0
0 0

[xwiki-devs] How many committers are using IntelliJ IDEA and are happy with it?

by vincent＠massol.net

Hi devs, Our intellij IDEA ultimate license has expired. Jetbrains is ok to renew it but they wish that the xwiki project gives something more in return: they mentioned some blog post for example. So first, who’s using IDEA and would like to continue using the Ultimate version (vs the community one which is free)? Any idea of what we could do? Thanks -Vincent

11 years, 4 months

5
11
0 0

[xwiki-devs] [Proposal] Also send system information when sending Active Installs pings

by vincent＠massol.net

Hi devs, I’d like to propose what I started writing in http://jira.xwiki.org/browse/XWIKI-10274 : " The idea is to send the following pieces of information too: - Java version - OS name, arch and version - Database product name and version This will allow us to know more our use base and evaluate better the consequences of moving from one version of Java to another, what are the most used DBs on XWiki, what OS is the most used for XWiki, etc. This is useful to understand where to focus our support efforts for example. See also http://design.xwiki.org/xwiki/bin/view/Proposal/ActiveInstalls2 “ WDYT? Thanks -Vincent

11 years, 4 months

5
4
0 0

[xwiki-devs] Fwd: Programmatically loading text file content with unicode characters into XWiki

by ananthakrishna

Hello, I want to load content in large number of(millions) text files into XWiki pages.The text files contain Unicode Kannada characters(as well as some English characters). Is there a way to programmatically load these text file content into a XWiki page? Also will it work for millions of pages? I am new to XWiki.Can you please help me out. Thank you, -- Regards, Ananthakrishna

11 years, 4 months

2
1
0 0

[xwiki-devs] [VOTE] Drop support for IE8 for 6.x

by Ecaterina Moraru (Valica)

Hi devs, This mail is about voting to drop support for IE8 in 6.x cycle. The issue is more complicated, since according to our 'Browser Support Strategy' [1] we are supporting IE8, IE9 and the latest versions of FF, Chrome (+ Safari5). IE8 was released in March 2009 (4 years ago) IE9 - March 2011 (2 years ago) IE10 - Sept 2012 (17 months ago) IE11 - Oct 2013 (4 month ago) With the release of IE11 some companies also dropped their support for IE9, so we should also adjust our support strategy by supporting newer browsers (IE10, IE11) and dropping the support for old ones (IE8, IE9). According to Statcounter for the last 6 month period http://gs.statcounter.com/#browser_version-ww-monthly-201309-201402-bar the most popular IE browsers are IE10 (8.48%) and IE8 (7.98%). While the market share is not neglectable there is something you need to consider: In 6.x we want to add a new skin: Flamingo. Ideally this skin should be responsive. In order to assure responsiveness we need media query support. IE8 doesn't has support for media query natively, we would need Respond.js [2] to enable it. While this solution exist, 6.x will be ready at the end of 2014 when I suspect the market share for IE8 will drop. Additional to not having media query support, there are other CSS3 properties and HTML5 elements that are not fully supported by IE8 (border-radius, box-shadow, transition, etc.). This is my +1 to drop support for IE8 in 6.x Thanks, Caty [1] http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy [2] https://github.com/scottjehl/Respond

11 years, 4 months

6
10
0 0

[xwiki-devs] [UX] Converge design of Mail Archive app with xwiki / flamingo / forum app

by Jeremie BOUSQUET

Hello, I was having a look at the proposal for Forum app design with Flamingo [1][2], and I thought it could be good to start thinking about the same for the Mail Archive app. Yes, I'm still working on this btw :) Would it be possible for me to re-use some graphical elements from this proposal ? (buttons icons, the grey icons around the boxes corners, this sort of thing). Would it be possible to somehow get close to this design even without Flamingo skin (so with colibri), as flamingo is still not a final skin ? Also I remember there were some discussions about it, but how should one proceed, keep the same app and maintain both colibri/flamingo look with distinct css (and how to switch between both ? detect the current skin of the wiki ?). Or just make a "flamingo" version that would not look too bad with colibri ? Would the ColorTheme variables still be available for a parsed ssx ? To be honest I like the proposal (and a forum app UI is the closest you could get to a mail archive app UI), except maybe for the topics / topics answers, if there's a large number of answers (occurs often with a mail thread), maybe it's not enough compact / paginated. In my most crazy dreams, the forum app and the mail archive app could share the same UI with small variants, but fed with different objects / data sources - seems very nice idea, but would be quite complex to achieve. I'm just trying to prepare myself only, because I will not work on this yet - I'm currently bugfixing and finishing some UIs. Maybe I should wait for the 6.x cycle (and flamingo) to be more mature. Thanks & regards, Jeremie [1] http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplicationDesign [2] http://xwiki.markmail.org/thread/kytpmsypd2cjemir

11 years, 4 months

2
2
0 0

[xwiki-devs] [UX][Proposal] Application: Tasks

by Ionut Maxim

Good day, One of the objectives of 6.0 is to review the existing applications on extensions.xwiki.org, improve them and see how they would integrate in the upcoming Flamingo skin (while also considering improvements suggestions). This mail covers the Flamingo integration for the Tasks Application<http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati…>. You are welcomed to review the proposal at: *http://design.xwiki.org/xwiki/bin/view/Proposal/TaskApplicationDesign <http://design.xwiki.org/xwiki/bin/view/Proposal/TaskApplicationDesign> * Any feedback is welcomed. Thank you, have a good day! -- Ionut MAXIM - - - - - - - - - - - - - - - - - - - - - - - - Web Designer @ XWiki SAS - - - - - - - - - - - - - - - - - - - - - - - - +40755120711 | www.xwiki.com

11 years, 4 months

3
2
0 0

[xwiki-devs] Continuing the search of the best directory structure for XWiki applications

by Caleb James DeLisle

Hello devs, As some of you know, about one year ago I developed a toolkit for scripting the generation and installation of .xar extensions. As of last July, my kit was really just a javascript API for crafting extensions programmatically. Recently I finished development of a directory structure for representing XWiki applications which layers on top of the toolkit. I documented it here: http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApp… I would like to hear some thoughts about this structure as I'm hoping to evolve the optimal human readable filesystem representation for XWiki applications and content so comments are most welcome. I would like to add: * simple representation of extension with all metadata necessary for uploading to extensions.xwiki.org * xardump to dump a xar file into a "cannonical" directory structure. * xarlint to check if a directory representation is cannonical, cannonicalize it, or warn if nodejs specific functions are being used. * maven job which builds xars from directory structures. WDYT? Caleb

11 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs