Re: SDL interface thoughts

[Eric McDonald <mcdonald@phy.cmich.edu>]

mskala@ansuz.sooke.bc.ca wrote:

> Not really, because I'm running Slackware - my general approach was to

Ah yes, Slackware, venerable old Slackware. Almost forgot that it 
existed.... (No offense.)

> 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,

I see.

> so the version you're using might have been fine with 1.2.4.

Yes, it should be, considering that I built ParaGUI 1.0.4 against a SDL 
lib that was earlier than 1.2.6 on my Linux system.

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

Well, with this bug, you wouldn't get stuck until all of the units had 
the chance to act. Then, when it came time to give the delayed units 
another chance is where it would get stuck. But, like I said, that 
should be fixed in the latest CVS.

> Okay - I only looked at the titlebar when I attempted to click the "close"
> button (with no effect).  

I added code to intercept the quit event (which is triggered by clicking 
close) over a month ago. You should have seen a prompt in the mouseover 
panel asking you whether you wanted to save the game. (Such prompts will 
be replaced with modal dialog windows as ParaGUI becomes more fully 
integrated into the SDL interface.)

>I didn't know there was a full-screen mode,

There is, but it is not something that one can switch to, at present. 
Depending on the results of Xconq's interrogation of your display 
configuration, the interface decides whether you get it or not. Or, at 
least, that is what I remember seeing when I looked at the relevant 
piece of code early on when I was getting acquainted with the interface 
code. Of course, I think that on systems where the full screen mode is 
supported, the user should have the option to switch back and forth. 
But, __haven't got that far yet....

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

Sure. I agree 100%. Matter of fact that is what I was working on before 
I got distracted by Sourceforge, ParaGUI, etc.... If you don't mind 
briefly coming into contact with a forum, you can see what I have in mind:
   http://www.xconq.org/modules.php?name=Forums&file=viewtopic&t=9
It's the fourth post on that topic. There is a list of command buttons 
that should appear, if the current unit/selected units support them in 
the current context.
And, I think I made an even more detailed listing in the sources, either 
in the 'update_unit_info' function or a function that it calls, IIRC.

>Even if I may eventually
> want to make that display go away for more screen real estate once I
> memorize the command, 

Sure. The "Hide" button is available to make the whole commands panel go 
away. It is more proof of concept than anything right now; it was a test 
to make sure that events handling would be okay in the absence of the 
panel. The unit action panel comes back when another unit is 
[auto]selected; that behavior will change once my attention returns the 
unit action buttons.

The other thing I plan on doing is displaying in the mouseover panel the 
"shortcut"/keyboard command needed to do the equivalent of clicking the 
button. I am thinking about setting it up so that the button is no 
longer displayed if the player uses the keyboard equivalent instead. 
This is useful for brushing aside buttons like "Delay" and "Skip" in 
favor of the construction buttons, etc....

As far as bringing the unit action panel or individual buttons back into 
view once they have been hidden, __a preferences screen or three are 
needed in the long run. That was one of my motivations for taking the 
"time out" to pursue ParaGUI integration.

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

Quite reasonable. In terms of our discussion, I think that will simply 
imply making the preferences screens easily accessible (and with some 
indication that the user can achieve the desired goal of showing hidden 
UI elements again).

Eric