[kepler-dev] Bring to Front vs Move to first menu choice
cxh at eecs.berkeley.edu
Mon Jan 30 17:08:04 PST 2006
[This problem resurfaced, so I'm patching it back in to the thread
where it started.]
>2. In the icon editor, "Bring to Front" actually means to send to back,
>and "Send to Back" means the reverse thing, too?
> Christopher relabled these menu items, and got it backwards I think...
I just went ahead and swapped these.
The problem is that what we have here is two ways to order items:
1) The Edit Menu:
Edit -> Send to Back (Ctrl+B)
Edit -> Bring to Front (Ctlr+F)
2) The right context menu:
Send to Back (Ctrl+B)
Bring to Front (Ctrl+F)
One issue is the the key binding is actually handled by the Edit menu,
not be the right button context menu.
Thus, if you put the mouse over one of two overlapping actors, don't select
the actor and then type Ctrl+B or Ctrl+F, nothing happens.
If you select the actor, then the Edit bindings come in to play.
Another issue is that vergil.toolbox.MoveAction has
/** Indicator for move down. */
public static final MoveType DOWN = new MoveType();
/** Indicator for move to first. */
public static final MoveType TO_FIRST = new MoveType();
/** Indicator for move to last. */
public static final MoveType TO_LAST = new MoveType();
/** Indicator for move up. */
public static final MoveType UP = new MoveType();
The right context menu is set up by vergil.kernel.AttributeController:
.addMenuItemFactory(new MenuActionFactory(new MoveAction(
"Send to Back", MoveAction.TO_FIRST)));
.addMenuItemFactory(new MenuActionFactory(new MoveAction(
"Bring to Front", MoveAction.TO_LAST)));
The issue here is that the MoveAction.TO_FIRST seems to mean
"Put this element first in the list of elements in the moml file",
which means that it is drawn first and thus appears in the back.
So, TO_FIRST means "put it in the back".
In other news, black is white :-)
Maybe I have this right this time. Can someone update
ptolemy/vergil, rebuild and try it?
The common commands for ordering overlapping objects in many graphics
Bring to Front
Send to Back
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
Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM 87131-0001
ldowney at lternet.edu
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...
At 12:33 PM 12/19/2005 -0800, Christopher Brooks wrote:
> > 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?
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
More information about the Kepler-dev