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

Jachym_Cepicky1 · May 30, 2006, 11:58pm

Hallo,

concerning the discussion about new GUI, used toolkit, programing
language, etc., etc., etc. I started to write script, which could show
us the way/problems/advantages/disadvantages.

It is the python script, with GTK+ toolkit (PyGTK). The GUI is build by
Glade. It took me 3 days include pretty much learning of how the things
are done by glade/pygtk, to write such an gui. I would say, it is pretty
fast.

v.pydigit should be graphical frontend to v.edit. Currently implemented
functions:

    * Displaying points
    * Displaying lines
    * Digitizing new points
    * Digitizing new lines (snaping included)
    * Zoom/Pan menu while digitizing by clicking with right mouse button

    * Zoom In/Out, Pan
    * Deleting lines
    * Deleting points
    * ...

Not all function in the list are *really* working, because of currently
limitations of v.edit (e.g. removing selected features means only mark
them as removed, the vector file is not touched). But that is not the target.
Target was to try, how difficult would it be for someone like me, who has only
limited programing skills (I learn python since 3 months, pygtk sice 1)

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?

* Raster map display.
Sollution: Swig? GDAL? r.out.png?

Screenshots:
http://les-ejk.cz/tmp/vpydigit1.png
http://les-ejk.cz/tmp/vpydigit2.png

Tar.gz:
http://les-ejk.cz/programs/grass/v.pydigit-31.5.05-1.tgz

What do you thing about it?
Atleast for me, it is usefull experience for next work on g-ps.map

Good night! Looking forward to your comments.

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

cmbarton · May 31, 2006, 5:22am

Jachym and others,

These look very nice. I don't know anything about programming in Python, but
here is the impression I'm getting from the discussion. I'd like to bounce
this off others potentially interested in contributing to the GUI to see if
I'm misunderstanding.

The jury seems still out between the main contenders for a GUI: QT,
wxWidgets, and GTK.

However, it seems that quite a few researchers are familiar with Python to
some extent. With a few notable exceptions, many of the active contributors
to GRASS development are researchers who know some programming rather than
programmers. This means that there may be a reasonable large group of
potential contributors with some expertise in Python.

There are Python interfaces/wrappers (whatever the correct term is) to all 3
of the main GUI contender platorms. That is a GUI could be produced in
either using relevant Python toolkits. I assume that someone who knew the
'guts' of one of these GUI tool kits could also work on the GUI without
going through Python (correct?). Using Python will probably be slower than
using one of these GUI platforms directly/natively. But this may not matter
if the GUI sets on top of GRASS C modules, maintaining the current modular
architecture that nearly everyone responding appears to like.

So Python versions of QT, wxWidgets, or GTK seem like a promising way to go
in moving GRASS to a more sophisticated GUI platform while retaining a large
potential pool of contributors to building and maintaining a GUI.

Does this seem like a reasonable assessment?

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

From: Jachym Cepicky <jachym.cepicky@centrum.cz>
Date: Wed, 31 May 2006 01:58:52 +0200
To: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Discussing new GUI toolkit: v.pydigit

Hallo,

concerning the discussion about new GUI, used toolkit, programing
language, etc., etc., etc. I started to write script, which could show
us the way/problems/advantages/disadvantages.

It is the python script, with GTK+ toolkit (PyGTK). The GUI is build by
Glade. It took me 3 days include pretty much learning of how the things
are done by glade/pygtk, to write such an gui. I would say, it is pretty
fast.

v.pydigit should be graphical frontend to v.edit. Currently implemented
functions:

    * Displaying points
    * Displaying lines
    * Digitizing new points
    * Digitizing new lines (snaping included)
    * Zoom/Pan menu while digitizing by clicking with right mouse button

    * Zoom In/Out, Pan
    * Deleting lines
    * Deleting points
    * ...

Not all function in the list are *really* working, because of currently
limitations of v.edit (e.g. removing selected features means only mark
them as removed, the vector file is not touched). But that is not the target.
Target was to try, how difficult would it be for someone like me, who has only
limited programing skills (I learn python since 3 months, pygtk sice 1)

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?

    * Raster map display.
        Sollution: Swig? GDAL? r.out.png?

