Hi Stefan. On Thu, Mar 6, 2014 at 12:45 PM, Blumentrath, Stefan < [email protected]> wrote:
> Hi Rashad and Vaclav, > > > > If you allow me a user comment: > User comments are not only allowed but they are needed. > The video looks very, very promoising. > > In our institution we are running GRASS on an Ubuntu Server which users > access graphically either through either TightVNC or CYGWin-X. > ssh -X, VNC etc. are of course always here, so the question is home much more we will get from other solutions. > What I like about the Server solution is the “work where your data is” > concept (even if server ressources may be smaller when shared by several > users, compared to modern single user desktop PCs). > So, it seems that you want the full fully-featured GUI, not just some basic one. > I also perceive GRASS`s mapset concept as very useful for multi-user > environment and data sharing (maybe except for the ownership check which > hampers usage of mapsets by groups of people (I know there are workarounds > (e.g. goup users as owners or overriding the ownership check in GRASS 7)). > This is what I was mentioning in other email. There could be different requirements on data management, especially sharing, in the online environment. > > > On the same Server we also have an RStudio-Server running which would be > comparable to your webGRASS-solution. > > Our experience with RStudio Server is very positive, so I would appreciate > such a solution for GRASS (though TightVNC and CYGWin-X are fine too)… > >From quick check RSStudio is written in Java. E.g. the new Java GUI framework JavaFX allows to create desktop and web (probably client-server) application at once. Unfortunately, nor wxPython/wxWidgets or Qt (or its Python friends) does not allow this by themselves. JavaFX is not really an option for use, however the concept is what I would like to have. The GUI with the same look and (I believe) the same implementation on all desktops and also on web. https://www.rstudio.com/ide/screenshots/ (first four screenshots) The main advantage is (from my point of view) that users do not have to > install additional software… > So, web-based solution is necessary for that. Which e.g. kills my suggestion of wxGUI executing commands on server. Thanks for your input, if you have more, please do. Vaclav > > Cheers > > Stefan > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Rashad M > *Sent:* 6. mars 2014 18:12 > *To:* Vaclav Petras > *Cc:* [email protected] > *Subject:* Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI > > > > Hi Vaclav, > > > > On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras <[email protected]> > wrote: > > Hi Rashad, > > > > 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. > > > > 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? > > > > This is the rather important part and we do want to reuse the code from > core classes. > > > > 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 rollapp.com is using. > > > > 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! > > > > When you write: > > > > WButton *button = new WButton(); > > > > 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. > > > > > > > > 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). > > > > > > 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. > > > > > > 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. > > > > 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. > > > > 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. > > > > > > 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 > > > > 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. > http://www.gapserve.ncsu.edu/segap/segap/). Minimizing duplication with > the desktop GUI seems crucial and merging this to GRASS and developing > other infrastructure, too. > > > > 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. > > > > 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. > > > > > > [1] https://www.youtube.com/watch?v=7giSheeVgnM (on emulator) > > [2] https://www.youtube.com/watch?v=v7jtsJXPhXU > > > > > > Vaclav > > > > PS: I just saw your video, congratulations, it looks good and responsive. > Is the code somewhere online? > > > > > > On Thu, Mar 6, 2014 at 4:28 AM, Rashad M <[email protected]> > wrote: > > Hello All, > > > > 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. > > > > Comments and suggestions are most welcomed. > > > > [1] http://www.webtoolkit.eu/wt > > > > -- > > Regards, > Rashad > > > > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > > > > > > > > -- > > Regards, > Rashad >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
