Radim Blazek wrote:
> A monolithic application would be much more usable, but also more
> limited (and potentially much more fragile). So, we're basically
> looking for a UI with plug-ins. However, that's easier said than done;
> designing a decent interface for interactive modules is *much* harder
> than for "fire-and-forget" commands.
> The last thing that anyone should be doing in that area is coding.
> That's how we got into this mess in the first place; too much of
> GRASS' code was written without any consideration as to how it fits
> into the whole.
But without coding we will never move forward. For years, reading
grass mailing list, I can see from time to time long discussions
about GUI for grass. Problem is that nobody started coding.
> A large part of the problem is that this isn't just a matter of
> getting enough manpower. The problem is that the result needs to be
> suitable for the purposes to which it will be put, and that requires
> input from the people who are likely to make use of it.
> And that takes time; the design will likely need to go through many
> iterations of putting ideas on the table, getting feedback and
> refining the ideas.
Do you believe we can go through this without coding? Are user here GRASS
users or programmers of UI plugins?
Regarding both of the above: coding only moves us forward if the end
result is actually usable. There isn't much difference between writing
code then discarding it and not writing it in the first place.
Coding is a necessary condition, but not a sufficient one. We need
code that is useful, not just any code.
> In the meantime, we are likely to be stuck with a situation where
> highly interactive tasks (e.g. digitising) require dedicated
> applications. Given that, I'm asking that people (in this instance,
> Radim) choose a better UI framework than R_get_location_with_*().
OK, what is that better framework? And, I cannot call some theoretical
framework functions. Currently nothing better than R_get_location_with_*
exists in GRASS, until somebody can give me something I have to use it.
GRASS doesn't include a database engine, but that hasn't prevented the
database modules from being written. Solution: use additional
components (in the database case, PostgreSQL or ODBC).
We already have some UI code: tcltkgrass, NVIZ and d.dm use Tcl/Tk;
xganim uses Motif. If the Windows port of GTK+ is sufficiently
advanced to run the GIMP, it's likely to suffice for anything that
GRASS might be needing to do; e.g. v.digit.
But BTW, I don't think that most of code in v.digit will be related to UI.
If I want to break a line for example, I need to get one point from UI, but
then I have to rewrite lines, update topology status (not topology) of lines
and appropriately display. That is much more code and that is what I am
working on. I added GUI just because old text based interface is terribly
uneffective even for debugging.
BTW2, I need v.digit because it will be the best way to test/debug
level2 update in vector library. New GUI for GRASS (or v.digit) is not my
primal aim. That I left for others.
The problem is that yet-another-hack was added to the monitor API.
R_get_location_with_* aren't suitable for anything beyond the most
trivial of uses, and are out of place in what's basically an output
API. IMHO, they should be removed, not expanded.
Adding a motion callback sounds suspiciously like a move in the
direction of the event/callback model which is the norm for all modern
UI toolkits. In which case, why not use such a toolkit instead of
turning XDRIVER into an X server and libraster into Xlib? Because
that's basically what lies at the end of the slippery slope on which
these changes are a start.
--
Glynn Clements <glynn.clements@virgin.net>
