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
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
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
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
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
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
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
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