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

[Moritz Lennert]

On 08/06/16 15:37, Anna Petrášová wrote:

On Wed, Jun 8, 2016 at 3:30 AM, Blumentrath, Stefan
 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Anna Petrášová]

On Wed, Jun 8, 2016 at 3:30 AM, Blumentrath, Stefan
 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Ondřej Pešek]

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 :

> > 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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Blumentrath, Stefan]

> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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-boun...@lists.osgeo.org] On Behalf Of Ondrej 
Pešek
Sent: 5. juni 2016 10:22
To: Vaclav Petras <wenzesl...@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

Hi,

2016-06-04 20:47 GMT+02:00 Vaclav Petras 
<wenzesl...@gmail.com<mailto:wenzesl...@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_source=link_campaign=sig-email_content=webmail>

Bez virů. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Ondřej Pešek]

Hi,


2016-06-04 20:47 GMT+02:00 Vaclav Petras :

>
> 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



Bez
virů. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

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  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt

[Ondřej Pešek]

Thanks, I'm going on that.


Bez
virů. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2016-05-30 9:14 GMT+02:00 Luca Delucchi :

> On 27 May 2016 at 23:27, Ondřej Pešek  wrote:
> >
> > Hi,
> >
>
> Hi Ondrej,
>
> > here is report of what I have done during this week in my GRASS
> >
> > GSoC Project:
> >
> > WEEK 1
> >
> > 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 (python
> forms.py r.buffer).
> >
> > Take a look at screenshots.
> >
>
> These look really a good starting point, please could you extend the
> README file adding how to test the code, for example dependencies and
> how to compile/use
>
> >
> > Best regards,
> > Ondrej
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt

[Luca Delucchi]

On 27 May 2016 at 23:27, Ondřej Pešek  wrote:
>
> Hi,
>

Hi Ondrej,

> here is report of what I have done during this week in my GRASS
>
> GSoC Project:
>
> WEEK 1
>
> 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 (python 
> forms.py r.buffer).
>
> Take a look at screenshots.
>

These look really a good starting point, please could you extend the
README file adding how to test the code, for example dependencies and
how to compile/use

>
> Best regards,
> Ondrej
>


-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt

[Ondřej Pešek]

Hi,

thanks for your response.

2016-05-25 17:26 GMT+02:00 Pietro :

>
> Perhaps, it could be useful to have a look at pygrass `Module` class [0],
> that already parse the generated xml and instantiate `Parameter` class [1]
> that validate the input from the user in the `_check_value` function [2].
> So should be possible to dynamically generate a `Qt Widget` from a
> `Parameter` instance and then compose everything in complete final
> `QtWidget`/`QtDialog`. If you think that  in the `Module` / `Parameter`
> class definition something is missing/wrong or bad implemented, after
> discussion, we can change it. They were not developed with this use case in
> mind and perhaps some changes are needed however I do think they are a
> starting point...
>
>
Thank you, 'Module' is really nice. I was working with 'task', but 'Module'
looks much better.



> I think that we should support both: PyQt and PySide, and I think you
> should use as primary choice for development Python3, support for Python2
> it is much easier to add later if needed.
>
>
Well, I have never worked with Python3. But of course I can try it. It
might be useful to learn it and if you think it's better. I have created
basics in Python2 but it was one week - so it's not thousands of lines. I
can still retype it. Thanks for idea.


I'm studying the rest (thanks, it really helps me),
Ondrej



Bez
virů. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt

[Pietro]

Hi Ondrej,

On Tue, May 24, 2016 at 12:48 PM, Ondřej Pešek 
wrote:
>
> the period of GSoC starts. I just want to present myself. My name is
> Ondrej Pesek and I'm from Czech Republic. I study geodesy, cartography and
> geomatics at Czech technical university in Prague. My project for GSoC 2016
> is reimplementation of GUI generated from xml, wxpython -> PyQt. You can
> see everything at [1].
>
> I'm open to all your requests, comments and hates. Don't hesitate to write
> me, I would appreciate it.
>

Perhaps, it could be useful to have a look at pygrass `Module` class [0],
that already parse the generated xml and instantiate `Parameter` class [1]
that validate the input from the user in the `_check_value` function [2].
So should be possible to dynamically generate a `Qt Widget` from a
`Parameter` instance and then compose everything in complete final
`QtWidget`/`QtDialog`. If you think that  in the `Module` / `Parameter`
class definition something is missing/wrong or bad implemented, after
discussion, we can change it. They were not developed with this use case in
mind and perhaps some changes are needed however I do think they are a
starting point...

You can see a good implementation of this logic in the fromlayout
project[3] that it is well written, support both PyQt and PySide and
Python2 and Python3.

Together with Francesco Geri we started writing a plugin for QGis (a proof
of concept (it works, but a lot of things are missing), just few hours of
work of our spare time..) that generate dynamically the form for the GRASS
modules, the code is not good and it is using qgis API... but I think that
can explain what I have in mind.

I think that we should support both: PyQt and PySide, and I think you
should use as primary choice for development Python3, support for Python2
it is much easier to add later if needed.

I hope these information/ideas can be useful for your GSoC.
Have fun!

all the best

Pietro


[0]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/interface/module.py#L266
[1]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/interface/parameter.py#L97
[2]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/interface/parameter.py#L15
[3] https://github.com/PierreRaybaut/formlayout
[4] https://bitbucket.org/fragit/rgreengui/src
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev