This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SDL interface thoughts


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]