<div dir="ltr">Rashad, please basic description of your idea to<div><br></div><div><a href="https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS">https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS</a><br>
</div><div><br></div><div class="gmail_extra">I also created a page to have ideas mentioned here stored in systematic way:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS">https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I will have limited possibilities to work on it in next days, so feel edit or put some facts directly there. I hope that others will also join this discussion which goes far behind the GSoC.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Vaclav<br><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 3:32 PM, Rashad M <span dir="ltr"><<a href="mailto:mohammedrashadkm@gmail.com" target="_blank">mohammedrashadkm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Vaclav,<div><br></div><div><div>I think that the web UI has to be based on the GRASS library and has to not depend on WxWidgets or any other Desktop gui toolkit like JavaFX. g.parser is enough to describe the modules interface and can be used to automatize the build of the module form for any modules. I got your idea of running the same on desktop, web, embedded platforms which is theoretically possible but the run into deadend from time to timeas they are started for desktop application. </div>
<div><br></div><div>Qt has webkit interface, like you said for JavaFX ( i dont know much about the java). The philosophy of a desktop gui toolkit is entirely different from a web application ui. For example message passing or Qt signals/slots can't be used directly. Infact these people have a different implementation and interpretation of signal and slot when used in web. </div>
<div>It is because people had written QtWebkit, Broadway with the same idea in mind as you, now it possible to run these. But they can't used in a many of application sucessfully. For example, rendering a map on Qt and web browser cant be same. We have WMS, WMTS etc.. for rendering imagery and WFS for vector data for this reason. We can't use the everywhere used GDAL for web easily. Boradway or JavaFX and other friends is very much feasible for some projects but not all. </div>
<div><br></div><div>For this idea i envision the web gui app based on :</div><div>- mapset-location wizard</div><div>- map canvas </div><div>- toolbar with:</div><div> pan, query<br></div><div> zoom in/out/bbox to-layer to-region</div>
<div>- menu bar with same layout of grass desktop</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Here you can use GDAL, you are not obliged to use WPS, WMS, WFS to deal with your data. of course you can. None will fix the data used by web application and you could just give a try without evening compiling etc.. (these are some view on webgrass we both saying). </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Regarding the reuse of code. I am planning to use python bindings for wt and core classes will be reused. for parsing description file and the instead of sending boradway or JavaFX etc.. I will use directly a jquery dialog, html button, text and will have direct access to js code such that if i need to render a grass vector i could do it in openlayers or using wt itself to read the grass vector directly using gdal and draw polygons on a HTML5Canvas, SVG, etc.. I could use render module of grass ui to render a ppm or use pygrass numpy to read grass and render as before.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">For Sharing data is one thing i need to think about and having a "shared location" like share folders could be explored. </div><div class="gmail_extra">
<br></div><div class="gmail_extra">For GRASS 3D. its not possible to use opengl on web. you must use webgl. and I dont think the previous GTK broadway could use opengl. </div><div class="gmail_extra"><br></div><div class="gmail_extra">
Also GRASS is famous for large data processing and i was exploring that too. So the webUI must be behave differently when dealing with large data and should allow you to queue any process. Just thinking for now. </div><div class="gmail_extra">
<br></div><div class="gmail_extra">And the whole idea of having webgrass will help users and developers as stefan was mentioning to run them on university or a company network without caring of operating system and Wt support Windows, Linux, OS X among other embedded platforms.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The demo video of android was from 2012 and since then Wt improved Android support. In 2012 there was not automated apk. But when I checked in 2013 wt build system if configured for android will generate an apk for your application.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I would ask you to think webUI as a wrapper like python, java etc.. You can have two gui for GRASS GIS. Remember about grass6.3 and earlier version which uses tcl/tk and was not used now because lack of support and or functionality and I am never saying Wxwidgets is not lacking a functionality for a desktop platform but on web perspective i think it is. Am I right?</div>
<div class="gmail_extra"><div><div class="h5"> <br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 8:42 PM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br>
<div class="gmail_quote">On Thu, Mar 6, 2014 at 1:38 PM, epi <span dir="ltr"><<a href="mailto:massimodisasha@gmail.com" target="_blank">massimodisasha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>At the moment i’m having so much fun with IPython Notebook</div>
<div>that is my actually my grass interface ... in this idea i can see a little room for it too :)</div></blockquote></div><br></div>IPython Notebook would be the clear choice of Python command console for a web GUI written from scratch. Similarly, OpenLayers or Leaflet could become a web GRASS GUI map display. The downside of things such as GTK+ Broadway is that these solutions are simply not available. Although they can be always used inside some web view. With this we are getting to the other option I was mentioning: web-based GUI used in a web view(s) on desktop. This would allow us to use all highly interactive Java Script visualization libraries on desktop.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://wxpython.org/Phoenix/docs/html/html2.WebView.html" target="_blank">http://wxpython.org/Phoenix/docs/html/html2.WebView.html</a><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class=""><font color="#888888">-- <br><div><font face="arial, helvetica, sans-serif">Regards,<br> Rashad</font></div>
</font></span></div></div>
</blockquote></div><br></div></div>