Re: [GRASS-dev] Interest in GSoC 2016

[Ondra.Lobo]

Hi, 

firstly, thanks for your interest. 

On Fri, Mar 25, 2016 at 3:12 AM, massimo di stefano  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á
 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







"



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

Re: [GRASS-dev] Interest in GSoC 2016

[Vaclav Petras]

On Fri, Mar 25, 2016 at 8:46 AM, massimo di stefano <
massimodisa...@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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in GSoC 2016

[massimo di stefano]

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á  wrote:
> 
> On Thu, Mar 24, 2016 at 10:12 PM, massimo di stefano
> > 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.l...@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 
>> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in GSoC 2016

[Anna Petrášová]

On Thu, Mar 24, 2016 at 10:12 PM, massimo di stefano
 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.l...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in GSoC 2016

[massimo di stefano]

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.l...@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

Re: [GRASS-dev] Interest in GSoC 2016

[Vaclav Petras]

Hi Ondrej,

On Thu, Mar 17, 2016 at 2:45 PM,  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in GSoC 2016

[Ondra.Lobo]

Hi Vaclav

On Thu, Mar 17, 2016 at 9:44 PM,  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







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

Re: [GRASS-dev] Interest in GSoC 2016

[Luca Delucchi]

On 17 March 2016 at 19:45,   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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in GSoC 2016

[Rainer M Krug]

Pietro  writes:

> Hi Ondřej,
>
> On Thu, Mar 17, 2016 at 7:45 PM,   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: Rainerkrugsde
PGP: 0x0F52F982


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

Re: [GRASS-dev] Interest in GSoC 2016

[Pietro]

Hi Ondřej,

On Thu, Mar 17, 2016 at 7:45 PM,   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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev