[GRASS-dev] wxGUI: new packages layout

cmbarton · November 10, 2011, 6:36pm

I think this is a good idea. The only thing is that the proposed directory structure seems a bit over-complicated. To actually make a change, fix a bug, or add a new feature, it is necessary to alter code in several different modules because of the complex links across different python modules. From the point of view of navigating this to access different modules, perhaps the number of subdirectories could be reduced somewhat to make this easier.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 11, 2011, at 3:21 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Wed, 9 Nov 2011 19:19:21 +0100
From: S?ren Gebbert <soerengebbert@googlemail.com>
Subject: Re: [GRASS-dev] wxGUI: new packages layout
To: Martin Landa <landa.martin@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID:
<CAPHDReKK3t1SZOjOtZVuRuejwB8G1atVHdEU92FnT5DxEk5iiw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Martin,
this is a great idea!

+1 from me

Best regards
Soeren

2011/11/9 Martin Landa <landa.martin@gmail.com>:

Hi all,

currently all wxGUI modules are located within one package called
`gui_modules`. This was more or less sufficient in the early stage of
wxGUI development. As wxGUI code base was growing new modules has been
added. Some wxGUI components (eg. vdigit) are based on more modules
(vdigit.py, mapdip_vdigit.py, etc.).

As wxGUI code base is still growing and the new components are being
introduced (psmap, and now real i.class replacement) this structure is
becoming highly unsuitable and almost possible to manage.

At this stage I would like to propose more structured layout based on
several packages (core, gui_core, forms, lmgr or mapdisp) and non-core
sub-packages in `modules` package.

See

?? ?? ?? wxGUIDevelopment – GRASS GIS

Please feel free to comment this proposal, better sooner than later. I
would like to start moving to the new package layout during next week
(in trunk). Later after some testing to introduce changes to `devbr6`
otherwise backporting bug-fixes will become almost impossible
(nightmare for wxGUI developers).

Thanks for any comments! Martin

martinl · November 24, 2011, 2:15pm

Hi,

2011/11/10 Michael Barton <michael.barton@asu.edu>:

I think this is a good idea. The only thing is that the proposed directory structure seems a bit over-complicated. To actually make a change, fix a bug, or add a new feature, it is necessary to alter code in several different modules because of the complex links across different python modules. From the point of view of navigating this to access different modules, perhaps the number of subdirectories could be reduced somewhat to make this easier.

I have started wxGUI code reorganization [1] in r49347. It introduced
several new GUI packages

core:
`core` for core non-GUI classes (gcmd, debug, etc.)
`gui_core` for core GUI classes (goutput, prompt, menuform, etc)

main wxGUI components:
`lmgr` for Layer Manager
`mapdisp` for Map Display

other components:
    `vdigit` for Vector Digitizer
    `gcp` for Georectifier
    `nviz` for 3D view (wxNviz)
    `gmodeler` for Graphical Modeler
    `psmap` for Cartographic Composer

Please feel free to comment the new layout. It took almost one day to
reorganize classes to the new modules/packages. I am expecting some
bugs (mainly wrongly imported modules), I hope that code will be
stabilized within few days. Please note, that `make distclean` is
required.

Happy testing;-) Martin

[1] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment#ChangingGUImodulesdirectorylayout

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Markus_GRASS · November 24, 2011, 3:01pm

Martin Landa wrote:

Hi,

2011/11/10 Michael Barton <michael.barton@asu.edu>:

I think this is a good idea. The only thing is that the proposed directory structure seems a bit over-complicated. To actually make a change, fix a bug, or add a new feature, it is necessary to alter code in several different modules because of the complex links across different python modules. From the point of view of navigating this to access different modules, perhaps the number of subdirectories could be reduced somewhat to make this easier.

I have started wxGUI code reorganization [1] in r49347. It introduced
several new GUI packages

core:
`core` for core non-GUI classes (gcmd, debug, etc.)
`gui_core` for core GUI classes (goutput, prompt, menuform, etc)

main wxGUI components:
`lmgr` for Layer Manager
`mapdisp` for Map Display

other components:
`vdigit` for Vector Digitizer
`gcp` for Georectifier
`nviz` for 3D view (wxNviz)
`gmodeler` for Graphical Modeler
`psmap` for Cartographic Composer

Maybe this new layout serves as good motivation to change these other
components to separate sub-processes instead of import'ing them...

Markus M

Please feel free to comment the new layout. It took almost one day to
reorganize classes to the new modules/packages. I am expecting some
bugs (mainly wrongly imported modules), I hope that code will be
stabilized within few days. Please note, that `make distclean` is
required.

Happy testing;-) Martin

[1] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment#ChangingGUImodulesdirectorylayout

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

martinl · December 1, 2011, 12:18pm

Hi,

2011/11/24 Martin Landa <landa.martin@gmail.com>:

Please feel free to comment the new layout. It took almost one day to
reorganize classes to the new modules/packages. I am expecting some
bugs (mainly wrongly imported modules), I hope that code will be
stabilized within few days. Please note, that `make distclean` is
required.

