Very many parts of the GUI are closely connected because many of the important wxPython classes are reused to optimize the code and make enhancements and bug fixes easier. I found long ago that doing a comprehensive GUI for GRASS meant a very large and complexly interconnected code base that is very different from the individual modules that make up the rest of GRASS. The number of lines of code in the GUI is daunting. While I'm sure that this could be reduced somewhat, doing so is a complicated and ongoing chore. This has made coding much trickier. As Martin and I know all too well, changing something in one part can have unexpected repercussions in another part.
At one time, when the "GUI" was simply a base menu system and independent dialogs for each command, it was possible to split out parts. With a display canvas and its associated functions (including digitizing, profiling, georectification, and 3D visualization), this would now be a great amount of work and I'm not sure that it would be worth the great effort to the majority of GRASS users given the very small number of programmers and the large amount of other work to do. Compiling without the GUI is a good idea. GRASS works fine without it. If you take it away now, it will simply start in text mode, but a cleaner solution is desirable. Trying to come up with a way for users to create a customized GUI that they can plug together sounds nice in theory, but in practice is very difficult. For example, a couple years back, I looked into what it would take to allow the layer manager to "dock" onto a display canvas so that GRASS could have the appearance of ArcGIS that some people favor. I found that it is possible, but would require a very large amount of rewriting of existing code. Now, it may be even more difficult. Something as complex as an interface like this is heavily affected by path dependence. We've tried to make it as robust as possible, and made a lot of good decisions about architecture early on. But there is still a lot of lock-in and interconnectivity--intentional and unintentional--that is impossible to decouple without months of programming time. Michael On Nov 27, 2010, at 10:00 AM, <[email protected]> wrote: > Date: Sat, 27 Nov 2010 12:04:24 +0100 > From: "Francesco P. Lovergine" <[email protected]> > Subject: Re: [GRASS-dev] CLI!=GUI > To: Martin Landa <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, > [email protected] > Message-ID: <20101127110420.ga2...@mithrandir> > Content-Type: text/plain; charset=us-ascii > > On Sat, Nov 27, 2010 at 11:43:02AM +0100, Martin Landa wrote: >> Hi, >> >> 2010/11/27 Markus Neteler <[email protected]>: >>> On Sat, Nov 27, 2010 at 6:51 AM, Paolo Cavallini <[email protected]> >>> wrote: >>>> E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS >>>> can be used >>>> for WPS? >>> >>> Likely not, but --without-wxwidgets should help. >> >> it will just disable wxGUI digitizer (wxNviz has been rewritten to python). >> >> We could add new flag --without-gui which would disable compiling (and >> installing selected components). >> >> martin >> > > That would be the very first step, indeed. Of course IMHO a full solution > would > imply also: > > - having a componentized GUI which could be added to the core without > rebuilding > the whole beast (possibly componentizing 2d/3d would be also a good idea). > - decoupling gui/core releases: my impression is that the core could evolve > much > fastly than the gui. That's based on counting the current number of GUI > related bugs > in comparison with core ones. > > -- > Francesco P. Lovergine > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
