[GRASS-dev] Discussing new GUI toolkit: v.pydigit

[Jachym Cepicky]

Hallo,
On Wed, May 31, 2006 at 09:56:17PM +1200, Hamish wrote:
> > [...]
> 
> FWIW, I don't know any Python, but I could learn some. (Transferable
> skills are nice)
> 
it is easy to learn -> basics took me about a week

> 
> > v.pydigit should be graphical frontend to v.edit.
> ..
> > Known problems:
> >     * Data reading/writing: Currently, the data are read through
> >         v.out.ascii  and the output (new data storing) is made by
> >         v.edit
> > 
> >         Sollution: Swig? OGR?
> 
> what about "v.in.ascii format=standard" and v.patch?
> 
> for raster option use r.in.poly or "v.in.*/v.edit" + v.to.rast?

He? Do you mean, that v.pydigit could be used as r.digit?
> 
> 
> >     * Raster map display.
> >         Sollution: Swig? GDAL? r.out.png?
> 
> Same as gis.m? Use the PNG driver to make a PNG (smaller file) or PPM
> (faster) image. Zoom/pan by setting "soft" region changes with
> GRASS_REGION= enviro variable?? (then GUI must keep track)

Currently: GRASS region settings are not touched. The script reads them
(g.region -g) and stores to self.region dictionary
(Vpydigit/vdigitGui.py). Everytime, it is zoomed/paned, this variable is
changed.

I wanted to do it possible independent on the Xdriver - didn't we want
to get rid of it?

Personally I thing, that the Zoom->PPM->Display approach one of the
reasons is, why *some* people od not really like the new gis.m - it is
slow. But I can see, there is no better way yet (swig could do this job IMHO). 

I was thinking about not to produce one big raster file, but to perform
kind of tiling support - but maybe later. If there would be quadtree
support in GRASS-rasters, would this problem allready be solved(?).
> 
> see:  g.manual pngdriver
> 

I'll

> ??
> 
> 
> > Screenshots:
> >     http://les-ejk.cz/tmp/vpydigit1.png
> >     http://les-ejk.cz/tmp/vpydigit2.png
> 
> nice.
> 
> 
> other points:
> which of the toolkits has the best support for translation efforts?
> 
AFAIK Qt and Gtk both. wxWindows?

> We should try and keep things easy to use for people with Mac OSX on
> laptops (only one mouse button). Annoying, but in the end you get a
> simpler to use app for new users. IIRC, one of the main reasons the mac
> stayed with the one button setup is that it forces devels to work harder
> on their design which leads to better experience for the end user.
> 
I can see your point. How is it done? Really only by mouse or can you
use key strokes (Ctrl..) too?

Suggestion:
    mouseL 1 click - digitize
    mouseL dbl click - menu 
                        |-> End digitizing
                        |-> Delete last
                        |-> Delete all
                        |-> Snap to closesd node
                        if boundary -> snap to begin

   mouseR - end digitizing
   mouseM - Delete last

> Will development of the GUI on a Mac require a Fink install? (e.g. glade2)
What is Fink? 
> Will the toolkit create a "native" looking/acting application? (yes please)
> 
AFAIK now. Does it harm? Mac people: could you live with gui like this?

> Glade makes XML files from a GUI.. how does Python fit in?

Python takes the xml and generates the gui on-the-fly. You are only
writing the handlers.
> 
> 
> Hamish

Thank you for your feedback and help

Jachym
-- 
Jachym Cepicky
e-mail: jachym.cepicky at centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky at gdf-hannover.de
URL:    http://gdf-hannover.de
Tel.:   +49 511-39088507
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060531/30a87a4b/attachment.bin