Roadmap: Enhanced Admin GUI #252

Open
geekwright opened this Issue Feb 21, 2015 · 20 comments

Comments

Projects
None yet
8 participants
@geekwright
Contributor

geekwright commented Feb 21, 2015

@bitcero, Eduardo Cortes, is currently working on an improved GUI layer for system administration.

@geekwright geekwright added the roadmap label Feb 21, 2015

@bitcero

This comment has been minimized.

Show comment
Hide comment
@bitcero

bitcero May 18, 2015

The new GUI for Xoops admin will be totally different from previous. This will include new elements available for designers/developers modules.


Theme

A new theme called Hydrogen that derives from the experience acquired with Common Utilities and based on Bootstrap 3. This theme will provide all graphical elements for admin section and its colors will be customizable.

Xoops dashboard

xoops-12

This is the current progress of graphical elements, but there are a lot of work left.

New Elements

There are new elements in this GUI, availabel for modules:

  • Main bar (at top of theme)
    xoops-07
  • Menu bar (sidebar) that can be positioned at top, below the main bar, or the left (currently). The menu bar will be a directly access to any page of modules trough the collapsable menu.
    xoops-06
  • Page header, where modules can show a title and icon (optionally) to inform user where are located. Also, the header can contain buttons or other elements.
    xoops-14
  • Toolbar, that can contain buttons with actions to access functions from modules.
    xoops-15
  • Widgets that will be small graphical elements to show information from modules. The widgets will be available trought the service manager.
    xoops-16

All changes pretend to maintain compatibility with current code, but in some cases, to use the new elements, new code will required.

Very important: You can participate with ideas and working on changes. Please contact me.


What is needed?

  • Definition of all graphical elements.
  • Adapt existing module from 2.6 branch to use new GUI (templates)
  • Define the Xoops dashboard.
  • New usefull widgets that will be provided by default.
  • ...

bitcero commented May 18, 2015

The new GUI for Xoops admin will be totally different from previous. This will include new elements available for designers/developers modules.


Theme

A new theme called Hydrogen that derives from the experience acquired with Common Utilities and based on Bootstrap 3. This theme will provide all graphical elements for admin section and its colors will be customizable.

Xoops dashboard

xoops-12

This is the current progress of graphical elements, but there are a lot of work left.

New Elements

There are new elements in this GUI, availabel for modules:

  • Main bar (at top of theme)
    xoops-07
  • Menu bar (sidebar) that can be positioned at top, below the main bar, or the left (currently). The menu bar will be a directly access to any page of modules trough the collapsable menu.
    xoops-06
  • Page header, where modules can show a title and icon (optionally) to inform user where are located. Also, the header can contain buttons or other elements.
    xoops-14
  • Toolbar, that can contain buttons with actions to access functions from modules.
    xoops-15
  • Widgets that will be small graphical elements to show information from modules. The widgets will be available trought the service manager.
    xoops-16

All changes pretend to maintain compatibility with current code, but in some cases, to use the new elements, new code will required.

Very important: You can participate with ideas and working on changes. Please contact me.


What is needed?

  • Definition of all graphical elements.
  • Adapt existing module from 2.6 branch to use new GUI (templates)
  • Define the Xoops dashboard.
  • New usefull widgets that will be provided by default.
  • ...
@txmodxoops

This comment has been minimized.

Show comment
Hide comment
@txmodxoops

txmodxoops May 18, 2015

I think that the first image is good for default in XOOPS 2.6, and the structure is good, I don't think you should add more for the moment 👍

I think you should simply call cpanel without deleting the actual default.

I think that the first image is good for default in XOOPS 2.6, and the structure is good, I don't think you should add more for the moment 👍

I think you should simply call cpanel without deleting the actual default.

@mambax7

This comment has been minimized.

Show comment
Hide comment
@mambax7

mambax7 May 18, 2015

Contributor

Eduardo,

I can only say one thing: AWESOME!!!! This is an EXCELLENT START and exactly the process that I have envisioned, i.e. to see:

a) what features should Admin Themes and our new "Presentation Layer" have, and
b) what is needed from Core to make it happen

So I very much appreciate you showing us your vision, and then spelling out for us what needs to change in Core to enable it!

Once again, congratulations on this awesome start - the first steps are always the most difficult, but once we have the new Presentation Layer in place for our modules, XOOPS will shine again!!!

Contributor

mambax7 commented May 18, 2015

Eduardo,

I can only say one thing: AWESOME!!!! This is an EXCELLENT START and exactly the process that I have envisioned, i.e. to see:

a) what features should Admin Themes and our new "Presentation Layer" have, and
b) what is needed from Core to make it happen

So I very much appreciate you showing us your vision, and then spelling out for us what needs to change in Core to enable it!

Once again, congratulations on this awesome start - the first steps are always the most difficult, but once we have the new Presentation Layer in place for our modules, XOOPS will shine again!!!

@alain01

This comment has been minimized.

Show comment
Hide comment
@alain01

alain01 May 19, 2015

Contributor

Hummm, i want it Nowwwww ;-))))
Great work !

Contributor

alain01 commented May 19, 2015

Hummm, i want it Nowwwww ;-))))
Great work !

@geekwright

This comment has been minimized.

Show comment
Hide comment
@geekwright

geekwright May 19, 2015

Contributor

Continuing a conversation that started elsewhere, regarding SVG icons.

I fully agree. We need to focus on the best for tomorrow, not the best for a few years ago.

I am fine with that approach. 👍

Contributor

geekwright commented May 19, 2015

Continuing a conversation that started elsewhere, regarding SVG icons.

I fully agree. We need to focus on the best for tomorrow, not the best for a few years ago.

I am fine with that approach. 👍

@geekwright

This comment has been minimized.

Show comment
Hide comment
@geekwright

geekwright May 19, 2015

Contributor

Re: triggerReturnEvent() ...

Ok. Can you provide me some example to implement?

First we would define a class. In this case, an ArrayObject would do. We give it a name, so everyone knows what we are talking about.

class SystemMenuList extends \ArrayObject
{
}

Then, in modules/system/menu.php, the event would be triggered something like this:

$systemMenuList = new SystemMenuList($adminmenu);
\Xoops::getInstance()->events()->triggerReturnEvent('system.admin.menu', $systemMenuList);
$adminmenu = $systemMenuList->getArrayCopy();

Finally, a listener could look something like this:

public static function eventSystemAdminMenu(SystemMenuList $menus)
{
    $menuItemToAdd = array(
        'title'     => __('Title', 'domain'),
        'link'      => 'landingpage.php',
        'icon'      => 'xicon-icon'
    );
    $menus->append($menuItemToAdd);
}

The menus get passed around as an object, so there is no worry about passing by reference, and we will get an error if the type does not match, so we shouldn't be trying to process garbage.

The class could be modified as needed. For example, adding a method like:

public function addItem($title, $link, $icon)
{
    $this->append(array($title, $link, $icon));
}

With the class, there is a layer where implementation details can be adjusted if needed. And it makes the code more self documenting and robust.

Contributor

geekwright commented May 19, 2015

Re: triggerReturnEvent() ...

Ok. Can you provide me some example to implement?

First we would define a class. In this case, an ArrayObject would do. We give it a name, so everyone knows what we are talking about.

class SystemMenuList extends \ArrayObject
{
}

Then, in modules/system/menu.php, the event would be triggered something like this:

$systemMenuList = new SystemMenuList($adminmenu);
\Xoops::getInstance()->events()->triggerReturnEvent('system.admin.menu', $systemMenuList);
$adminmenu = $systemMenuList->getArrayCopy();

Finally, a listener could look something like this:

public static function eventSystemAdminMenu(SystemMenuList $menus)
{
    $menuItemToAdd = array(
        'title'     => __('Title', 'domain'),
        'link'      => 'landingpage.php',
        'icon'      => 'xicon-icon'
    );
    $menus->append($menuItemToAdd);
}

The menus get passed around as an object, so there is no worry about passing by reference, and we will get an error if the type does not match, so we shouldn't be trying to process garbage.

The class could be modified as needed. For example, adding a method like:

public function addItem($title, $link, $icon)
{
    $this->append(array($title, $link, $icon));
}

With the class, there is a layer where implementation details can be adjusted if needed. And it makes the code more self documenting and robust.

@bitcero

This comment has been minimized.

Show comment
Hide comment
@bitcero

bitcero May 19, 2015

Very clear... and instructive as always.

I'm agree with you.

2015-05-19 16:12 GMT-05:00 Richard Griffith notifications@github.com:

