From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11059 invoked by alias); 24 Aug 2004 02:51:02 -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 11015 invoked from network); 24 Aug 2004 02:50:57 -0000 Received: from unknown (HELO smtp808.mail.sc5.yahoo.com) (66.163.168.187) by sourceware.org with SMTP; 24 Aug 2004 02:50:57 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@67.123.172.242 with plain) by smtp808.mail.sc5.yahoo.com with SMTP; 24 Aug 2004 02:50:56 -0000 Subject: Re: Three thoughts From: Lincoln Peters To: Eric McDonald Cc: Xconq list In-Reply-To: <412A9D1E.4000907@phy.cmich.edu> References: <1093308446.2792.30246.camel@localhost> <412A9D1E.4000907@phy.cmich.edu> Content-Type: text/plain Message-Id: <1093315933.2792.30478.camel@localhost> Mime-Version: 1.0 Date: Tue, 24 Aug 2004 03:02:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01013.txt.bz2 On Mon, 2004-08-23 at 18:42, Eric McDonald wrote: > Lincoln Peters wrote: > > > > > 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. Okay. I can see quite clearly how TclTk and GTK+ differ in 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. Understood. I suppose that I started thinking about this stuff again after I saw a computer at Novell's booth at LinuxWorld where they were showing off what you can do with Mono (Novell merged with Ximian a while ago). > >>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. Somehow I didn't see the suggestion about a modifier key earlier. Maybe I've been staring at my computer screen too long. > > >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? No, but I imagine that if the size of the cell doesn't change, you'd have to shrink the other units to accommodate the enlarged unit image unless you were willing to obscure units by placing them underneath the enlarged unit image (which it looks like was what you have in mind). I guess that you could enlarge the entire grid so that every unit image fits on the screen at a reasonable size, but that could easily result in the most unmanageable map ever. Although I suppose that if there was an easy way to toggle between that view and the "normal" view, the only disadvantage would be the CPU load (which wouldn't be too bad except on old hardware). > > 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. I noticed that the SDL interface blows up the selected unit to fill the entire cell even if other units occupy the cell. I find it to be rather awkward, as it makes it hard to reach units underneath it (I often can't figure out where to click to select another unit in the same cell unless I de-select the current unit first. And sometimes it looks weird when several tiny unit images appear underneath a big unit image. > > > 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. Actually, it does sound like the simplest solution. > > > 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. I'm not sure which solution would work better. It might be necessary to implement both solutions and see which holds up better in practice. Maybe it will help to look at the corrected URL, below. > > > http://homepage.mac.com/lmpeters/cell_closeup2.png > > 404. Sorry; typo. http://homepage.mac.com/lmpeters/cell-closeup2.png --- Lincoln Peters It's a very *__UN*lucky week in which to be took dead. -- Churchy La Femme