gem/qt-experiments — pull request #20 by ptormene (2014-01-02 14:41:17+00:00)
Title: Workflow improvements

"standardization" (https://github.com/gem/qt-experiments/pull/15) and "huge-geometries" (https://github.com/gem/qt-experiments/pull/19) branches should be merged first.

This pull request fixes some small bugs and a number of minor issues about plugin's usability, e.g.:
- removed redundancy in definition of actions and relative menu items and toolbar buttons
- checks on field data types and on availability of loaded layers
- automatic pre-selection of fields, based on data types
- error messages or warnings displayed in the QGis message bar instead of throwing exceptions
- additional modal dialogs to select layers and attributes when the user triggers actions from the plugin's menu
- additional docstrings

OPEN ISSUES:

1) In this branch I'm using a self-made joining between SVI and aggregated losses (by zone id), instead of using the built-in QGis "join" functionality. In branch "flexible-workflow-native-join" I am exploring the other approach, but currently it is not working properly, for some strange reason. It looks like the new layer containing both SVI and aggregated losses contains only a subset of accessible fields (the fields added from the aggregation layer do not appear in the list of fields of the new layer, although they are correctly displayed in the attribute table from the QGis GUI). Please, Marco, have a look at the above-mentioned branch, and try figuring out what I'm doing wrong there.

2) Another problem might be partially correlated to the first one. When attempting to retrieve field.typeName(), in some cases it is empty. In particular, it looks like I should manually set the typeName each and every time I add a new field to a layer, otherwise it remains empty. This behavior sounds a bit weird, because I would expect the typeName to be set automatically by QGis, depending on the actual type of the field (otherwise the two things might mismatch if not properly handled). Currently I am avoiding to get the typeName and I retrieve, instead, the type, which is a numeric code, but such solution is probably sub-optimal.