[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Key Binding Problem
|
Darin Wright wrote:
I've been looking at this problem with Kevin, so I will join in...
1) The Java debugger defines a command for "Display" (CTRL-Shift-D)
2) The command is currently associated with the global scope, but could be
associated with the debug scope.
The whole key mapping thing would be much improved if you just removed
the global scope. The only things that truly belong there are Ctrl-X,
-Z, -C and -V.
Bob
> The command is valid in the Java editor,
Scrapbook editor, and in the details pane of the variables view (so it's
*not* just for editors).
3) The debug scope is unlike other scopes, as it is not bound to a
specific part. The scope is bound to the fact that something is being
debugged. The stepping commands have to work no matter which part has
focus - the editor, debug view, variables, etc. Thus, the debug scope
(although it comes and goes), is really part of the global scope (i.e.
competes in the same namespace).
4) The "Display" command performs an evaluation, the result of which is
shown in a popup. For convenience, we'd like the "Move result to Display
View" command to be bound to the 'Enter' key when the popup appears. For
example, you perform an evaluation, like what you see, decide to keep the
result, and simply press 'Enter' to save the result (or 'Esc' to dismiss
it). However, if we keep the scope of the pop-up in the global scope (or
debug scope), then we are competing in a global namespace for keybindings
(and 'Enter' will not work).
The issues with retrieving the keybinding of a command, to display in a
label are these:
1) When a command is queried for its bindings,
(ICommand.getKeySequenceBindings()), it only returns the currently bound
key bindings (based on which scopes are active).
2) When a scope (context) is activated, the command manager and
keybindings are updated asynchronously. Thus, activating a scope, and
immediately querying a command for its new keybindings does not result in
new keybindings. You have to wait for the command to update. This can be
done with a command listener. The interaction works, but seems complex -
i.e. add yourself as a command listener, enable a context, wait for the
command to update, and then retrieve the keybinding. This is, of course,
due to the transient nature of our "popup" scope.
3) We currently register the popup shell with the keybinding service to
overcome the problem of dialogs not being considered for keybindings.
4) The behavior in the popup is poor, since when we open the popup we
display the label - but we don't yet have the complete label since the
keybinding is not yet updated. Thus, the label changes after it becomes
visible. This causes an "animated" label, and changes the size of the
label, which means that sometimes, the entire label is no longer visible.
Since we did not have the complete text of the label before the popup
became visible, the popup does not get a chance to perform default size
calculations properly.
We have created the "debug popup" scope to avoid competing with the global
namespace for keybindings, and to provide the user with a nice keybinding
for accepting the evaluation result. I.e. its a common user interaction to
press 'Enter' when a dialog appears to accept the result (similar to
pressing Enter to activate the OK button on a dialog, which is the default
button/action when a dialog appears).
Darin
Chris McLaren/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
03/03/2004 12:16 AM
Please respond to
platform-ui-dev
To
platform-ui-dev@xxxxxxxxxxx
cc
Subject
Re: [platform-ui-dev] Key Binding Problem
Hi Kevin,
I tried the popup today. Question: If I have a valid selection, but the
mouse is elsewhere, do I have to see a popup? Should I not be able to just
select in the editor, press Ctrl+Alt+D, and be done with it?
Here are my thoughts. Debug should:
1. Define a command 'Add To Display View'.
2. Add a key binding to this command ('Ctrl+Alt+D' was it?)
3. If the command only makes sense in the editor, register an action
through the key binding service. Do it early in the game (around editor
creation time, not when the popup shows).
As long as the editor is *the active part* the key binding will invoke the
action, and the key binding can be customized without you doing any extra
work.
If you want to display the key binding for this command at any time,
either in a popup or not, you can do this:
ICommand command =
PlatformUI.getWorkbench().getCommandSupport().getCommandManager().getCommand("org.eclipse.debug.whatever.addToDisplayView");
This will get you a command object, which among other things, allows you
to query for the real key binding(s)
(after the user gets to customizing it, it might not be assigned to
Ctrl+Alt+D anymore).
I can see two *potential* problems for you:
A. When the popup is open, the editor is no longer the active part (? -
I'll have to check this.) If so, your command wouldn't reach the action
registered in key binding service.
You have two possible solutions to this:
i) Register a key listener in your popup shell and process the keys
yourself. Admittedly, this is a pain for you if the user has customized
his key sequence to one with multiple keystrokes (emacs style). If the
user presses the correct key sequence, close the popup (to give the focus
back to the editor), and call command.execute() to execute the command
programmatically.
ii) Wait until we can give you automatic key binding processing for child
shells, which is coming for M8 or early in M9.
B. If you've defined the keybinding to the command *in a particular
context*, like 'debugging', that context may not be active when the popup
is open, and hence the keybinding won't be considered to be assigned to
the command at that time. I'll have to check this out for you, or you can
simply do a test and check with the context manager which contexts are
active when the popup is open. If 'debugging' is not active, please file a
bug to me. Your solution to this, at least for displaying the keysequence,
is to obtain the keysequence to the command immediately before the popup
opens.
The rest of your post kind of lost me a bit :)
- Why do you want to allow users to map keys to close popups? i assume you
mean map keys to execute the command, a side effect of which would be
closing the popup?
- I don't think this is a case for contexts at all, and would definitely
advise not declaring a context for 'debug popups'.
- I don't understand what the problem is with the CommandManager 'not
updating right away'.
Please email Doug Pollock and/or myself, or call either of us at the
Ottawa Lab and we'll walk you through this.
Thanks,
Chris.
Kevin Barnes/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
03/01/2004 03:55 PM
Please respond to
platform-ui-dev
To
platform-ui-dev@xxxxxxxxxxx
cc
Subject
[platform-ui-dev] Key Binding Problem
Hello UI team,
I've been working on the Inspect and Display actions for debug a lot
lately and have encountered a problem that I cannot find a work-around
for.
You've probably noticed that the "Display" and "Inspect" actions use
pop-ups now. Last week I week I was working on creating a key binding to
dismiss the popup to allow for user configurability, but also to prevent
some focus issues that we were having before we started using key
bindings.
Because the new key binding that we created only needed to be active when
the popup was actually visible, and because we wanted the user to be able
to map "Enter" to the command to dismiss the popup, we created a new
org.eclipse.debug.ui.debugging.popups context for our command. When the
popup becomes visible, we enable the context and register our action with
KeyBindingService. Once the action is registered we want to set a label on
the popup that says something like "Press XXX to Move to Display View."
Our problem is that the CommandManager doesn't actually updateCommands()
right away. This means that the KeyBindingSequence isn't available when
our popup become visible and we are forced to change the Label while the
popup is visible (we're doing this with a CommandListener right now).
Is there anyway to get the KeyBindingSequences from the command sooner? Or
is there a way to force the CommandManager to update our command so that
we can get the KeySequenceBinding from it before the popup is visible?
Kevin
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
