[GRASS-dev] Who wants GUI and who does not and why

[Huidae Cho]

I really like this idea and want to go further by splitting into four main
parts:

- grass-lib: keep the current core libraries as is. Low level GIS layer

- grass-plugins: implement raster/raster3d/vector/... whatever the current
commands implement as libraries. These libraries spit out xml for building
CLI/GUI interfaces. One plugin per module. High level modeling/analysis
layer

- grass-cli: very light xml parser. Maybe, we'll only need one command and
give a plugin name and its parameters to this command.

- grass-gui: also very light xml parser.

This way, other GIS programs can use grass-lib and grass-plugins to build
their interface from xml output without having to update their client code
heavily whenever a major GRASS GIS is released.

Regards,
Huidae



On Fri, Apr 18, 2014 at 5:15 AM, Pietro <peter.zamb at gmail.com> wrote:

> Hi Vaclav,
>
> actually I'm a bit more extremist... :-)
>
> I would like to split GRASS in three main parts:
> - grass-lib
> - grass-cli
> - grass-gui
>
> often we have these things mixed to each other, for example a lot of
> GRASS modules implement functions that could be moved to grass/lib
> (e.g. r.stats). I would like to see the CLI interface just only as
> command line interface to the GRASS library, not more not less. At the
> moment each GRASS module implement it's own functions.
>
> The same is true for the GUI, inside the GUI libraries there are a lot
> of functions and objects that partially implement functionality that
> should be moved to lib. Again I would like a clearer distinction
> between the logic/functionality and Graphic user interface.
>
> These changes could help to reduce redundancy and reduce the code size
> of the GRASS project.
>
> Split the GRASS project in these three parts perhaps could help us to
> clearly distinguish between functionalities and interfaces
> (command/graphic),and we should re-organize the grass root
> consistently.
>
> Splitting the library from the CLI, should make easier other FOSS
> projects to use the GRASS processing capabilities.
>
> At least should be possible to build these parts separately, leaving
> the decision to split in several packages to the package maintainer of
> each distribution (Debian, Fedora, etc.).
>
> Regards
>
> Pietro
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140501/9fa3ead0/attachment.html>