| Summary: | [Commands] Show View cannot be executed from the Command Composer | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Paul Webster <pwebster> | ||||||||||||
| Component: | UI | Assignee: | Paul Webster <pwebster> | ||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | eclipse, mike.pawlowski, wassim.melhem | ||||||||||||
| Version: | 3.3 | ||||||||||||||
| Target Milestone: | 3.3 M7 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | |||||||||||||||
| Bug Blocks: | 172321, 173206, 178228 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Paul Webster
Created attachment 61932 [details]
Work in progress - v01
Register the second type of dialog
PW
As it turns out, there are 2 types of dialogs eclipse. A dialog that expects to be a dialog :-) and a dialog that is part of the current workbench window work flow (like the command composer or the expanded hover icon bar). The dialog always removes window keybindings (which we want) and deactivates all workbench window based handlers (which we don't want). The first approach I'm trying is allowing dialog shells to register in IContextService#registerShell(*) with the TYPE_DIALOG_WITH_WORKBENCH constant. The getShellType(*) method will return TYPE_DIALOG, but the workbench services will be able to differentiate between dialogs that should deactivate workbench window handlers and dialogs that shouldn't. The default if you don't do anything will be the current behaviour. PW test should be: d.create(); //register shell d.open() Created attachment 62000 [details]
Dialog supports Workbench v02
A dialog registered with the correct constant will have the active workbench window available to its evaluation context.
PW
Created attachment 62012 [details]
Command composer supports workbench v02
This is the matching *draft* patch to the command composer that marks the dialog as "running with wolves" uh I mean workbench window.
PW
Since this requires new API, it will (unfortunately) have to be put off until 3.4 PW Perhaps a way to execute a command in a given context would work. PW Created attachment 64257 [details]
Handler Service v01
Currently internal methods, but a way to ask the handler service to execute the correct handler for a given context (and get a proper context snapshot).
PW
Created attachment 64547 [details]
Hander Service v02
As much as possible, execute a command within a specified application context.
PW
(In reply to comment #9) > Created an attachment (id=64547) [details] > Hander Service v02 Released to HEAD >20070422 PW A much more predictable approach is the allow the application context to be fed into the system and control the aspects of command execution (activate handler, enable handler, execute). The internal approach will suffice for 3.3 for use with PDE and bug 183810 has been opened to work out the API for 3.4 PW In I20070501-0010 PW |