From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32193 invoked by alias); 24 Aug 2004 01:43:09 -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 32182 invoked from network); 24 Aug 2004 01:43:08 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 24 Aug 2004 01:43:08 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (rwcrmhc12) with ESMTP id <20040824014307014007um8je>; Tue, 24 Aug 2004 01:43:07 +0000 Message-ID: <412A9D1E.4000907@phy.cmich.edu> Date: Tue, 24 Aug 2004 02:09:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) MIME-Version: 1.0 To: Lincoln Peters CC: Xconq list Subject: Re: Three thoughts References: <1093308446.2792.30246.camel@localhost> In-Reply-To: <1093308446.2792.30246.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01010.txt.bz2 Lincoln Peters wrote: >>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". You're reading too much into what I meant by "widget style" (which was in parentheses for a reason). Perhaps another way to put it is simply, look-n-feel. > 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. Well, it was not too long ago that I revived this suggestion (having first made it during the Great Flame War of November 2003), and some of those who read it infused assumptions into its implications, such as that I would recommend using GTK components without "redecorating" them to fit their environment. It took a while to untangle that thread, and I would rather not go there again any time soon. > 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). These are some of the benefits that crossed my mind as well when we last discussed this (last year). > 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. I have thought about this on and off in the past few weeks. After reviewing the SDL API and GTK API, and looking at the existing SDL code, I think that I am going to give SDL a try first. (After reading portions of both API's yesterday, I actually did sit down and fix some bugs in the SDL app.) >>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). > > > Unless you have an intuitive way for the user to indicate > when to zoom and when not to zoom, See my suggestion above about pressing a modifier key. >the user might be rather surprised > when the mouse hovers over a cell and one unit suddenly gets bigger > while the others get smaller. Well, I never suggested that other get smaller.... Does the MacOS X icon bar have that property? I was just thinking in terms of making one image larger than the others, and then partially or totally obscuring its neighbors for the duration of the magnification. > In conclusion, this kind of zooming is probably more work than you had > in mind. I didn't have any amount of work in mind. It was just a suggestion. But, now that you mention it, I am not sure that it would be so much work. > 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. I think that is what Elijah and Matthew were suggesting (or something similar), and it is certainly what I had in mind until the "icon magnification" idea occurred to me. > http://homepage.mac.com/lmpeters/cell_closeup2.png 404. Eric