Eric S. Raymond
esr at thyrsus.com
Sun Oct 28 09:57:27 PDT 2012
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.)
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>
More information about the rfk-dev