<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">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>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><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>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> </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>I still don't understand what do you mean by grass-plugins.</div><div><br></div><div>Vaclav</div><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 class=""><div class="h5"><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">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><br></div></div>