Community
Participate
Working Groups
Need to create a single handlers extension point to replace existing extension points for browse handlers and jump handlers. The new extension point should be flexible enough to attach handlers to arbitrary commands. In particular, it needs to be able to handle the create command being introduced. The new extension point should be implemented without reliance on Eclipse extensions registry. The extension point needs to work when Sapphire is not running in an Eclipse/OSGi container. Part of this task is to create an editor for the extension point schema.
Generalizing this work item. The actions API as a whole needs to be re-worked. Current situation: An API exists for contributing actions to editors, pages, sections and content outline nodes, but it is is poorly suited for extending to property editors. Property editors such as default list (table with buttons) and default value (text box with optional browse button) present appearance that's similar to actions, but are largely not extensible. In the case of the value property, custom facilities exist for extending browse and jump capabilities. Requirements for new actions API: 1. Single API that is able to cover usecases of any UI part (editor, page, section, content outline node, property editor). 2. Allow multiple handlers to be contributed for one action by different parties. This should be mapped to a popup menu when action is rendered as a button and as a cascading menu when action is rendered as a menu item. 3. Better control for positioning actions and handlers in relation to each other. 4. Better control for suppressing or overriding system actions and handlers. In particular, the immediate tangible effect of this work is that default list and default value property editor should allow contribution of new actions and handlers. Exposing actions on other UI parts would be handled by separate work items as necessary.
> Are you aware that a large number of your recently edited bugs are getting a > '**' prepended to their Summary? Yes. It's a temporary process marker as we are migrating to open source.
Marking as fixed.
Verify all 4 requirements. One issue which is probably user error. I was able to add an editor action in the UI definition file. But when I copy the exact the same code into the sapphire-extension.xml, the action does not show up. <action> <id>Sapphire.Sample.Message</id> <label>message</label> <image>images/balloon-yellow.png</image> <key-binding>SHIFT+CONTROL+ALT+m</key-binding> <context>Sapphire.EditorPage</context> </action> <action-handler> <action>Sapphire.Sample.Message</action> <id>Sapphire.Sample.Message.Yellow</id> <impl>MessageBoxActionHandler</impl> <label>yellow message</label> <image>images/balloon-yellow.png</image> <context>Sapphire.EditorPage</context> <param> <name>message</name> <value>This is a yellow message.</value> </param> </action-handler>
User error. In the handler, impl cannot be relative as there is no import package equivalent. You have to use qualified class name.
The action still did not show up when I qualified the impl class. Anything else?
Ok. This is a bug. You've identified a pretty big flaw in how classes are loaded from Sapphire extensions. I have committed a fix. Please re-verify this bug from the beginning.
Verified.
