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

[Huidae Cho]

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

>
>
>
> On Fri, May 2, 2014 at 8:29 AM, Huidae Cho <grass4u at 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 at krugs.de> wrote:
>>
>>> Luca Delucchi <lucadeluge at gmail.com> writes:
>>>
>>> > On 18 April 2014 11:15, 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
>>> >>
>>> >
>>> > 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 at krugs.de
>>>
>>> Skype:      RMkrug
>>>
>>> PGP: 0x0F52F982
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
>> _______________________________________________
>> 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/20140502/7b48f556/attachment-0001.html>