[kepler-dev] Bring to Front vs Move to first menu choice

Tue Dec 20 19:15:31 PST 2005

I went ahead and changed the context menu "Move to first(back)" to
"Bring to Front" and "Move to last(front)" to "Send to Back"

Also, I changed the Edit menu so that they choices were in the same
order as the context menu.

It seems to me like the Edit menu Bring to Front and Move to Last work
fine, but there are problems with the context menu.  I'll take a look.

I'm questioning about having the context menu have the same
keybindings as the Edit Menu.  This is starting to play in to the Cut
and Paste choices on the context menu Kepler bug.  It would be nice to
see that Kepler bug resolved in a way that makes Edward happy and the
Kepler group happy.  

About the parameter ordering changes that Edward describes:
1) Start Kepler
2) File -> New -> Graph Editor
3) Search for Parameter
4) Drag a Parameter on to the canvas three times
5) Right click on the background, select Configure
6) Note that the parameters are listed in Edit Parameters
   Parameter:
   Parameter2:
   Parameter3:
7) Close the Edit Parameters window
8) Right click on Parameter2 and select 
   "Bring to Front" if you have rebuilt Ptolemy
   Or
   "Move to First" if you have not rebuilt Ptolemy or are
   using alpha8. 
9) Right click on the background, select Configure
10) Note that the parameters are listed in Edit Parameters
   Parameter2:
   Parameter:
   Parameter3:

Yes, there should be a better way to reorder parameters.
Alphabetizing has been considered, but was rejected at some point.
Perhaps we wanted to be able to group by function of something?

Perhaps alphabetizing is the way to go?  This is much like
alphabetizing fields and methods in Java classes.  Ultimately it is a
win, though some expressiveness is lost.

It seems me that using the "Bring to Front" menu choice to order
parameters is ingenious but confusing.  Perhaps this menu choice has
too many meanings?

One thing I have seen for setting the order of a list is a specific
dialog that allows the items to be dragged and dropped or otherwise
reordered.

_Christopher

Laura writes:
--------

    The common commands for ordering overlapping objects in many graphics
    programs are:

    Bring to Front
    Send to Back
    Bring Forward
    Send Backward

    So I would recommend those.

    And yes, I would recommend that the commands (whatever they are), are
    phrased the same in the main menu and the right click (context) menus.
    (Was that too polite? ;-) )

    I don't know if I quite understand the issue you described about the
    ordering of parameters in the config dialog.  So you are saying that the
    parameters are listed bottom up as first to last?  But even so, I don't
    think that will cause a huge usability issue other than the few users that
    notice the order is reversed from what they might have expected.  The order
    of the parameters as listed has no inherent meaning does it?  And if not,
    then the most important thing is just that all the parameters are there for
    adjustment if desired.  In fact one way to do things would be just to
    alphabetize the parameters, which is a standard expectation of things in
    lists.

    Laura L. Downey
    Senior Usability Engineer
    LTER Network Office
    Department of Biology, MSC03 2020
    1 University of New Mexico
    Albuquerque, NM  87131-0001
    505.277.3157 phone
    505.277-2541 fax
    ldowney at lternet.edu

    -----Original Message-----
    From: kepler-dev-bounces at ecoinformatics.org
    [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Edward A. Lee
    Sent: Monday, December 19, 2005 9:39 PM
    To: Christopher Brooks
    Cc: ptresearch at chess.eecs.berkeley.edu; kepler-dev at ecoinformatics.org
    Subject: Re: [kepler-dev] Bring to Front vs Move to first menu choice

    Oops... These menus should have the same labels (the menu bar menu and
    the context menu).  I just checked, and they both do the same thing,
    and the Ctrl-F and Ctrl-B bindings work.  To check this, create decorative
    objects in a Vergil screen (graphical elements like rectangles, text, etc.)
    and the select them and select Ctrl-F or Ctrl-B.

    For the record, "Send to Back" seems more user friendly, but
    "Move to first(back)" is more technically correct.  The fact is,
    you can invoke these commands on any attribute, and it will affect not
    just how they are rendered, but also in what order they appear when
    you edit the parameters of the container...

    I agree with what Laura will inevitably think (but is probably too
    polite to say :-) that this is pretty confusing... But it will also be
    confusing if one chooses "Send to Back" on a parameter, and it has
    the side effect of putting it first in the Configure dialog...
    I don't have a good answer here...  Perhaps we should just go with
    "Send to Back" and hope nobody notices :-)

    Note that I recently made it so decorative elements (which are just
    attributes with icons) would appear behind or ahead of objects
    of an entirely different type (e.g., text can be put behind or in front of
    an actor). This didn't used to be the case...

    Edward

    At 12:33 PM 12/19/2005 -0800, Christopher Brooks wrote:
    >Edward writes:
    > >    Note that I would not use Ctrl+F for Full Screen...
    > >    It is currently bound to "bring to front", which is a fairly common
    > >    choice in graphics software, and is far more commonly needed than
    > >    Full Screen.
    >
    >Ok, this is a little confusing.
    >
    >What we have now is the Edit menu (above the toolbar) has
    >Send to Back   (Ctrl+B)
    >Bring to Front (Ctrl+F)
    >(These are defined in vergil/basic/BasicGraphFrame.java)
    >
    >The context menu for an actor has
    >Move to first(back)
    >Move to last(front)
    >(These are defined in vergil/kernel/AttributeController.java)
    >
    >It seems to me that these are one and the same, but I guess they are
    >not?  How are these different?
    >
    >What got me started was I was expecting "Move to first (back)" to have
    >a Ctrl+F shortcut, but it did not.
    >
    >Is there any way we can combine something here?
    >
    >_Christopher
    >

    ------------
    Edward A. Lee
    Professor, Chair of the EE Division, Associate Chair of EECS
    231 Cory Hall, UC Berkeley, Berkeley, CA 94720
    phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
    eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  

    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------