Re: SDL interface thoughts

[mskala at ansuz dot sooke dot bc dot ca]

On Sun, 21 Nov 2004, Eric McDonald wrote:
> Hopefully the provided RPM packages or Windows installer were of some use.

Not really, because I'm running Slackware - my general approach was to
find out the name of each thing I needed, and then install the latest
version of that item, recursively getting and installing each prerequisite
as they showed up.

> is 1.0.4 stable, but it was one fewer dependency to foist upon other 
> developers.

Okay... I didn't really pay attention to the version number required, just
saw "Oh, it wants ParaGUI" and so grabbed the latest version.

> > and a new version of SDL,
> 
> Which version did you previously have? It may have worked with ParaGUI, 
> and maybe I just need to make the configure script version-checking less 
> aggressive.

I had 1.2.4, it wanted 1.2.6, and I installed 1.2.7.  It was ParaGUI that
complained about it, not XConq, but it was ParaGUI 1.1.8 that complained,
so the version you're using might have been fine with 1.2.4.

> I squashed this afternoon. Perhaps my commit had not yet reached the 
> outward-facing CVS pserver when you did your checkout. Were you using 
> the delay ('d') command at all during the game?

I was, and I think that was probably the bug that bit me because it seemed
to get stuck right after the first time I used "delay".

> Were you in full screen mode? If not, then you should have seen the turn 
> number on the titlebar. (No, that's not the best place to put it, but 
> until I get some more display space inside the window, that's where it 
> is going to have to be.)

Okay - I only looked at the titlebar when I attempted to click the "close"
button (with no effect).  I didn't know there was a full-screen mode,
which brings up my next point:

> As far as menus go, __it depends on what you mean by menu. Two of the 

I meant "menu" in a very general sense.  The principle is that I want to
be able to *see* every command that I can use.  Even if I may eventually
want to make that display go away for more screen real estate once I
memorize the command, it should always be easy to bring back the
information of "what are all the commands I can use?" when I want to be
reminded.  Whether it's an item on a list that drops down (as in the TCL
interface), or a button on a panel, or whatever, doesn't matter; it's just
that as far as I'm concerned as a user, a command doesn't exist if the
interface doesn't tell me about it.

Oh - and on hiding the menu information for expert users, don't do what
the Konqueror Web browser does.  By default it starts up with an "info"
page.  That info page explains that if you want the browser to start up
faster, you can disable the info page by going to such-and-such obscure
menu and unchecking a check box.  So I did that.  It turns out that
turning off the info page does not actually make the browser start any
faster, but DOES have the side effect of making it start up with a very
small window by default, which is really annoying.  So I figured I'd turn
the info page back on... but the menu on which that has to be done is
several levels deep, only documented on the info page which I could no
longer see because I'd turned it off, and took a lot of searching to
find.  Moral:  let the user turn off informational displays if you think
they'll want to, but also make it easy to turn the displays back
on.  Other moral:  configuration settings should not have weird unexpected
side effects.

> sure that you must have noticed the unit action buttons along the bottom 
> of the screen, though; these are a menu. There will be more such 

Yes; things like that would be fine.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/