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

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