[GRASS-dev] Interest in GSoC 2016

GRASS GIS GRASS GIS developer
,
1

Hi,

My name is Ondřej Pešek and I am student of Czech Technical University in Prague. I am in the last year of bachelor studium (geodesy, cartography and geoinformatics). My bachelor thesis is development of QGis plugin (for aerial data leveling). I’m developing in python and I have some basics in C++. Often I work also with other gis programs (ArcGis). I am very interested in co-working with Grass for Google Summer of Code 2016.

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is increasingly used (look at QGis, for example) and I think it would be better to have minimally the roots of GUI in Qt. It’s also much easier to maintain with new features. Work with design is also much more user-friendly. It seems that in the future, it can be nice shortcut to change something in the GUI.

Thanks and I’m looking forward for your answers,

Ondřej Pešek

=

2

Hi Ondrej,

On Thu, Mar 17, 2016 at 2:45 PM, <Ondra.Lobo@seznam.cz> wrote:

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt)
is increasingly used (look at QGis, for example) and I think it would be
better to have minimally the roots of GUI in Qt. It’s also much easier to
maintain with new features. Work with design is also much more
user-friendly. It seems that in the future, it can be nice shortcut to
change something in the GUI.

this is a good idea. To make it really work, I think, it is necessary to
use the generic part code also for the current GUI besides using it for the
prototype of Qt-based GUI. This would ensure that the new code is actually
used right away. It would also ensure few more other important things
already described at the wiki.

Vaclav

3

Hi Vaclav

On Thu, Mar 17, 2016 at 9:44 PM, wenzeslaus@gmail.com wrote:

To make it really work, I think, it is necessary to use the generic part code also for the current GUI besides using it for the prototype of Qt-based GUI. This would ensure that the new code is actually used right away. It would also ensure few more other important things already described at the wiki.

Yeah, the original idea came from wiki, I’ve read it. I will need some time to deeply explore GRASS GUI. But I believe it could be fun…

Thanks for your response,

Ondrej

=

4

On 17 March 2016 at 19:45, <Ondra.Lobo@seznam.cz> wrote:

Hi,

Hi Ondřej,

My name is Ondřej Pešek and I am student of Czech Technical University in
Prague. I am in the last year of bachelor studium (geodesy, cartography and
geoinformatics). My bachelor thesis is development of QGis plugin (for
aerial data leveling). I’m developing in python and I have some basics in
C++. Often I work also with other gis programs (ArcGis). I am very
interested in co-working with Grass for Google Summer of Code 2016.

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
increasingly used (look at QGis, for example) and I think it would be better
to have minimally the roots of GUI in Qt. It’s also much easier to maintain
with new features. Work with design is also much more user-friendly. It
seems that in the future, it can be nice shortcut to change something in the
GUI.

Thanks and I’m looking forward for your answers,

Your proposal is really interesting.

What could you be able to port to Qt? Layer manager and map display?

Ondřej Pešek

--
ciao
Luca

www.lucadelu.org

5

Hi Ondřej,

On Thu, Mar 17, 2016 at 7:45 PM, <Ondra.Lobo@seznam.cz> wrote:

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
increasingly used (look at QGis, for example) and I think it would be better
to have minimally the roots of GUI in Qt. It’s also much easier to maintain
with new features. Work with design is also much more user-friendly. It
seems that in the future, it can be nice shortcut to change something in the
GUI.

I like the idea, and I think could be strategic for the long run,
especially because it is not clear to me if and when Phoenix (the
wxPython for python3) will be ready (and from my superficial
understanding of the GRASS problem on OS X El Captain Wx it seems part
of the issue), instead both pyQt and pySide support python3 (I think
we should build a GUI compatible with both binding. Consider that
GRASS is already working with Python3 (with except of the ctype stuff)
what it is critical (imho) it is the GUI.

I do like the idea of Vaclav to share a core of functionalities of the
GUI (between Wx, Qt, Jupyhter, etc). This shared functionalities
should go in /lib/python/grass/{gui|somethingelse}. This should allow
us to reduce duplication and the number of code that must be
maintained.

I think that we should also consider to split GRASS and its
functionalities, but I open a separate thread on this.

Best regards

Pietro

6

Pietro <peter.zamb@gmail.com> writes:

Hi Ondřej,

On Thu, Mar 17, 2016 at 7:45 PM, <Ondra.Lobo@seznam.cz> wrote:

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
increasingly used (look at QGis, for example) and I think it would be better
to have minimally the roots of GUI in Qt. It’s also much easier to maintain
with new features. Work with design is also much more user-friendly. It
seems that in the future, it can be nice shortcut to change something in the
GUI.

I like the idea, and I think could be strategic for the long run,
especially because it is not clear to me if and when Phoenix (the
wxPython for python3) will be ready (and from my superficial
understanding of the GRASS problem on OS X El Captain Wx it seems part
of the issue),

With my limited grasp of the grass internals and wxpython:

The main issue For El Capitan is the use of DYNLD_LIBRARY_PATH when
running binaries in /usr/bin or /bin directories (e.g. make). In the
case of homebrew (presumibly Macports as well), during compilation (I
can turn of SIP (System Integrity Progtection) on El Capitan, compile and
install, and enable it again, and it works) and in the case of the
binary compilation and running (as GRASS uses the shell which is in /usr/local/bin).

instead both pyQt and pySide support python3 (I think
we should build a GUI compatible with both binding. Consider that
GRASS is already working with Python3 (with except of the ctype stuff)
what it is critical (imho) it is the GUI.

I do like the idea of Vaclav to share a core of functionalities of the
GUI (between Wx, Qt, Jupyhter, etc). This shared functionalities
should go in /lib/python/grass/{gui|somethingelse}. This should allow
us to reduce duplication and the number of code that must be
maintained.

I think that we should also consider to split GRASS and its
functionalities, but I open a separate thread on this.

Best regards

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

7

Hi Ondřej,

I also think that Qt is a mature, powerful and stable framework to develop GUI.
can you please explain us your approach to develop a Qt based map canvas?

While the development of a window for each module is pretty straightforward
(the use of g.parser and a template.ui should make this task relatively easy)

I was wondering if you considered the adoption of modern OpenGL based rendering system.

Thanks,
Massimo.

On Mar 17, 2016, at 2:45 PM, Ondra.Lobo@seznam.cz wrote:

Hi,

My name is Ondřej Pešek and I am student of Czech Technical University in Prague. I am in the last year of bachelor studium (geodesy, cartography and geoinformatics). My bachelor thesis is development of QGis plugin (for aerial data leveling). I’m developing in python and I have some basics in C++. Often I work also with other gis programs (ArcGis). I am very interested in co-working with Grass for Google Summer of Code 2016.

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is increasingly used (look at QGis, for example) and I think it would be better to have minimally the roots of GUI in Qt. It’s also much easier to maintain with new features. Work with design is also much more user-friendly. It seems that in the future, it can be nice shortcut to change something in the GUI.

Thanks and I’m looking forward for your answers,

Ondřej Pešek

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

8

On Thu, Mar 24, 2016 at 10:12 PM, massimo di stefano
<massimodisasha@gmail.com> wrote:

Hi Ondřej,

I also think that Qt is a mature, powerful and stable framework to develop
GUI.

I was wondering if you considered the adoption of modern OpenGL based
rendering system.

Could you be more specific about the OpenGL, do you have some
solutions in mind? I thought this project would be about using the
current rendering system and focusing on rewriting to qt plus
refactoring of the current code because that alone is a lot of work
if you are not familiar with the current codebase. Better rendering
could be added later on. But I think Ondrej is open to suggestions.

Anna

Thanks,
Massimo.

On Mar 17, 2016, at 2:45 PM, Ondra.Lobo@seznam.cz wrote:

Hi,

My name is Ondřej Pešek and I am student of Czech Technical University in
Prague. I am in the last year of bachelor studium (geodesy, cartography and
geoinformatics). My bachelor thesis is development of QGis plugin (for
aerial data leveling). I’m developing in python and I have some basics in
C++. Often I work also with other gis programs (ArcGis). I am very
interested in co-working with Grass for Google Summer of Code 2016.

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
increasingly used (look at QGis, for example) and I think it would be better
to have minimally the roots of GUI in Qt. It’s also much easier to maintain
with new features. Work with design is also much more user-friendly. It
seems that in the future, it can be nice shortcut to change something in the
GUI.

Thanks and I’m looking forward for your answers,

Ondřej Pešek

_______________________________________________
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

9

On Thu, Mar 24, 2016 at 10:12 PM, massimo di stefano <
massimodisasha@gmail.com> wrote:

can you please explain us your approach to develop a Qt based map canvas?

I don't know how well known is this but definitely work mentioning. Soeren
implemented some new methods into GRASS C library which can be used to show
raster maps in GUI. They seems to be working quite well in the Grass Data
Explorer QGIS Plugin. This might be an interesting alternative to the
current d-command-based approach which is the default solution I assume.
But as Anna said, we need to make a distinction between rendering (getting
picture of data) and GUI (buttons to say which picture), although in case
of map display they are tightly coupled.

10

Hi Anna,

Depending on how much effort the implementation in Qt of the current rendering system will require
maybe is worth to explore new rendering tools.
Or design the gui code base in a way that will make the adoption of new rendering systems as easy as possible.
It is my understanding that the hardest part will be the development of tools to interact with the map canvas.

for the rendering I was thinking of 2 different approaches using library like vispy:

http://vispy.org/

or datashader:

https://github.com/bokeh/datashader

the first is an OpenGL rendering system (smooth pan/zoom and continue rendering)
the second is suitable for large data (render billions of point without crashing the app)

I tried both with standard dataset.

vispy is an attractive library very fast rendering but I don’t know how much effort is required to implement
“mouse events like digitizing and other map canvas interactive tools”

datashader is more “matplotlib-like”, at an api level,
that should make the development of tools to interact with the map canvas a little easier.

I agree with you, a new rendering system can be coded outside GSoC, what you mentioned

using the
current rendering system and focusing on rewriting to qt plus
refactoring of the current code

is indeed a lot of work for a single GSoC.
I’ve some experience with PyQt, and I’m willing to help in making this a successful idea.

Massimo.

On Mar 24, 2016, at 10:32 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Mar 24, 2016 at 10:12 PM, massimo di stefano
<massimodisasha@gmail.com> wrote:

Hi Ondřej,

I also think that Qt is a mature, powerful and stable framework to develop
GUI.

I was wondering if you considered the adoption of modern OpenGL based
rendering system.

Could you be more specific about the OpenGL, do you have some
solutions in mind? I thought this project would be about using the
current rendering system and focusing on rewriting to qt plus
refactoring of the current code because that alone is a lot of work
if you are not familiar with the current codebase. Better rendering
could be added later on. But I think Ondrej is open to suggestions.

Anna

Thanks,
Massimo.

On Mar 17, 2016, at 2:45 PM, Ondra.Lobo@seznam.cz wrote:

Hi,

My name is Ondřej Pešek and I am student of Czech Technical University in
Prague. I am in the last year of bachelor studium (geodesy, cartography and
geoinformatics). My bachelor thesis is development of QGis plugin (for
aerial data leveling). I’m developing in python and I have some basics in
C++. Often I work also with other gis programs (ArcGis). I am very
interested in co-working with Grass for Google Summer of Code 2016.

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
increasingly used (look at QGis, for example) and I think it would be better
to have minimally the roots of GUI in Qt. It’s also much easier to maintain
with new features. Work with design is also much more user-friendly. It
seems that in the future, it can be nice shortcut to change something in the
GUI.

Thanks and I’m looking forward for your answers,

Ondřej Pešek

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

11

On Fri, Mar 25, 2016 at 8:46 AM, massimo di stefano <
massimodisasha@gmail.com> wrote:

Or design the gui code base in a way that will make the adoption of new
rendering systems as easy as possible.

+1. High quality code should be the main focus here.

12

Hi,

firstly, thanks for your interest.

On Fri, Mar 25, 2016 at 3:12 AM, massimo di stefano massimodisasha@gmail.com wrote:

can you please explain us your approach to develop a Qt based map canvas?

While the development of a window for each module is pretty straightforward
(the use of g.parser and a template.ui should make this task relatively easy)

I was wondering if you considered the adoption of modern OpenGL based rendering system.

On Fri, Mar 25, 2016 at 3:33 AM, Anna Petrášová
kratochanna@gmail.com wrote:

I thought this project would be about using the
current rendering system and focusing on rewriting to qt plus
refactoring of the current code because that alone is a lot of work
if you are not familiar with the current codebase. Better rendering
could be added later on. But I think Ondrej is open to suggestions.

Exactly as Anna said. My primary object is rewriting to qt. It means that it depends on the time and my works, primarily I want to develop something most similar to current project, just in Qt. Now I’m just personally exploring your ideas (vispy and datashader) and if everything goes well, I can try it. But it’s just additional goal (but very attractive).

Best, Ondřej

=