Re: [xwiki-devs] [Proposal] Entry point for Extensions

[Vincent Massol]

Hi Paul,

> On 14 Oct 2016, at 19:05, Paul Libbrecht  wrote:
> 
> 
> On 14 Oct 2016, at 19:03, Thomas Mortagne  wrote:
>> For me this is already the job of the uix we use for application panel
>> so I don't really see the point of adding something else.
> 
> Well, that would be a job for extensions.xwiki.org:
> - prioritise entry-points in search results
> - display appropriately that some extensions are of a given type 
> (entry-point, dependency, … macro?)

My use case/need isn’t related to e.x.o but to one's XWiki instance.

Thanks
-Vincent

> 
> paul
> 
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Entry point for Extensions

[Vincent Massol]

> On 14 Oct 2016, at 19:03, Thomas Mortagne  wrote:
> 
> This does not make any sense at general Extension level.
> 
> Could be custom metadata that apply to XAR extensions. Since that only
> make sense for XAR extensions I would prefer to have this be
> implemented as a xobject as usual.

Yes, it could be implemented as a UIXP/XObject of the Extension UI.

> For me this is already the job of the uix we use for application panel
> so I don't really see the point of adding something else.

It’s not enough at all. That was my main point and explanation. Apparently I 
failed to explain the problem correctly.

I’ll give more details:
* You install a XAR extension that provides a ConfigurableClass (but you don’t 
know that as a user)
* After you’ve installed that extension, as a user, you don’t know what to do. 
You need to go read the doc for the app to understand where you need to go to 
start using it.

So I’m really convinced we need something better than what we have now.

Now after we move the Applications UIXP to the xwiki-platform-applications 
module, we could add an “entrypoint’ property in the UIXP but that would mean 
that the Extension Manager UI module would depend on 
xwiki-platform-applications. We would need to decide if it’s ok. I think it is 
since it can be considered as an application descriptor and I don’t see a 
problem of having the EM UI module know about application descriptors.

WDYT?

Thanks
Vincent

> On Fri, Oct 14, 2016 at 4:10 PM, Vincent Massol  wrote:
>> Hi devs,
>> 
>> Problem
>> ===
>> 
>> We have 2 issues right now when installing an extension in XWiki:
>> 
>> 1) It’s not clear where is the entry point of that extension.
>> - Example1: an app that is only for admins and only has a ConfigurableClass
>> - Example2: an app that provides a macro and doesn’t have a UI
>> 
>> 2) Even when an extension registers itself in the Applications Panel, the 
>> user still need to refresh the page or navigate away to see it.
>> 
>> Proposal
>> 
>> 
>> * Introduce the concept of Entry point (a.k.a home page) in Extension 
>> metadata
>> * Have the EM UI display the extension’s entry point (when there’s one) 
>> after having installed the extension so that the user can click on it and be 
>> taken to the home page of the extension.
>> 
>> This would make extensions more discoverable IMO.
>> 
>> Implementation Details
>> ==
>> 
>> * Some maven extension metadata properties in pom.xml
>> 
>> * A format to represent an entry point. It shouldn’t be a full URL since 
>> that needs to be computed at runtime. Basically it should contain:
>> ** The document reference
>> ** The action to use (view, admin, etc) - optional, should default to “view"
>> ** The query string to use - optional, should default to an empty query 
>> string
>> 
>> This corresponds to the notion of ResourceReference (EntityResourceReference 
>> to be precise). However we don’t have any textual representation of it ATM.
>> 
>> WDYT? Good idea? Bad idea?
>> 
>> Thanks
>> -Vincent
>> 
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
> 
> 
> 
> -- 
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Entry point for Extensions

[Paul Libbrecht]

On 14 Oct 2016, at 19:03, Thomas Mortagne  wrote:
> For me this is already the job of the uix we use for application panel
> so I don't really see the point of adding something else.

Well, that would be a job for extensions.xwiki.org:
- prioritise entry-points in search results
- display appropriately that some extensions are of a given type (entry-point, 
dependency, … macro?)

paul


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Entry point for Extensions

[Thomas Mortagne]

This does not make any sense at general Extension level.

Could be custom metadata that apply to XAR extensions. Since that only
make sense for XAR extensions I would prefer to have this be
implemented as a xobject as usual.

For me this is already the job of the uix we use for application panel
so I don't really see the point of adding something else.

