Hi Rashad and Vaclav, As mentioned, I really like the idea of a web-gui. Yet, at the end it will compete with VNC / Cygwin-X (at least in our setting). And I am afraid if it does not offer the same (or at least comparable functionality) most of my colleagues will stick to the former solutions.
Things which would be high on my personal priority list would be: - A commandline interface (and possibly also a python console) in order to be able to paste code - Handling of user logins for accessing other ressources e.g in the home directory Another interesting question would be probably how users can get results to their local machines, both regarding map data (e.g. r.out.gdal) and text output (e.g. from r.stats)... Is there a chance for fetching output through the web-gui or would users have to connect to the server e.g. using FTP or fileshares e.g. in a company network? But of course, a research company network is only one use-case for a web-gui for GRASS... Maybe you ask on the user-list how other users would like to use a web-gui? That could help identifying priorities in the development process (e.g. regarding the possible data-license or security problems). Best regards, Stefan From: Rashad M [mailto:[email protected]] Sent: 6. mars 2014 21:32 To: Vaclav Petras Cc: epi; Blumentrath, Stefan; [email protected] Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Hi Vaclav, 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. 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. 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. For this idea i envision the web gui app based on : - mapset-location wizard - map canvas - toolbar with: pan, query zoom in/out/bbox to-layer to-region - menu bar with same layout of grass desktop 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). 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. For Sharing data is one thing i need to think about and having a "shared location" like share folders could be explored. 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. 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. 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. 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. 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? On Thu, Mar 6, 2014 at 8:42 PM, Vaclav Petras <[email protected]<mailto:[email protected]>> wrote: On Thu, Mar 6, 2014 at 1:38 PM, epi <[email protected]<mailto:[email protected]>> wrote: At the moment i'm having so much fun with IPython Notebook that is my actually my grass interface ... in this idea i can see a little room for it too :) 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. http://wxpython.org/Phoenix/docs/html/html2.WebView.html -- Regards, Rashad
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
