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
Notifications application is almost ready to replace the Activity Stream's
UI. The only remaining thing is the display
of the messages from the Message Stream in the Notifications.
We have made a quick brainstorming with Caty and Vincent, and here is our
conclusions.
1/ We think it make sense to display user messages in the notifications
because it is typically what notifications
are made for: pop-up important information concerning what the user cares.
In the past, we decided to disable the
Message Stream by default because messages were lost in the Activity
Stream. But in the case of the notifications, users
can chose what they want to receive so there is less chance to miss
messages in the middle of thousand of events.
2/ Like all other types of notification, there should be a button in the
notification settings of each user to decide to
enable or disable these messages in the notifications. It should be enabled
by default.
3/ We should add the "send message" gadget in the "alert" menu (via an UIX)
so it's easy to find and to send messages.
4/ Provide a form to be able to reply to a personal message.
5/ Let the message stream disabled by default. Users who are used to it
will not lose the feature but we don't make it
visible for now until we make some other improvements.
This is what I am starting to implement right now with the hope it's done
for XWiki 10.5.
In the future, we should add the following features:
a/ Having a real "inbox" application (a "Message Center") to handle all
messages.
b/ Be notified when someone mention you in a content or in a comment
(example: "@vmassol: You may want to read this
page" will trigger a notification to Vincent Massol).
c/ Handling correcty messages sent to a group if the first implementation
do not handle it (group filtering could be a problem
with SQL).
Caty, Vincent, please reply if I've forget something.
All others: if you have any recommendation or counter argument, please post
it quickly :)
Thanks for you time and have a great day,
Guillaume
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hello devs(a)xwiki.org<mailto:devs@xwiki.org>
I has a question for the XWiki.Registration
I tried to add input validation for the registration and it seems the following link has the information about it.
http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration%20Appli…
When I read this document, there is the text like:
Things which you may configure by editing XWiki.Registration
However where can I find XWiki.Registration ? Is it configuration file ?
I already check Registration section of the Administration Interface but I can not find.
Please let me know where can I find XWiki.Registration.
Thanks
Kwan