Hi +1 to put them under a plugins->database menu
Perhaps merging some of the plugins to provide a 'super postgis' manager plugin would also be worth thinking about? Regards Tim On Thu, Aug 19, 2010 at 2:10 AM, Giuseppe Sucameli <[email protected]> wrote: > Hi all, > > On Wed, Aug 18, 2010 at 10:05 PM, Martin Dobias <[email protected]> wrote: >> >> Hi Borys >> >> On Sun, Aug 15, 2010 at 11:59 AM, Borys Jurgiel <[email protected]> >> wrote: >> > My suggestion for now is to put everything to a PostGIS submenu within >> > the > > > Plugins menu: >> > >> > self.iface.addPluginToMenu('PostGIS', actionBlahBlah) >> >> Right. I will do that for postgis manager in the next release. > > > I moved all my 2 PostGis plugins (rt_sql-layer e rt_postgres-extractor) > to the PostGIS menu: > > self.iface.addPluginToMenu('&PostGIS', self.action) > >> > Then we can modify the QgsInterface.addPluginToMenu method to put each >> > submenu either to the Plugins branch or to the main menu, so each user >> > can >> > configure which plugin sumbenus are at hand. It's a five-minuts-fix to >> > read >> > it from QSettings (still without any GUI for configuring it, but it's a >> > step >> > forward). >> > >> > The third step is the GUI. I started refactoring the Installer (just >> > three >> > hours per month, so it's why no changes are commited) and with Martin >> > and >> > Anne we plan to put it as a second tab of the manager. What about a >> > third >> > tab "menus and toolbars", when an user can be able to: >> > >> > 1. Select whether given submenu (e.g. PostGIS) goes to the main menu or >> > the >> > Plugins menu >> > >> > 2. Select whether given submenu creates its own toolbar or goes to the >> > main >> > Plugin toolbar. >> > >> > 3. Compose own toolbar(s) with a set of individual plugin buttons. It >> > allows >> > to hide the native plugin toolbar and enable personalized ones, like >> > "Monday's tasks", "Tools useful for X-files processing etc" >> > >> > 4. Save/load profiles (at least sets of plugins to be loaded - now I >> > often >> > have to use --noplugins option to make qgis faster) >> > >> > What do you think? The first two steps can be done in a moment. >> >> I like this idea of giving the users a chance to override the default >> placement. I would like to go even further - to allow user to >> manipulate individual actions created by the plugins - but that would >> probably need an addition to interface API (otherwise the >> identification of actions would depend on their name in current >> translation). I think of showing a tree widget to the user where nodes >> would be menus and submenus, the leafs would be individual actions. >> The user would be able to modify the tree in any way he likes: add new >> top level menus with some actions or just reorganize the 'Plugins' >> menu. >> >> If we end up updating the plugin interface, we could also proceed with >> defining the categories as we have discussed at the hackfests. Each >> plugin would be _strongly_ advised to suggest a category where it >> belongs, so ideally the users will not have to organize the plugins >> manually. > > +1, would be great! > > Cheers > > -- > Giuseppe Sucameli > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) ============================================== Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net ============================================== _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
