<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 6, 2014 at 12:12 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,<br><div class="gmail_extra"><br>
<div class="gmail_quote"><div class="">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></blockquote></div></div></div></div></blockquote></div><div class="gmail_quote">...</div><div class="gmail_quote"><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 class=""><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">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>
</blockquote><div><br></div></div><div>This is the rather important part and we do want to reuse the code from core classes. </div></blockquote></div><br>You need to use Python to really reuse the classes. And do also a large refactoring of wxGUI code to make them reusable (although some improvements were already made). How much you can reuse? How much you want to reuse? This is probably hard to answer, easier might be which functionality do we want in web GUI? Only modules and map visualization? Or also digitizers, animations, map swipe, ...?</div>
<div class="gmail_extra"><div class="gmail_quote"><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">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.</blockquote>
</div><br>This is what previously mentioned GTK+ Broadway is doing. I'm not sure how does this compare to Ulteo and to whatever <a href="http://rollapp.com" target="_blank">rollapp.com</a> is using. noVNC is VNC where client runs in web browser. The advantage of these is that you don't write any new GUI code.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://developer.gnome.org/gtk3/stable/gtk-broadway.html">https://developer.gnome.org/gtk3/stable/gtk-broadway.html</a><br></div><div class="gmail_extra">
<a href="http://blogs.gnome.org/alexl/2012/12/27/broadway-multi-process-suppor/">http://blogs.gnome.org/alexl/2012/12/27/broadway-multi-process-suppor/</a><br></div><div class="gmail_extra"><a href="http://kolyakosenko.wordpress.com/2013/07/18/wxwidgets-2-9-5/">http://kolyakosenko.wordpress.com/2013/07/18/wxwidgets-2-9-5/</a><br>
</div><div class="gmail_extra"><a href="https://www.youtube.com/watch?v=P6lzZpS5M4g">https://www.youtube.com/watch?v=P6lzZpS5M4g</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://en.wikipedia.org/wiki/Ulteo_Open_Virtual_Desktop">http://en.wikipedia.org/wiki/Ulteo_Open_Virtual_Desktop</a><br>
</div><div class="gmail_extra"><a href="http://www.ulteo.com/">http://www.ulteo.com/</a><br></div><div class="gmail_extra"><a href="http://kanaka.github.io/noVNC/">http://kanaka.github.io/noVNC/</a><br></div><div class="gmail_extra">
<a href="https://www.youtube.com/watch?v=ZiIxtoHa9bU">https://www.youtube.com/watch?v=ZiIxtoHa9bU</a> (<a href="http://rollapp.com">rollapp.com</a>)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">
<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 class=""><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 class="">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><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>
</blockquote></div><br>I though that the goal is to have something like Google Docs but for GIS. Which could be provided by GRASS community but more importantly, everyone would be able to setup his or her own server. I'm not concern about license of data, in terms of security, I'm concern about users accidentally deleting each other data or somebody running some evil processes on my server. And in terms of usability, some data upload/download functions are needed, management, ideally also sharing and perhaps publishing through web services by forwarding then to some map server.<br>
</div><div class="gmail_extra"><div class="gmail_quote"><br class="">On Thu, Mar 6, 2014 at 12:12 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 class=""><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>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><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>
</blockquote></div><br>How much code are these applications? I somewhere accessible? How much development was in Wt since than? Some improvements, e.g. for Android?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
<div class="gmail_quote"><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 class=""><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"><br class="">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>
</blockquote><div><br></div></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></div>
<br>I hope too but my point is that we should do it the right way this time because now it is really needed. For some things like improvements of modules, I'm not concerned. It will prevail once it is in the source code, module is needed, improvement is needed, this is clear. But we can create a web GUI and it will be forgotten or superseded by something better in few years. For example, Gimp was not writing a web based GUI but now I can use Gimp on web using <a href="http://rollapp.com">rollapp.com</a>.<br>
</div></div>