<div dir="ltr">Hi Vaclav,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 5:08 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">Hi Rashad,<div><br></div><div>web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful.</div>
<div>
<br></div><div>First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add?</div>
</div></blockquote><div><br></div><div>This is the rather important part and we do want to reuse the code from core classes. </div><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><br></div><div>Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what <a href="http://rollapp.com" target="_blank">rollapp.com</a> is using.<br>
</div></div></blockquote><div><br></div><div>I am interested to use Wt, not because of C++ and its recent Python love, because the idea of Widget centric, security of Wt apps (very much safe than any other web framework), embedded platform support. and so on. The main idea behind the birth of Wt is they want a web application to run on Web browser and embedded platforms (Android and others). The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. Indeed I am allowed to use as much as javascript code. In the demo you can see openlayers widget!</div>
<div><br></div><div>When you write:</div><div><br></div><div>WButton *button = new WButton();</div><div><br></div><div>Wt makes the css for Wbutton which it has and provide a very decent and easy access to render it on browsers. I would rather stop here talking about Wt before it turn into a name drop of the toolkit which I dont want to do.</div>
<div><br></div><div><br></div><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><br></div>
<div>Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS).</div>
<div><br></div></div></blockquote><div><br></div><div>IIUC, you mean security of the data right?. WebGRASS project is not about providing server infrastructure to preserve the data. Of course it wont allow to get other users data and in my plan users will have access to their own location rather than anyone can use everyone's data. And sensitivity of data uploaded is a question and you never publish such kind of data under NDA or so in public server right? And you cant access a data on server even when you render it on browser screen. That is what mapserver, Openlayers and other web map viewer are doing.</div>
<div><br></div><div> <br></div><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></div>
<div>
Fourth, the processing on server could be also invoked from a desktop GUI. This would require user to install the desktop GUI but the processing part would be placed on server. This is just another option.</div></div></blockquote>
<div><br></div><div>I am not clear with this. Why do you need to invoke a desktop interface for running a webapp. I did had a the demo version running on server with no X server. </div><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><br></div><div>Fifth, the choice of the GUI framework is important. We don't want to tight this to some project which will not be here in few years. Wt has nice examples and your (Rashad's) experience is big plus. But there is many others such as Dabo and some of them might be better for us since they are using Python, so we could share some code with wxGUI. Results on mobile platforms must be evaluated, too.</div>
<div><br></div></div></blockquote><div><br></div><div>There has been a python binding for Wt and myself and massmio had tried these successfully. The support for bindings are not much, I would say but I had a pretty much idea about how its generated which BTW is not using swig and SIP. Regarding mobile platforms I do had a working apk of another Wt application for which I got a recording on youtube[1] (offline android). [2] is the web version. The patch required for me was very minimal as Wt compiles clean on Android. [1] also used libgdal (Android). This one just renders a shapefile and style it without OpenLayers or its friends</div>
<div> </div><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></div><div>And finally, a sustainability of the new web GUI must be considered. What will happen after the GSoC? There already were several GRASS web interfaces starting with GRASSLinks in 1995 and also we have some web sites using GRASS in background but they are not general GRASS GUI (e.g. <a href="http://www.gapserve.ncsu.edu/segap/segap/" target="_blank">http://www.gapserve.ncsu.edu/segap/segap/</a>). Minimizing duplication with the desktop GUI seems crucial and merging this to GRASS and developing other infrastructure, too. </div>
</div></blockquote><div><br></div><div>Of course sustainability is considered and I was hoping it would last forever and becoming a good addition to GRASS GIS as previous year's GSoC projects. </div><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><br></div><div>I don't want you to feel overwhelmed by all of these considerations but I was thinking about this topic for some time, so I collected some ideas and now is the time to share them.</div></div></blockquote>
<div><br></div><div><br></div><div>[1] <a href="https://www.youtube.com/watch?v=7giSheeVgnM">https://www.youtube.com/watch?v=7giSheeVgnM</a> (on emulator)</div><div>[2] <a href="https://www.youtube.com/watch?v=v7jtsJXPhXU">https://www.youtube.com/watch?v=v7jtsJXPhXU</a></div>
<div> </div><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"><span class=""><font color="#888888"><div>
<br></div>
<div>Vaclav</div></font></span><div><br></div><div>PS: I just saw your video, congratulations, it looks good and responsive. Is the code somewhere online?</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div class="h5">
On Thu, Mar 6, 2014 at 4:28 AM, Rashad M <span dir="ltr"><<a href="mailto:mohammedrashadkm@gmail.com" target="_blank">mohammedrashadkm@gmail.com</a>></span> wrote:<br></div></div><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><div class="h5">
<div dir="ltr">Hello All,<div><br></div><div>I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. </div>
<div><br></div><div>Comments and suggestions are most welcomed.</div><div><br></div><div>[1] <a href="http://www.webtoolkit.eu/wt" target="_blank">http://www.webtoolkit.eu/wt</a></div><span><font color="#888888"><div>
<div><br></div>-- <br><div><font face="arial, helvetica, sans-serif">Regards,<br>
Rashad</font></div>
</div></font></span></div>
<br></div></div><div class="">_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br></div></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><font face="arial, helvetica, sans-serif">Regards,<br> Rashad</font></div>
</div></div>