2011/12/21 Alexander Bruy <[email protected]>: > Hi Alessandro > > 2011/12/21 Alessandro Pasotti <[email protected]>: >> 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 _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
