[GRASS-dev] Re: Wxgrass status update

Thu Feb 1 15:52:34 EST 2007

Hi,

I am really *not* sure whether to re-open grass-gui mailing list or
not. Generally speaking, the less mailing list exist the better for
the users and developers. On the other hand this issue (i.e.
GRASS-GUI) is long-running in GRASS community and (maybe) should be
separated from grass-dev. I really don't know.

Regards, Martin

2007/2/1, Jáchym Čepický <jachym.cepicky at centrum.cz>:
> Hmm, one problem:
>
> http://grass.itc.it/community/support.php
>
> GRASSGUI belongs to the old and unused mailing lists.. shall we move
> the discussion to grass-dev?
>
>
> Jachym
>
> 2007/2/1, Martin Landa <landa.martin at gmail.com>:
> > Hi all,
> >
> > I also vote for moving this discussion to the grass-gui mailing list...
> >
> > Best regards, Martin
> >
> > 2007/2/1, Jáchym Čepický <jachym.cepicky at centrum.cz>:
> > > maybe we should move the discussion to grass-gui list again...
> > >
> > > jachym
> > >
> > > 2007/2/1, Michael Barton <michael.barton at asu.edu>:
> > > > Jachym,
> > > >
> > > > I did a quick glance and it looks like it will make working with display
> > > > layers much easier. Options panels can use these classes to define how
> > > > layers should be displayed.
> > > >
> > > > Somewhere we'll need to wrap this code into the integrated application. This
> > > > module is called render.py in my version--the one that I proposed renaming.
> > > > Maybe disputil.py would make more sense in the long run. I'm not sure yet
> > > > how much we should split up different functions into distinct smaller
> > > > modules and how much they should be expressed as classes in included in
> > > > larger modules.
> > > >
> > > > As we go along, we should keep trying to refactor like you've done here, and
> > > > produce clean code that will be easier to maintain in the future. I've
> > > > become acutely aware of this after untangling a lot of ancient TclTk
> > > > spaghetti code (some of it not so ancient and mine).
> > > >
> > > > I'm copying a couple of other people who've been working on the interface
> > > > and wx.Python recently so that they can have a link to this site and start
> > > > to get an idea of where we are at.
> > > >
> > > > Cheers
> > > > Michael
> > > >
> > > > I'm copying a couple other folks
> > > >
> > > > On 2/1/07 1:45 AM, "Jáchym Čepický" <jachym.cepicky at centrum.cz> wrote:
> > > >
> > > > > hi Michael, it is good, that you are back!
> > > > >
> > > > >
> > > > >
> > > > > 2007/2/1, Michael Barton <michael.barton at asu.edu>:
> > > > >>
> > > > >>  Jachym,
> > > > >>
> > > > >>  I'm actually working with wx.Python again. Thank goodness it is starting to
> > > > >> come back to me after a 5 month hiatus. I decided to just focus on the
> > > > >> mundane tasks of the layer manager. This is good practice for me and pretty
> > > > >> straightforward in many respects, though sufficiently challenging (ie.,
> > > > >> difficult) that progress remains slow--for me at least. And I've only got
> > > > >> bits and pieces of time to devote to this at the moment.
> > > > >>
> > > > >>  What I've got now is a wx.Choicebook with a page for each display opened.
> > > > >> On that page is a wx.Notebook with a layer tree (at least theoretically
> > > > >> since I'm still trying to make it work) notebook page and a command console
> > > > >> notebook page. Each layer (i.e., node in the tree) will need a way to
> > > > >> indicate the name of the map in the layer, some indication (e.g., an icon)
> > > > >> of whether it is raster or vector (or something else), a way to make the
> > > > >> layer active/inactive, and some way to call up a panel to set the display
> > > > >> options for the layer. It looks like wx.CustomTreeCtrl will work quite well
> > > > >> for this. Once I get that far, I'll put it up on the cvs so that anyone can
> > > > >> play with it. If you'd like to see where I'm at any time, just let me know
> > > > >> and I'll send you some files.
> > > > >>
> > > > >>  One other thing is that the render.py module has become a handy place to
> > > > >> stash a few methods to track open displays, related variables, and the like
> > > > >> so that they don't instantiate new displays or control panels when
> > > > >> called--along with other display rendering functions. If it continues to
> > > > >> serve in this way, do you think we should rename it to something like
> > > > >> mapfunct.py or multifunct.py???
> > > > >>
> > > > >>  Just wanted to bring you up to date. Hope your trip is going well.
> > > > >>
> > > > >>  Cheers
> > > > >>  Michael
> > > > >>  __________________________________________
> > > > >>  Michael Barton, Professor of Anthropology
> > > > >>  School of Human Evolution & Social Change
> > > > >>  Center for Social Dynamics & Complexity
> > > > >>  Arizona State University
> > > > >>
> > > > >>  phone: 480-965-6213
> > > > >>  fax: 480-965-7671
> > > > >>  www: http://www.public.asu.edu/~cmbarton
> > > > >>
> > > > >>
> > > > >
> > > > > I started to define new set of classes, which should be easy to use
> > > > > and more logical orderd.
> > > > >
> > > > > Please look at the
> > > > > https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_gra
> > > > > ssaddons_gui_
> > > > >
> > > > > you can test it with
> > > > >
> > > > > python mapimg.py
> > > > >
> > > > > and see the documentation with
> > > > >
> > > > > pydoc ./mapimg.py
> > > > >
> > > > > How to work with it, look at the end of mapimg.py
> > > > >
> > > > > Idea is, that each Map has defined set of layers (rasters, vectors,
> > > > > graphs, WMS, WCS, ...). This set of layers should be taken over by
> > > > > each Display.
> > > > >
> > > > > Let me know, if you like it
> > > > >
> > > > > I moved the work to grasssvn-addons repository, because this are all
> > > > > fresh ideas and the code is not mature yet. Ones we have basic working
> > > > > GUI, we shoul reorganize gui/wxpython directory. subversion anables us
> > > > > to rename the files and so on.
> > > > >
> > > > > I hope, you like it
> > > > >
> > > > > Jachym
> > > > >
> > > > > P.S. I Sent this e-mail in a copy to Martin Landa - second GUI developer.
> > > >
> > > > __________________________________________
> > > > Michael Barton, Professor of Anthropology
> > > > School of Human Evolution & Social Change
> > > > Center for Social Dynamics & Complexity
> > > > Arizona State University
> > > >
> > > > phone: 480-965-6213
> > > > fax: 480-965-7671
> > > > www: http://www.public.asu.edu/~cmbarton
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Jachym Cepicky
> > > e-mail: jachym.cepicky gmail com
> > > URL: http://les-ejk.cz
> > > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
> > >
> >
> >
> > --
> > Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
> >
>
>
> --
> Jachym Cepicky
> e-mail: jachym.cepicky gmail com
> URL: http://les-ejk.cz
> GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
>

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