I don't think the Debugging Pop-up context
will work as a child of the dialog context. The popups are actually Shell
objects (similar to hovers). They aren't dialogs, and as far as I know
the workbench doesn't know about them at all, so it couldn't promote the
dialog context for us. I think we have to leave them under debugging
Ideally we'd like to make debug popup
context go away, but we haven't found a way to do that and still maintain
the functionality (binding the enter key). This is something that we had
planned on revisiting.
Douglas Pollock <douglas.pollock@xxxxxxxx>
03/17/2004 01:08 PM
Please respond to
Jared Burns <jaredburns@xxxxxxx>,
Changes in Context Structure
I would like to change the context structure slightly. The change
support key bindings in dialogs. I propose a new parenting structure:
The workbench would be responsible for promoting and demoting the
dialogAndWindow, window and dialog contexts. There would be new semantic
that these three special contexts have the ability to "block"
from activating. So, for example, if the "window" context
is inactive, the
"Debugging" context would be inactive as well. This would
all be handled
transparently by the workbench.
"dialogAndWindow" would be active when either a window or a dialog
I wish to commit these changes for M8. These changes will break the
of existing contexts. For example, if I committed the code without
to "debug.ui/plugin.xml", all debugging keys would be active
debug context is active -- regardless of whether a dialog is open or not.
(Right now, key bindings never work in dialogs.)
Would you be willing to accept these changes? Do you have comments,
questions, queries, concerns?