GSoC 2016 PyQt based GUI of GRASS automatically generated from XML

Title:	PyQt based GUI of GRASS automatically generated from XML
Student Name:	Ondrej Pesek, ​Czech Technical University in Prague
Organization:	​OSGeo - Open Source Geospatial Foundation
Mentor Name:	​Vaclav Petras, Anna Petrasova
GSoC proposal:	​view proposal
Repository:	​github
Documentation:	[TODO]

Abstract

GUI forms (module dialogs) are now automatically generated from XML into wxPython. My idea is to create code that is generating the same code into more powerful Qt.

Goal

Create a table of individual widgets, their features and when their are used. Existing GUI in GRASS GIS and also in QGIS GRASS plugin and QGIS Processing plugin are good starting points.

List of standard options in GRASS GIS https://grass.osgeo.org/grass71/manuals/parser_standard_options.html gives list of commonly used parameters which are likely to become specialized widgets (but it is not 1:1 - a lot of them are actually the same map selection widget just with different parameters). The general specification of options and flags is in the programming manual https://grass.osgeo.org/programming7/gislib_cmdline_parsing.html.

There is more ways to do it. We will try to make more files. Nowadays, it is just one file with more than 3000 lines. It is not very readable. We hope that we can change it.

Notes

In the first version, creating GUI will work just as script started from GRASS. Of course I want to implement it as normal function (there is variable "gui" in GRASS), but it's not necessary. When the GUI is ready and compatible with many functions, then tere is possibility to make it. (not in timeline, additional goal)

The same is with styling. I will try to make everything very similar to current GUI, but I didn't make any window in timeline for that. I will work on that within all the GSoC period assuming that I have the time.

I have a problem with the end of the june. I have Final Examinations at my school so maybe I won't have so much time. I will try to make everything here ahead of time. In the case I won't, I will definitely catch up it after this period. It will be same for every hiatus that can raise.

Timeline

timeline created during bonding
		status
Community bounding period	Familiarization with the existing code	*
Let the summer begin
MAY 23 - 27	Creating empty generated GUI	*
MAY 30 - JUNE 3	Creating basic GUI (just basic widgets) of some function - e.g. r.buffer	*
JUNE 6 - 10	Updating GUI - using standard Qt widgets and creating the first version of copyable/runable code	*
JUNE 13 - 24	Updating GUI - using standard Qt widgets + make Run button runable	*
Mid term evaluation
JUNE 27 - JULY 8	Implementation of custom widgets (gselect.Select), running also flags
JULY 11 - 22	Linking widgets, dependencies (select map -> columns)
JULY 25 - 29	Clearing of code
AUGUST 1 - 5	Testing
AUGUST 8 - 13	Writing documentation
The end

Requirements

​GRASS 7.1

Development

Weekly reports

May 23 - 27

Designed basic GUI shuck. From XML is now automatically generated GUI with name, keywords and basic layouts (description, tabs, buttons).

Code now works as a script with parameter - for example r.buffer

May 30 - June 3

I have made GUI using some basic widgets - checkboxs, labels, lineedits...

Now the code is reading those types - float, range, sql_query, flags

It also writes the label (or name) and type into GUI.

June 6 - June 10

I have upgraded GUI - now it works also with the string and integer types. (on the basic level)

I also have made some changes - SqlQuery is now lineedit and when the float isn't multiple, the GUI generates QDoubleSpinBox.

The important thing is the first version of copyable/runable code. The buttons don't work yet, but user can see it and it automatically reads the code.

And one elegant thing - all the widgets are now stretched upper.

June 13 - June 17

The Run button really runs (but still not with flags). It's still the only button with any function. Also the code-string on the bottom of GUI was recreated. Now it's just one (only readable) textedit. When the string is too long, you will get the scrollbar.

Completely retyped code in parameters.py. Now it works like Factory. Factory is dynamically creating the list of methods classes with canHandle method and the called class depends on the values in this method. It means that there are not so many "ifs" and the code is better readable. And those classes return "self" instead of method get().

Float coords is lineedit.

When the string has values, it's editable combobox with implemented values.

Nearly last thing: I implemented the TreeComboBox for inouts/outputs. Both raster and vector. It works very similarly to the one in old GUI. Mapset is parent and then you have many children to choose. It's in gselect.py and in parameters.py is just the class inheriting it from gselect with added canHandle method. It's much readable for anyone than just directing program elsewhere.

For not implemented thing I use lineedit (because You can write there anything manually). Now I highlight it with red colour and word TODO in GUI. It's just for me and will not be in the real version.

I'm sorry but at June the 27th, I have my bachelor final exams at school so I won't be able to do anything related to GSoC in next week (I really have to learn something before exams). I have done everything in my timeline for next week so I hope it's okay. Thanks.