Rashad, please basic description of your idea to https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS
I also created a page to have ideas mentioned here stored in systematic way: https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS 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. Vaclav On Thu, Mar 6, 2014 at 3:32 PM, Rashad M <mohammedrasha...@gmail.com> wrote: > 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 <wenzesl...@gmail.com>wrote: > >> >> On Thu, Mar 6, 2014 at 1:38 PM, epi <massimodisa...@gmail.com> 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 grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev