[GRASS5] 100% cpu mouse bug

[Glynn Clements]

Radim Blazek wrote:

> > Whilst I could probably figure out how to modify v.out.pov to behave a
> > bit more like v.out.ascii (i.e. dump out "raw" data), the main problem
> > is that, in order to avoid trashing users' data (which I'd really like
> > to avoid), you need to be sure to include /everything/ in the exported
> > data. Which essentially requires that you understand what you are
> > doing, rather than just dumping out whatever data you can find and
> > hoping that you haven't missed anything.
> 
> Now I understand, but I don't believe that would be a good solution.
> It is not problem to export everything you want (but v.in/out.ascii
> imports/exports everything).
> 
> The problem is that you need to reimplement big part of
> the vector library in TclTk. For example, if an end vertex of boundary is moved,
> the topology of neighbour areas have to be rebuild in order to redraw
> lboundaries with oppropriate symbology. Without topological symbology
> editing of topological format is nightmare. Similarly for centroids,
> nodes etc. You will also need to reimplement spatial index
> otherwise redraw of a bit larger file (zoomed in) will be terribly slow
> as well as selection of existing lines/vertices.

Right; I hadn't considered the issue of modifying portions of large
maps. That would probably be a killer.

> Why dont you want to use C API from TclTk?

Partly the effort involved in creating all of the bindings, but mostly
because it negates one of the main advantages to using Tcl/Tk, namely
the fact that you can modify the program without having to re-compile
anything (as well as eliminating compilation issues).

Also, the Tk canvas (or any similar "retained mode" graphics system)
isn't particularly well suited to editing data which is held in or
synchronised with some other system. It's designed for the case where
you let the canvas keep track of the data.

In retrospect, it would probably be better to just replace the use of
the GRASS display architecture in the existing v.digit with a
conventional GUI toolkit. I'm not sure which one; ideally something
which runs natively on MacOSX (by which, I mean "doesn't use X11"). 
AFAICT, that means either Qt or wxWidgets.

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