From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31678 invoked by alias); 26 Aug 2004 17:59:57 -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 31511 invoked from network); 26 Aug 2004 17:59:54 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 26 Aug 2004 17:59:54 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7QHsIP6002429; Thu, 26 Aug 2004 13:54:18 -0400 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 13:56:47 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 06EE87002C; Thu, 26 Aug 2004 13:59:38 -0400 (EDT) Date: Thu, 26 Aug 2004 19:12:00 -0000 From: Eric McDonald To: Jim Kingdon Cc: xconq7@sources.redhat.com Subject: Re: Three thoughts In-Reply-To: <200408260613.i7Q6Dk903199@panix5.panix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 26 Aug 2004 17:56:47.0512 (UTC) FILETIME=[0E567980:01C48B96] X-CanItPRO-Stream: default X-Spam-Score: -0.9 () X-Bayes-Prob: 0.0001 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg01035.txt.bz2 On Thu, 26 Aug 2004, Jim Kingdon wrote: > > (1) Scaling images to non-standard sizes would likely be > > necessary to accomodate the suggested scheme. > > Or playing with the size of the hexes, or re-working the bigicons > feature, or something. There are plenty of details that would need to > worked out. But first one needs to think through whether the concept > seems promising in general. Agreed. Certainly, the concept is an interesting one, especially if one ignores the small number of scaling bins in use and assumes an "infinite" number of them instead. > > (3) Scaling down the images of other units would likely degrade > > their identifiability as certain types > > The smallest image currently in use is about a 4x4? It is pretty > small. I don't imagine you'd go smaller than that. Agreed. But then what? If space constraints were to force one to go smaller, then what? Would this feature be selectively implemented to only work at high view powers, and be disabled for ones lower than the default one currently in use? > But it is also worthwhile thinking about whether there is some way to > provide some of the information with having to look back and forth to > a window which is off to the side. I agree. That is why I think some sort of selection rectangle ("crawling ants", blinking square, etc...) around the selected unit is a good idea. At small scales, it may be necessary to flash the entire unit icon to make it stand out from the crowd. >Maybe it isn't center and edges, > maybe it is top and bottom. In the tcltk interface now, the top half > is for the transport and the bottom half is for the occupants. Right. I had wondered about this approach as well. However, do we want to confuse paradigms? Top-bottom presently indicates transport-occupant; do we want to overload this for selected-unselected as well? > With scaling and drawing otherwise the same as now. I agree that it does have that benefit. Eric