[mcountd] forward plan

[Joe B. <rbe...@Pi...>]

On Sun, 23 Jan 2000, Karl-Martin Skontorp wrote:

> On Thu, 20 Jan 2000, Joe Bentley wrote:
> > While we're on the subject of upgrades
> >    1. it would be helpful to use ncurses. that way
> >       there wouldn't be that distracting scroll up
> >       every second
> 
> Indeed. My only concern is that this will very likely break the ELKS
> support, but since I do not have my 8088 machine here, there aren't really
> any i86 testing at all. I think I will remove all references to ELKS, this
> can be added again later, anyway.

I'm not familiar with ELKS. Last I heard the project still
did not have a stable release. Has this changed?

> 
> Do you know ncurses?

I do know N curses for sufficiently small values of N :-)

> 
> >    2. also it should use the environment variables
> >       'LINES' and 'COLS', if available, to determine
> >       the proper size to draw the letters and scale
> >       them to fit the screen. I generally use a
> >       140x44 window in X which makes the 80x25 look
> >       really small
> 
> Interesting ideas, but how can the scaling be implemented?

I think the easiest approach would be to use a vector
drawing approach for the digits. The digits are currently
specified with 10x13 bitmaps. Suppose we wish to convert
the representation of '3'. The vector form would be
   =
    |
   -
    |
   -
   moveto 1,0
   lineto 8,0

   -
    ||
   -
    |
   -
   moveto 9,1
   lineto 9,5

   -
    |
   =
    |
   -
   moveto 1,6
   lineto 8,6

   -
    |
   -
    ||
   -
   moveto 9,7
   lineto 9,11

   -
    |
   -
    |
   =
   moveto 1,12
   lineto 8,12

Note that all those positions are against a 10x13 grid.
When you scale the grid by some factor dx,dy then you
also scale each of those positions. The result is a
scaled bitmap.
Except that that scaled bitmap would not look very good
for large resolutions because the segments would seem
to get thinner as the screen got bigger. So you have to
treat each segment as a rectangle. Right now each
rectangle has a width or a height of exactly one. That
would have to get scaled along with the grid.

> 
> >    3. a more natural specification of time would
> >       simplify the invocation. eg '12:34' instead
> >       of calling date on the command line
> 
> Just need to make a parser. Maybe I can use something from date?

It's gpled. They _want_ you to use it. Or if you don't want
to wrestle with importing someone else's code you could
call date with system(3) and copy the output to a temp file.

> 
> >    4. the ability to end when the timer rolls over.
> >       This would make it possible to use it as a
> >       count-down timer for a shell script
> 
> Simple. I will also add the function to have it display only zeros at
> roll-over.

And actually exit. So the user can make a script to the effect of
   mcountd ${auction_end_time}
   beep ; beep ; beep

> 
> >    5. and a marketing shift. As a 'millenial count
> >       down' it had a single purpose which ( depending
> >       on your perspective of the y2k vs y2k+1 debate )
> >       either passed or will pass in only 300+ days.
> >       But it can be billed as the 'count down timer
> >       _for_ the millenium'. Which extends its apparent
> >       life for another thousand years.
> 
> The name is actually kind of stupid... I'll add your comment to the
> webpage.

The name was a great name until a few days ago. The only
problem is that it is restrictive in the users mind. I see
a 'millenial countdown timer' and have to exercise major
cognition to realize that I can use the same thing for
counting down to the end of an auction.

> 
> >       For instance, I did not use it for counting down
> >       on new year's eve, but I do use it for counting
> >       down the time remaining on my ebay auctions.
> 
> I had planned to use it at new years eve. I was going to bring my 8088
> laptop, which can withstand great impact, but failed to finish the port in
> time.

Champagne will do that to you.