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@gclements.plus.com>