Re: triggerReturnEvent() ...

Ok. Can you provide me some example to implement?

First we would define a class. In this case, an ArrayObject would do. We
give it a name, so everyone knows what we are talking about.

class SystemMenuList extends \ArrayObject
{
}

Then, in modules/system/menu.php, the event would be triggered something
like this:

$systemMenuList = new SystemMenuList($adminmenu);
\Xoops::getInstance()->events()->triggerReturnEvent('system.admin.menu', $systemMenuList);
$adminmenu = $systemMenuList->getArrayCopy();

Finally, a listener could look something like this:

public static function eventSystemAdminMenu(SystemMenuList $menus)
{
$menuItemToAdd = array(
'title' => __('Title', 'domain'),
'link' => 'landingpage.php',
'icon' => 'xicon-icon'
);
$menus->append($menuItemToAdd);
}

The menus get passed around as an object, so there is no worry about
passing by reference, and we will get an error if the type does not match,
so we shouldn't be trying to process garbage.

The class could be modified as needed. For example, adding a method like:

public function addItem($title, $link, $icon)
{
$this->append(array($title, $link, $icon));
}

With the class, there is a layer where implementation details can be
adjusted if needed. And it makes the code more self documenting and robust.


Reply to this email directly or view it on GitHub
#252 (comment).

bitcero commented May 19, 2015

Very clear... and instructive as always.

I'm agree with you.

2015-05-19 16:12 GMT-05:00 Richard Griffith notifications@github.com:

Re: triggerReturnEvent() ...

Ok. Can you provide me some example to implement?

First we would define a class. In this case, an ArrayObject would do. We
give it a name, so everyone knows what we are talking about.

class SystemMenuList extends \ArrayObject
{
}

Then, in modules/system/menu.php, the event would be triggered something
like this:

$systemMenuList = new SystemMenuList($adminmenu);
\Xoops::getInstance()->events()->triggerReturnEvent('system.admin.menu', $systemMenuList);
$adminmenu = $systemMenuList->getArrayCopy();

Finally, a listener could look something like this:

public static function eventSystemAdminMenu(SystemMenuList $menus)
{
$menuItemToAdd = array(
'title' => __('Title', 'domain'),
'link' => 'landingpage.php',
'icon' => 'xicon-icon'
);
$menus->append($menuItemToAdd);
}

The menus get passed around as an object, so there is no worry about
passing by reference, and we will get an error if the type does not match,
so we shouldn't be trying to process garbage.

The class could be modified as needed. For example, adding a method like:

public function addItem($title, $link, $icon)
{
$this->append(array($title, $link, $icon));
}

With the class, there is a layer where implementation details can be
adjusted if needed. And it makes the code more self documenting and robust.


Reply to this email directly or view it on GitHub
#252 (comment).

@redheadedrod

This comment has been minimized.

Show comment
Hide comment
@redheadedrod

redheadedrod May 21, 2015

Contributor

Looks very Nice.

I have been using Drupal to make some pages for a local team and it has been an experience. I would like to share how their modules stuff looks as a suggestion for something that we could consider to work towards.

Basically they show if it is enabled with a check box.. To enable one just checks the check boxes and hit submit and they are enabled as long as the required modules are also enabled. If any required modules are NOT enabled then it will enable them as well. I will attach a screen shot for an example.

At a minimum I think we should be changing up the Xoops modules for 2.6 and instead of the "Official" and "extension" tags we need to remove all that and just add a Categories tag.

This will allow us to group like modules together like they are on this drupal example. While their modules page is very plain I am sure we can do better but this is atleast a start.

They also show required and dependent modules as well as if there is a help screen and allow permissions and configurations right from this screen.
But this would be a new modules module... We need to start somewhere though.. Not sure if you really want the modules to all be listed on the main admin screen since you can have literally hundreds of them eventually. Especially with the new service manager and other stuff up and coming.

Contributor

redheadedrod commented May 21, 2015

Looks very Nice.

I have been using Drupal to make some pages for a local team and it has been an experience. I would like to share how their modules stuff looks as a suggestion for something that we could consider to work towards.

Basically they show if it is enabled with a check box.. To enable one just checks the check boxes and hit submit and they are enabled as long as the required modules are also enabled. If any required modules are NOT enabled then it will enable them as well. I will attach a screen shot for an example.

