[GRASS5] Platform for next generation UI

[Glynn Clements]

Trevor Wiens wrote:

> > > That is why it will be important to have support from the broader community
> > > and not just a 'UI development team'.
> > > 
> > > Is there anything that I and/or others (e.g., another person offered TclTk
> > > help) could do with TclTk (since we are already invested in it) to take some
> > > of the interim steps you mention while a more complete system is under
> > > development? I'm fooling around with vtcl and it seems to be not crashing
> > > now.
> > 
> > There's one specific task which springs to mind.
> > 
> > Here is a list of modules using the R_get_location_with_* functions:

[snip]

> > Figure out if any of them can be replaced or have the calls removed. 
> > Modules which are inherently interactive need to be replaced; cases
> > such as d.legend can simply have the "use mouse" feature removed
> > (ultimately, the GUI will handle placement and pass the position via
> > the at= option).
> > 
> > The existence of those functions is a major obstacle to re-working the
> > display libraries, because they need to handle not only display, but
> > also mouse input.

[snip]

> Based on these comments and others in Glynn's reply to my query there
> is a lot of interim work to do. This approach seems reasonable as it
> moves things forward in a way we are assured of some result. I don't
> know tcl/tk but am willing to learn and help or simply work on updating
> documentation as things change if that would be more efficient. I'm
> also willing to look through some of the modules and work with others
> to set up alternative code based on compilation options or a runtime
> setting to adjust module behaviour to operate in the current situation
> or the planned one.

Removing gratuitous mouse usage (e.g. "d.legend -m") only requires
knowledge of C.

That should probably wait at least until it's viable to offer similar
functionality through d.m, but doesn't really need to wait until the
feature is actually implemented. Loss of that feature isn't critical,
and provides an incentive for anyone who wants it to add it to d.m.

> Perhaps others who have offered to help using specific tool kits Bob
> with GTK and Christian with Qt can still work on conceptual issues such
> as CLI/GUI interaction without committing us to any new toolkit yet,
> but simply laying groundwork for a new GUI?

CLI/GUI interaction issues are quite simple.

Command-line modules behave like typical Unix commands; you provide
them with command-line arguments, and they run to completion without
prompting or attempting to query the mouse.

The GUI uses a module like it would use a high-level function: i.e. it
runs the modules with arguments obtained from user input or its
internal state.

> It is important to note however that improving the current Tcl/tk gui
> increases our chances that we will not bother changing toolkits.

If it's good enough, there may not be a need to change toolkits. Even
if we run into limitations with Tcl/Tk (and I expect that we will),
re-implementing an existing application is a lot easier than building
one from scratch, as the design issues have already been sorted out.

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