re: front & back end communication / was GUI ...

--- Raymond Toy <toy@rtp.ericsson.se> wrote:
> 
> I think emacs talks to gdb in a similar fashion.  gdb sends extra
> stuff that emacs uses, but doesn't display.
> 
> In any case, I think trying to maintain 2 sets of info is sure to go
> wrong. 

What problems do you forsee?  If both processes keep track of changes
and submit those to the other process, where would that go wrong?

> It would seem much better that, if the GUI needed some info,
> the GUI would just ASK maxima to give back the info, hiding any
> output from the user.  If the GUI changes something, then it sends
the
> appropriate command to the kernel.  At least this way, you can never
> get out of sync.

The problem is (to take an example) what if, when the physconst package
is loaded and defines a bunch of new constants, the interface has a
constant menu with buttons for all defined constants and should be
updated to reflect the new additions?  Then also, if a user accidently
redefines one of these constants wouldn't it be nice to have the symbol
on that button change to read to reflect the change and alert the user?
Or what if a PDE package wants to change a dialouge or interface
component?  Either the package has to specifically tell the GUI about
changes, or the GUI can be aware of what is going on in the kernel as
well as allowing the package to directly define stuff.  Which policy do
we want to impliment?  Should the GUI be "dumb" and do nothing unless
the packages include code telling it what to do, or try and be smarter
to allow features that change dynamically based on the state of the
kernel without the kernel needing to specifically instruct the GUI to
do something?  I guess in either case we will need to define some kind
of API for the GUI that packages could use.

CY

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com