At a minimum I think we should be changing up the Xoops modules for 2.6 and instead of the "Official" and "extension" tags we need to remove all that and just add a Categories tag.

This will allow us to group like modules together like they are on this drupal example. While their modules page is very plain I am sure we can do better but this is atleast a start.

They also show required and dependent modules as well as if there is a help screen and allow permissions and configurations right from this screen.
But this would be a new modules module... We need to start somewhere though.. Not sure if you really want the modules to all be listed on the main admin screen since you can have literally hundreds of them eventually. Especially with the new service manager and other stuff up and coming.

@bitcero

This comment has been minimized.

Show comment
Hide comment
@bitcero

bitcero Jun 22, 2015

Report of progress


There are some changes made in Xoops GUI:

Header commands

Added support for «header commands»: elements that can be shown in page header.

xoops-01

Commands can be added trough \Xoops\Core\Helper\HeaderCommands.

Admin buttons

«admin buttons» is a special area where buttons can be added to provide actions in a module. Admin buttons as controled with \Xoops\Module\Admin() and added trought method addItemButton().

xoops-02

Modules manager (in progress)

The modules manager has been updated to make it more intuitive and better looking. Existing modules can be displayed as list or cards (as in previous GUI). Also the modules manager has been moved to modules/system/modules.php and still is in progress, but I have some progress and I can show.

xoops-03

xoops-04

xoops-05

Contextual options (item options)

Added support for a new contextual options (or item options) in order to make it more easy to use and implement.

xoops-06

Options are shown below to item (in table row) and activated/deactivated with a command button. (The above image show the item options for module item in modules manager).

New javascript interface

I'm starting the replacement for standard javascript functions contained in xoops.js file. Now all functions will replace for xoops javascript interface for better access. This interface will be an object that can be called in next way:

xoops.function();

This interface can be easily extended to increase its functionallity and make all available for other components.

New dialogs using bootstrap

Now the bootstrap modal component is available trough xoops javascript interface that uses bootbox to create dialogs easily. Dialogs can be created by using:

// Alert
xoops.modal.alert('Alert text');
// Confirm
xoops.modal.confirm('confirm');
// Custom dialog
xoops.modal.dialog({
    title: response.title,
    message: response.content,
    color: 'primary',
    buttons: {
        main: {
            label: response.close,
            className: 'btn-primary'
        }
    }
});

xoops-07

Note that bootbox has been modified (small modifications) to provide some new capabilities to dialogs.

Dialogs can be colorized by using the options 'color' when dialog is created:

xoops.modal.dialog({
    title: '...',
    message: '...',
    color: 'primary'
});

color can be: primary, info, success, warning, danger, azure, sky, palegreen, pink, indigo, midnight, orange, yellow, brown, alizarin, purple or magenta. Some exmaples:

xoops-08 xoops-09 xoops-10


Note: The above examples are based in dialog for «system module details» and is incomplete. I'm working on that.


Modules logo

I've changed the logo for system module, and I hope that all logos for current modules can be changes to provide a new consistent appearance.

logo

I can provide templates to adapt current logo images.


Some additional changes has been made but I'll post in another report.

I wait your comments and feedback.


Important: this changes are not in the main repository but you can find in my XOOPS fork.

Todo list:

  • Complete modules manager
  • Start blocks manager (lot of changes)
  • Start users and groups manager
  • Start module settings forms
  • Update modules templates
  • Update xoops_version files for modules
  • ...

All help is appreciated and welcomed!

bitcero commented Jun 22, 2015

Report of progress


There are some changes made in Xoops GUI:

Header commands

Added support for «header commands»: elements that can be shown in page header.

xoops-01

Commands can be added trough \Xoops\Core\Helper\HeaderCommands.

Admin buttons

«admin buttons» is a special area where buttons can be added to provide actions in a module. Admin buttons as controled with \Xoops\Module\Admin() and added trought method addItemButton().

xoops-02

Modules manager (in progress)

The modules manager has been updated to make it more intuitive and better looking. Existing modules can be displayed as list or cards (as in previous GUI). Also the modules manager has been moved to modules/system/modules.php and still is in progress, but I have some progress and I can show.

xoops-03

xoops-04

xoops-05

Contextual options (item options)

Added support for a new contextual options (or item options) in order to make it more easy to use and implement.

xoops-06

