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 t
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
On Fri, May 2, 2014 at 10:03 AM, Vaclav Petras wrote:
>
>
>
> On Fri, May 2, 2014 at 8:29 AM, 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
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
independ
On Fri, May 2, 2014 at 8:29 AM, 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.
>
> This of
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 an
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,
Luca Delucchi writes:
> On 18 April 2014 11:15, Pietro 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 a
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 bu
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
On 18 April 2014 11:15, Pietro 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...
>
> At least should be possible to build these parts separately, leaving
> the
Hi,
2014-04-18 11:15 GMT+02:00 Pietro :
> 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
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
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 GRA
1. Allow for the release stable versions of core GRASS without
having to wait for GUI fixes on different OS.
+1 for that !
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
on, http://csdc.asu.edu
>
>
>
>
> On Apr 16, 2014, at 5:22 AM, grass-dev-requ...@lists.osgeo.org
> <mailto:grass-dev-requ...@lists.osgeo.org> wrote:
>
>> *From: *Yann Chemin mailto:yche...@gmail.com>>
>> *Subject: **Re: [GRASS-dev] Who wan
>>
Subject: Re: [GRASS-dev] Who wants GUI and who does not and why
Date: April 16, 2014 at 5:20:59 AM MST
To: Vaclav Petras mailto:wenzesl...@gmail.com>>
Cc: GRASS developers list
mailto:grass-dev@lists.osgeo.org>>
Reply-To: mailto:yann.che...@gmail.com>>
Maybe some of the
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 wrote:
> Hi all,
>
> I believe, I was calling for this discussion
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 discuss
19 matches
Mail list logo
