From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20237 invoked by alias); 24 Aug 2004 00:46:13 -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 20209 invoked from network); 24 Aug 2004 00:46:10 -0000 Received: from unknown (HELO smtp810.mail.sc5.yahoo.com) (66.163.170.80) by sourceware.org with SMTP; 24 Aug 2004 00:46:10 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@67.123.172.242 with plain) by smtp810.mail.sc5.yahoo.com with SMTP; 24 Aug 2004 00:46:09 -0000 Subject: Re: Three thoughts From: Lincoln Peters To: Eric McDonald Cc: Xconq list In-Reply-To: References: Content-Type: text/plain Message-Id: <1093308446.2792.30246.camel@localhost> Mime-Version: 1.0 Date: Tue, 24 Aug 2004 00:55:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01008.txt.bz2 On Mon, 2004-08-23 at 09:40, Eric McDonald wrote: > On Sun, 22 Aug 2004, Lincoln Peters wrote: > > > Here's a rather crazy possible solution: Would it be possible to use > > TclTk *and* another toolkit, such as GTK+, simultaneously? That might > > allow us to not only use GTK+ to implement new features, but also to > > "phase out" the TclTk code (since nobody seems to like TclTk anymore) > > and replace it with GTK+ code. > > I think it would be possible, but probably would be rather > hackish. Both Tk and GTK+ have their own window hierarchies, and > that would require a fair amount of bookkeeping on Xconq's part, > to make sure that focus gets restored after a window closes, > etc.... > > Also, the "widget styles" of the two toolkits are a bit different > and so the resulting UI would end up looking like Frankenstein, I > think. I'm not familiar with TclTk's (Tk's?) "widget style". Does it work based on a grid, where widgets are positioned by coordinates rather than through the use of containers (horizontal and vertical boxes, tables, etc.; as per GTK+)? From the references I can find on the Web, it looks like Tk can use containers in a manner similar to GTK+, but it has only had that feature since version 8.4. Would Xconq look any worse if it used Tk code and GTK+ code simultaneously than it looks now? As I see it right now, we have three possibilities: Current TclTk interface: ugly and unintuitive Proposed GTK+ interface: more intuitive than TclTk, but would look like an Office app In-development SDL interface: looks cool, more intuitive than TclTk, but more work to develop than the first two Over the long term, it might be worthwhile to try to develop a common UI based on SDL and GTK+/GNOME, since SDL could provide a more game-like (i.e. less Office-app-like) interface and GTK+ could provide a bunch of features where it doesn't particularly matter if they look like they belong in an Office app. For example, I think it would be fairly simple to implement the Xconq "Welcome" screen using a GNOME Druid. > > Your idea does have the merits you suggest, though. > Interesting.... There might be a few hardcore strategy gamers who would appreciate being able to use Mono to link Xconq to a spreadsheet application and do some intensive data analysis on games like advances.g (e.g. track production, technology, offensive/defensive power, over time). Of course, there are a *lot* of other things to deal with before worrying about spreadsheet applications! Perhaps it would be possible to avoid the "hackish" aspect of using TclTk and GTK+ simultaneously by completely switching from TclTk to GTK+ in one fell swoop, but that idea is probably even more scary for most developers. The closest I'd expect us to reasonably come to that scenario would be to implement GTK+ as a separate interface and then label the TclTk interface as a "legacy" interface. > > > The situation illustrated here is the city Sausalito and a fighter > > flying overhead. Within the city are infantry, armor, a bomber, a > > battleship, and a carrier. > > If the ship types corresponded to U.S. Navy naming conventions, I > think you would have two carriers and zero battleships. Not that > it really matters.... Honestly, I just used the names of the first two ships from "Star Trek" that I could think of. Last night, a local TV station ran "Star Trek IV: The Voyage Home" > > The closup view window that you propose is an interesting idea, > but I agree that we should try to avoid extra work to fish out an > unit, if possible (as someone mentioned in a later message in > this thread). One idea that I thought of would be magnify the > icon of an unit if the cursor passes over it in a manner similar > to that little bar of icons at the bottom of the MacOS X > interface (IIRC). Or maybe that magnification should only happen > when a modifier key is being pressed when the mouse passes over > the unit, so that the magnified view does not normally get in the > way of other units in the same hex (and possibly surrounding > hexes). Magnification as per the MacOS X dock would be a possibility, but an awkward one. Unless you have an intuitive way for the user to indicate when to zoom and when not to zoom, the user might be rather surprised when the mouse hovers over a cell and one unit suddenly gets bigger while the others get smaller. Of course, if you don't want to shrink the unit images, you'd probably have to shrink the neighboring hexes... In conclusion, this kind of zooming is probably more work than you had in mind. Another possibility might be to make the close-up dialog be a separate window that displays each unit in the same arrangement as on the main screen, but it draws every unit in the cell at the same size. Something like: http://homepage.mac.com/lmpeters/cell_closeup2.png (As before, I'm limited to the GTK+/GNOME stock icons, none of which look like an Xconq unit, unless I write some actual UI code.) --- Lincoln Peters "Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"