Options are shown below to item (in table row) and activated/deactivated with a command button. (The above image show the item options for module item in modules manager).

New javascript interface

I'm starting the replacement for standard javascript functions contained in xoops.js file. Now all functions will replace for xoops javascript interface for better access. This interface will be an object that can be called in next way:

xoops.function();

This interface can be easily extended to increase its functionallity and make all available for other components.

New dialogs using bootstrap

Now the bootstrap modal component is available trough xoops javascript interface that uses bootbox to create dialogs easily. Dialogs can be created by using:

// Alert
xoops.modal.alert('Alert text');
// Confirm
xoops.modal.confirm('confirm');
// Custom dialog
xoops.modal.dialog({
    title: response.title,
    message: response.content,
    color: 'primary',
    buttons: {
        main: {
            label: response.close,
            className: 'btn-primary'
        }
    }
});

xoops-07

Note that bootbox has been modified (small modifications) to provide some new capabilities to dialogs.

Dialogs can be colorized by using the options 'color' when dialog is created:

xoops.modal.dialog({
    title: '...',
    message: '...',
    color: 'primary'
});

color can be: primary, info, success, warning, danger, azure, sky, palegreen, pink, indigo, midnight, orange, yellow, brown, alizarin, purple or magenta. Some exmaples:

xoops-08 xoops-09 xoops-10


Note: The above examples are based in dialog for «system module details» and is incomplete. I'm working on that.


Modules logo

I've changed the logo for system module, and I hope that all logos for current modules can be changes to provide a new consistent appearance.

logo

I can provide templates to adapt current logo images.


Some additional changes has been made but I'll post in another report.

I wait your comments and feedback.


Important: this changes are not in the main repository but you can find in my XOOPS fork.

Todo list:

  • Complete modules manager
  • Start blocks manager (lot of changes)
  • Start users and groups manager
  • Start module settings forms
  • Update modules templates
  • Update xoops_version files for modules
  • ...

All help is appreciated and welcomed!

@mambax7

This comment has been minimized.

Show comment
Hide comment
@mambax7

mambax7 Jun 22, 2015

Contributor

Awesome work, Eduardo!!!
😋 😄 👍 👍 👍 👍

I'll need to install your fork and test it to give you a more meaningful feedback, but so far it looks AWESOME!!!! 😋

Contributor

mambax7 commented Jun 22, 2015

Awesome work, Eduardo!!!
😋 😄 👍 👍 👍 👍

I'll need to install your fork and test it to give you a more meaningful feedback, but so far it looks AWESOME!!!! 😋

@geekwright

This comment has been minimized.

Show comment
Hide comment
@geekwright

geekwright Jul 6, 2015

Contributor

I agree with Michael, AWESOME!

Sorry to be so slow in responding. I'm still catching up after vacation. I'll get a full review as soon as I can, but everything looks and sounds fantastic.

Contributor

geekwright commented Jul 6, 2015

I agree with Michael, AWESOME!

Sorry to be so slow in responding. I'm still catching up after vacation. I'll get a full review as soon as I can, but everything looks and sounds fantastic.

@bitcero

This comment has been minimized.

Show comment
Hide comment
@bitcero

bitcero Dec 18, 2015

Updates

These are the last updates in X26 GUI:

System admin sections has been migrated to a separate URL. Now, instead of use system/admin.php?fct=users the system module use system/users.php. This change offers a more semantic URLs and encapsulated code to improve maintanance.

Report of changes


Preferences

New settings manager for modules. The new design is cleaner and responsive to maximize its functionality.

  • Dynamic settings. System is capable to load options dynamically to improve the development flow and updates.
  • Avoiding the old form tabs based on jQueryUI. Now bootstrap is fully integrated with tabs and, with this change, I'm prevent to embed HTML code in form PHP files.

xoops-12-01

xoops-12-02

Users management

Also the users management has been ported to new GUI.

xoops-12-03

Groups management

Groups management has been ported to new GUI.

xoops-12-04


Other changes

A lot of changes has been made in order to get this working, but more work is left. However, I think that the new GUI is pretty functional and modules templates can be adapted to new appearance.

bitcero commented Dec 18, 2015

Updates

These are the last updates in X26 GUI:

System admin sections has been migrated to a separate URL. Now, instead of use system/admin.php?fct=users the system module use system/users.php. This change offers a more semantic URLs and encapsulated code to improve maintanance.

