[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Blumentrath, Stefan]

Hei,

And thanks for your work on the PyQT-GSoC project!

When it comes to possible GUI improvements, I am wondering if it would be feasible to take e.g. parser rules into account by means of either

a)      generating widgets depending on parser rules (if e.g. two flags are mutually exclusive, use radio button instead of two tick-boxes)

b)      making the GUI “interactive” (e.g. a flag and an option are mutually exclusive, grey out the option when the flag is set, and the other way around)

If it in principle would be possible to make the GUI more dynamic that would be nice. Here I am thinking of e.g. to be able to generate lists for selections or default values, from for example a python script that is run before the GUI opens... A use-case would be the i.ortho.* modules (which still have not been ported to G7), where for example the values stored in a camera file (which is a simple text file) would have to be read into the GUI, so users can edit camera definitions, camera exposure parameters ...

Nothing essential, but it might open some new possibilities...

Kind regards,
Stefan

From: grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Ondrej Pešek
Sent: 5. juni 2016 10:22
To: Vaclav Petras <wenzeslaus at gmail.com>
Cc: GRASS developers list <grass-dev at lists.osgeo.org>
Subject: Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

Hi,

2016-06-04 20:47 GMT+02:00 Vaclav Petras <wenzeslaus at gmail.com<mailto:wenzeslaus at gmail.com>>:

the screenshots looks good. For the code, it might little bit too soon to judge it, but just keep in mind the need for design we talked about earlier. For some simple help, you can use pylint tool which will demand some code style. Start with the file tools/pylintrc.txt in the GRASS source code.


yes, I want to write there also some comments etc. And I'll try the pylint.


When I ran it for v.buffer I see you are using text edit / line edit for float even when it is not [multiple]. I think Qt has double spin box which you can use. In general, you don't have to fully follow the current look or behavior. If you think that something can be done in a better way, do it.

For example, this would be one thing we can reconsider. The shorter description (label or description field) shows as the name/label for a field while the longer description (description field) shows as a tooltip of the label. One improvement could be showing it as a tooltip for the input field as well (or perhaps in a completely different way).

I will consider it all. While coding I was experimenting, but everytime I considered that the original widget = the best widget. Thanks for tips, I will try it your way. And the tooltip version sounds good. Should I put the name and type (input=string) upper (where now is description) or on the right side (as in current version).

Thanks for tips and have a nice time,
Ondrej


[Image removed by sender.]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>

Bez virů. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160608/8d115173/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 524 bytes
Desc: image002.jpg
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160608/8d115173/attachment-0001.jpg>