On Fri, Oct 14, 2016 at 4:10 PM, Vincent Massol  wrote:
> Hi devs,
>
> Problem
> ===
>
> We have 2 issues right now when installing an extension in XWiki:
>
> 1) It’s not clear where is the entry point of that extension.
> - Example1: an app that is only for admins and only has a ConfigurableClass
> - Example2: an app that provides a macro and doesn’t have a UI
>
> 2) Even when an extension registers itself in the Applications Panel, the 
> user still need to refresh the page or navigate away to see it.
>
> Proposal
> 
>
> * Introduce the concept of Entry point (a.k.a home page) in Extension metadata
> * Have the EM UI display the extension’s entry point (when there’s one) after 
> having installed the extension so that the user can click on it and be taken 
> to the home page of the extension.
>
> This would make extensions more discoverable IMO.
>
> Implementation Details
> ==
>
> * Some maven extension metadata properties in pom.xml
>
> * A format to represent an entry point. It shouldn’t be a full URL since that 
> needs to be computed at runtime. Basically it should contain:
> ** The document reference
> ** The action to use (view, admin, etc) - optional, should default to “view"
> ** The query string to use - optional, should default to an empty query string
>
> This corresponds to the notion of ResourceReference (EntityResourceReference 
> to be precise). However we don’t have any textual representation of it ATM.
>
> WDYT? Good idea? Bad idea?
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Proposal] Entry point for Extensions

[Vincent Massol]

Hi devs,

Problem
===

We have 2 issues right now when installing an extension in XWiki:

1) It’s not clear where is the entry point of that extension. 
- Example1: an app that is only for admins and only has a ConfigurableClass
- Example2: an app that provides a macro and doesn’t have a UI

2) Even when an extension registers itself in the Applications Panel, the user 
still need to refresh the page or navigate away to see it.

Proposal 


* Introduce the concept of Entry point (a.k.a home page) in Extension metadata
* Have the EM UI display the extension’s entry point (when there’s one) after 
having installed the extension so that the user can click on it and be taken to 
the home page of the extension.

This would make extensions more discoverable IMO.

Implementation Details
==

* Some maven extension metadata properties in pom.xml

* A format to represent an entry point. It shouldn’t be a full URL since that 
needs to be computed at runtime. Basically it should contain:
** The document reference
** The action to use (view, admin, etc) - optional, should default to “view"
** The query string to use - optional, should default to an empty query string

This corresponds to the notion of ResourceReference (EntityResourceReference to 
be precise). However we don’t have any textual representation of it ATM.

WDYT? Good idea? Bad idea?

Thanks
-Vincent

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Proposal] Roadmap for 8.4.x till end of the year

[Vincent Massol]

Hi devs,

After discussing with XWiki SAS internally here’s a list of items that’s 
interesting to fix for XWiki SAS (in that order, from top to bottom) from now 
till end of the year (i.e. 8.4.x).

The goal is to try to take as many issues as possible from this list, starting 
from top to bottom.

Process I propose:
* For each dev, take an issue that is the closest possible from the top and 
work on it. Put your name on http://www.xwiki.org/xwiki/bin/view/Roadmaps/ and 
assign yourself to the jira issue.
* Once done, repeat.
* The names put below are just indicative and should be considered as ideas of 
devs who could work on them.

Ordered list (top is most important):

* Periodic crashes with ClassLoader related locking issue - XWIKI-13792 - Thomas
* Admins should be able to decide the order in which apps are displayed in the 
Applications Panel - XWIKI-13075 - Guillaume
* When I'm in full mode I would like to save directly without returning to 
normal Edit Mode - CKEDITOR-112 - Marius?
* Make the WYSIWYG admin UI display configuration for all available WYSIWYG 
editors - XWIKI-13654 - Marius?
* Sort Recommended Extensions by Ratings when no search query is specified - 
XWIKI-13779 - Thomas
* When inserting large images while editing, it should all fit, the user should 
not need to scroll to the right to see it all. - CKEDITOR-108 - Marius?
* Clarify the Hamburger Menu - XE-1582 - Guillaume
* Provide an option in the AWM wizard that creates a Template Provider for the 
app - XWIKI-13761 - Marius?
* Solr search UI is still very slow - XWIKI-13192 - Thomas
* Provide a way to filter templates in the creation step - XWIKI-13762 - 
Guillaume
* Simplify creation of New link to new page in CKEditor - CKEDITOR-116 - Marius?
* Cannot upgrade the CKEditor extension - XE-1570 - Guillaume?
* Cannot delete document with many large attachments - XWIKI-8910 - Thomas
* For regular users, "Data" level is confusing in the Pages tree for an 
application created with App Within Minutes - XWIKI-13360 - Guillaume?
* Customizing the PDF export CSS could cause a NPE - XWIKI-13457 - Vincent
* The parent-child relationship of a page is not updated during a move - 
XWIKI-13493 - Marius?
* Add Check List of actions to perform to create first content in XWiki with 
links to video tutorials - (Missing JIRA) - Caty?
* --Attachments are not copied from a Template Provider - XWIKI-13524 - Edy--
* Extension Manager add extension search should suggest only compatible 
versions - XWIKI-9920 - Thomas?
* Hard to understand which is the default value for Profile's Preferences 
entries (edit/view mode) - XWIKI-7715 - Guillaume
* Adding a new overriding template resulted in the creation of 190 
XWikiSkinFileOverrideClass - XWIKI-13179 - Thomas?
* Demo Content Inside XE - (Missing JIRA) - Caty?
* Admin UI to allow disabling tours on a given wiki or for all wikis - TOUR-50 
- Guillaume?
* Bad Image Scaling Quality - XWIKI-7623 - Guillaume?
* See to which groups a user belongs to - XWIKI-1901 - Guillaume?
* Make a tool to evaluate the status of the hierarchy before running the nested 
spaces migrator - NPMIG-46 - Guillaume
* Hide "XWiki" space from Navigation Tree - (Missing JIRA) - ?
* Reorder the  "Create a Page" menu steps in a more coherent way - XE-1588 - 
Marius?
* Allow resetting changes found by the "Compute change" feature of EM - 
XWIKI-13747 - Thomas
* Admin tools doesn't work anymore on 8.0+. In general test features to see if 
they work in 8.3+ - ADMINTOOL-45 + ADMINTOOL-46 + ... - Alex
* Add highlighted text to invite newcomers to click on the edit button to start 
modifying content - XE-1583 - Caty?
* Change the user type for the Admin user to 'simple' - XE-1580 - Guillaume?
* Page creation date should be the date of the installation - XWIKI-7058 - 
Thomas?
* Add an administration control panel for the redirects created on rename - 
XWIKI-13385 - Guillaume?
* Add "Index Page" Template  - TEMPLATES-7 - Caty?
* Deactivate "section editing" by default and/or hide them in CSS and display 
them with hover - (Missing JIRA) - Caty?
* Change saved into a LESS SSX that is already cache does not always get 
recompiled  - XWIKI-13300 - Thomas?
* Have an option to edit directly in full screen mode - XWIKI-13793 - Marius?
* Add support for nested spaces in Distribution Wizard report - XWIKI-12270 - 
Guillaume?
* Remove XWiki Enterprise and transform it into a Knowledge Base Flavor - 
XE-1581 - Thomas
* Replace Home Page with actual content and move current Home page to a 
documentation page accessible from that home page - (Missing JIRA) - Caty?
* Move "Last modified by" next to "Create by" - (Missing JIRA) - Caty?
* Display sponsored extensions on extensions.xwiki.org - XINFRA-211 - Vincent
* Implement a View mode in addition to Standard/Advanced, with cookie based 
setting - (Missing JIRA) - Caty?
* Put the "Add a new page" button is (really) outside of the Menu relating to 
the current page (because it's about another page) - XE-1587 - 

Re: [xwiki-devs] [Proposal] Having the docextra tabs in edit mode.

[Denis Gervalle]

+1 for your proposal until we have a better solution. I would avoid comment tab 
if ever possible, since it increase the inconveniences already explained. I 
agree with almost all other comments, but until we have time for something 
better, this proposal would be a first improvement. We should just ensure it 
does not cause any regression.
--
Denis Gervalle
SOFTEC sa - CEO
On Fri, Oct 14, 2016 at 12:19 PM, Denis Gervalle  
wrote:
+1 for your proposal until we have a better solution. I would avoid comment tab 
if ever possible, since it increase the inconveniences already explained. I 
agree with almost all other comments, but until we have time for something 
better, this proposal would be a first improvement. We should just ensure it 
does not cause any regression.

--
Denis Gervalle
SOFTEC sa - CEO
On Thu, Oct 13, 2016 at 11:28 AM, Guillaume Delhumeau 
 wrote:
2016-10-13 11:07 GMT+02:00 Ecaterina Moraru (Valica) :

> Some notes about the comments:
> - @GD: In CkEditor when drag it doesn't open a file explorer
> (that's for the simple upload), instead you just drag the image from
> Desktop and it inserts it.
>

I think I was not clear. I know CKEditor does not a file explorer. But you
have to open that kind of application by yourself (in mac it's called
"Finder", on my laptop it's called "Nautilus") if the file you plan to drag
is not on your desktop (which is the case 99% of the time). That is exactly
what I dislike.


> - @Vincent: the inline editing approach (with keeping the attachments tab
> in the same location) doesn't work for cases when we hide the docextra: we
> will have the same problem, and we might plan to remove that area for other
> skins.
> - @Thomas: yes this approach to have attachments tab in edit is problematic
> because of the save and other js events, plus to me is still oldish.
>
> So I don't want us to include the attachment tab in edit mode (although it
> sounded as a nice option). Instead I would like at least to have an
> improved drag for CkEditor (improvement) and in the 'future' to
> support drag in wiki mode (new feature).
>
> Thanks,
> Caty
>

Thanks,


>
>
> On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne <
> thomas.morta...@xwiki.com
> > wrote:
>
> > Something is not clear to me. What is exactly going to happen in edit
> > mode when you select an attachment ?
> >
> > If the plan is to let the attachment tab behave exactly as it does in
> > view mode (which is to actually upload the attachment and save the
> > document) I'm really not a big fan of this. If we support attachments
> > in edit view it should not send anything until we click save.
> >
> >
> > On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol 
> > wrote:
> > >
> > >> On 12 Oct 2016, at 18:47, Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com> wrote:
> > >>
> > >> Just some remarks before I go:
> > >> * As a developer, I always use the Wiki editor, and even for me it's a
> > pain
> > >> to go to view mode to upload a file (for example, an image in the
> > release
> > >> notes).
> > >> * I never use drag in whatever application I have. I have never
> > liked
> > >> it because it requires to open a file explorer specially for that and
> > it's
> > >> always a pain because I use applications in full size mode. I'm sure
> I'm
> > >> not the only one so I'm not fond of having it as the only way to
> upload
> > >> attachments.
> > >
> > > For the sake of the discussion, also note that there’s another option.
> > Don’t leave the view page when editing (ie. inline editing) and just
> > replace the view area by an edit area. And find how to display the page
> > syntax and include/display references in the UI.
> > >
> > > The nice part is that it 1) it saves a reload of the UI (good for perf)
> > and 2) it feels more snappy and no context switching for the user (better
> > usability).
> > >
> > > If you remember this was a proposal done a very long time ago by
> > Jean-Vincent Drean (tried to find the thread again but didn’t succeed).
> > >
> > > Thanks
> > > -Vincent
> > >
> > >> Thanks,
> > >>
> > >> 2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) <
> vali...@gmail.com
> > >:
> > >>
> > >>> There are some problems with docextra, because it contains comments,
> > which
> > >>> are mostly needed in view mode, not in edit. So in edit mode, we
> would
> > need
> > >>> just some tabs from docextra. But I'm not sure that adding docextra
> now
> > >>> will fix the underlying problem of the issue.
> > >>>
> > >>> The issue was trying to fix the attachments uploading limitation of
> the
> > >>> editor. The problem is that the editors (including CKEditor) are
> > >>> advertising that they add images and not other file types. If users
> > want to
> > >>> add a PDF they might be confused.
> > >>>
> > >>> Ideally the users would just need to drag a file and we would
> > insert a
> > >>> displayer depending on the dragged 

Re: [xwiki-devs] [XWiki Day] BFD#121

[Alexandru Cotiuga]

Hi devs,

There was a mistake that I made in the announcement of this week's BFD:
it's #122 and not #121.
See the results in the blogpost:
http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+122.

Thanks,
Alex

On Thu, Oct 13, 2016 at 10:51 AM, Alexandru Cotiuga <
alexandru.coti...@xwiki.com> wrote:

> Hello devs,
>
> This Thursday is BFD#121:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays
>
> Our current status for the 1 year period is 58 bugs behind. See:
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100
> 00#Created-vs-Resolved-Chart/10470
>
> Here's the BFD#121 dashboard to follow the progress during the day:
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13698
>
> Happy Bug Fixing Day,
> Alex
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Officially deprecate GWT WYSIWYG editor and don't fix issues related to it

[Thomas Mortagne]

+1 to move issue to a new jira project and duplicate those that
reproduce in the new WYSIWYG

On Fri, Oct 14, 2016 at 2:56 AM, Eduard Moraru  wrote:
> Hi,
>
> If we retire it to contrib, then indeed, it needs its own jira project and
> the existing opened issues (bugs/improvements/etc) need to be move there.
>
> However, do keep in mind that we would still need to keep (or duplicate)
> the issues that still apply to the current WYSIWYG (CK) editor, specially
> on the improvements/new features side.
>
> +1 to move.
>
> Thanks,
> Eduard
>
> On Thu, Oct 13, 2016 at 8:38 PM, Vincent Massol  wrote:
>
>> Hi devs,
>>
>> I’d like that we agree on an official position re the GWT WYSIWYG editor.
>>
>> We’ve already decided to make CKEditor the default editor and to keep the
>> GWT editor bundled (but off by default) till the end of the 8.x cycle.
>>
>> I’d like now that we agree about 2 points:
>>
>> * We don’t fix issues related to the GWT editor that do not reproduce on
>> the CKEditor editor.
>> * Now remains the question as to whether we close them as won’t fix or
>> not. Ideally the best IMO is to create a new JIRA project for the GWT
>> Editor in the Contributed Extensions category, and move all opened JIRA
>> issues to it. We create a version labelled “Previous versions when the GWT
>> editor was in platform” so that we can use that as affects. Of course
>> another option would be to not touch those issues FTM and wait till we do
>> the move in 9.0+. I prefer moving the issues now if we agree now that we
>> don’t fix issues related to the GWT editor.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>>
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs