🚀 go-pugleaf

In article <47878@linus.UUCP> eachus@mbunix.mitre.org (Robert I. Eachus) writes:
>     The Workbench should consist of two main tasks, the fist of which
>interacts with the user, and the second, "the daemon" interacts with
>the disks.  A user request (double click) to open a disk would require
>the first task only to send a message to the daemon to open that
>window.  As the daemon retrieved .info files it would sent messages
>(not replies, the initial reply corresponds to request recieved) to
>the Workbench task containing the locations of the data.  (Who manages
>clean-up, etc. is an implementation detail, but I would put it in the
>daemon.)

   My replacement (sans INFO window as of now :-< ) consists of four tasks --
disk, window, input (user), and a server to tie all of these, and any other
programs that want to be attached into the system, together.

>...interface, of course) which would do nice things like open a disk (or
>some particular nested directory) on the workbench from the CLI or
>your startup, by sending requests to the daemon.  (The Workbench
>process won't get confused.)

Yep, I could do that with my program -- would be very simple, actually.  I've
already written things to:  place a pattern on the backdrop window, wrote
a calculator that takes input from whatever window (Workbench inclusive) you're
in, iconizes windows, rubber-bands open/close windows, puts audio samples
for beeps, and the list goes on...

>P. S.  I am cross-posting because this really belongs in .tech, so
>       please followup there only.
  Okay... :-)

>					Robert I. Eachus
>
>with STANDARD_DISCLAIMER;
>use  STANDARD_DISCLAIMER;
>function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

If I had any ideas, they'd be my own, but as it stands.... :-)


					David Navas