Report of changes


Preferences

New settings manager for modules. The new design is cleaner and responsive to maximize its functionality.

  • Dynamic settings. System is capable to load options dynamically to improve the development flow and updates.
  • Avoiding the old form tabs based on jQueryUI. Now bootstrap is fully integrated with tabs and, with this change, I'm prevent to embed HTML code in form PHP files.

xoops-12-01

xoops-12-02

Users management

Also the users management has been ported to new GUI.

xoops-12-03

Groups management

Groups management has been ported to new GUI.

xoops-12-04


Other changes

A lot of changes has been made in order to get this working, but more work is left. However, I think that the new GUI is pretty functional and modules templates can be adapted to new appearance.

@mambax7

This comment has been minimized.

Show comment
Hide comment
@mambax7

mambax7 Dec 18, 2015

Contributor

👍 Awesome progress!!!

Contributor

mambax7 commented Dec 18, 2015

👍 Awesome progress!!!

@alain01

This comment has been minimized.

Show comment
Hide comment
@alain01

alain01 Dec 18, 2015

Contributor

👍 Very nice Work !
Just 1 question for the modules.
if the web site use lot of modules, i "m afraid that it would be not usefull to see the modules in a vertical list, no ?

Contributor

alain01 commented Dec 18, 2015

👍 Very nice Work !
Just 1 question for the modules.
if the web site use lot of modules, i "m afraid that it would be not usefull to see the modules in a vertical list, no ?

@txmodxoops

This comment has been minimized.

Show comment
Hide comment
@txmodxoops

txmodxoops Dec 18, 2015

When will it be available for testing?

When will it be available for testing?

@bitcero

This comment has been minimized.

Show comment
Hide comment
@bitcero

bitcero Dec 18, 2015

@alain01 The sidebar menu is scrollable to navigate trough modules list, however I'm planning to include a "quick search box" to find modules easily.

bitcero commented Dec 18, 2015

@alain01 The sidebar menu is scrollable to navigate trough modules list, however I'm planning to include a "quick search box" to find modules easily.

@bitcero

This comment has been minimized.

Show comment
Hide comment
@bitcero

bitcero Dec 18, 2015

@txmodxoops You can try my fork, but I not tested it on standalone installation... btw, you can help me with this and check if it is possible to install it...

bitcero commented Dec 18, 2015

@txmodxoops You can try my fork, but I not tested it on standalone installation... btw, you can help me with this and check if it is possible to install it...

@txmodxoops

This comment has been minimized.

Show comment
Hide comment
@txmodxoops

txmodxoops Dec 18, 2015

I think you need to update the Core Master, because it gives this error in installation

http://localhost/XoopsCoreBitcero-master/htdocs/install/page_siteinit.php

Fatal error: Unsupported operand types in D:\wamp\www\XoopsCoreBitcero-master\htdocs\xoops_lib\Xoops\Core\Kernel\Handlers\XoopsModule.php on line 94
Call Stack

Time Memory Function Location

1 0.0005 291336 {main}( ) ..\page_siteinit.php:0
2 0.2491 7032824 SystemModule->install( ) ..\page_siteinit.php:62
3 0.2571 7494936 Xoops\Core\Kernel\Handlers\XoopsModule->loadInfoAsVar( ) ..\module.php:208

I think you need to update the Core Master, because it gives this error in installation

http://localhost/XoopsCoreBitcero-master/htdocs/install/page_siteinit.php

Fatal error: Unsupported operand types in D:\wamp\www\XoopsCoreBitcero-master\htdocs\xoops_lib\Xoops\Core\Kernel\Handlers\XoopsModule.php on line 94
Call Stack

Time Memory Function Location

1 0.0005 291336 {main}( ) ..\page_siteinit.php:0
2 0.2491 7032824 SystemModule->install( ) ..\page_siteinit.php:62
3 0.2571 7494936 Xoops\Core\Kernel\Handlers\XoopsModule->loadInfoAsVar( ) ..\module.php:208

@loriga

This comment has been minimized.

Show comment
Hide comment
@loriga

loriga Jan 14, 2016

Great work!

loriga commented Jan 14, 2016

Great work!

@kevinpetit

This comment has been minimized.

Show comment
Hide comment
@kevinpetit

kevinpetit Jun 27, 2016

Is there a new update? :)

Is there a new update? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment