QGIS

http://osgeo-org.1560.x6.nabble.com/Processing-Parameters-and-widgets-refactoring-td5268569.html
Constat
Actuellement, dans le plugin Processing, tous les contrôles de saisie des paramètres d'entrée sont codés en dur dans la classe ParametersPanel sur la base du type de paramètre. Ceci est relativement rigide et ne permet pas de créer des contrôles de saisie customisés en fonction du contexte.

En plus de cela, nous avons beaucoup de duplication de code entre :
- La fenêtre d'algorithme standard ;
- La fenêtre de traitement par lot ;
- La fenêtre du modeleur.

Lors du dernier HackFest QGIS, nous avons donc proposé une refactorisation de la relation parametre d'entrée / contrôle de saisie associé.
Proposition
L'idée est de créer un contrôle de saisie propre à chaque type de paramètre. La classe ParametersPanels n'aurais donc plus qu'a parcourir les paramètres et créer les contrôles associés.

Il serait donc possible de créer des nouveaux types de paramètres et des contrôles associés sans avoir besoins de créer des boîtes de dialogues spécifiques ou de modifier la classe ParametersPanel. Chaque fournisseur d'algorithmes pourrait facilement proposer, avec ses algorithmes, ses propres contrôles de saisie.

Le nouveau design serait le suivant :

- La classe de base parametre disposerait d'un nouvel attribut "widget" avec éventuellement d'autres options d'interface. Cet attribut pourrait contenir un widget, une classe de widget, ou, pour la plupart des cas, simplement une chaine de caratère indiquant le chemin de la classe pour un import dynamique. Chaque algorithme pourrait donc demander un widget différent sans même avoir besoin d'importer des modules de l'interface graphique.

- Chaque classe dérivée de paramètre aurait une valeur par défaut pour l'attribut "widget". Nous aurions ainsi, sans modifier les algorithmes existants, un comportement similaire des boites de dialogues.

- Chaque paramètre enverrait des signaux lors d'un changement de sa valeur, l'interface pourrait ainsi réagir de façon transparente à ces changements de valeurs.

Avec ce concept, nous obtenons une dissociation entre les paramètres (code) et les contrôles d'interface associés (ui). Les contrôles de saisie pourrait être facilement étendus sans avoir besoin de modifier la partie core de processing.

Pour l'exemple, nous pourrions facilement créer des contrôles de saisie spécifiques à PostGIS, capables de faire de l'introspection de base de données pour proposer des listes déroulantes pour les schemas, les tables, capables de repérer les clés primaires, les colonnes géométriques, tout en s'appuyant des paramètres de type "String".

A moyen terme, ceci pourrait donc se traduire par des boites de dialogues bien plus interractives et adaptées au contexte.

Tout ceci pourrait être intégré à la version 3.0 de QGIS, et la communauté à montré un vif intérêt pour cette évolution, notamment Victor Olaya, concepteur original du module Processing.