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@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@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@centrum.cz>:
> > maybe we should move the discussion to grass-gui list again...
> >
> > jachym
> >
> > 2007/2/1, Michael Barton <michael.barton@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@centrum.cz> wrote:
> > >
> > > > hi Michael, it is good, that you are back!
> > > >
> > > > 2007/2/1, Michael Barton <michael.barton@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@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@gmail.com> * http://gama.fsv.cvut.cz/~landa *