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

[xwiki-devs] Android Authenticator 0.4.2
by Алексей Овсянников 11 Jun '18

11 Jun '18

What’s new? - Fixed bug with private XWiki instances - Fixed bug with impossibility to edit contact (was error) All information about common 0.4 version you can read on previous release note: https://forum.xwiki.org/t/android-authenticator-0-4-release-here/3104 --------- Best regards, Ovsyannikov Aleksey, ovsyannikov.alexey95(a)gmail.com

1 0

[xwiki-devs] GitLab Commit Application
by Ludovic Dubost 10 Jun '18

10 Jun '18

Hi, I've created a GitLab commit application in order to be able to commit XWiki pages to a GitLab instance using the gitlab v4 api. http://extensions.xwiki.org/xwiki/bin/view/Extension/gitlab%20Application/ I've commited it on the XWiki SAS GitLab instance as a way to test the tool https://git.xwikisas.com/ludovic/application-gitlab/ Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.orgTry XWiki on the cloud <http://www.xwiki.com/en/products/try-xwiki-cloud> - Try Cryptpad: Secure realtime Wysiwyg Editing <https://cryptpad.fr>

1 0

[xwiki-devs] Android Authenticator 0.4 Release here!
by Алексей Овсянников 10 Jun '18

10 Jun '18

Whats news: 1. Fully rewritten network part 2. Rewritten graphical part 3. Fixed a bugs 4. Changed package id (incompatible with old version) More information you can find on XWiki forum page: https://forum.xwiki.org/t/android-authenticator-0-4-release-here/3104 --------- Best regards, Ovsyannikov Aleksey, ovsyannikov.alexey95(a)gmail.com

1 0

[xwiki-devs] [VOTE] Change Android Authenticator package
by Алексей Овсянников 09 Jun '18

09 Jun '18

Hello everybody! We are stuck for the release of "Android Authenticator" application. You need 2 things to publish on play store: - A unique application ID (the current one is "org.xwiki.android.authenticator") - An associated publication key Problem is that we lost the key (we lost contact with Fitz during first GSOC before he get a change to give us the private key he used for the first release) and you can't change the key for an application on play store. We contacted the support to know if we could modify the key but we did not get any answer and since it' not too critical to ditch the old (beta released only) application and create a new one (new from play store point of view) we decided to change the id. Also note that the Java package we use in the module is "org.xwiki.android.authenticator" which is why we have the current application id. Here are a few proposals: 1) "org.xwiki.android.authenticator.v2" as in the second version of the key and if we loose the key again it can be v3 :) 2) "org.xwiki.android.authenticator.i2" to not look to much like a version of the application (id 2) 3) "org.xwiki.android.sync" since the application is about synchronization of xwiki data 4) "org.xwiki.android.sync.contacts" since the application is about synchronization of contacts too 5) "org.xwiki.android.authenticator.reborn" as in it's been a long time since we did a release of this application and half of it has been rewritten since that time WDYT ? I think that "*.(v2|reborn)" are not better ways to rename (but "reborn" better than "v2" becase "v2" mean version number 2, but what for do we have android app version?:) ) and in my humble opinion we must choose "org.xwiki.android.sync.contacts" or better to choose "org.xwiki.android.sync" because it will not prohibit us to add extension applications with packages as "org.xwiki.android.sync.contacts" and will show first value and purpose of application. Issue: https://jira.xwiki.org/browse/ANDAUTH-35 --------- Best regards, Ovsyannikov Aleksey, ovsyannikov.alexey95(a)gmail.com

3 5

[xwiki-devs] GSoC Blockly Editor
by Vivek Iyer 08 Jun '18

08 Jun '18

Hello everyone! So Vincent asked me to send a mail to the dev list regarding the current status of the Blockly editor project, and what needs to be done in the coming few months, so we're all on the same page, so here goes. Firstly, regarding the current status of the project, here's what the user çan do: - Create and delete Blockly blocks - Generate code in Javascript (Show Javascript) - Execute it - Save the code to the page (without executing it) However after discussion with Vincent, he raised the following concerns: 1. Show Javascript just appends content to right and does not do anything to the existing content. Now I'm a bit confused as to what the problem is here, because the code just gets appended to the right of the cursor position, and that's how I wanted it to be, because that way the user can just navigate normally to the line where he/she wants code inserted, and click on "Show Javascript" to generate said code. So I believe this is fine. 2. Code does get saved but not interpreted and this is a problem. 3. There is no option to execute the code in view mode, this exists only in the editor 4. There is no option to convert the generated code back to Blockly blocks. Blockly actually does not provide this feature. In order for this to be implemented, the AST generated using Velocity needs to be converted to XML so it can be displayed using blocks, but I feel this would be outside the scope of this project. IMO what we can do is push this to the end and add this feature later if time permits. However if we provide this support for Velocity, we won't be able to provide it for other languages, since it would be much more complicated then and providing the back conversion feature for just one language (ie. Velocity) doesn't make sense to me. That's something else we need to consider. Maybe it can be implemented as part of a separate project. 5. There is a design flaw when the page gets redirected to Blockly/Editor for editing the content of the page. I had implemented it this way since Clement suggested me this editor (https://github.com/xwiki- contrib/application-xwebide) as reference, and so I used this. Nevertheless, it does cause some complications as the content of the page gets edited in case the $docRef is empty which can be handled but it doesn't make sense logically. The solution which we agreed upon is: For points 2 and 3, the generated code should be saved in an XObject that's retranslated back to code when the edit page is rendered. A sheet is attached to this XObject for view and edit modes, and the content gets rendered appropriately. A Javascript macro is used to render the code, and it gets executed when an execute button is pressed in the view mode. For point 5, we decided to drop Blockly as an editor and remove the edit menu entry and implement it as a template instead using a template page and a template provider page, similar to how its been done in https://github.com/xwiki-contrib/application-diagram/. That is all! This is what I've understood so far, and if any of you has feedback/suggestions, please get back to me ASAP! :) Regards, Vivek Iyer

1 0

[xwiki-devs] [XWiki Day] BFD#180
by Alex Cotiugă 08 Jun '18

08 Jun '18

Hello devs, This Thursday is BFD#180: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday <http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays> Our current status is: * -51 bugs over 120 days (4 months), i.e. we need to close 51 bugs to have created bugs # = closed bugs # * -89 bugs over 365 days (1 year) * -146 bugs over 500 days (between 1 and 2 years) * -306 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#180 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14301 Happy Bug Fixing Day, Alex

1 1

[xwiki-devs] [UX][Idea] User Index Cards
by Ecaterina Moraru (Valica) 08 Jun '18

08 Jun '18

Hi devs, This proposal displays an additional layout mode for the User Index, where users are displayed using cards. http://design.xwiki.org/xwiki/bin/download/Proposal/Users/UserIndex/UserInd… This idea was proposed / discussed by Nicolas Lemoine. The initial purpose was to improve the UI of our User Index. I've iterated also on some other ideas, like application specific actions integration inside content menu, user actions (send message, follow) in the card display, user groups display, etc. Proposal: http://design.xwiki.org/xwiki/bin/view/Proposal/Users/UserIndex/UserIndexCa… Let me know what you think, Caty

3 6

[xwiki-devs] [Brainstorming] Best practices on indentation for rendering macros in scripts
by Vincent Massol 07 Jun '18

07 Jun '18

Hi, Context 1: https://jira.xwiki.org/browse/WIKIEDITOR-58 Context 2: Fill the “velocity code style” section of http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/ Option A-1: No top level indentation ========================= {{velocity}} #set ($var = …) #if (…) … #if (…) #end #end {{/velocity}} Nested example: {{velocity}} #if ($doc.fullName != 'XWiki.AdminInlineSheet') #set($formname = 'inline') #set($saveaction = 'save') #set($previewenabled = true) #set($xnotification = $!request.getParameter('xnotification')) {{html}} <form id="inline" method="post" action="$doc.getURL('preview’)"> <div> … {{/velocity}} Pros: * This is what we currently do which IMO means it’s the more natural way * Makes content more visible when editing inside xwiki since it takes less horizontal space * Less typing and less chance to make it wrong Option A-2: Top level indentation ======================== {{velocity}} #set ($var = …) #if (…) … #if (…) #end #end {{/velocity}} Nested example: {{velocity}} #if ($doc.fullName != 'XWiki.AdminInlineSheet') #set($formname = 'inline') #set($saveaction = 'save') #set($previewenabled = true) #set($xnotification = $!request.getParameter('xnotification')) {{html}} <form id="inline" method="post" action="$doc.getURL('preview’)"> <div> … {{/velocity}} Pros: * More logical since a macro is a container (even though it’s different syntax - wiki markup vs velocity - so it’s arguable) * More legible? Cons * This means slowly changing everywhere we use scripting. WDYT? I think my preference goes to A-1 FTM since I’ve never thought to myself that it was an issue all these years of using it. Thanks -Vincent

9 13

[xwiki-devs] Nexus account creation
by Vivek Iyer 06 Jun '18

06 Jun '18

Hi everyone! I want to release v0.1 of the Blockly extension, and I need a Nexus account as per the steps given here ( http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HJIRARelease) I would like my username for the Nexus account to be Remorax. Please do the needful and get back to me! Thanks and regards, Vivek iyer

2 1

[xwiki-devs] [GSoC] Reminder: First evaluation deadline on 15th of June 16:00 UTC (1 week)
by Eduard Moraru 06 Jun '18

06 Jun '18

Hello, GSoC students and mentors. I would like to remind you that the first evaluation deadline is approaching at the end of next week. Below is an extract from the timeline[1]: June 11 16:00 UTC Mentors and students can begin submitting Phase 1 evaluations June 15 16:00 UTC Phase 1 Evaluation deadline As a result, please make sure students talk to their mentors and make sure they are prepared and understand what is expected from them in order to successfully pass the evaluation. Very important: Do not forget to actually fill in the evaluation, when asked by Google, as not doing so (either by the student or the mentor) will cause the student to be failed by default, even if they did a great job so far. So *both* mentors and students need to fill in evaluations, and not only mentors! Hope you're having a great time, learning and building cool stuff! Thanks, Eduard ---------- [1] https://developers.google.com/open-source/gsoc/timeline

1 0