[Qgis-developer] Plugin reorganization (again)

[Alessandro Pasotti]

2011/12/21 Alexander Bruy <alexander.bruy at gmail.com>:
> Hi Alessandro
>
> 2011/12/21 Alessandro Pasotti <apasotti at gmail.com>:
>> I'm not sure I got it right, does this metadata also apply to python plugins ?
> Yes, this metadata applied to all plugins: Python and C++
>
>> A few questions arise in this case:
>>
>> 1 - are there any plan for making any use of the plugin "tags"
>> metadata as was planned in Lisbon ?
> Unfortunately I miss Lisbon meeting and can't find any page with
> results of this discussion. I think we anyway should review QGIS
> plugin system and make it more user friendly and improve it's
> usability.

Alexander,

I completely agree about the need of better plugins organization in
the QGIS client, in Lisbon we discussed (IIRC Boris and Tim were most
involved in this topic) and decided to add tags to cassify plugins.
Tags have been implemented in the new plugin app ( plugins.qgis.org )
since june 2011.

There were some discussions concerning plugin tags on this list during
the last few months and weeks, you can find some specs about the
plugins metadata here:

https://github.com/qgis/qgis-django/blob/master/qgis-app/plugins/docs/introduction.rst

tags are just a space-separated list of words.

I'm not against hierarchy-based (category) classification in
principle, but I'm reluctant to throw away a considerable amount of
work already done in the web application to support tags and implement
a brand new classification system for plugins (which will require
another fair good amount of work).


>
>> 2 - the new optional "category" metadata can be any value or the
>> choice will be a limited set  ("vector" "databases" etc.)
> There is no limitations, but as this metadata now used to inform users
> where to find plugin I suggest to limit available values with currently
> available menu/toolbar entries.
>

Can you please provide a list of the "permitted" values ?

What do you think we should do when a user uploads a plugin with an
invalid category (ignore, warn, abort) ?


>> 3 - do you think that the category will ever be a tree data structure
>> or it will always be a flat list ?
> Well, I think something like tree with categories (and maybe subcategories)
> and filtering capabilities will be nice. Also it will be good to move plugin to
> the proper menu/toolbar automatically, not using hardcoded destination.
>

Talking about the new plugin web application, I'm a bit confused about
what to do at this point: adding a "category" text field and keeping
tags is the easiest solution (with potential problems with typos in
the category and no validation possible) , but other options are
possible:

* throw away tags
* implement a MPTT tree-like category structure, in this case an
invalid category will abort the plugin upload
* implement the category as a FK relation from the plugin table and
use a flat list for categories

in any case, the category should become the main navigation system for
plugins in the web app and this is also not trivial.


-- 
Alessandro Pasotti
w3:   www.itopen.it