I hope that the most of bugs related to wxGUI code reorganization
should be already fixed. Anyway any testing is highly welcomed, most
of bugs are very easy to fix, they just need to be discovered;-)

Currently we are in the complicated situation, GUI modules are
different in trunk and devbr6/relbr64. It causes that any backport
trunk -> devbr6/relbr64 is very time consuming task, in other words,
`svn merge` will not work. We hope that 6.4.2 will be released before
Christmas, so I would expect 6.4.3 to be out in May/July. GRASS 7
development goes slowly, personally I would be not surprised to see
6.4.4 released in the end of year 2012. From this perspective it's
unrealistic to keep two completely different wxGUI code bases. I think
that this period is perfect for GUI modules reorganization also in
devbr6/relbr64. I would suggest the roadmap below:

1) within next days reorganize wxGUI modules in devbr6 based on the
layout from trunk
2) stabilize wxGUI in devb6 within one-two weeks
3) *after* releasing 6.4.2 backport new layout also to relbr64

The result will be the same GUI package layout in all active branches,
this condition is very important for wxGUI backports for 6.4.3
release.

What do you think? Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

marisn · December 2, 2011, 6:35am

Unfortunately not all bugs are fixed. Tested with trunk r49481

Start v.clean from menu:
Traceback (most recent call last):
File "/home/maris/soft/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/wxgui.py", line 1144, in
OnVectorCleaning

win = VectorCleaningFrame(parent = self, cmd = cmd[0])
File "/home/maris/soft/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/modules/vclean.py", line 37, in
__init__

wx.Frame.__init__(self, parent, id, title, pos, size, style)
NameError
:
global name 'pos' is not defined

g.remove doesn't start GUI from CLI but works from wxgui. Nothing with
WX_/DEBUG=5, exit code 0.

Maris.

2011/12/1 Martin Landa <landa.martin@gmail.com>:

Hi,
I hope that the most of bugs related to wxGUI code reorganization
should be already fixed. Anyway any testing is highly welcomed, most
of bugs are very easy to fix, they just need to be discovered;-)

martinl · December 2, 2011, 12:07pm

Hi,

2011/12/2 Maris Nartiss <maris.gis@gmail.com>:

Unfortunately not all bugs are fixed. Tested with trunk r49481

nobody claimed that "all bugs are fixed". True is that it will be never true;-)

Start v.clean from menu:
Traceback (most recent call last):
File "/home/maris/soft/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/wxgui.py", line 1144, in
OnVectorCleaning

win = VectorCleaningFrame(parent = self, cmd = cmd[0])
File "/home/maris/soft/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/modules/vclean.py", line 37, in
__init__

wx.Frame.__init__(self, parent, id, title, pos, size, style)
NameError
:
global name 'pos' is not defined

not really related to the code reorganization, hopefully fixed in
r49487. Thanks for testing.

[...]

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · December 2, 2011, 12:08pm

Hi,

2011/12/2 Maris Nartiss <maris.gis@gmail.com>:

g.remove doesn't start GUI from CLI but works from wxgui. Nothing with
WX_/DEBUG=5, exit code 0.

do you mean launch `g.remove` from wxGUI prompt without arguments? It
works for me.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

marisn · December 2, 2011, 12:28pm

No. Pure CLI (Konsole). Modules, that fail to start, g.copy, g.rename,
g.remove, g.region (others too?). g.mapset, g.filename work fine. Had
no time to test all modules. r.* v.* and d.* modules seem to work just
fine.

When launching from menu or wxgui command prompt, all modules start just fine.

Maris.

2011/12/2 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/12/2 Maris Nartiss <maris.gis@gmail.com>:

g.remove doesn't start GUI from CLI but works from wxgui. Nothing with
WX_/DEBUG=5, exit code 0.

do you mean launch `g.remove` from wxGUI prompt without arguments? It
works for me.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · December 2, 2011, 12:37pm

Hi,

2011/12/2 Maris Nartiss <maris.gis@gmail.com>:

No. Pure CLI (Konsole). Modules, that fail to start, g.copy, g.rename,
g.remove, g.region (others too?). g.mapset, g.filename work fine. Had
no time to test all modules. r.* v.* and d.* modules seem to work just
fine.

they don't fail to start, the modules which has no required options
(such g.remove) just do nothing. This is a feature of the parser in
GRASS 7, this behaviour seems to be quite confusing for the user.

To force GUI dialog run

g.remove --ui

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Glynn_Clements1 · December 2, 2011, 1:52pm

Martin Landa wrote:

> No. Pure CLI (Konsole). Modules, that fail to start, g.copy, g.rename,
> g.remove, g.region (others too?). g.mapset, g.filename work fine. Had
> no time to test all modules. r.* v.* and d.* modules seem to work just
> fine.

they don't fail to start, the modules which has no required options
(such g.remove) just do nothing. This is a feature of the parser in
GRASS 7, this behaviour seems to be quite confusing for the user.

To force GUI dialog run

g.remove --ui

Originally, G_parser() generated the UI if a module was run with no
arguments. Individual modules had to explicitly skip the G_parser()
call if they could meaningfully be run without arguments.

However, skipping G_parser() altogether has side-effects which were
frequently overlooked, e.g. setting the program name from argv[0],
parsing opt->options into opt->opts, parsing opt->descriptions into
opt->descs, etc.

Consequently, a decision was made to always call G_parser(), and to
only generate a UI when no arguments are given and at least one option
is required (to do otherwise would be a nuisance for modules which can
be and often are run without options).

This falls down in the case where at least one option is required, but
not any particular option. Modules can (and should) generate an error
in this case, but currently there's no way to instruct the parser to
produce a GUI.

Well, there's no "proper" way to do this, although it would be
possible to "hack" the argc and argv which are passed to G_parser(),
e.g.:

  if (argc < 2) {
      static char *args[3];
      args[0] = argv[0];
      args[1] = "--ui";
      args[2] = NULL;
      argv = args;
      argc = 2;
  }
  if (G_parser(argc, argv))
      exit(EXIT_FAILURE);

But really we need to come up with a long-term solution to the
situation where a module has requirements beyond the simplest case of
individual options being required. A solution should ideally handle
the "at least one of" case, as well as mutual exclusion and
dependencies (if A is given, B must also be given). It should also be
able to generate meaningful error messages (i.e. not just "that
combination of options is invalid").

--
Glynn Clements <glynn@gclements.plus.com>

neteler · December 2, 2011, 7:42pm

On Thu, Dec 1, 2011 at 1:18 PM, Martin Landa <landa.martin@gmail.com> wrote:
...

I hope that the most of bugs related to wxGUI code reorganization
should be already fixed. Anyway any testing is highly welcomed, most
of bugs are very easy to fix, they just need to be discovered;-)

Currently we are in the complicated situation, GUI modules are
different in trunk and devbr6/relbr64. It causes that any backport
trunk -> devbr6/relbr64 is very time consuming task, in other words,
`svn merge` will not work.

yes

We hope that 6.4.2 will be released before Christmas,

yes, that should happen very soon.

so I would expect 6.4.3 to be out in May/July. GRASS 7
development goes slowly, personally I would be not surprised to see
6.4.4 released in the end of year 2012.

Personally I am interested to switch to GRASS 7 now since
6.4 is fine enough for the "market".

From this perspective it's
unrealistic to keep two completely different wxGUI code bases.

I agree - Luca and me tried to backport something yesterday,
a real hard "grep" task...

I think
that this period is perfect for GUI modules reorganization also in
devbr6/relbr64. I would suggest the roadmap below:

1) within next days reorganize wxGUI modules in devbr6 based on the
layout from trunk

You mean: shuffle files around but not new code from GRASS 7?
that could be fine.

2) stabilize wxGUI in devb6 within one-two weeks

I guess it will be a bit more effectively...

3) *after* releasing 6.4.2 backport new layout also to relbr64

Question: how much to 6.4 and 6.5 differ *now*?

The result will be the same GUI package layout in all active branches,

This I would definitely support.

this condition is very important for wxGUI backports for 6.4.3
release.

Markus

annakrat · December 2, 2011, 9:18pm

Hi all,

I would like to praise Martin for this new layout, it is intuitive and
I think everyone will get used to it quickly.

Thanks,
Anna

martinl · December 3, 2011, 12:09pm

Hi Markus,

2011/12/2 Markus Neteler <neteler@osgeo.org>:

[...]

I think
that this period is perfect for GUI modules reorganization also in
devbr6/relbr64. I would suggest the roadmap below:

1) within next days reorganize wxGUI modules in devbr6 based on the
layout from trunk

You mean: shuffle files around but not new code from GRASS 7?
that could be fine.

Exactly.

2) stabilize wxGUI in devb6 within one-two weeks

I guess it will be a bit more effectively...

3) *after* releasing 6.4.2 backport new layout also to relbr64

Question: how much to 6.4 and 6.5 differ *now*?

Differs a bit. Anyway there is a plan to backport wxGUI after
releasing 6.4.2 from `devbr6` to `relbr64`. This model is working
since 6.4.0. The wxGUI has been backported immediately after release,
first two months kept in sync with `devbr6` and next four months
backports limited only to bug-fixes - assuming half of year period for
new release. It keeps wxGUI up-to-date and stable for release.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · December 4, 2011, 8:40pm

Hi,

2011/12/2 Markus Neteler <neteler@osgeo.org>:

The result will be the same GUI package layout in all active branches,

This I would definitely support.

if no objections I will start wxGUI code reorganization in `devbr6` on
Tuesday (6/12).

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · December 8, 2011, 1:21pm

Hi all,

2011/12/4 Martin Landa <landa.martin@gmail.com>:

2011/12/2 Markus Neteler <neteler@osgeo.org>:

The result will be the same GUI package layout in all active branches,

This I would definitely support.

if no objections I will start wxGUI code reorganization in `devbr6` on
Tuesday (6/12).

I started reorganization of wxGUI modules in r49621 (note that `make
distclean` is required). I hope to stabilize GUI in `devbr6` with few
next days. I would like to kindly ask you for testing the GUI a
reporting all errors you receive (ML is enough in this case).

Thanks, Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa