[GRASS-dev] libgrass+grass-gui?

Hi all.
Would it be feasible to split grass into several branches:
- libgrass, with all CLI modules
- grass-py-gui
- grass-tk-gui
and release them separately? I guess this would make the release process easier, and integration
with other sw smoother.
Any major technical problem? I know there is some mixed code (nviz, imagery etc.), but this could go
into the gui package, leaving in the lib only the CLI stuff.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc

On Fri, Sep 25, 2009 at 8:47 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Hi all.
Would it be feasible to split grass into several branches:

(we are already overwhelmed with 3 branches to maintain:
grass-trunk, grass65, grass64)

- libgrass, with all CLI modules
- grass-py-gui
- grass-tk-gui
and release them separately? I guess this would make the release process easier, and integration
with other sw smoother.

I don't know, because...

Any major technical problem? I know there is some mixed code (nviz, imagery etc.), but this could go
into the gui package, leaving in the lib only the CLI stuff.

... you can configure GRASS to deactivate Tcl or WxPython.
I am doing so on my cluster installation which is CLI only.

In which sense does the py-gui or tk-gui break QGIS?

Markus

Markus Neteler ha scritto:

... you can configure GRASS to deactivate Tcl or WxPython.
I am doing so on my cluster installation which is CLI only.

In which sense does the py-gui or tk-gui break QGIS?

It does not, but splitting development in 3 branches would allow easier release of each. For
instance there is a critical bug in one of the GUIs, but CLI is not affected, then libgrass can be
released, and other apps (including QGIS) can rely on a stable release.
The basic idea is that CLI and GUI have different speed of development and diffwerent stability
issues and requirement, so when it is possible to allow different speed of release, this *seems* to
me a good option.
Thanks.
--
Paolo Cavallini: http://www.faunalia.it/pc

Paolo wrote:

It does not, but splitting development in 3 branches would
allow easier release of each.

I see where you are coming from, but to me it becomes a bit of
a "divided we fall" situation.

As the GUIs have developed in tandem we've added little library
and module functions along the way when some variable needed
to be exposed or some function deineractivated (if that word
makes sense). Development is not completely independent,
especially if you consder the mixed components like wxVdigit
and wxNviz.

For instance there is a critical bug in one of the GUIs,
but CLI is not affected, then libgrass can be released,

Currently we have pretty much a max of 2 people working on the
GUI at any one time. With the current release stalled primarily
due to GUI on Windows issues it forces me to at least look at
that code, even though I usually don't use either the GUIs or
Windows myself. If it were separate that incentive wouldn't be
there and the gui devels might get lonely and discouraged.

and other apps (including QGIS) can rely on a stable release.

? AFAIK they can and do rely on the releasebranch_6_4, which
should be stable enough not to be sensitive to this issue.

The basic idea is that CLI and GUI have different speed of
development and diffwerent stability issues and requirement,
so when it is possible to allow different speed of release,
this *seems* to me a good option.

I worry that with a multi-tier system the lesser developed
components would be further neglected by the other devels.

The GUI is not-scriptable so the UI parts of it can change
quite a bit within a stable release cycle without being limited
by the preserve-backwards compatibility rule.

regards,
Hamish

Hi Hamish.
Thanks for your thoughts. I think we agree more than it may seem.

Hamish ha scritto:

As the GUIs have developed in tandem we've added little library
and module functions along the way when some variable needed
to be exposed or some function deineractivated (if that word
makes sense). Development is not completely independent,
especially if you consder the mixed components like wxVdigit
and wxNviz.

I think modularity is the base of happiness: keeping things as separated as possible is good. As I
mentioned, anything dubious should go to the GUI.

Currently we have pretty much a max of 2 people working on the
GUI at any one time. With the current release stalled primarily
due to GUI on Windows issues it forces me to at least look at
that code, even though I usually don't use either the GUIs or
Windows myself. If it were separate that incentive wouldn't be
there and the gui devels might get lonely and discouraged.

I acknowledge this problem, but on the other hand I do not think it is very good to delay the
release of stable libs because of a problem in the GUI: why not releasing the libs now, and the GUI
as soon as it will be ready?

? AFAIK they can and do rely on the releasebranch_6_4, which
should be stable enough not to be sensitive to this issue.

This is not very good for packagers though.

I worry that with a multi-tier system the lesser developed
components would be further neglected by the other devels.

Yes, this is a risk, very much present in GRASS since ages (as we all know, there are still unported
tcltk menus, the nviz issue, etc.). However, delaying what many people see as the main strength of
GRASS, its analytical power (this is not meant to offend GUI devs, sorry) is a symmetrical risk.

The GUI is not-scriptable so the UI parts of it can change
quite a bit within a stable release cycle without being limited
by the preserve-backwards compatibility rule.

Yes, I think GUI can have a different release cycle for this, as I mentioned earlier.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc