[rfk-dev] bugs

[Eric S. Raymond]

Peter A. H. Peterson <pedro at tastytronic.net>:
> So I have built and am running the new robotfindskitten! Hooray!
> 
> Eric S. Raymond, I'd like to present to you, as a token of the
> consortium's esteem and gratitude, this small statue of robot:
> 
> #

Thank you, thank you.  It's an honor just to be nominated.
 
> Genuine bugs:
> 
> 0. I second Tim Allen's complaint. However, you can test it without
> installing by running 'src/robotfindskitten' from the build directory
> and it will find the NKIs.
> 
> 1. There is no canonical success message. cf. the stable version.
> After the success animation, the status line should look something
> like this:
> 
> robotfindskitten v1.7320508.406                                                        
> You found kitten! Way to go, robot!               j#                          

Yes, these are clear bugs.  I think they naturally belong to Alexey,
and that he will fix them once he gets his dev access.  You might
want to create tracker tickets for them on SF.

> 2. The version string above the playfield should include the tertiary
> NKI number. (See above.) However, perhaps that should be automatically
> calculated from the available pool of NKI now that they are external?

This one is logically mine.  Presently the version number is set in exactly one
spot - configure.in - and I have bumped it to have a new value (1+sqrt(5))/2
to reflect the major change in the POSIX codebase.  It doesn't, as you
have obseved, presently have a minor part.

It is my present intention that we should update configure.in manually to 
have a current-NKIs minor part just before each release. (See the file
RELEASE).  We can't do much better than this within autotools, its 
assumptions about how PACKAGE_VERSION is generated and propagated
are too rigid.

The actual fix, therefore, requires scrapping autotools.  I think this
would be a good idea in general - autotools is hugely overcomplicated
and heavyweight for rfk's needs.  But it's a larger and potentially 
more controversial change than I wanted to try to make in combination with 
merging Alexey's code.

rfk has simple enough dependencies that a flat Makefile would handle
it perfectly well.  But in that case the minor version part would
still need to be manually tweaked.

Given my druthers, I'd go to an scons-based build.  Under that engine
we could update the minor part auto,atically with no trouble.

> 3. NKI typo -- Unless Shaddam the 4th has an emporium, he is more
> appropriately an emperor. (I have no idea how old that NKI is.)

Fixed.

Note for the future: I am willing to take the laboring oar in maintaining
the NKI list.

> 1. I think one quit key is enough, say, q. We can make both Q and q
> work without explicitly listing both cases. The long list of escaping
> keys seems excessive and makes the intro screen kind of wordy. Also, I
> think that ^C can be implied.

I'd be OK with this change.

> 2. I don't like how "In Glorious Color" stays in the status line
> until you touch the first NKI. It kind of breaks the spell for me,
> because it's not status -- but there it is, masquerading as one! 

It's a minor flaw, and I wouldn't have brought it up if nobody
else had objected...but I concur.

> 3. I'm actually not sure how I feel about having the NKI messages in
> color -- I'm not sure it's a UI enhancement. Some colors are great for
> NKI color variety but I find a little harder to read. And I find the
> color changes to be a little distracting a la #2 above.

Again I concur. On a black background, some of the darker colors like
blue are hard to read.  This one I was working my way around to
bringing up myself.  I hadn't decided what I think the right fix is,
but I could live with just reverting the messages to uncolored.

> 4. I'm not sure that I like the bounded playfield. It uses up
> real-estate and is a UI change that I'm not sure anyone was asking
> for. On the other hand, it does imply a certain boundedness to the zen
> plane, which I can appreciate in that it lends clarity to the
> representation and implies that field won't resize given a larger
> window. My personal jury is still out on this one. Comments?

I did this, not Alexey.  Note that if the FRAME macro is set to 0 rather
than 1 the frame gracefully disappears.

First, note that the playfield (and the frame) *does* resize with the
winow.  Though Alexey's code sometimes complains "Stop, you're crushing
me!" for reasons that I'm not clear about from looking at it.

I added the frame because (a) I think it looks better that way, (b)
it's a common visual element with other games written in a nethackish
UI style, and most importantly (c) it makes the actual game look more
like the pseudo-screens on the website.

I don't think the amount of screen real-estate the frame takes up
is a thing to worry about on modern displays - terminal emulator
windows aren't large, any more, unless you want them to be.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>