Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!bloom-beacon!dawn.crd.ge.COM!stpeters
From: stpeters@dawn.crd.ge.COM (Dick St.Peters)
Newsgroups: comp.windows.x
Subject: Re: XView Notifier
Message-ID: <8909211441.AA05440@dawn.crd.Ge.Com>
Date: 21 Sep 89 14:41:20 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 28

mcsun!cernvax!ethz!marti@uunet.uu.net  (Robert Marti) writes:
> SunView programs use the so-called Notifier which wants to be informed
> about all sorts of events besides the window-related ones, eg., signals,
> file descriptors ready for reading, and so on.  As a result, there is
> an entire section of dos and donts for SunView programs in the SunView
> Programmer's Guide.  This state of affairs is annoying when you want to
> build a nice user-interface on top of someone elses code and that code
> just happens to violate some of the rules imposed by the presence of
> the Notifier.

The original release of SunView several years ago did specify a large
number of donts.  However, over the years SunView has evolved, and
most of the donts have disappeared.  For example, you can now do
select()'s on your descriptors while the Notifier does select()'s on
its descriptors.  They've also provided a specific hook for attaching
a SunView interface to existing code.

These improvements are part of XView.  Having logically simultaneous
select()'s is almost certainly why XView has its own select() and uses
syscall(), as someone recently complained about.

These newer SunView features also make things like journalling easy -
I have a journalling shelltool written in SunView.  As soon as I have
a good excuse, I plan to convert it to XView.

--
Dick St.Peters, GE Corporate R&D, Schenectady, NY
stpeters@dawn.crd.ge.com	uunet!dawn.crd.ge.com!stpeters