[geeklog-devel] Redesign the Plugin "Editor"

[Tom]

Your layout ideas make sense.

One thing I thought of is that there are a few projects related to plugins
that you may want to consider with the redesign. These haven't been
implemented yet but at some point we should and when we do they may affect
how the plugins form is laid out:

Plugin Version Control and Dependencies
http://project.geeklog.net/tracking/view.php?id=1154

Plugin Repository
http://wiki.geeklog.net/index.php/SoC_plugin_repository#Plugin_Repository
- See all on this page: Plugin admin panel
- This has been worked on as a GSOC project and I know Dirk had wanted to
finish it up at some point.

Tom


-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan
Placella
Sent: January-15-11 1:53 PM
To: Geeklog Development
Subject: [geeklog-devel] Redesign the Plugin "Editor"

Hi all,

I found another task on openhatch [1] that I would like to have a go at.
Here's its summary:

"Geeklog's plugin 'editor' is mainly a form that displays some information
about a plugin. It really only has options to enable/disable a plugin and
possibly to update it. The main issue with this form, however, is that
unlike all of the other editors in Geeklog, it has the buttons (save,
cancel, ...) at the top of the form. But moving them to the bottom (for
consistency) leaves some ugly blank space at the top of the form. So the
task is to come up with a new design for this form that's both consistent
with the rest of Geeklog and also looks nice."


However I fail to see how the plugin editor is actually useful. All the
information that it displays can be safely moved to the plugin list.
This can be done by either directly inserting information in the table or by
using the new COM_tooltip() function. The "delete" function can also be
inserted in the plugin list table, including the confirmation function.
There would be only one thing left for which the plugin editor would be
useful after the changes that I described above are
implemented: enabling and disabling plugins without the need for JavaScript
to be turned on. But I tackled this last issue in "feature request
#0001243"[2]. So, basically we'd be left at this point with the same
implementation as in glFusion plugin admin ( Can be seen on their demo site
[3] ). So, what do you guys think? Should I do it like that?
Any other ideas / suggestions / recommendations?

Take care,
Rouslan


[1]: https://openhatch.org/+projects/geeklog
[2]: http://project.geeklog.net/tracking/view.php?id=1243
[3]: http://demo.glfusion.org/admin/plugins.php

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel