Community
Participate
Working Groups
To reproduce: 1. Create and instantiate a multi-instance view with a non-empty secondary ID. 2. Activate another view. 3. Use Ctrl+3 and type in the name of your multi-instance view. Observed: - A new instance of the multi-instance view opens. (Presumably an instance with a null secondary ID). Expected: - An existing instance of the view is activated.
Window -> Show View has the same problem
You can reproduce this with the console view.
This is not specific to Ctrl+3: Window>Show View exhibits the same behaviour.
Sounds like the org.eclipse.ui.views.showView command needs another parameter for the secondary ID.
(to start with)
Actually (good thing these comments are free) I dont know if this would even be possible. You can't have a parameter keyed on the value of another parameter can you? IParameterValues doesn't accept an arguement or initializer of any kind...
I can add the secondary id to showView command, and if you bind it in a plugin.xml or programmatically it would work fine. But the keybinding preference page doesn't have anything like the CommandComposer in UA, which allows users to just fill in parameters (much more like an multi-field editor), it generates combinations based on the IParamterValues. A possible enhancement (I think we already have a bug open about it) would be to have the keybinding preference page show existing bindings and "parameterized markers" that could somehow open something to fill in required and any optional parameters that a command could take. That being said, I can add the secondary ID parameter for use, but massive modifications to the keys preference page is not on my plan for 3.4. PW
> A possible enhancement (I think we already have a bug open about it) would > be to have the keybinding preference page show existing bindings > and "parameterized markers" that could somehow open something to fill > in required and any optional parameters that a command could take. YES! I think I suggested that when the whole parameterized command thing was first written. That would simplify the code and give us a prettier UI. It would also fix the explosion of unbound command IDs that are cluttering the keybindings page. That is, there would only be ONE command ID for show view that opens a "choose a view" dialog when you bind to it rather than having 100s of "show view x" commands. It would also permit a wider variety of commands - for example, we could have commands that run a user script or that execute a sequence of mouse gestures - stuff that can't be easily enumerated. It would also speed up the extension point, since it would no longer be necessary to enumerate all possible command arguments when gathering the list of command IDs. For an example of how it might work, check out the extension points for the JDT classpath containers. They use this pattern and it works quite nicely. That is, the data stored in a classpath container is just an arbitrary string. They have one extension point that interprets that string and performs behaviors based on it, and another extension point that provides a UI for editing the string. The string itself could be XML or some arbitrary persistence format known only to the implementor of the two extensions. If you don't have a bug report for it yet, it would be awesome to track this somewhere.
Remy is now responsible for watching the [ViewMgmt] category.
Created attachment 156692 [details] show views with secondary IDs v01 This updates the showView command to take a secondary ID, and the Window>Show View menu to display open views with secondary IDs as well as the shortcuts. No update to quick access, though a similar pattern could be applied there. PW
Created attachment 184232 [details] Patch v02 Patch v01 + support for Quick Access
Patch v02 released to HEAD
Verified in I20110124-1800
Reopening as the ui.workbench part did not make it into the 4.x stream.
Aggregate move to M5. Retarget to a different milestone if you wish...
The commit to work with: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b6ec935e2251d9dc6a7cbc25d9ca57d1104f7179 PW
The patch has been already ported to the 4.x version. However got adjusted to the E4 architecture Daniel
