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

GRASS GIS GRASS GIS developer
,
1

Hi all,

···

I believe, I was calling for this discussion recently, and I’m calling for it again. It seems that there are quite different opinions on GRASS GIS GUI ranging from “GUI is the only thing which brings us new users” to “no GUI needed”.

There is no better time to discuss this: we are discussing issues with MS Windows support, planing to release 7, working towards compatibility of 7 with QGIS and gvSIG, and we also discussed WebGRASS topic recently.

Here are recent quotations from “Handling of Python scripts on MS Windows” discussion (http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with few notes and questions but feel free to start wherever you want.

On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke <benducke@fastmail.fm> wrote:

On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

[Side note: The same discussion should also constantly be held about
functionality which is specific to the GUI, because specifically
developed for it), i.e. not just a GUI layer above command line
functionality, something I’m afraid to see creep in more and more…]

Does this mean that you want remove everything from gui/* besides gui/wxpython/forms/*?

Agreed. Once more, I plead for a clean separation between GUI
and CLI developments, and a disconnection of their release cycles.

I see some advantages, for example just using same bug tracker makes difficult to say what is critical issue; but there are some GUI errors are tightly coupled to core module issues.

On the other hand, I don’t see how these disconnected release cycles would work. Also it seems that it is impossible or very hard to create good GUI without the support of the processing and management tools.

The wxPython GUI can be considered a monolithic application,
and FWIW it can pull every trick in the book to integrate a
Python interpreter, and to make it all easier for Windows users.

…

I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
monolithic applications and let their maintainers figure out how
to deal with this. In the gvSIG CE project, we do a lot of hair-
raising stuff to hide the complexity of GRASS and its dependencies
from the end user, and I suspect so does QGIS. But I would not
advocate the same approach to the core GRASS architecture.

Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins. Managing one GUI less in OSGeo could save some work. For example, QGIS GRASS plugin is developed separately, so there is no need to have another graphical user interface for GRASS with disconnect development.

I also think that some of the debate comes from the question of whether
the wxGUI should have a special status or whether it should just
be treated as one of the hundreds of modules that GRASS offers.

This is more or less the current state, there is g.gui, you can start without it, there are g.gui.* modules. On the other hand, there is always something spatial with GUI, e.g. if you want GUI to start when module is started without parameters/with --ui.

Or, are you satisfied with the situation as it is now?

Thanks for sharing your thoughts,
Vaclav

2

Maybe some of the earlier involved developers can share their thoughts on the Tcl/Tk GUI and its integration, its rise and fall, why and where this experience can lead the wxPython GUI now…

···

On 16 April 2014 08:00, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi all,

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

I believe, I was calling for this discussion recently, and I’m calling for it again. It seems that there are quite different opinions on GRASS GIS GUI ranging from “GUI is the only thing which brings us new users” to “no GUI needed”.

There is no better time to discuss this: we are discussing issues with MS Windows support, planing to release 7, working towards compatibility of 7 with QGIS and gvSIG, and we also discussed WebGRASS topic recently.

Here are recent quotations from “Handling of Python scripts on MS Windows” discussion (http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with few notes and questions but feel free to start wherever you want.

On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke <benducke@fastmail.fm> wrote:

On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

[Side note: The same discussion should also constantly be held about
functionality which is specific to the GUI, because specifically
developed for it), i.e. not just a GUI layer above command line
functionality, something I’m afraid to see creep in more and more…]

Does this mean that you want remove everything from gui/* besides gui/wxpython/forms/*?

Agreed. Once more, I plead for a clean separation between GUI
and CLI developments, and a disconnection of their release cycles.

I see some advantages, for example just using same bug tracker makes difficult to say what is critical issue; but there are some GUI errors are tightly coupled to core module issues.

On the other hand, I don’t see how these disconnected release cycles would work. Also it seems that it is impossible or very hard to create good GUI without the support of the processing and management tools.

The wxPython GUI can be considered a monolithic application,
and FWIW it can pull every trick in the book to integrate a
Python interpreter, and to make it all easier for Windows users.

…

I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
monolithic applications and let their maintainers figure out how
to deal with this. In the gvSIG CE project, we do a lot of hair-
raising stuff to hide the complexity of GRASS and its dependencies
from the end user, and I suspect so does QGIS. But I would not
advocate the same approach to the core GRASS architecture.

Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins. Managing one GUI less in OSGeo could save some work. For example, QGIS GRASS plugin is developed separately, so there is no need to have another graphical user interface for GRASS with disconnect development.

I also think that some of the debate comes from the question of whether
the wxGUI should have a special status or whether it should just
be treated as one of the hundreds of modules that GRASS offers.

This is more or less the current state, there is g.gui, you can start without it, there are g.gui.* modules. On the other hand, there is always something spatial with GUI, e.g. if you want GUI to start when module is started without parameters/with --ui.

Or, are you satisfied with the situation as it is now?

Thanks for sharing your thoughts,
Vaclav

3

I agree with what Michael and Benjamin have said, but since I was cited personally just a short reaction:

On 16/04/14 04:30, Vaclav Petras wrote:

Hi all,

I believe, I was calling for this discussion recently, and I'm calling
for it again. It seems that there are quite different opinions on GRASS
GIS GUI ranging from "GUI is the only thing which brings us new users"
to "no GUI needed".

There is no better time to discuss this: we are discussing issues with
MS Windows support, planing to release 7, working towards compatibility
of 7 with QGIS and gvSIG, and we also discussed WebGRASS topic recently.

Here are recent quotations from "Handling of Python scripts on MS
Windows" discussion
(http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with
few notes and questions but feel free to start wherever you want.

On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke <benducke@fastmail.fm
<mailto:benducke@fastmail.fm>> wrote:
> On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

     > [Side note: The same discussion should also constantly be held about
     > functionality which is specific to the GUI, because specifically
     > developed for it), i.e. not just a GUI layer above command line
     > functionality, something I'm afraid to see creep in more and more...]
     >

Does this mean that you want remove everything from `gui/*` besides
`gui/wxpython/forms/*`?

I don't know how you come to that conclusion from the above quote. I never saif I don't want the GUI. What I refered to was a recurrent discussion about making sur that all functionality for which this is possible should be available via the CLI, and not only via the GUI. Just to cite one example which shows some degree of divergence:

The GUI import wizards (vector and raster) allow specifying a directory from which to import all (or a selection) of the files. AFAIK, there is no command line equivalent for that, except for creating the loop yourself in your favorite scripting language. So, to follow my idea, we should have a r.in.gdal.dir/v.in.ogr.dir module which does the job on the command line and which the GUI builds upon.

I know: if it's an itch just scratch it yourself, but I'm just using this an example to illustrate the quote above. And it's not meant as a criticism to anyone, but rather as a reminder to ourselves to be vigilant about this.

The recent creation of the g.gui.* commands is a good step in the other direction, i.e. making small modules of specific GUI processes.

    The wxPython GUI can be considered a monolithic application,
    and FWIW it can pull every trick in the book to integrate a
    Python interpreter, and to make it all easier for Windows users.

    ...

    I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
    monolithic applications and let their maintainers figure out how
    to deal with this. In the gvSIG CE project, we do a lot of hair-
    raising stuff to hide the complexity of GRASS and its dependencies
    from the end user, and I suspect so does QGIS. But I would not
    advocate the same approach to the core GRASS architecture.

Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins.

This is _your_ conclusion, although others have had that same conclusion before, but, as Michael has argued convincingly, there are sufficient developers who want to spend time on a specific GRASS GUI as they feel the need, and so the discussion is void.

I personally certainly find the GRASS GUI very useful, and have never been able to warm up to using QGIS or gvSIG for the task, notably because of the loss of explicit control over the whole location management (in Sextante and derivatives) which I actually find very useful when teaching (and using) GIS.

> I also think that some of the debate comes from the question of whether

the wxGUI should have a special status or whether it should just
be treated as one of the hundreds of modules that GRASS offers.

This is more or less the current state, there is g.gui, you can start
without it, there are g.gui.* modules. On the other hand, there is
always something spatial with GUI, e.g. if you want GUI to start when
module is started without parameters/with --ui.

All that was meant by the above statement is that specific needs of the wxGUI should not interfere in overall management of GRASS installation and compilation any more than other modules.

Or, are you satisfied with the situation as it is now?

In terms of the fact that we have a wxGUI I'm very satisfied. The discussion you cite has never been about abandoning the GUI, but about how to handle GRASS installation.

Moritz

4

Hi Vaclav,

actually I'm a bit more extremist... :slight_smile:

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

5

Hi,

2014-04-18 11:15 GMT+02:00 Pietro <peter.zamb@gmail.com>:

I would like to split GRASS in three main parts:
- grass-lib
- grass-cli
- grass-gui

I was thinking about splitting `grass` package at least manually for
OSGeo4W framework. This idea makes sense to me. Martin

6

On 18 April 2014 11:15, Pietro <peter.zamb@gmail.com> wrote:

Hi Vaclav,

actually I'm a bit more extremist... :slight_smile:

I would like to split GRASS in three main parts:
- grass-lib
- grass-cli
- grass-gui

I also like this idea...

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.).

I think that someone is already doing something like this.
But I don't know more because I usually compile myself GRASS

Regards

Pietro

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

7

Hi,

Ubuntu follows debian packaging for GRASS GIS like others. And most of the packaging rules are copied from DebianGIS.

So for debian, and its derivaties. GRASS packaging has

grass-core, grass-gui, grass-docs, packages
grass-dev. too is there for development version.

···

On Sun, Apr 20, 2014 at 1:42 AM, Luca Delucchi <lucadeluge@gmail.com> wrote:

On 18 April 2014 11:15, Pietro <peter.zamb@gmail.com> wrote:

Hi Vaclav,

actually I’m a bit more extremist… :slight_smile:

I would like to split GRASS in three main parts:

  • grass-lib
  • grass-cli
  • grass-gui

I also like this idea…

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.).

I think that someone is already doing something like this.
But I don’t know more because I usually compile myself GRASS

Regards

Pietro

–
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Regards,
Rashad

8

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@gmail.com> wrote:

Hi Vaclav,

actually I’m a bit more extremist… :slight_smile:

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

9

Luca Delucchi <lucadeluge@gmail.com> writes:

On 18 April 2014 11:15, Pietro <peter.zamb@gmail.com> wrote:

Hi Vaclav,

actually I'm a bit more extremist... :slight_smile:

I would like to split GRASS in three main parts:
- grass-lib
- grass-cli
- grass-gui

I also like this idea...

I think this would be a very good idea as it would make the whole GRASS
ecosystem more transparent and easier (in my opinion) to maintain and to
use certain aspects from different applications.

Re functionality in the GUI:

The question would be if the split is

lib--cli--gui

or

   |--cli
lib|
   |--gui

in other words, if the cli is just a non graphical UI or THE interface
to the lib, through which the gui operates. I think the first design
approach would be the better one.

Cheers,

Rainer

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.).

I think that someone is already doing something like this.
But I don't know more because I usually compile myself GRASS

Regards

Pietro

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

PGP: 0x0F52F982

10

I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli & grass-lib or grass-gui & grass-lib.

Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, … should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly.

grass-lib ↔ grass-plugins ↔ grass-cli, grass-gui, other GISs: Full analysis/modeling suite

grass-lib ↔ other GISs: Simple GIS data manipulation very common in all fields.

Regards,
Huidae

···

On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug <Rainer@krugs.de> wrote:

Luca Delucchi <lucadeluge@gmail.com> writes:

On 18 April 2014 11:15, Pietro <peter.zamb@gmail.com> wrote:

Hi Vaclav,

actually I’m a bit more extremist… :slight_smile:

I would like to split GRASS in three main parts:

  • grass-lib
  • grass-cli
  • grass-gui

I also like this idea…

I think this would be a very good idea as it would make the whole GRASS
ecosystem more transparent and easier (in my opinion) to maintain and to
use certain aspects from different applications.

Re functionality in the GUI:

The question would be if the split is

lib–cli–gui

or

|–cli
lib|
|–gui

in other words, if the cli is just a non graphical UI or THE interface
to the lib, through which the gui operates. I think the first design
approach would be the better one.

Cheers,

Rainer

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.).

I think that someone is already doing something like this.
But I don’t know more because I usually compile myself GRASS

Regards

Pietro

–

Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

PGP: 0x0F52F982

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

11

On 02/05/14 14:29, Huidae Cho wrote:

I agree. grass-cli and grass-gui should be completely independent and at
the same level. They are simply two different UIs that directly depend
on grass-lib. The user wants either grass-cli & grass-lib or grass-gui &
grass-lib.

Now, my opinion is if we put analysis and modeling code in grass-lib,
grass-lib would be too big or, for some users, it would contain too much
irrelevant code if all they want is simply GIS operations. Very
field-specific code such as hydrology, remote sensing, ... should be
separated out from the grass-lib and put in another layer of the
libraries. grass-cli/gui will interact with that layer directly.

grass-lib <-> grass-plugins <-> grass-cli, grass-gui, other GISs: Full
analysis/modeling suite

grass-lib <-> other GISs: Simple GIS data manipulation very common in
all fields.

I don't think I understand: there is no such thing as grass-lib that can be called from either a grass-cli _or_ a grass-gui. The GUI actually calls grass modules. And these modules _are_ the CLI. And as many discussions have shown before, GRASS libs should not be called from anything else but GRASS modules.

Moritz

12

On Fri, May 2, 2014 at 8:29 AM, Huidae Cho <grass4u@gmail.com> wrote:

I agree. grass-cli and grass-gui should be completely independent and at
the same level. They are simply two different UIs that directly depend on
grass-lib. The user wants either grass-cli & grass-lib or grass-gui &
grass-lib.

This of course makes sense. However, we are very far from anything like

this. Functionality is in the modules (i.e. CLI), not library, and even
Python libraries contains CLI calls. I don't see any chance of changing
this state any time soon, although it would be beneficial. The grass-lib
would no just contain very basic things (compared to what CLI would
provide). Consequently there cannot be any GUI without CLI now.

Now, my opinion is if we put analysis and modeling code in grass-lib,

grass-lib would be too big or, for some users, it would contain too much
irrelevant code if all they want is simply GIS operations. Very
field-specific code such as hydrology, remote sensing, ... should be
separated out from the grass-lib and put in another layer of the libraries.
grass-cli/gui will interact with that layer directly.

As I said this is very theoretical and in fact, there was one refactoring

which moved things from lib to modules. Anyway, it would be beneficial to
know what would be concrete steps to do this, what are the issues this must
solve, and, similarly to GUI, what is the general opinion on this. For
example, the implementation of RPC interface for library (as discussed in
another threads) would allow usage of grass-lib by any application, not
only modules (CLI), so then GUI could depend directly on grass-lib. On the
other hand, modules define a nice user interface for processing, so I don't
think that GUI should define some other, it should just use the modules
(the current state). The other question is what should be used to implement
GUI.

Regardless of purpose of grass-lib, there are some thing which should be
moved to the library to be reused in more modules. Pietro recently
suggested in some ticket that functionality of r.univar should be available
in the library.

grass-lib <-> grass-plugins <-> grass-cli, grass-gui, other GISs: Full
analysis/modeling suite

I still don't understand what do you mean by grass-plugins.

Vaclav

grass-lib <-> other GISs: Simple GIS data manipulation very common in all
fields.

Regards,
Huidae

On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug <Rainer@krugs.de> wrote:

Luca Delucchi <lucadeluge@gmail.com> writes:

> On 18 April 2014 11:15, Pietro <peter.zamb@gmail.com> wrote:
>> Hi Vaclav,
>>
>> actually I'm a bit more extremist... :slight_smile:
>>
>> I would like to split GRASS in three main parts:
>> - grass-lib
>> - grass-cli
>> - grass-gui
>>
>
> I also like this idea...

I think this would be a very good idea as it would make the whole GRASS
ecosystem more transparent and easier (in my opinion) to maintain and to
use certain aspects from different applications.

Re functionality in the GUI:

The question would be if the split is

lib--cli--gui

or

   |--cli
lib|
   |--gui

in other words, if the cli is just a non graphical UI or THE interface
to the lib, through which the gui operates. I think the first design
approach would be the better one.

Cheers,

Rainer

>
>>
>> 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.).
>>
>
> I think that someone is already doing something like this.
> But I don't know more because I usually compile myself GRASS
>
>> Regards
>>
>> Pietro
>>

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

PGP: 0x0F52F982
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

13

I’m not talking about the current structure. Yes, the modules are the CLI right now and the GUI calls the CLI modules internally. What I’m saying is that it would great if we could separate the logic and CLI and put the logic in plugins and let the CLI and GUI calls the logic. GUI would be independent on CLI and directly call the logic plugin. Here, I’m saying plugin because each module could be implemented as a mod_.so just like Apache modules. Then we could implement a CLI environment that can load mod_.so as needed dynamically. In the same way, other programs can call mod_*.so without creating a separate process for individual modules.

Actually, even now, GRASS libs are called directly from GDAL for handling raster/vector maps.

···

On Fri, May 2, 2014 at 9:58 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 02/05/14 14:29, Huidae Cho wrote:

I agree. grass-cli and grass-gui should be completely independent and at
the same level. They are simply two different UIs that directly depend
on grass-lib. The user wants either grass-cli & grass-lib or grass-gui &
grass-lib.

Now, my opinion is if we put analysis and modeling code in grass-lib,
grass-lib would be too big or, for some users, it would contain too much
irrelevant code if all they want is simply GIS operations. Very
field-specific code such as hydrology, remote sensing, … should be
separated out from the grass-lib and put in another layer of the
libraries. grass-cli/gui will interact with that layer directly.

grass-lib ↔ grass-plugins ↔ grass-cli, grass-gui, other GISs: Full
analysis/modeling suite

grass-lib ↔ other GISs: Simple GIS data manipulation very common in
all fields.

I don’t think I understand: there is no such thing as grass-lib that can be called from either a grass-cli or a grass-gui. The GUI actually calls grass modules. And these modules are the CLI. And as many discussions have shown before, GRASS libs should not be called from anything else but GRASS modules.

Moritz

14

On Fri, May 2, 2014 at 10:03 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, May 2, 2014 at 8:29 AM, Huidae Cho <grass4u@gmail.com> wrote:

I agree. grass-cli and grass-gui should be completely independent and at
the same level. They are simply two different UIs that directly depend on
grass-lib. The user wants either grass-cli & grass-lib or grass-gui &
grass-lib.

This of course makes sense. However, we are very far from anything like

this. Functionality is in the modules (i.e. CLI), not library, and even
Python libraries contains CLI calls. I don't see any chance of changing
this state any time soon, although it would be beneficial. The grass-lib
would no just contain very basic things (compared to what CLI would
provide). Consequently there cannot be any GUI without CLI now.

That's correctly. GUI is a wrapper around CLI because CLI has the "logic".
Other programs that want to use GRASS capabilities should also call CLIs by
executing external programs (CLIs). Instead of calling external processes,
we could dynamically link to the logic libraries and simply call
"functions" if we could do further separations.

Now, my opinion is if we put analysis and modeling code in grass-lib,

grass-lib would be too big or, for some users, it would contain too much
irrelevant code if all they want is simply GIS operations. Very
field-specific code such as hydrology, remote sensing, ... should be
separated out from the grass-lib and put in another layer of the libraries.
grass-cli/gui will interact with that layer directly.

As I said this is very theoretical and in fact, there was one refactoring

which moved things from lib to modules. Anyway, it would be beneficial to
know what would be concrete steps to do this, what are the issues this must
solve, and, similarly to GUI, what is the general opinion on this. For
example, the implementation of RPC interface for library (as discussed in
another threads) would allow usage of grass-lib by any application, not
only modules (CLI), so then GUI could depend directly on grass-lib. On the
other hand, modules define a nice user interface for processing, so I don't
think that GUI should define some other, it should just use the modules
(the current state). The other question is what should be used to implement
GUI.

Regardless of purpose of grass-lib, there are some thing which should be
moved to the library to be reused in more modules. Pietro recently
suggested in some ticket that functionality of r.univar should be available
in the library.

grass-lib <-> grass-plugins <-> grass-cli, grass-gui, other GISs: Full
analysis/modeling suite

I still don't understand what do you mean by grass-plugins.

What I mean by grass-plugins is that we can separate the current CLIs (UI
and logic) into plugins (logic) and light-weight CLI that calls the
plugins. GUI would also call the plugins. Think about Apache. httpd is an
executable file that can load its modules as needed. We cannot call
individual modules directly without using httpd and individual modules have
the logic. I think that this plugin idea would make GRASS analysis/modeling
capabilities more like libraries, not external programs, while maintaining
clear separation of heavy analysis logic from the core grass-lib. And like
you said, yes, we're far from this theoretical status.

Huidae

Vaclav

grass-lib <-> other GISs: Simple GIS data manipulation very common in all
fields.

Regards,
Huidae

On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug <Rainer@krugs.de> wrote:

Luca Delucchi <lucadeluge@gmail.com> writes:

> On 18 April 2014 11:15, Pietro <peter.zamb@gmail.com> wrote:
>> Hi Vaclav,
>>
>> actually I'm a bit more extremist... :slight_smile:
>>
>> I would like to split GRASS in three main parts:
>> - grass-lib
>> - grass-cli
>> - grass-gui
>>
>
> I also like this idea...

I think this would be a very good idea as it would make the whole GRASS
ecosystem more transparent and easier (in my opinion) to maintain and to
use certain aspects from different applications.

Re functionality in the GUI:

The question would be if the split is

lib--cli--gui

or

   |--cli
lib|
   |--gui

in other words, if the cli is just a non graphical UI or THE interface
to the lib, through which the gui operates. I think the first design
approach would be the better one.

Cheers,

Rainer

>
>>
>> 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.).
>>
>
> I think that someone is already doing something like this.
> But I don't know more because I usually compile myself GRASS
>
>> Regards
>>
>> Pietro
>>

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

PGP: 0x0F52F982
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

15

Hi,

if you allow me a user comment on this:

> The user wants either grass-cli & grass-lib or grass-gui & grass-lib.

Actually, the combination of CLI and GUI is extremely handy in everyday work, which is why I regularly introduce students quite early to this combination. The possibility to copy the commands from GUI is here very helpful too. I missed having a CLI in parallel on Windows until it came with GRASS 7. Before I regularly started two grass sessions. First the GUI then the command line. It would be a pity if this perfectly matched team would be separated (in terms of user experience)…

Cheers

Stefan

16

Huidae Cho wrote:

I'm not talking about the current structure. Yes, the modules are the CLI
right now and the GUI calls the CLI modules internally. What I'm saying is
that it would great if we could separate the logic and CLI and put the
logic in plugins

We already do that, except that the plugins are called "modules", and
the calling mechanism is program execution.

All of GRASS' significant functionality is in the modules. The
libraries are just utilities which ensure some degree of consistency
and avoid the need for modules to continually re-invent the wheel.

Splitting every single module into an "interface" executable and a
"logic" library amounts to a complete re-write of GRASS. Feel free to
start your own fork, but don't expect everyone else to jump on board.

There's also the fact that, with a persistent application, any
segfault takes down the entire application, any memory leak persists
for the lifetime of the application, etc. So you can't just separate
the code, you also have to clean it up significantly.

Actually, even now, GRASS libs are called directly from GDAL for handling
raster/vector maps.

That is long overdue for change.

It has been problematic ever since the r.external functionality was
added. Because now the GRASS libraries call GDAL, so the GDAL-GRASS
bridge has to be a separate plugin to avoid a circular dependency.

And if we ever removed the support for the legacy versions of the
raster format from GRASS, GDAL would automatically stop supporting
them as well.

Now that we have r.external, the ideal solution would be to move the
actual raster I/O code into GDAL itself, and perform all raster access
via GDAL.

I would have done it myself, except that it ideally needs to be done
by two people to avoid "contaminating" GDAL with the GPL used by
GRASS. One person would document the raster file formats, while
another would write a clean implementation based upon the
documentation.

--
Glynn Clements <glynn@gclements.plus.com>