[Qgis-developer] Re: Add QScintilla2 PyQt module to QGIS Distributions?

[Larry Shaffer]

Hello Vincent,

Thank you for your reply and valuable input. I will try to address each of
your comments, as you bring up important points.

> Making the learning curve easier for users to write plugins is great, but
we
> should be careful to keep constraints on them, or at least good habits in
> plugin development, or we will end up with a lot of bad-quality plugins,
which
> is clearly a problem. There is of course a balance to find between
> constraints and ease of development, but it should be well thought in
order
> not to create more problems than it solves.

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.

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.

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.

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.

> One thing that bothers me a bit is that you directly edit your local
plugin in
> plugin's directory and not in code repository.
> The packaged and deployed plugin content is often different from the
plugin
> code repository.

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.

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.

> While your plugin is great for editing, it lacks a simple way to do the
following steps :
> * git management (init, commit)
> * compile and deploy (make commands)
>
> Maybe integrating a little terminal dock panel could be enough to let the
user
> achieve these steps.

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).

Adding a new 'temp deployment' step I noted above.

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.

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.

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.


> I give a lot of training sessions on QGIS and especially on plugin
> development.The workflow I am using is the following :
>
> * Generate the plugin start code with plugin builder in a dev directory
> * init git on this directory
> * edit code
> * compile (ui to py, i18n)
> * deploy to local plugin dir (make deploy)
> * commit
> * package and upload (make upload)

Here are the development steps I see right now, when a new developer starts
using the Editor plugin:

* 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.

* 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.

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.

Thank you for your comments and making me think more about the design of my
plugin.

Larry Shaffer


-- 

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20120212/5dc2810a/attachment.html