Hi devs.
This vote is about enabling notifications about "page" events (create,
update, delete, comment) by default, for both notification menu and emails.
I think it is important since watchlist is replaced by notifications in the
next version. If the user does not enable it, then even if there is a
bridge between the watchlist preferences and the notifications, she won't
receive emails anymore.
Moreover, it makes this feature more discoverable (for sure!).
Here is my +1.
Thanks,
PS: my plan was initially to have it for 10.1RC1 and 9.11.3. Regarding the
time-frame, I'm not sure we can do it for 10.1RC1. So either we do it for
10.1 final or 10.2RC1.
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi devs,
I’m currently working on improving our TeX renderer (which is really a POC ATM), in an effort to see if it could be used to generate nice PDF exports (you generate LaTeX and then you convert to PDF).
The main issue is that LaTeX doesn’t have any technology for applying style to it (like CSS has for HTML). In addition I wasn’t able to find any good HTML+CSS to TeX converter (as we have for PDFs with XSLT+FOP).
So right now my idea is to implement some default behavior in the Tex Renderer (that could be configured globally in xwiki.properties and/or in the Admin UI) and give the ability to override specifically in the content.
For example, imagine that you need to decide how to position table column content (left, centered, right) or whether the rows and/or columns of your table have vertical and horizontal lines (or other configs, autowrap, etc).
The idea is that the Tex Renderer would support some custom tex-specific parameters. For example:
(% tex-table-spec=“c | c | c" tex-table-floating="true" tex-table-caption="caption" %)
|=A|=B
(% tex-table-row-ending="\hline" %)|a|b
(by default the table spec would be left aligned with vertical lines, and rows would be separated by horizontal lines).
If you have some comments or ideas, please let me know.
Inventing a CSS-like mechanism would just be too hard to implement IMO.
Thanks
-Vincent
PS: If you want to see table options in LaTeX, see https://en.wikibooks.org/wiki/LaTeX/Tables
We would need an extension point inside the Help application content in
order for the applications to insert their documentation, usage, actions,
etc.
There are several use cases that would need an extension point inside the
Help application:
- Templates section: some templates might want to promote themselves with
previews;
- Macros section: same;
- Applications section: same;
- Help Homepage
-- Tours: there is a proposal that adds a Tour section that lists the
available Tours, see
http://design.xwiki.org/xwiki/bin/download/Proposal/MultiPageTours/helpHome…
and
http://design.xwiki.org/xwiki/bin/view/Proposal/MultiPageTours#HHelpTours
-- Scripting Documentation Application
http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting%20Documentat…
could insert itself inside Help section, instead of AppBar.
- Not sure if extension points also apply for Sandbox and XWiki Syntax, or
if these should be just moved here.
WDYT?
Thanks,
Caty
+1
Le 12 févr. 2018 1:51 PM, "Vincent Massol" <vincent(a)massol.net> a écrit :
Hi devs,
I’m following up from the http://markmail.org/message/zegx62ogtq5evbsy
thread and creating a new one since this is a side topic.
The idea is that right now when the user needs to create side content (ie
Panels), it’s confusing since they can use either the Panels app or Menu
app.
I have the following proposal: Separate the apps
* Keep the 2 concepts of Panels and Menus and make them separate: Use the
Menu app for creating menus and the Panel app for creating panels
* Remove the ability to create panels from the Menu app
* Improve the Panel app to make it simpler to create panels
** Introduce a new xproperty for the panel title (and supporting scripting,
could be a text area).
** If the panel xproperty content is empty then don’t display the title.
This is to no loose the ability to have panels displayed only if some
conditions are met.
** Display panel content textarea in WYSIWYG to make it simple for new
admins to create panels.
* Note that this solves issue https://jira.xwiki.org/browse/XWIKI-10112
since we already have a Panel Wizard!
* If we want, we can also easily introduce the concept of visibility for
panels.
WDYT?
Do you see any use case that wouldn’t be covered?
Thanks
-Vincent
Hi devs,
As most of you already know, XWiki has been accepted to Google Summer of
Code 2018!
We currently have 12 project proposals and 8 mentors [1].
There is 1 month left [2] before the student application period begins, so
if others want to sign up as mentors and/or propose new GSoC projects for
the students, please do so on the ideas list [1].
During this period, students are supposed to ask questions about the
proposed projects so please don`t hesitate to welcome and help them out!
Another thing you can help with is to increase the list of "Trivial" issues
that we know about on jira.xwiki.org. You can to set the "Difficulty" field
of a jira issues to "Trivial" if you know for a fact that it would be
something easy for someone new to XWiki to fix. We`re currently using a
JIRA filter [3] to gather all these "Trivial" issues and listing them on
the guidelines [4] page to help students discover them more easily.
Thanks,
Eduard
----------
[1] http://gsoc.xwiki.org
[2] https://developers.google.com/open-source/gsoc/timeline
[3] https://jira.xwiki.org/issues/?filter=10534
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HIncreasi…
There are several applications that are listed in the Recommended
extensions, but meanwhile they were bundled in Platform. According to the
Definition of a Recommended Extension [1] they should be not removed from
the Recommended list. Examples of applications:
- CKEditor
- Help Application
- Templates Application
- Menu Application
- Tour Application
- Syntax Highlighting Application
Maybe we kept them to promote them or because we forgot. Also there is no
list on e.x.o with the bundled applications. Would that be useful? Still
kind of hard to differentiate between user related applications and very
technical bundled applications.
Let me know what you think,
Caty
[1]
http://extensions.xwiki.org/xwiki/bin/view/ExtensionCode/RecommendedExtensi…
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE, "Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1, false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT, PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki or Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
Dear XWiki devs
We are using the XWiki platform for our applications but sadly are still
stuck with 2.7.2. Lately we ran into issues on a large database and noticed
"disappearing" BaseObjects. We were able to link it to XWIKI-6990
<http://jira.xwiki.org/browse/XWIKI-6990>, where hibernate IDs collided
(hash collisions) and overwrote other objects without any trace - neither
visible in the history nor in a log file.
We analysed your implemented solution from 4.0+ in XWikiDocument
<https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…>
and BaseElement
<https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…>
and
noticed that you changed the 32bit String#hashCode to 64bit MD5, which
makes a collision less likely. I have a few questions regarding your
solution:
1) Is there any specific reason why you have chosen MD5 over SHA-1 or 2?
2) Collisions are still possible and would be extremely hard to notice
since they are completely silent. Have you considered to implement a
collision detection to at least log occurring collisions - or even better
reserve 1-2bits of the 64bit to be used as collision counter in the case of
it happening?
3) To question the concept of generating a hash for an ID in general:
Wouldn't a database defined "auto increment" be a much more robust solution
for the hibernate IDs? A collision would be impossible and
clustering/scalability is still possible with e.g. the InnoDB “interleaved”
autoincrement lock mode. Why have you chosen a hash based solution in the
first place?
I'm sorry if these questions were already answered in the dev mailing list
or on issues, please link me to them since I couldn't find any concrete
answers.
Thanks for your time and regards
Marc Sladek
synventis gmbh