Matthias Kuhn wrote :
I remember, I discussed another key website with Borys, which
would be shown in a frame in the plugin description page. This
could be used to show even pictures in a description. Or we could
just embed the URL listed in homepage.
Jonathan Moules
Is there a real problem we are trying to solve with this?
I am not sure, each plugin will belong to exactly one menu and the
rules can technically be enforced. IMO They can as well have some
entries in two different menus. Or require a totally new menu (although
there need to be really good
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 07/01/2014 09:04, Matthias Kuhn ha scritto:
Therefore, I would propose not to implement hard rules (like specifying
the menu in metadata) but leave all the options to the plugin author
and have some intelligent soft rules, which can be
On 7 January 2014 08:04, Matthias Kuhn matthias.k...@gmx.ch wrote:
Is there a real problem we are trying to solve with this?
Users (even technical ones) have problems finding where plugins have
actually installed stuff - I've seen it first hand. By using a logical and
consistent approach, that
Hi Paolo and Jonathan,
Thank you for sharing your thoughts.
We should encourage plugin-authors to write a good get-started section
in the description in their metadata. Or we could include yet another
getstarted metadata section. I remember, I discussed another key
website with Borys, which
I remember, I discussed another key website with Borys, which would be
shown in a frame in the plugin description page. This could be used to show
even pictures in a description. Or we could just embed the URL listed in
homepage.
If I'm understanding correctly, you're proposing that the
On 01/07/2014 02:29 PM, Jonathan Moules wrote:
I remember, I discussed another key website with Borys, which
would be shown in a frame in the plugin description page. This
could be used to show even pictures in a description. Or we could
just embed the URL listed in homepage.
Richard,
We were discussing it already, without any success, and I can't imagine how it
could be done with the 2.x API.
Currently each plugin just calls one of the QgisInterface methods:
addPluginToVectorMenu, addPluginToRasterMenu etc. An obvious idea is to create
an universal method
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 06/01/2014 20:22, Borys Jurgiel ha scritto:
But maybe somebody has a simpler idea?
I see. In any case, I think we should not approve a plugin unless it goes in the
appropriate menu.
BTW, could someone point out where we have a list of the items
Hi all.
I would suggest an additional rule to accept a new plugin: we should
make sure it registers itself in the appropriate menu (Vector, Raster,
Database, Web, etc.), leaving in Plugins menu only those who cannot be
classified because they belong to more than one category,
This will help
On 05-01-14 19:00, Paolo Cavallini wrote:
I would suggest an additional rule to accept a new plugin: we should
make sure it registers itself in the appropriate menu (Vector, Raster,
Database, Web, etc.), leaving in Plugins menu only those who cannot be
classified because they belong to more
11 matches
Mail list logo
