(no subject)

jont@hsa.com.au writes:
>My system was this:
>
> +------+<->+----------------+ +---------------+
> |window|<->|appl 1 front end|<---------->| application 1 |
> |system|<->+----------------+ protocol 1 +---------------+
> | |<->
> +------+<->+----------------+ +---------------+
> MADO |appl n front end|<---------->| application n |
> +----------------+ protocol n +---------------+

OK. Given the architecture I defined, this would be possible (and
perhaps a good idea. You could provide menus etc. to text based
programs).

Basile STARYNKEVITCH <basile@soleil.serma.cea.fr>:
Thank you *very* much for the article. I should note that if I do add
an interpreter to MADO et al. it will probably be scheme (in fact, I'd
probably use a hacked version of siod in the beginning), because 1)
I'd prefer a language I can understand/debug easily, and 2)

>Ouch. If the performance of ghostscript overall is any indicator of the
>performance of its postscript engine, then I can guarantee you that *I*
>will stick with the cons server!

Exactly. Ghostscript is painfully slow, and requires a lot of memory.

>A generalized interpreter might be overkill. I definitely *do* like the
>idea of having a base set of "widgets" on the server, common to all
>applications. Frankly, if you give me windows, pull-down menus,
>mouse, keyboard, and perhaps a pop-up or two then I think I can do
>all the window programming needed. The continuity it would provide
>across applications seems to me a feature, not a bug.

I tend to agree, as far as GUI's are concerned. In fact, I would
probably use Basile's idea, and write them in C, in the server.
However, for graphics (which, I do little of, but...), I think it
could be very advantageous to be able to download a function to
generate a lot of the drawing, than to do the drawing directly.

I'll ponder this some more. From the looks of it, most people seem to
think that:

  1) Basic rectangular windows will suffice (and I never planned it
     any other way).
  2) A basic widget set built into the window server would be a win.
  3) A programmable server seems desirable.

BTW. The notion of using display postscript, and thereby gaining the
ability to send stuff to the printer seems to be to be a nice feature,
but not too important. People display stuff on a screen far more often
than they do on a printer. Provided that either a) the application, or
b) the window system can generate postscript on request, I don't see a
problem. (Actually, I'd tend to offload this onto the application).
Received on Wed Oct 20 16:48:36 1993