Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #185552 +++ As a replacement of the former RSE remoteSystemsViewPreferencesActions extension point, RSE should contribute an org.eclipse.ui.handlers extension with a paramterized handler for showing a particular Preference page. org.eclipse.ui.menus should be used instead of SystemCascadingPreferencesAction to contribute the Preferences submenu, and for registering a preference page action therein. Basically, current action class SystemShowPreferencesPageAction will need to be turned into a Handler.
Try to address for RC3
From bug 225506: Xuan you have some experiences with dynamic menus now. Creating this org.eclipse.ui.handlers extension should not be overly difficult, such that extenders can register their own preference pages into the RSE submenu by the org.eclipse.ui.menus extension point. If you think that you need this for any IBM product, you'd have to address it by M7 I'd think -- currently it's assigned to "Future".
I've been trying to workaround this issue without having to add api, but haven't been able to. Since the menu is dynamic I can't contribute a command to the menu.preferences/additions group. Since this is a regression from old IBM products we will need this in 3.0.1. Changed Priority/severity as appropriate. Martin, do you have any ideas for doing this with not adding api or are you okay with adding api for this issue in 3.0.1?
It looks like there are two issues: 1.) How to add a command to the menu where it's desired. I think that contributing additional commands to a menu should always be possible, by means of writing plugin.xml code only. If the desired menu is not capable of accepting such additional menu items this must be fixed. I would count this as a bugfix rather than API change: if only the way how plugin.xml is interpreted changes, it's binary compatible anyways (but would work in 3.0.1 but not in 3.0). 2.) How to execute a command that ends up showing a certain Preference Page. It looks like we'll need to register a Handler that's capable of doing that. Again, we'd only change the way how plugin.xml is interpreted so the change is binary compatible and I'm OK with it. See the org.eclipse.rse.terminals.ui / plugin.xml for an example of how to define a command and its handler. In this case, the handler would accept one required parameter from the command: the ID of the Preference Page to show. Actually, in order to be 100% sure I'd think that (2) can also be done in client code outside openRSE, so that would only leave (1) to get fixed in 3.0.1 - unless I'm missing something?
Created attachment 107168 [details] Example Contribution without API Change Doing this through the extension point would still be an api change as we would need a handler for the Remote Systems preference page currently. The attached patch fixes the issue without using the extension point and also shows using the org.eclipse.ui.menu's extension point with a command handler for adding a preference page to that menu. The handler is just a quick thing I put together. For 3.1 we can fix this up to be done using the menu's extension point and have a proper handler that everyone can use.
Very nice! The handler looks almost exactly like what I had though about. I only have few questions / modification requests: * If you make the commandId "internal" then I'd not consider this API. In this case, though, I thinkI'd prefer the commandId to be in a public non-internal namespace since this is something we'd want to encourage adopters to use. * The parameter of the handler is public API, so the parameter's ID should not be "internal". * The two concrete menu entries (UniversalFilesPreferences and SystemCachePreferencePage) should of course live in the rse.files.ui plugin and not in rse.ui * I think it would make sense to make the Parameter optional, and if it is not given then fall back to showing the "Remote Systems" Preference page plus its entire subtree in the Preference tree. This way, the command could be bound to a keyboard shortcut if anybody wanted to do that. * It looks like your patch makes the SystemCascadingPreferencesAction class obsolete, so that one should be removed. In terms of the API or Not? Question, I think it is OK adding this (with non-internal ID's) into RSE 3.0.1 -- the effect of running some software that uses the new feature with RSE 3.0 is that there are two entries in the Error Log saying that the corresponding command ID's are not defined (and, of course, the menu items are not created). So, the program that's written against RSE 3.0.1 does still link and run against 3.0 -- it just prints the warnings and misses the feature; this could be treated like a bug in 3.0 which was fixed in 3.0.1 Therefore I'm ok having this in 3.0.1 if you want, but I'm also OK with waiting till 3.1 -- but not till the Future, so I'm setting target milestone 3.1 for now.
PS I'd propose also adding Documentation to the rse.doc.isv explaining how to use the handler and menu extension, especially since this is a feature which replaces something that was an extension point in a former life.
Created attachment 107279 [details] Proposed patch for 3.0.1 I propose this patch for 3.0.1. Same as the previous one minus my example code I had for using a handler and removing SystemCascadingPreferencesAction. For 3.1: 1. Change our current Action to a Handler. 2. Remove all code for creating the submenu and Remote Systems... action and do it all through the menu's extension point. This way the Remote Systems preference action is also a command. With this the parameter to our handler would be required. Doing this in 3.1 is not possible as changing the Remote Systems... action to a handler and using the menus extension point would require new nls as the label for the command is specified in plugin.properties and it is not currently.
Committed proposed patch for 3.0.1. Leaving bug open to address doing this all through extension points in 3.1.
Created attachment 108338 [details] Additional patch adding some comments Attached additional patch adds some comments to the code, i.e. * indicate HelpContext "actnpref" obsolete * indicate ACTION_CASCADING_PREFERENCES_TOOLTIP obsolete * Purge code of references to obsolete SystemCascadingPreferencesAction * Add comment to plugin.xml how to add command for adding preferences action. Committed: [186769] Add comments about how to add RSE preference page actions
Moving deferred 3.3 api items to 3.4
Clearing target milestone for deferred items.