Screenshots:
    http://les-ejk.cz/tmp/vpydigit1.png
    http://les-ejk.cz/tmp/vpydigit2.png

Tar.gz:
    http://les-ejk.cz/programs/grass/v.pydigit-31.5.05-1.tgz

What do you thing about it?
Atleast for me, it is usefull experience for next work on g-ps.map

Good night! Looking forward to your comments.

Jachym

|-- Vdigit
| |-- __init__.py
| |-- etc
| | |-- grasslogo.png
| | |-- new.boundary.gif
| | |-- new.centroid.gif
| | |-- new.line.gif
| | |-- new.point.gif
| | |-- select.gif
| | |-- v.pydigit.glade
| | `-- v.pydigit.gladep
| `-- vdigitGui.py
`-- v.pydigit

--
Jachym Cepicky
e-mail: jachym.cepicky@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Trevor_Wiens2 · May 31, 2006, 5:37am

On Wed, 31 May 2006 01:58:52 +0200
Jachym Cepicky <jachym.cepicky@centrum.cz> wrote:

Hallo,

concerning the discussion about new GUI, used toolkit, programing
language, etc., etc., etc. I started to write script, which could show
us the way/problems/advantages/disadvantages.

It is the python script, with GTK+ toolkit (PyGTK). The GUI is build by
Glade. It took me 3 days include pretty much learning of how the things
are done by glade/pygtk, to write such an gui. I would say, it is pretty
fast.

This is pretty quick.

I downloaded and played with it a bit tonight and it seems good. In
notice that the active highlighting on object selection was not smooth;
nice idea, but perhaps not necessary. I really liked the undo feature.

Thanks for doing this, this is a valuable test and helps in the
thinking process.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

Trevor_Wiens2 · May 31, 2006, 5:48am

On Tue, 30 May 2006 22:22:35 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Jachym and others,

These look very nice. I don't know anything about programming in Python, but
here is the impression I'm getting from the discussion. I'd like to bounce
this off others potentially interested in contributing to the GUI to see if
I'm misunderstanding.

The jury seems still out between the main contenders for a GUI: QT,
wxWidgets, and GTK.

However, it seems that quite a few researchers are familiar with Python to
some extent. With a few notable exceptions, many of the active contributors
to GRASS development are researchers who know some programming rather than
programmers. This means that there may be a reasonable large group of
potential contributors with some expertise in Python.

There are Python interfaces/wrappers (whatever the correct term is) to all 3
of the main GUI contender platorms. That is a GUI could be produced in
either using relevant Python toolkits. I assume that someone who knew the
'guts' of one of these GUI tool kits could also work on the GUI without
going through Python (correct?). Using Python will probably be slower than
using one of these GUI platforms directly/natively. But this may not matter
if the GUI sets on top of GRASS C modules, maintaining the current modular
architecture that nearly everyone responding appears to like.

I think this is an important point. Once a toolkit is chosen and if
things are written in a modular fashion, we may find that that for
certain modules, more speed is needed than can be provided in a Python
module (like v.pydigit). In this case, the work in prototyping the
function in Python first is not wasted. The application could still be
made to appear visually consistent and behave consistently, so the end
user would be unaffected.

An example might be, if we set user key bindings for the cartographic
front end, it would be nice for those to be honoured by the digitizing
tool.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

Jachym_Cepicky1 · May 31, 2006, 6:59am

On Tue, May 30, 2006 at 11:37:26PM -0600, Trevor Wiens wrote:

On Wed, 31 May 2006 01:58:52 +0200
Jachym Cepicky <jachym.cepicky@centrum.cz> wrote:

> Hallo,
>
> concerning the discussion about new GUI, used toolkit, programing
> language, etc., etc., etc. I started to write script, which could show
> us the way/problems/advantages/disadvantages.
>
> It is the python script, with GTK+ toolkit (PyGTK). The GUI is build by
> Glade. It took me 3 days include pretty much learning of how the things
> are done by glade/pygtk, to write such an gui. I would say, it is pretty
> fast.
>

This is pretty quick.

I downloaded and played with it a bit tonight and it seems good. In
notice that the active highlighting on object selection was not smooth;
nice idea, but perhaps not necessary. I really liked the undo feature.

Thanks for doing this, this is a valuable test and helps in the
thinking process.

T
--
Trevor Wiens
twiens@interbaun.com

Undo? Oh yes. That was only the example of the content menu. Actualy,
the mouse-button funtions are

    L - digitize new
    doublL - end of line
    M - delete last (undo)
    R - menu

thanks for support

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Paulick_Consult · May 31, 2006, 8:15am

Am 31.05.2006, 07:22 Uhr, schrieb Michael Barton <michael.barton@asu.edu>:
...

However, it seems that quite a few researchers are familiar with Python to
some extent. With a few notable exceptions, many of the active contributors
to GRASS development are researchers who know some programming rather than
programmers. This means that there may be a reasonable large group of
potential contributors with some expertise in Python.

I've never met ever since a Tcl/Tk programmer in Industrial Automation

Yes, there are loads of python-programmers out in the fields.
And for the old fossils like me, python is plain and simple to learn
and it is pretty easy to understand the code. It's worth giving python a try.

Using Python will probably be slower than using one of theseGUI platforms directly/natively. But this may not matter
if the GUI sets on top of GRASS C modules, maintaining the current modular architecture that nearly everyone responding appears to like.

We use python for realtime image processing in test&measurement applications.
The visible bottlenecks are disk-I/O, serial- and usb-devices, not the GUI.

In Grass I would estimate that most of the raster module execution time is
eaten by reading and writing entire lines of the raster.
When working with a 9x9 grid of raster points, there are 9 rows of data to
be transfered from and back to the disk (right?).

And yes, the modular architekture suits very well to be "glued" by python.
Maybe there are some minor adaptions neccessary to unify the text- and message
passing, but this is to be cleaned up anyway.

Mit freundlichen Grüßen / With kindest regards

Stefan Paulick

http://www.urbeli.com
mailto://stefan.paulick@urbeli.com
/*----------------------*/

Jachym_Cepicky1 · May 31, 2006, 8:21am

Hallo,
just one note

On Wed, May 31, 2006 at 10:15:42AM +0200, Stefan Paulick wrote:

Am 31.05.2006, 07:22 Uhr, schrieb Michael Barton <michael.barton@asu.edu>:
...
In Grass I would estimate that most of the raster module execution time is
eaten by reading and writing entire lines of the raster.
When working with a 9x9 grid of raster points, there are 9 rows of data to
be transfered from and back to the disk (right?).

No, it means read 9 lines and than only 1 line will be stored, 1 loaded
and 8 pointers will change their target.

...
Stefan Paulick

How did you like the icons ?

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

H_B · May 31, 2006, 9:56am

concerning the discussion about new GUI, used toolkit, programing
language, etc., etc., etc. I started to write script, which could show
us the way/problems/advantages/disadvantages.

It is good to see these things.

It is the python script, with GTK+ toolkit (PyGTK). The GUI is build
by Glade. It took me 3 days include pretty much learning of how the
things are done by glade/pygtk, to write such an gui. I would say, it
is pretty fast.

FWIW, I don't know any Python, but I could learn some. (Transferable
skills are nice)

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?

* 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)

see: g.manual pngdriver

??

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?

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.

Will development of the GUI on a Mac require a Fink install? (e.g. glade2)
Will the toolkit create a "native" looking/acting application? (yes please)

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

Hamish

H_B · May 31, 2006, 10:58am

[Python]

Larger devel pool vs. C.
Whole classes bugs are removed vs. C.
It will never be as fast as C, but apparently it is fast enough?
(the GUI doesn't take much number crunching; backend is still C)
I'm for it. (in my ignorance...)

The jury seems still out between the main contenders for a GUI: QT,
wxWidgets, and GTK.

Will Qt/GTK+ act+look natively on Mac/Windows? [no?] I think this is
most important for Mac; Windows it would be nice but the interface is
more of a mash; and let linux people do whatever they want (total mash).
If I understand Glynn's comments, this points to wxW?

I'm not sure I have the order correct:
We program in Python, calling wxWidgets commands via wxPython bindings.
wxW would then use a) Native Mac; b) GTK+ on linux; or c) Native Windows
[GTK is not needed for Mac or Windows versions]

[*] Mac/windows users: how is "Audacity" for you? http://audacity.sf.net
I'd suggest WinGimp and MacGimp as a GTK test and Qgis as a Qt platform
test.

interesting:
"A wxGLCanvas package is available to allow wxWidgets applications
(currently GTK and Windows only) to support OpenGL. Very few changes
need to be made to existing OpenGL applications."

also http://wxglade.sourceforge.net

From WikiPedia:
WxWidgets is released under "a permissive modified (but explicitly
OSI-approved) LGPL".

Sounds no problem, but what does it mean?

Also from WikiPedia "It also has a built in ODBC based database library,
an Interprocess Communication layer, socket networking functionality,
and more."

Will the "Interprocess Communication layer" help our piping stderr &
return value woes? Can ODBC be used for DB tasks, such as v.digit
attribute editing?

The other big Toolkit requirement is how easily each of these will allow
for integration of translation efforts. I have no idea about this, but
it could help us decide if one is great/terrible at i18n.
Do we have to go through another Unicode debate?

Hamish

Jachym_Cepicky1 · May 31, 2006, 12:19pm

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@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Paulick_Consult · May 31, 2006, 12:21pm

Jachym Cepicky schrieb:

How did you like the icons ?

Wonderful!!! A icon in the morning will make my day!!! :-))

Anyway, we should try to get hold of some performance data to compare the influence of GUI in Grass applications vs. module execution speed. Just in case there are some hidden traps...

/Stefan

William_Kyngesburye · May 31, 2006, 2:26pm

On May 31, 2006, at 7:19 AM, Jachym Cepicky wrote:

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

I wonder - does it (python I assume you mean here) get button-click info from the system, or interpret mouse/trackpad directly? A feature of recent PowerBooks, and the new MacBook I'm lovin', is (if one uses the pad-tap feature) tapping with *two* fingers does a right-click. If Python sees it as left/right click, you wouldn't have to worry about trying to interpret meta-keys as well. Same goes for ctrl-click - it's a standard setup for the system to do a right-click - if Python sees this as right-click instead of ctrl-click, it wouldn't have to deal with having to have alternatives for extra buttons on a Mac. There's nothing for a middle-click, so we're only down to two buttons, not one.

There are also drivers available to do similar things for older PowerBooks.

Will development of the GUI on a Mac require a Fink install? (e.g. glade2)

What is Fink?

Fink is just *one* way to get Unix libraries and programs on Mac OS X. It's a package manager. Another is Darwinports. Personally I don't use either. Many don't. I would build my own dependencies needed or locate a binary distribution. Mac Python extensions have their own binary distribution repository anyways (though it's kinda lean right now, as the Universal Python 2.4.3 is so new, but wxPython is there).

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

Jachym_Cepicky1 · May 31, 2006, 3:55pm

On Wed, May 31, 2006 at 09:26:29AM -0500, William Kyngesburye wrote:

>
I wonder - does it (python I assume you mean here) get button-click
info from the system, or interpret mouse/trackpad directly? A
feature of recent PowerBooks, and the new MacBook I'm lovin', is (if
one uses the pad-tap feature) tapping with *two* fingers does a right-
click. If Python sees it as left/right click, you wouldn't have to
worry about trying to interpret meta-keys as well. Same goes for
ctrl-click - it's a standard setup for the system to do a right-click
- if Python sees this as right-click instead of ctrl-click, it
wouldn't have to deal with having to have alternatives for extra
buttons on a Mac. There's nothing for a middle-click, so we're only
down to two buttons, not one.

There are also drivers available to do similar things for older
PowerBooks.

I can get the info, what mouse button was clicked.

So how should be done? Does anyone know, how esri/topol has it? Is it
good?

>>Will development of the GUI on a Mac require a Fink install? (e.g.
>>glade2)
>What is Fink?

Fink is just *one* way to get Unix libraries and programs on Mac OS
X. It's a package manager. Another is Darwinports. Personally I
don't use either. Many don't. I would build my own dependencies
needed or locate a binary distribution. Mac Python extensions have
their own binary distribution repository anyways (though it's kinda
lean right now, as the Universal Python 2.4.3 is so new, but wxPython
is there).

Are you able to run v.pydigt ?

Thank you for feedback and infos
Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Glynn_Clements1 · May 31, 2006, 5:24pm

Jachym Cepicky wrote:

concerning the discussion about new GUI, used toolkit, programing
language, etc., etc., etc. I started to write script, which could show
us the way/problems/advantages/disadvantages.

It is the python script, with GTK+ toolkit (PyGTK). The GUI is build by
Glade. It took me 3 days include pretty much learning of how the things
are done by glade/pygtk, to write such an gui. I would say, it is pretty
fast.

v.pydigit should be graphical frontend to v.edit. Currently implemented
functions:

    * Displaying points
    * Displaying lines
    * Digitizing new points
    * Digitizing new lines (snaping included)
    * Zoom/Pan menu while digitizing by clicking with right mouse button

    * Zoom In/Out, Pan
    * Deleting lines
    * Deleting points
    * ...

Not all function in the list are *really* working, because of currently
limitations of v.edit (e.g. removing selected features means only mark
them as removed, the vector file is not touched). But that is not the target.
Target was to try, how difficult would it be for someone like me, who has only
limited programing skills (I learn python since 3 months, pygtk sice 1)

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

That's the hard part, and the solution will probably dictate the
fundamental structure of any v.digit replacement.

v.digit uses V_get_updated_line() etc to determine which parts need to
be redrawn. Redrawing from scratch by enumerating the entire visible
portion of the map may be feasible. Enumerating the entire map without
regard to the current region probably won't be.

AFAICT, the V_get_updated_line() approach would require v.edit to
output the information after each update, as the "updated" status
doesn't persist between processes (i.e. it's stored in the client, not
the database).

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

Glynn_Clements1 · May 31, 2006, 5:43pm

Stefan Paulick wrote:

In Grass I would estimate that most of the raster module execution time is
eaten by reading and writing entire lines of the raster.
When working with a 9x9 grid of raster points, there are 9 rows of data to
be transfered from and back to the disk (right?).

The use of line-oriented storage is an issue if you often work with
the current region set to a small portion of the map's overall width,
or if an algorithm scans the data along paths which are far from
horizontal.

If you process the data top-to-bottom, but need to access a number of
contiguous rows (e.g. convolution operations), you can either use the
rowio library to perform caching (as r.mapcalc does) or perform your
own caching (as r.grow does).

Similarly, use of a row cache (rowio or your own) will suffice for
scanning the data along near-horizontal paths (this would probably
suffice for r.proj in most cases; in most common projections, latitude
lines tend to be almost horizontal).

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

Jachym_Cepicky1 · May 31, 2006, 6:07pm

Hallo,

I created new site, where actual versions will be stored

http://les-ejk.cz/?cat=vpydigit

Currently version

http://les-ejk.cz/programs/grass/v.pydigit-06-05-31-1.tgz

BUGS:
* Some point data are not read

Chages:
* Should be *much* faster, than the previous version

Jachym

On Wed, May 31, 2006 at 01:58:52AM +0200, Jachym Cepicky wrote:

Hallo,

concerning the discussion about new GUI, used toolkit, programing
language, etc., etc., etc. I started to write script, which could show
us the way/problems/advantages/disadvantages.

It is the python script, with GTK+ toolkit (PyGTK). The GUI is build by
Glade. It took me 3 days include pretty much learning of how the things
are done by glade/pygtk, to write such an gui. I would say, it is pretty
fast.

v.pydigit should be graphical frontend to v.edit. Currently implemented
functions:

    * Displaying points
    * Displaying lines
    * Digitizing new points
    * Digitizing new lines (snaping included)
    * Zoom/Pan menu while digitizing by clicking with right mouse button

    * Zoom In/Out, Pan
    * Deleting lines
    * Deleting points
    * ...

Not all function in the list are *really* working, because of currently
limitations of v.edit (e.g. removing selected features means only mark
them as removed, the vector file is not touched). But that is not the target.
Target was to try, how difficult would it be for someone like me, who has only
limited programing skills (I learn python since 3 months, pygtk sice 1)

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?

    * Raster map display.
        Sollution: Swig? GDAL? r.out.png?

Screenshots:
    http://les-ejk.cz/tmp/vpydigit1.png
    http://les-ejk.cz/tmp/vpydigit2.png

Tar.gz:
    http://les-ejk.cz/programs/grass/v.pydigit-31.5.05-1.tgz

What do you thing about it?
Atleast for me, it is usefull experience for next work on g-ps.map

Good night! Looking forward to your comments.

Jachym

|-- Vdigit
| |-- __init__.py
| |-- etc
| | |-- grasslogo.png
| | |-- new.boundary.gif
| | |-- new.centroid.gif
| | |-- new.line.gif
| | |-- new.point.gif
| | |-- select.gif
| | |-- v.pydigit.glade
| | `-- v.pydigit.gladep
| `-- vdigitGui.py
`-- v.pydigit

