<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 10:03 AM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Fri, May 2, 2014 at 8:29 AM, Huidae Cho <span dir="ltr"><<a href="mailto:grass4u@gmail.com" target="_blank">grass4u@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div>
<br></div></div></blockquote></div><div>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.<br>
</div></div></div></div></blockquote><div><br></div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div>
<div>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.</div>
<div><br></div></div></blockquote></div><div>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.</div>
<div><br></div><div>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.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>grass-lib <-> grass-plugins <-> grass-cli, grass-gui, other GISs: Full analysis/modeling suite</div>
<div><br></div></div></blockquote></div><div>I still don't understand what do you mean by grass-plugins.</div></div></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Huidae</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<span class="HOEnZb"><font color="#888888"><div><br></div><div>Vaclav</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div></div><div>grass-lib <-> other GISs: Simple GIS data manipulation very common in all fields.</div>
<div><br></div><div>Regards,</div><div>Huidae</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug <span dir="ltr"><<a href="mailto:Rainer@krugs.de" target="_blank">Rainer@krugs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Luca Delucchi <<a href="mailto:lucadeluge@gmail.com" target="_blank">lucadeluge@gmail.com</a>> writes:<br>
<br>
> On 18 April 2014 11:15, Pietro <<a href="mailto:peter.zamb@gmail.com" target="_blank">peter.zamb@gmail.com</a>> wrote:<br>
>> Hi Vaclav,<br>
>><br>
>> actually I'm a bit more extremist... :-)<br>
>><br>
>> I would like to split GRASS in three main parts:<br>
>> - grass-lib<br>
>> - grass-cli<br>
>> - grass-gui<br>
>><br>
><br>
> I also like this idea...<br>
<br>
</div>I think this would be a very good idea as it would make the whole GRASS<br>
ecosystem more transparent and easier (in my opinion) to maintain and to<br>
use certain aspects from different applications.<br>
<br>
Re functionality in the GUI:<br>
<br>
The question would be if the split is<br>
<br>
lib--cli--gui<br>
<br>
or<br>
<br>
|--cli<br>
lib|<br>
|--gui<br>
<br>
in other words, if the cli is just a non graphical UI or THE interface<br>
to the lib, through which the gui operates. I think the first design<br>
approach would be the better one.<br>
<br>
Cheers,<br>
<br>
Rainer<br>
<div><br>
><br>
>><br>
>> At least should be possible to build these parts separately, leaving<br>
>> the decision to split in several packages to the package maintainer of<br>
>> each distribution (Debian, Fedora, etc.).<br>
>><br>
><br>
> I think that someone is already doing something like this.<br>
> But I don't know more because I usually compile myself GRASS<br>
><br>
>> Regards<br>
>><br>
>> Pietro<br>
>><br>
<br>
--<br>
</div>Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)<br>
<br>
Centre of Excellence for Invasion Biology<br>
Stellenbosch University<br>
South Africa<br>
<br>
Tel : <a href="tel:%2B33%20-%20%280%299%2053%2010%2027%2044" value="+33953102744" target="_blank">+33 - (0)9 53 10 27 44</a><br>
Cell: <a href="tel:%2B33%20-%20%280%296%2085%2062%2059%2098" value="+33685625998" target="_blank">+33 - (0)6 85 62 59 98</a><br>
Fax : <a href="tel:%2B33%20-%20%280%299%2058%2010%2027%2044" value="+33958102744" target="_blank">+33 - (0)9 58 10 27 44</a><br>
<br>
Fax (D): <a href="tel:%2B49%20-%20%280%293%2021%2021%2025%2022%2044" value="+4932121252244" target="_blank">+49 - (0)3 21 21 25 22 44</a><br>
<br>
email: <a href="mailto:Rainer@krugs.de" target="_blank">Rainer@krugs.de</a><br>
<br>
Skype: RMkrug<br>
<br>
PGP: 0x0F52F982<br>
<div><div>_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>