Re: Fw: [platform-ui-dev] Key Binding Problem

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

some more thoughts..

- you should bind the key in the debug
context. you should make sure you are in the debug context while working
in all those views and editors where ctrl+shift+d can be pressed. can ctrl+shift+d
also be pressed when the popup is open? - if so, we will have to make sure
you are also in the debug context when the popup is open. 

- you should not need any other contexts,
and again i don't think you should be defining a context for debug popups.
i'm not sure what you mean by 'competing in a global namespace'. if you
have defined the key binding in the debug context, and you are in the debug
context, you will get the key over any command that defined a key binding
to the same key in the global context.

- register your actions in whatever
views and editors you need using key binding service. or put it in an action
set (make sure to set the 'actionDefinitionId'). (shortly, you will have
a new way of registering 'handlers' to commands which is even easier)

- when the popup is open, why don't
you just put a key listener for the enter key, and call the action directly?
are you not receiving enter in the popup? if enter is the only key that
should work in the popup (besides esc to dismiss), perhaps you should not
be registering your shell for key bindings - then you will receive enter
(and esc) for sure.

- regarding the asynchronous updating
of the command manager - i'm not sure how this is possible, i'll definitely
want to discuss this further with you. if you set the debug context, you
should immediately be able to get the command's keybinding which considers
that scope, without adding the listener. we can definitely sort this one
out with you..

this is now a pretty esoteric problem
- perhaps we can take this offline?
if you'd like to set up a call we can
do this as well..

thanks,
chris.


> Forgot to mention... all of this is to say that
this is what we've done. 
> It works, but we wonder if there might be a better solution to our
> problem:
> 
> * How can we avoid competing in a global namespace for keybinding
when the 
> debug popups are visible?
> * If it requires a new scope/context, then how can we retrieve keybindings
> for commands in a static way (i.e. all defined keybindings for a command,
> independant of what scopes are currently active)?
> 
> Darin
> 
> ----- Forwarded by Darin Wright/Ottawa/IBM on 03/03/2004 08:08 AM
-----
> 
> Darin Wright/Ottawa/IBM
> 03/03/2004 08:06 AM
> 
> To
> platform-ui-dev@xxxxxxxxxxx
> cc
> 
> Subject
> Re: [platform-ui-dev] Key Binding Problem
> 
> 
> 
> 
> 
> 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 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