nanogui: pk-0.9.1
Subject:
Re: pk-0.9.1
From:
"Frank W. Miller" ####@####.####
Date:
8 Oct 1999 17:49:13 -0000
Message-Id: <199910081733.NAA04425@macalpine.cornfed.com>
pk has no explicit device model. printf and getchar are implemented as
system calls under the assumption that there is a single screen. This will
be problematic first off. There needs to be a way to tie a window to
a thread for its stdio. Need to think about this one a bit.
> interfacing. The screen entry points handle open/close as well as read/write pixel
> and drawhline and drawvline.
The screen driver can be handled easily. I even had someone donate a
drawvline routine for the driver today too so I can add that one to the
next release.
> The keyboard drivers use /dev/tty for Linux, and bios for DOS. The
> hardware serial mouse driver currently runs on top of the OS serial port
> mechanism, and supports MS, Logitech, and PC mice.
>
Keyboard driver probably needs to be expanded. It only handles shift right
now, no ctrl or alt or multiple combinations.
> The mid level engine requires a select() like mechanism for UNIX
> like systems, and works by waiting for an event from the mouse or keyboard
> file descriptors. For systems that don't support select(), a polling version
> is implemented. For other systems, a slight recoding would be necessary.
> I plan on doing this for a win32 port (yes, lets run win32 on win32... ;-)
>
pk provides an event mechanism that has semantics similar to a barrier.
You define an event and then threads can wait on it. When the event occurs,
all waiting threads are scheduled for execution. There is no mechanism
for a single thread to wait on multiple events simultaneously yet.
Later,
FM
--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com
