From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21758 invoked by alias); 22 Nov 2004 07:23:17 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 21747 invoked from network); 22 Nov 2004 07:23:11 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 22 Nov 2004 07:23:11 -0000 Received: from [192.168.181.128] (c-67-176-41-158.client.comcast.net[67.176.41.158]) by comcast.net (sccrmhc11) with ESMTP id <2004112207231001100omapme>; Mon, 22 Nov 2004 07:23:10 +0000 Message-ID: <41A193CE.9000900@phy.cmich.edu> Date: Mon, 22 Nov 2004 19:02:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: mskala@ansuz.sooke.bc.ca CC: xconq7 Subject: Re: SDL interface thoughts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01428.txt.bz2 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