From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24657 invoked by alias); 5 Sep 2004 06:02:03 -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 24474 invoked from network); 5 Sep 2004 06:01:55 -0000 Received: from unknown (HELO smtp809.mail.sc5.yahoo.com) (66.163.168.188) by sourceware.org with SMTP; 5 Sep 2004 06:01:55 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@67.123.174.46 with plain) by smtp809.mail.sc5.yahoo.com with SMTP; 5 Sep 2004 06:01:53 -0000 Subject: Re: Changing the Standard Game From: Lincoln Peters To: Eric McDonald Cc: Xconq list In-Reply-To: <4139FF56.9070801@phy.cmich.edu> References: <20040903061032.12825.qmail@web13121.mail.yahoo.com> <1094277237.32432.6242.camel@localhost> <4139FF56.9070801@phy.cmich.edu> Content-Type: text/plain Message-Id: <1094364227.4338.9783.camel@localhost> Mime-Version: 1.0 Date: Sun, 05 Sep 2004 15:52:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01104.txt.bz2 On Sat, 2004-09-04 at 10:45, Eric McDonald wrote: > Well, I think that part of the problem might be simply that when you > call one game the "standard" game, it implies that the others are either > substandard or offshoots of it. Perhaps, then, we should change the name of the Standard game to the Default game, or something else that doesn't imply that other Xconq games are sub-standard. At least, if _I_ saw that the first choice on the list was called the "Default game," I wouldn't be as inclined to doubt the quality of the other games. Or maybe it needs a more descriptive name. > > When I first tried out Xconq back in 1999 or 2000, this was one of the > things that kept me away from the other games. And I barely did more > than open a few of the others before I abandoned Xconq then because the > UI was not very good. Even more reason to build a better UI, although I think we all agree that bug-fixing usually takes precedence over UI building. > > >I can envision a "Welcome" screen that looks like > > the following (which, as usual, I designed with Glade without having to > > write any code): > > Of course, code would still have to be added for event handlers for the > various UI elements, so that a click on, say, a radio button will > translate into the proper Xconq internals being updated. Of course. Right now, I'm just trying to figure out what the interface should look like. > > Furthermore, as soon as you click "Apply", you could theoretically jump > > to the existing SDL interface and thus leave behind anything that even > > remotely resembles an Office app. > > I would suggest the "Apply" button be relabelled to "Accept" or "Start > Game". I'm pretty sure that there's a way to do that, but I'd have to write actual code (Glade won't let me change the labels of buttons when the buttons are part of a Druid widget). > > What you propose is interesting. This would certainly save time in the > development of the startup screens, a task I have only half been looking > forward to. The tradeoff is that the Windows installer would get quite a > bit larger, because we cannot reasonably assume that a Windows user > would have the GDK, GTK+, Pango, etc. libraries on his/her system. I'll have to study the Mono framework, but it might be possible to implement one UI that runs on both Linux and Windows with minimal platform-specific code or dependencies. It also looks like Novell (the company that now owns Ximian) is working on a Mono implementation for MacOS X, which might simplify things further (but not until there is a Mono-based interface that is actually better than the existing MacOS interface). If I remember correctly from that talk I attended back in 2002, the biggest stumbling block that the Mono project encountered at the time was the difference in widget styles (coordinate-based vs. hierarchical, although I don't think he used those exact words). However, since they've finally released Mono 1.0, I would assume that they found a solution to that problem. Based on their FAQ, it looks like an application written for Mono/.NET should work fine on UNIX/Linux or Windows with no difficulty as long as it is a "100% .NET application" (essentially it is fully compliant with the .NET standard and contains no platform-specific code). Although I have no idea how much work it would take to convert Xconq into a "100% .NET application," and I don't think any of us want to find out (at least not until post-7.5). And, of course, there's the possibility of drastically simplifying network games by implementing ZeroConf/Rendezvous (to make Xconq LAN parties easier to set up) and/or an Xconq game server (maybe just a modified IRC server to put Xconq players in contact with each other). Although that would almost certainly cause the appearance of Page 4 to change somewhat, and it's not something I'd consider a high priority. (Yes, I remember that the idea of using Mono was originally floated in the midst of last year's great flame war, but I think that it's an idea worth taking seriously, even if it was originally accompanied by a lot of hot air.) --- Lincoln Peters "Kill the Wabbit, Kill the Wabbit, Kill the Wabbit!" -- Looney Tunes, "What's Opera Doc?" (1957, Chuck Jones)