Hi all!
Here is the second report of my GSoC project - PyQt based GUI of GRASS automatically generated from XML
What did you get done this week?
-
Now the code is reading those types - float, range, sql_query, flags
-
It also writes their names or labels and types into GUI
What do you plan on doing next week?
-
Other types - especially I have on my mind string and name
-
I also want to make the GUI little bit more elegant. It means I want to insert spacer on the end of every tab → it means that widgets will be at the top, not averagely placed.
Are you blocked on anything?
Here is the wiki with screenshots etc.: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI
Hi Ondrej,
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.
On Sat, Jun 4, 2016 at 5:27 AM, Ondřej Pešek <pesej.ondrek@gmail.com> wrote:
What did you get done this week?
* Now the code is reading those types - float, range, sql_query, flags
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.
* It also writes their names or labels and types into GUI
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).
Another thing to consider would be the visibility or emphasis of the actual
name of the parameter, but we can leave that for later.
* I also want to make the GUI little bit more elegant. It means I want to
insert spacer on the end of every tab -> it means that widgets will be at
the top, not averagely placed.
Also note that sometimes the list of widgets can be long, see e.g. g.region
Resolution tab.
Best,
Vaclav
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
(attachments)
···
Hi,
2016-06-04 20:47 GMT+02:00 Vaclav Petras <wenzeslaus@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
On 08/06/16 08:57, Blumentrath, Stefan wrote:
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)
Side question: do the parser rules include flags ? I thought they were only available for options.
Moritz
Side question: do the parser rules include flags ? I thought they were only available for options.
Actually, I have no idea. I just checked the add-ons I wrote, and saw that I only used them for options. I was not aware of this limitation...
Thanks for pointing that out...
Cheers
Stefan
Hi,
it sounds good, thank you for opening new possibilities. To be honest, I didn’t know about the g.parser rules.
Now I’m just looking on that. It looks nice. In some latest version, I will try to implement it. Especially the mutually exclusive ones, it should be nice.
Thanks
···
2016-06-08 9:30 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:
Side question: do the parser rules include flags ? I thought they were only available for options.
Actually, I have no idea. I just checked the add-ons I wrote, and saw that I only used them for options. I was not aware of this limitation…
Thanks for pointing that out…
Cheers
Stefan
On Wed, Jun 8, 2016 at 3:30 AM, Blumentrath, Stefan
<Stefan.Blumentrath@nina.no> wrote:
Side question: do the parser rules include flags ? I thought they were only available for options.
Actually, I have no idea. I just checked the add-ons I wrote, and saw that I only used them for options. I was not aware of this limitation...
Thanks for pointing that out...
Check the manual:
https://grass.osgeo.org/grass72/manuals/g.parser.html
It's implemented and I used it couple of times successfully.
Anna
Cheers
Stefan
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 08/06/16 15:37, Anna Petrášová wrote:
On Wed, Jun 8, 2016 at 3:30 AM, Blumentrath, Stefan
<Stefan.Blumentrath@nina.no> wrote:
Side question: do the parser rules include flags ? I thought they were only available for options.
Actually, I have no idea. I just checked the add-ons I wrote, and saw that I only used them for options. I was not aware of this limitation...
Thanks for pointing that out...
Check the manual:
https://grass.osgeo.org/grass72/manuals/g.parser.html
It's implemented and I used it couple of times successfully.
Right. Sorry. I'd tried it without the '-' and it didn't work, so I just assumed it didn't... Not sure if I find it intuitive to require the dash...
Moritz