Hello Vincent,<br><br>Thank you for your reply and valuable input. I will try to address each of your comments, as you bring up important points.<br><br>> Making the learning curve easier for users to write plugins is great, but we<br>
> should be careful to keep constraints on them, or at least good habits in<br>> plugin development, or we will end up with a lot of bad-quality plugins, which<br>> is clearly a problem. There is of course a balance to find between<br>
> constraints and ease of development, but it should be well thought in order<br>> not to create more problems than it solves.<br><br>Agreed. The last thing I want to do is make it fast and efficient for new plugin developers to make bad-quality plugins. That would be a burden upon both developers and users.<br>
<br>Finding the right balance between a comfortable learning curve while maintaining some control over making sure new developers write quality code under best practice techniques is part of why I started this plugin project.<br>
<br>When I release my plugin's source (on github), I would welcome anyone to fork the project and help add anything they think will help new plugin developers. I would especially appreciate any input on the plugin's embedded tutorial, as it will be the focus point where current QGIS developers can pass on best practice techniques.<br>
<br>I want my plugin to just solve problems, not create any. Towards this end, I will not be releasing the plugin to the public QGIS repository, even under 'experimental,' until other developers have had a chance to download it from github and send me any corrections they think will help.<br>
<br>> One thing that bothers me a bit is that you directly edit your local plugin in<br>> plugin's directory and not in code repository.<br>> The packaged and deployed plugin content is often different from the plugin<br>
> code repository.<br><br>Locally deploying to QGIS from a development directory is something I find an unnecessary step, especially once you have the ability to edit directly in QGIS. During plugin development, I found I only need a method of compiling PyQt/Qt resources and the 'plugin reloader' script.<br>
<br>However, deploying the plugin for use by users is another matter. The package and upload tools I intend to make (still developing their logic and workflow now) could include a deployment step and toolbar icon. This could generate a duplicate plugin, but one that has been fully deployed. This would allow the developer to see how their plugin would look and work after deployment. That temp plugin could then be deleted, as the packager tool would auto-deploy as part of the packaging process.<br>
<br>> While your plugin is great for editing, it lacks a simple way to do the following steps :<br>> * git management (init, commit)<br>> * compile and deploy (make commands)<br>><br>> Maybe integrating a little terminal dock panel could be enough to let the user<br>
> achieve these steps.<br><br>Compiling will be built in (working on it now), including individual compiling of files, to one-click whole project compiling (recursive directory search for compileable resources).<br><br>
Adding a new 'temp deployment' step I noted above.<br><br>SCM, like git, is certainly a best practice in any software development. However, I feel this should be optional, but have available builtin support in the editor for setting up local repo and firing off commits.<br>
<br>I developed this plugin, up until yesterday, only relying upon my hourly Time Machine backups (rsync on a Mac). I didn't feel the need for a repo until I thought other developers might want to get involved, or once I had enough stable code base, and didn't want to break it trying out new ideas (i.e. start doing forks and merges). It's my opinion that most new dvelopers won't even need it for most small projects.<br>
<br>I still want to see git as part of the Editor plugin. It certianly should be part of the tutorial and an available option for users to choose, from the start of a project.<br><br><br>> I give a lot of training sessions on QGIS and especially on plugin<br>
> development.The workflow I am using is the following :<br>><br>> * Generate the plugin start code with plugin builder in a dev directory<br>> * init git on this directory<br>> * edit code<br>> * compile (ui to py, i18n)<br>
> * deploy to local plugin dir (make deploy)<br>> * commit<br>> * package and upload (make upload)<br><br>Here are the development steps I see right now, when a new developer starts using the Editor plugin:<br><br>
* Open Editor and read help docs, explaining how to use the editor, what steps they should anticipate during development, and where QGIS plugin development resources are located.<br><br>* Read part 1 of the tutorial, installing the tutorial's demo plugin to follow along; editing the demo, reloading and running it, all from within QGIS. An introduction to the QGIS Python Console would also be included. Best practices are introduced and discussed.<br>
<br>There are further parts to the tutorial, including all steps leading up to releasing. On first relese of the plugin, anyone is welcome to fork the Editor's embedded tutorial document and add to it.<br><br>Thank you for your comments and making me think more about the design of my plugin.<br>
<br>Larry Shaffer<br><br><br>-- <br><br>Larry Shaffer<br>Dakota Cartography<br>Black Hills, South Dakota<br>