nanogui: Thread: Contributed clock program to nano-X

Al,
	I have added the clock program to MicroWindows v0.82, which
I will release shortly.

	It's pretty cool!  Anyway, I have a couple comments.  I changed
the color model to RGB a while back, so any function that takes a GR_COLOR,
like GrSetGCForeground, must use an RGB color, or a color macro, like WHITE.
Values like si.white are technically PIXELVALs, not COLORVALs, so they
can't be passed from the upper level.  The system converts COLORVALS to
PIXELVALs based on the available palette.  The file device.h has 16
reserved colors that are guaranteed to be in a palette (see devpal4.c/devpal8.c)
and can be used by name.  These work by indexing the palette entry (see PALINDEX
macro).  So I changed all the si.white/si.black to WHITE and BLACK, and 8 to GRAY.

	The time is one hour off over here.  Is that because you're not
adding back the daylight savings time?  Does gettimeofday() handle that?

Greg

Greg Haerr writes:
> 
> Al,
> 	I have added the clock program to MicroWindows v0.82, which
> I will release shortly.
> 
> 	It's pretty cool!  Anyway, I have a couple comments.  I changed
> the color model to RGB a while back, so any function that takes a GR_COLOR,
> like GrSetGCForeground, must use an RGB color, or a color macro, like WHITE.
> Values like si.white are technically PIXELVALs, not COLORVALs, so they
> can't be passed from the upper level.  The system converts COLORVALS to
> PIXELVALs based on the available palette.  The file device.h has 16
> reserved colors that are guaranteed to be in a palette (see devpal4.c/devpal8.c)
> and can be used by name.  These work by indexing the palette entry (see PALINDEX
> macro).  So I changed all the si.white/si.black to WHITE and BLACK, and 8 to GRAY.
> 
> 	The time is one hour off over here.  Is that because you're not
> adding back the daylight savings time?  Does gettimeofday() handle that?
> 

I wasn't quite sure how this worked from reading the gettimeofday man page.
There are some references made in the manpage to the kernel
no longer using the tz structure, but when I included the second line
of the code fragment below, it worked fine in the UK. (we are currently in
daylight saving time) whereas previously it had been an hour slow.

        gettimeofday(&tv, &tz);
        now = tv.tv_sec - (60 * tz.tz_minuteswest);

If the line is not in the version I sent you then I sen the wrong one by
mistake. Please let me know whether this is the case.

Al

: I wasn't quite sure how this worked from reading the gettimeofday man page.
: There are some references made in the manpage to the kernel
: no longer using the tz structure, but when I included the second line
: of the code fragment below, it worked fine in the UK. (we are currently in
: daylight saving time) whereas previously it had been an hour slow.
: 
:         gettimeofday(&tv, &tz);
:         now = tv.tv_sec - (60 * tz.tz_minuteswest);
: 
: If the line is not in the version I sent you then I sen the wrong one by
: mistake. Please let me know whether this is the case.
: 

	I tried removing that line, and replacing the later call to gmtime()
with localtime().  The results were identical.  The minutes west is not
an indicator of daylight savings time, however.

Greg