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

[Larry Shaffer]

Hi,

@Alessandro: Would you consider writing, or scaffolding, a Python
class that assumes a correctly written and prepared plugin (i.e.
properly packaged plugin) and the necessary extra textual information
that is needed for the repository listing, and interfaces an upload to
the repository app using its API? This is the first plugin I will be
releasing, and I have not gone through the process of uploading to the
new repo app yet. I could take your class and add a GUI onto it for
the upload to plugins.qgis.org part of the Editor's upload tool.

After completing the Plugin Editor's tool set, I would like to wrap
its packaging and uploading tools into two Eric4 plugins, so plugin
developer's who move to (or start with) that IDE can have those tools
available to them as well.


@Paolo: What about the Editor plugin offering to auto-setup a Redmine
git repo upon upload to the plugins.qgis.org repo app, if the plugin
author hasn't set one up until then? Part of the package and upload
tools' logic should be to verify and offer as much best practice
functionality as possible, as this directly affects how the plugin is
released to (seen by) the public.


@all (sorry, this is a bit long-winded): After reading this discussion
on requisites and best practice techniques, I'm noticing a need to
define the anticipated base user for the Editor plugin.

To do this I tried (incompletely, no doubt) to put together what is
needed by a potential new plugin dev to create an 'ideal' QGIS plugin.
I have also tried to put these requisites in some sense of functional
order, i.e. what should be known first to produce an actual working
plugin, not necessarily in any best practices order:

* Read other plugin devs Python code and discern the logic. I think
this is the root level of starting to learn any new coding technique,
and the Editor is built around this principle.

* Understand Python, and how to write procedural functions with it.
OOP and PEPs are something many coders new to Python don't do right
away.

* Understand how the QGIS Python API works, i.e. what a Python binding
is. This includes learning to read C++ class docs, an undertaking not
usually associated with learning a single scripting language API.

* How to use the Python Console to test code snippets.

* Know how the parts of a plugin work (__init__.py, factory class, etc.).

* How to test/debug the plugin. Plugin Editor has no debugging (though
it could); but since it has the simple reload functionality (based on
Richard Duivenvoorde's work), getting to QGIS's Python error traces is
pretty quick. For example, I have not really needed to use a command
line debugger when writing the Editor plugin (yet), just Richard's
reloader plugin.

* Understand how to build a GUI with PyQt. I think this is a big
hurdle for many new devs (it was for me, since I didn't learn PyQt/Qt
until needing to make a QGIS plugin). Learning PyQt, Qt,
signals/slots, and Designer alone takes some time and head-scratching.

* Creating a proper QGIS plugin deployment for use by others (not
necessarily the public). Using 'make' to aid deployment seems fine to
many devs, but most scripters have never had to learn how to write
make files when working with an interpreted language. The
functionality of a make file could be replaced with simple check-boxed
include/exclude listing of project files in the GUI for stripping out
unneeded resources. Compiling will already be done during
deployment/packaging.

* Learn how to use the new plugin repo for a plugin release. This may
be the first time a coder has had to use or need a SCM. Having git
available on hub.qgis.org will be a definite boon to those new to such
things.

* Learn how to work with users via a bug tracker, etc. and respond
with fixes or new releases.

* Learn QtWebKit, or similar tool, for creating good, embedded user
documentation.

* Learn how to internationalize the visible strings of the plugin. A
cursory examination of currently available plugins shows this is not
always at the top of most devs list.

* Learn Sphynx to generate plugin documentation, especially if the
pugin has public methods, etc.

* Learn to write proper code (PEP adherence, use of PyLint, etc.).

* Learn to work with other devs who may want to fork the plugin and
introduce new code.

* Learn to create unit tests (if they care about stability and not
breaking code).

* I'm sure there are others


Let's assume some realistic, but proficient QGIS users who may want to
try to develop a plugin...

A) Know none of the above requisites.

B) Know some Python, but never created plugins or GUIs with it before.

C) Know some Python, created some plugins for other software, but no
GUIs with it before. (<-- I started here)

D) Know quite a bit of Python and have written some GUIs before (maybe
with wxPython or PyQt)

E) Know more than users A thru D.


Given the above noted requisites for crafting a QGIS plugin, which
should be considered the base user for my plugin? I'm designing for
user A), for whom I think the Plugin Editor should a least offer a
clear understanding of how to achieve not only writing a plugin, but
also how to eventually meet the best practice requisites noted above,
and offer the tools or links to resources to do so.

The QGIS project has first-class, clearly written code and support
documentation, created by driven developers and authors who try to
meet high-quality OS standards. It would be good to gently push new
plugin developers to strive to meet similar standards, but not at the
price of the learning curve becoming a wall. I'm hoping that Plugin
Editor will help new plugin developers enjoy their path to writing
quality plugins by reducing learning obstacles to manageable steps.
Any help with breaking down the requisites, and when they should be
introduced to the neophyte developer (in the embedded tutorial) would
be greatly appreciated.

I'm striving to have the Plugin Editor qualify for 'user-friendly,' a
status already achieved by QGIS, which is why I use it.


Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota