[GRASS-dev] Re: [GRASS-user] Compiling grass 6.2.1: i.class error

[Glynn Clements]

Hamish wrote:

> > If a monolithic C application is required, you realistically need a UI
> > toolkit, and I'm not sure that any of the alternatives are a
> > significantly better choice than Motif (Athena also seems to be
> > treated as an "add-on" nowadays; you can't rely upon it being
> > installed along with the rest of X).
> > 
> > OTOH, GTK has the advantage of native Windows and MacOSX ports (I
> > don't know how stable the native MacOSX version is, but the Windows
> > version is perfectly usable).
> 
> Will SWIG hooks allow wxPy GUIs to be nearly as fast as C + toolkits?
> I don't see any point in adding a new, but different, 1-off GUI toolkit,
> as that is the main issue we are trying to undo.

If you need to write C code, you may as well skip Python and use
wxWidgets directly.

The main issue is how fast you can load and animate a sequence of PPM
files. I would assume that using wx.Bitmap.LoadFile and
wx.DC.DrawBitmap from Python wouldn't be noticably slower than using
the underlying wxWidgets methods from C++, so you probably wouldn't
need any C code.

> > > > I'm not sure what r.digit can do that GIMP + r.in.ppm can't.
> 
> IMPO r.digit needs a wxPy replacement of some flavour; the xterm version
> must die before GRASS 7.
> 
> Requiring GIMP + user understanding how to do multi-layer gimping &
> reimport is too much to ask IMO, so we'll eventually need something
> built in presenting a streamlined process. (e.g. gimp solution will lead
> to endless r.in.{tiff} unregistered re-imports into lat/lon locations +
> >90 error reports)
> 
> Due to the v.digit + v.to.rast solution I don't consider a r.digit
> replacement to be ultra-high priority, but I don't think it will be a
> huge hard task once someone gets started on it.

AFAICT, the main problem with v.digit + v.to.rast is that v.digit
doesn't have a tool for drawing circles.

> > > seamless georeferencing?
> > 
> > I'm not sure that's an issue; presumably, you are going to be drawing
> > over an existing map, in which case you can use "r.region rast=..." to
> > align the new map with the original.
> 
> at minimum it would take a mini-tutorial, as the solution is not
> obvious. (r.digit is obvious, even if it is awkward)

Right. But we could probably use that mini-tutorial anyhow. There will
always be tasks where a decent image editing program will be useful.

Also, it would probably be a good idea to ensure that all r.{in,out}.*
programs can {read,write} .tfw (or similar) files. This would
eliminate any issues with r.out.* + external editing + r.in.* and
georeferencing.

> > > not a PITA to use?
> >
> > I can't see how anything could be more of a PITA than something built
> > using terminal I/O and libraster.
> 
> user perspective, not devel perspective. (understanding that dev
> complexity usually trickles down into user pain)
> 
> Current r.digit may be odd, but the steps are presented in a straight
> forward order, and I don't recall ever answering a usage question about
> it.

Maybe because no-one uses it? More seriously, its limited capabilities
probably have a lot to do with it. For more complex tasks, the ability
to undo operations would probably be useful.

> > > Set cat + label for each new feature?
> > 
> > The category is just the colour number (obviously, you would use a
> > paletted image); you would have to set the labels separately, though.
> 
> see "PITA" above. also note that we'd have to make a new r.support GUI
> to edit the cats file, without an xterm.

We need a convenient way to edit categories in any case.

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