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: Another Possible Solution to the Occupants Display Problem
Date: Mon, 06 Sep 2004 22:09:00 -0000	[thread overview]
Message-ID: <413CCD52.4080402@phy.cmich.edu> (raw)
In-Reply-To: <200409061942.i86Jgq712540@panix5.panix.com>

Jim Kingdon wrote:

> Instead of "Occs" or "OV", I think I'd go with an icon (if someone can
> design one which makes sense and fits in 16x8 or so).  Or maybe just
> "...".  That fits in almost any size box and seems to be kind of
> logical for what the button does (and indicates). 

This seems reasonable.

> Or maybe just draw
> the transport full-size in the "unit in a white box meaning occupants"
> which the tcltk interface now uses at 16x16 (hmm, I guess that only

That's a thought. I wonder how obvious its intended meaning would be for 
newbies?

>>For 11x11 (8x8), clicking anywhere in the transport should probably
>>bring up the occupant view popup.
> 
> Yes.  Likewise at any magnification for clicking on occupants which
> are displayed in the transport (in the 1-2 occupant case).

Hmmm... This would be overriding the meaning of a mouseclick on an unit. 
But, I can see the advantage as well....

(If the idea is just get more info on an occ, then switch into survey 
mode and click on it.)

> But it seems odd for click to sometimes mean act on the unit and
> sometimes mean bring up the popup.  I'm thinking more that the popup
> should be a mouseover (although I don't know about things like nested
> popups in that context).

Wrt the magnifier idea that I had earlier, I had suggested that the 
magnifications happen during a mouseover, only if a modifier key is 
being pressed.

However, there are really only two universal modifier keys, shift and 
control, and I would rather not use either of them for this, as I can 
think of better uses for them. Also, there is the issue of dismissing a 
popup/magnified transport box. Should it disappear when the mod key is 
released? And, if so, then how do you get nested popups/magnified 
transport boxes, or, at leat, just the one(s) you want? If we opt to use 
escape, then there seems to be an asymmetry: mouseover+keydown to 
invoke, but keypress to revoke.

These concerns are what made me shy away from the magnifier idea, and 
suggest what I am now suggesting.

To address the question about what a click means....
The idea of using a click to bring up an occs display popup initially 
concerned me in the same way that you seem to be concerned. But, then I 
asked myself, "Are we really overriding the meaning of a click?" The 
fact that we are clicking on a button in the transport box rather than 
the transport itself makes me think we are okay in this regard. Context 
can be preserved inside the popup boxes. If the cursor is in attack 
mode, then clicking on the popup button will bring up a display of occs 
to attack (assuming one can attempt such a thing). If the cursor is in 
move mode, then clicking on the popup button will bring up a display of 
occs that can be entered (after entering/passing through their transport 
of course); the move/enter code still needs some work to properly handle 
this, but I started looking into it a few months ago. (And got 
sidetracked, as usual....) In survey mode, yada yada.... Etc, etc.... 
The main point here is that clicking on the button is not the same as 
clicking on the transport (though at the lowest map zooms, clicking on a 
transport may be the same as clicking on the popup button; but, this is 
not a big deal, because the transport can be clicked on inside the 
resulting popup window).

> Also ACPs, materials and plans (hit points optionally, although there
> is already a damage bar for that).

I might concede the ACP's, and possibly the goal and plan description. I 
am less enthusiastic about materials; as it is, I am on the brink of 
deciding whether to keep the materials in the unit info panel in the SDL 
interface, or whether they should only be displayed (with the 
possibility of showing more than 9 of them, and showing their icons, if 
they have any) in a popup if a button in the unit info panel is clicked.

>  As long as we are bringing up a
> popup, might as well make it possible to avoid having to glance over
> to a separate unit details pane.

I agree with this in principle. The question is what is necessary for 
the peruser to make an informed decision. Also, there is the question of 
how much info would actually be available to the peruser. If I am 
looking for something to attack and click on the popup button of an 
enemy's unit view, I can really only know location.

> I'm not as sure about location - it seems like the fact that you get
> to the popup from the map maybe means location is reduant.  It seems
> kind of inelegant to be using a bunch of text if there is some way to
> provide the information visually in a contextual way.

Point conceded. I guess this would leave us with name, ACP, health, and 
goal and plan. Possibly materials, but I think a materials display 
triggered by a button might be better. Most decisions don't involve 
in-dpeth knowledge of materials, construction being a possible 
exception. If I am attacking or moving, it is generally good enough to 
just to see the "SupplyLow" indicator. IMO, the existing materials 
display is inadequate and hogs too much space in comparison to its 
relative worth.

> Anyway, if the popup has this kind of information, it would be useful
> to be able to bring up this popup by clicking on the transport itself
> (or a unit with no occupants).

This is true. The info on the transport would be more than what is 
provided by simply hovering the mouse over an unit. I guess this 
bolsters the case for the kind of popup being proposed.

> I don't remember what the other choices du jour were, but this one
> seems promising.  Or some variant thereof...

Good.

Eric

  reply	other threads:[~2004-09-06 20:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-06 19:42 Eric McDonald
2004-09-06 20:49 ` Jim Kingdon
2004-09-06 22:09   ` Eric McDonald [this message]
2004-09-07 17:03     ` Jim Kingdon
2004-09-08  1:29       ` 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=413CCD52.4080402@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).