public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Jim Kingdon <kingdon@panix.com>
Cc: xconq7@sources.redhat.com
Subject: Re: Three thoughts
Date: Thu, 26 Aug 2004 19:12:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0408261344450.27633-100000@leon.phy.cmich.edu> (raw)
In-Reply-To: <200408260613.i7Q6Dk903199@panix5.panix.com>

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

  reply	other threads:[~2004-08-26 17:59 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-20 16:22 mskala
2004-08-20 18:34 ` Eric McDonald
2004-08-20 21:17   ` Andreas Bringedal
2004-08-20 21:28     ` Eric McDonald
2004-08-20 23:57       ` Andreas Bringedal
2004-08-21  1:21         ` Eric McDonald
2004-08-21  4:35           ` Jim Kingdon
2004-08-21 20:38           ` Jim Kingdon
2004-08-20 22:03     ` Elijah Meeks
2004-08-20 23:27       ` Eric McDonald
2004-08-21  1:17         ` mskala
2004-08-21  2:31           ` Eric McDonald
2004-08-21  4:33             ` mskala
2004-08-22  3:09 ` Hans Ronne
2004-08-22  6:38   ` Item Units Elijah Meeks
2004-08-22  9:37     ` Eric McDonald
2004-08-24  1:43       ` Lincoln Peters
2004-08-24  2:38         ` Eric McDonald
2004-08-24  2:51           ` Lincoln Peters
2004-08-24  3:32             ` Eric McDonald
2004-08-22 14:00   ` Three thoughts mskala
2004-08-22 18:56     ` Hans Ronne
2004-08-22 19:16       ` Lincoln Peters
2004-08-23  4:31         ` Jim Kingdon
2004-08-23 13:04           ` Elijah Meeks
2004-08-24 18:07             ` Eric McDonald
2004-08-24 20:59               ` Elijah Meeks
2004-08-25  0:54                 ` Unit-Image Bug Elijah Meeks
2004-08-25  4:58                   ` Eric McDonald
2004-08-23 16:48         ` Three thoughts Eric McDonald
2004-08-24  0:55           ` Lincoln Peters
2004-08-24  2:09             ` Eric McDonald
2004-08-24  3:02               ` Lincoln Peters
2004-08-24 18:12                 ` Eric McDonald
2004-08-25  5:34                   ` Jim Kingdon
2004-08-25 17:16                     ` Lincoln Peters
2004-08-25 22:09                       ` Jim Kingdon
2004-08-26  2:15                         ` Eric McDonald
2004-08-26  6:17                           ` Jim Kingdon
2004-08-26 19:12                             ` Eric McDonald [this message]
2004-08-26 22:08                               ` CXP??? Elijah Meeks
2004-08-27  1:50                                 ` CXP??? Lincoln Peters
2004-08-27  5:10                                 ` CXP??? Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0408261344450.27633-100000@leon.phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=kingdon@panix.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).