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

My suggestion is to look at the (large) macsyma front
end description which probably says what is done for
macsyma in enough detail to resolve some of these questions.
The author of the front end knew a lot about macsyma
and also user interface design.

I THINK, but am not sure, that there are a set of
parameters of concern to the front end. When they are
altered then their new values are communicated to the front
end. The front end does not know the values of all macsyma
variables.
  There are also issues of saving values (e.g. does user X
prefer output display to be in a particular color or size)
in some registry.
Of course the front end must also be able to communicate
"stop this computation"  "load a new kernel"  "start a new
workbook" "save the display to a file" etc etc.


   Anyone interested enough in this problem to write more
code should look at the documentation sooner rather than
later, on the off chance that Macsyma inc would change
its preferences on posting of their material.

RJF


C Y wrote:
> --- Raymond Toy <toy@rtp.ericsson.se> wrote:
> 
> 
>>Keeping the same information in 2 places is always a problem,
>>basically.
> 
> 
> Hard to sync them?
>  
> 
>>Loading the package can send info to the GUI to do stuff.
> 
> 
> Yes, but once it is loaded, are things then frozen?  Mightn't it be
> good if the UI were able to warn about definitions being changed, for
> example?
>  
> 
>>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.
> 
> 
> Writing it might be a little tricky, but most of the grunt work should
> be handled by the GUI in the first place and I wouldn't think the
> package defining a new dialouge or button would be terribly difficult,
> unless some really complicated things needed to happen on the UI end.  
>  
> 
>>If the GUI and kernel were in one image, this would make it much
>>easier, because they then have complete knowledge of each other. :-)
> 
> 
> I agree :-).  But the preference seems to be strongly in favor of two
> separate processes for GUI and kernel, and the lack of threads is a bit
> of a problem as far as the single lisp image idea goes.  So the
> question becomes how to best provide that complete knowledge when doing
> things in two processes.
> 
> 
>>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.
> 
> 
> But what it does do is in effect provide the same lisp environment for
> both the GUI and the kernel, which is the next best thing to them being
> in the same lisp process.  I suppose total duplication might not be
> terribly elegant, but it would be effective.  I can't imagine this
> would give modern hardware any trouble.  The duplication would in
> effect be the price of having two separate processes for GUI and
> kernel, which seems to be the popular way to go on the list.  So long
> as the GUI part has the information of the kernel without having to do
> the work of deriving it, that should (hopefully) be fairly CPU
> inexpensive.  
>  
> 
>>Ray, who is still just talking
> 
> 
> Saying interesting stuff though :-).  I think these are issues we are
> going to need to hash out before we have a proper idea of how to go
> about this, so I wouldn't say it is "just talking" - think of it as
> preliminary design discussions :-).  Of course, I'm probably the wrong
> one to be thinking about all this, but at least it is educational for
> me ;-).  One of the nice things about open source is we have the
> leasure to do things the "right way" as opposed to the quick way, if we
> are so inclined.
> 
> CY
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima