Conference azur::mcc

Rob,

Your idea about having a pushbutton on the Management Window to close to window
is a good one, and has been recommended by others also.

We will try to get it in for EFT.

Thanks,
Verna

    In another note it was suggested that someway to set a default path
    for entities would be good (like mcc_bridge_path = my_ns:.mcc_bridge.)
    etc.
    
    To go along with this sort of thing it would be useful if the lables
    for window title bars, window icons and entity icons could be displayed
    (optionally - and dynamicaly of course) as just the right most simple
    name.
    This would be obvious if you use a vertical column for a decwindows
    icon box and you have entities like :.lkg.s.mcc_domains.lkg2-1-grn .
    This generates a very long icon name for the map window icon and even
    with an icon box that can display 23 character, the unique and useful
    part of the name doesn't show up. On the map, the icon lables get very
    long and really clutter up the display.
    
    for the above example I would only see LKG2-1-GRN as the icon lable on
    the map. Much easier on the user.
    
    s/rob

    It would be nice if "Look up" had a keyboard accelerator.
    
    s/rob

    I frequently find that I have 'gone down a series of levels' by double
    clicking (is there a simple term for what I am describing?) on domains
    and then I go back to the top with a series of "Look Up" selections.
    
    At that point I have a series of objects selected and at present the
    only way I know of to deselect them all is to walk back down the tree
    and "shift/select" them.
    
    Two requests:
    
     to reduce movement between the keyboard and mouse how about making a
    single click on an already selected icon de-select it?
    
     how about a way to "De-select all (below you I guess)"?
    
    s/rob

    Placing a new icon on a map takes a bit of time from the click until
    there is something painted on the screen. The cursor goes to "wait"
    mode but it would be friendly if you marked the screen where the
    cursor was when the click occured.
    
    Another example which is even more frustrating is deleting an icon from
    a map. In this case it can take 20 seconds (even on a 3100) during
    which there is no indication that the requested operation is underway.
    
    In general, more instant feedback is needed on click operations.
    
    s/rob
    

  Accelerator for Look Up:  Good idea, if there is no conflict with other
  bindings, we'll take a look at it.

  Single click to deselect:  This goes against DECwindows style.  The way it is
  implemented corresponds to DECwindows style and the selection semantics used
  by other products.

  Suggestion:  If you have a number of icons selected, some off of the screen,
  you can select any single icon on the screen (do not use the shift key) and
  all of the other icons will be deselected -- only the icon on which you just
  single-clicked will be selected now.  You don't have to walk around to map to
  find all selected icons and deselect them individually.

								- Dave

    I realize that I can deselect things by selecting other things.
    
    I object to needing the keyboard for mouse actions and vice versa.
    
    I wouild say the DECwindowns style is wrong if it fails to provide
    needed flexibility. Besides, in the toolbox, selecting an action (not
    sure what the term is cause they arn't labled - ya know, draw a line,
    delete a map icon etc) that is already selected deselects it now.
    
    All I want is more consistancy from the user view (and please don't
    take the current good behaviour away... :-).
    
    s/rob
    

  I don't believe that the DECwindows style guidelines are wrong in this
  situation.  DECwindows is certainly not a mouse-only environment.  I agree
  that a user should not be forced to needlessly go back and forth between
  the mouse and the keyboard.  That is not the case here.  I agree that a
  Deselect All menu item is perfectly reasonable and desirable.  We just
  have not had the time to put it in.  There are definite interactions
  between the mouse and the keyboard.  We have accelerators, as do just
  about all window-based applications.  Combinations such as shift-click
  (hold down the shift key while hitting MB1 on the mouse) are common and
  useful -- DECwrite, DECwindows MAIL, and DECwindows Notes are examples.
  This is also an accepted technique on the Macintosh, and probably on all
  other window-based systems as well.

  In terms of the Iconic Map, I don't think that you really want the icon
  in the map to deselect after each use.  The next question is, what is a
  "use"?  A Look Into?  Bringing up a management window?  You can bring up
  multiple management windows from one map (or from one icon on one map).
  This is also consistent with other window-based products.  The object
  stays selected until you deselect it.

  The toolbox is somewhat different.  The delete tools and class icons reset
  after use.  This behavior for the delete tools is to keep you from
  inadvertently shooting yourself in the foot by keeping the delete tool
  active.  With the class icons, if you want to drop more than one icon,
  hit Apply instead of Ok.  This is also consistent among windows-based
  applications.  The line and text tools are different.  In this case we
  tried to do the best thing for the user.  The assumption is that if you
  are drawing a line, you might want to draw more than one.  If you are adding
  text, you might want to add more than one text block.  So, those tools stay
  active in the toolbox.  If this inconsistent is so obnoxious we can have them
  deselect, but I feel that this is will not inhibit learning to use the PM.

    Sorry, I must have been unclear in my example.
    
    In the toolbox, the selected thing (if it is draw a line) stays
    selected untill the user de-selects it. I agree with this.
    
    However, if I want to do something else on the map and want to de-select 
    line drawing, I can simply single click on it. This works and does not
    conflict with anything. I like this behaviour.
    
    Several other things in the toolbox do in fact de-select themselves
    after a single use. I have no problem with this where appropriate.
    
    However, on the map, if I just want to de-select something why not
    permit a single click to do it? Single click on an already selected
    object has no current function. Is it really prohibited to allow a
    single click to toggle the state of something?
    
    s/rob

    In Macintosh and Interleaf and other DECwindows applications, clicking
    on a selected object does not deselect it.  This seems reasonable; if
    you're not double-clicking fast enough, you should not be penalized by
    having the object not only not affected but deselected to boot.
    
    I gather, though, that if you want to deselect something in DECmcc, you
    cannot simply click "off of it;" for example, click on the map
    background to deselect an icon.  That is not the behavior of Macintosh,
    Interleaf, or DECwindows, and I think it is not reasonable or correct
    behavior, either.