--
Jachym Cepicky
e-mail: jachym.cepicky@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Jachym Cepicky
e-mail: jachym.cepicky@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@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

H_B · June 1, 2006, 5:04am

> 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?

sure, why not?

see the r.in.poly help page. The format is almost the same as v.in.ascii
format=standard. v.digit and r.digit may as well be put in the same app.

> 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 whole point of $GRASS_REGION and $WIND_OVERRIDE is that you don't
need to touch the region settings. The changes only exist in the current
processes and don't persist.

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?

the PNG[/PPM] driver is not dependant on the XDRIVER.

Hamish

H_B · June 1, 2006, 5:05am

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.

Zoom->PPM->Display does not have to mean Zoom->PPM->Disk->Display

Hamish

H_B · June 1, 2006, 5:10am

I wonder - does it (python I assume you mean here) get button-click
info from the system, or interpret mouse/trackpad directly? A
feature of recent PowerBooks, and the new MacBook I'm lovin', is (if
one uses the pad-tap feature) tapping with *two* fingers does a right-

click. If Python sees it as left/right click, you wouldn't have to
worry about trying to interpret meta-keys as well. Same goes for
ctrl-click - it's a standard setup for the system to do a right-click

- if Python sees this as right-click instead of ctrl-click, it
wouldn't have to deal with having to have alternatives for extra
buttons on a Mac. There's nothing for a middle-click, so we're only
down to two buttons, not one.

