From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6183 invoked by alias); 22 Nov 2004 04:10:52 -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 6160 invoked from network); 22 Nov 2004 04:10:47 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org with SMTP; 22 Nov 2004 04:10:47 -0000 Received: from [192.168.181.128] (c-67-176-41-158.client.comcast.net[67.176.41.158]) by comcast.net (rwcrmhc11) with ESMTP id <20041122041046013004sgcae>; Mon, 22 Nov 2004 04:10:46 +0000 Message-ID: <41A166B3.6020605@phy.cmich.edu> Date: Mon, 22 Nov 2004 05:53: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/msg01426.txt.bz2 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.