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

>>>>> "CY" == C Y <smustudent1@yahoo.com> writes:

    CY> --- 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. 

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

Keeping the same information in 2 places is always a problem,
basically.

    CY> The problem is (to take an example) what if, when the physconst package
    CY> is loaded and defines a bunch of new constants, the interface has a
    CY> constant menu with buttons for all defined constants and should be
    CY> updated to reflect the new additions?  Then also, if a user accidently

Loading the package can send info to the GUI to do stuff.

    CY> redefines one of these constants wouldn't it be nice to have the symbol
    CY> on that button change to read to reflect the change and alert the user?
    CY> Or what if a PDE package wants to change a dialouge or interface
    CY> component?  Either the package has to specifically tell the GUI about

The PDE package sends stuff to the GUI.  

But these have problems too because you have to describe in some
appropriate language that when I click on this button or select some
dialog box the appropriate information in the GUI gets translated to
the appropriate information in the kernel.  I think makes it somewhat
hard to design.

If the GUI and kernel were in one image, this would make it much
easier, because they then have complete knowledge of each other. :-)

    CY> changes, or the GUI can be aware of what is going on in the kernel as
    CY> well as allowing the package to directly define stuff.  Which policy do
    CY> we want to impliment?  Should the GUI be "dumb" and do nothing unless
    CY> the packages include code telling it what to do, or try and be smarter
    CY> to allow features that change dynamically based on the state of the
    CY> kernel without the kernel needing to specifically instruct the GUI to
    CY> do something?  I guess in either case we will need to define some kind

Unless the GUI is clairvoyant, the kernel has to tell the GUI, or the
GUI will eventually end up duplicating all knowledge of the kernel
state, including all things that modify the state.  This seems a
needless duplication.

Ray, who is still just talking