There are also drivers available to do similar things for older
PowerBooks.

AFAIR, ctrl-click and apple-click on the mac were translated to
middle/right click somewhere in the system before X11. (but it doesn't
always work right in some X applications)

Play with "xev" to test?

Hamish

William_Kyngesburye · June 1, 2006, 2:07pm

Ooh - xev tells me that the two-fingered right-click indeed does 'button 3' in X11. Another interesting thing: another two-fingered trick is scrolling, which seems to work also, giving buttons 4 & 5 in X11, the scroll-wheel I presume.

With the emulate 3 button mouse option on in X11, it's apple-click for right-click (and option for middle). These also show the correct button click in xev, but the apple/option keys precede that, which might confuse some X11 programs (not GRASS).

On Jun 1, 2006, at 12:10 AM, Hamish wrote:

I wonder - does it (python I assume you mean here) get button-click
info from the system, or interpret mouse/trackpad directly? A
feature of recent PowerBooks, and the new MacBook I'm lovin', is (if
one uses the pad-tap feature) tapping with *two* fingers does a right-

click. If Python sees it as left/right click, you wouldn't have to
worry about trying to interpret meta-keys as well. Same goes for
ctrl-click - it's a standard setup for the system to do a right-click

- if Python sees this as right-click instead of ctrl-click, it
wouldn't have to deal with having to have alternatives for extra
buttons on a Mac. There's nothing for a middle-click, so we're only
down to two buttons, not one.

There are also drivers available to do similar things for older
PowerBooks.

AFAIR, ctrl-click and apple-click on the mac were translated to
middle/right click somewhere in the system before X11. (but it doesn't
always work right in some X applications)

Play with "xev" to test?

Hamish

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy