From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 797 invoked by alias); 22 Nov 2004 05:53:41 -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 789 invoked from network); 22 Nov 2004 05:53:37 -0000 Received: from unknown (HELO urk.execulink.net) (199.166.6.45) by sourceware.org with SMTP; 22 Nov 2004 05:53:37 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp11.ac3.56k.execulink.com [209.239.3.11]) by urk.execulink.net (8.11.6/8.11.6) with ESMTP id iAM5rZ622049; Mon, 22 Nov 2004 00:53:35 -0500 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id iAM5knP19274; Mon, 22 Nov 2004 00:46:49 -0500 Date: Mon, 22 Nov 2004 07:23:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: xconq7 Subject: Re: SDL interface thoughts In-Reply-To: <41A166B3.6020605@phy.cmich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01427.txt.bz2 On Sun, 21 Nov 2004, Eric McDonald wrote: > Hopefully the provided RPM packages or Windows installer were of some use. Not really, because I'm running Slackware - my general approach was to find out the name of each thing I needed, and then install the latest version of that item, recursively getting and installing each prerequisite as they showed up. > is 1.0.4 stable, but it was one fewer dependency to foist upon other > developers. Okay... I didn't really pay attention to the version number required, just saw "Oh, it wants ParaGUI" and so grabbed the latest version. > > 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 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, so the version you're using might have been fine with 1.2.4. > 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 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". > 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.) Okay - I only looked at the titlebar when I attempted to click the "close" button (with no effect). I didn't know there was a full-screen mode, which brings up my next point: > As far as menus go, __it depends on what you mean by menu. Two of the 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. Even if I may eventually want to make that display go away for more screen real estate once I memorize the command, it should always be easy to bring back the information of "what are all the commands I can use?" when I want to be reminded. Whether it's an item on a list that drops down (as in the TCL interface), or a button on a panel, or whatever, doesn't matter; it's just that as far as I'm concerned as a user, a command doesn't exist if the interface doesn't tell me about it. Oh - and on hiding the menu information for expert users, don't do what the Konqueror Web browser does. By default it starts up with an "info" page. That info page explains that if you want the browser to start up faster, you can disable the info page by going to such-and-such obscure menu and unchecking a check box. So I did that. It turns out that turning off the info page does not actually make the browser start any faster, but DOES have the side effect of making it start up with a very small window by default, which is really annoying. So I figured I'd turn the info page back on... but the menu on which that has to be done is several levels deep, only documented on the info page which I could no longer see because I'd turned it off, and took a lot of searching to 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. Other moral: configuration settings should not have weird unexpected side effects. > 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 Yes; things like that would be fine. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/