Re: SDL interface thoughts

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

mskala@ansuz.sooke.bc.ca wrote:
> Compiling that took longer than I
> expected because I had to install ParaGUI, 

Hopefully the provided RPM packages or Windows installer were of some use.

> and ParaGUI required something
> called "sigc++",

Yes and no. The 1.0.x stable versions of ParaGUI do not require 
libsigc++. The >=1.1.5 devel versions of ParaGUI do require it, IIRC. 
However, I am developing against 1.0.4, so this should not be necessary. 
One of the reasons that I went with 1.0.4 over 1.1.8 is that, not only 
is 1.0.4 stable, but it was one fewer dependency to foist upon other 
developers.

> 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 have one thing that may be a bug:  After playing for a while in the
> standard game, the interface seemed to get into a state where I couldn't
> proceed.  I could switch between move and select modes and click on units,
> but all the units I selected seemed to already have orders and be out of
> movement points. I couldn't seem to wake them, or override or change their
> current orders. 

I can't tell exactly from your description, but this sounds like the bug 
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 wondered if maybe I'd run out of movement points. I
> figured out by trial and error that I could press "enter" to end the turn,
> but that didn't help; it let the computer units move but it didn't seem to
> let me give commands to my own units.  

This sounds weird, and it does not sounds like the delay bug. It does 
sounds like a bug with 'autonext_unit' and friends and/or the Xconq 
kernel scheduler.

I wish I had hooked in the save game code to the SDL interface, because 
then I could ask you to see if it was reproducible.

> I also couldn't tell what turn I
> was on, 

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.)

> I typed and deleted a rant about the hidden input states and lack of any
> kind of menu in the SDL interface, so that it's impossible to use
> comfortably, because I imagine that those things are already in the
> process of being corrected.  The bug, though, might actually be a bug.

It might. Hopefully we can get some more information on what was 
happening. Feel free to use the bug submission form on the Sourceforge 
site, if you get more information.

As far as hidden input states go, the cursor usually gives some 
indication of what is expected [1]. Also, the "mouseover" panel becomes 
"locked" with a prompt when the interface is in a modal state.

As far as menus go, __it depends on what you mean by menu. Two of the 
ideas that has been circulating around the list on and off for the past 
year is the idea of the "clean rectangle" and the "enchanting 
interface". These seem to speak against the traditional menu bar. I am 
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 
buttons, not just for unit actions and side research, but also for other 
side- and game-related functions....

Eric

[1] There is a bug, where, if the interface is in survey mode, you 
select an enemy unit, and hover the cursor over one of your own units, 
then the cursor will change to the battle cursor. This should be quite 
simple to fix, but I haven't gotten around to it yet.