Community
Participate
Working Groups
User has a parameterized command with two parameters. Now this command will be displayed in the Quick Access dialog as: --------------- Run (Runner: CoolRunner; Project: ABC) Run (Runner: MyRunner; Project: XYZ) --------------- It seems to me this would be clearer in some cases: --------------- Run with CoolRunner (Project: ABC) Run with MyRunner (Project: XYZ) --------------- So, a requested feature is to be able to use parameter(s) as a part of command's name. User will declare command's name i.e. in plugin.properties as: Some_Command_name = Run with {0} - '{0}' in command's name will be replaced with a value for a parameter with index 0; - parameter with index 0 would not appear in the list of parameters.
Created attachment 150632 [details] Proposed implementation This patch is against 3.5.0.I20090429-1800. Source code was imported using Plug-ins context menu 'Import as' - 'Source project'.
Created attachment 152320 [details] Missing NON-NLS tag was added
Mykola I applied both patches you prepared (for this bug and for bug 293453) and I noticed that when changing ParametrizedCommand.java you added invalid references to system libs. o.e.core.commands is supposed to run on J2SE-1.3 (see MANIFEST.MF) but you're using classes added in 1.4. This is very similar to what happened to o.e.ui.workbench in bug 298153. I'm afraid you'll need to update the patch.
Thank you for pointing this out, Tomasz. I'll take a look at this.
Created attachment 155065 [details] J2SE-1.3-compatible implementation
I'll have to look at this in M6 PW
(In reply to comment #5) > Created an attachment (id=155065) [details] > J2SE-1.3-compatible implementation I can't apply this patch (it's not a project or workspace patch, simply a git patch with 'a' and 'b' at the top). Please see http://wiki.eclipse.org/Platform_UI/How_to_Contribute PW
Paul, the patch will apply fine if you select 'o.e.core.commands' project on the Target Resource page of the Apply Patch wizard and when previewing the patch you set 'Ignore leading path name segments' to 1.
(In reply to comment #5) > Created an attachment (id=155065) [details] > J2SE-1.3-compatible implementation Patch applied fine following Tomasz instructions. Some comments that would need to be addressed: 1) it won't handle the case where there are 2 parameters and you want the second one as part of the name (it appends the ", ") Run with CoolRunner (Project: ABC, ) 2) what guarantees the order of the parameters? For example, a could a change in the configuration swap the order in the parameterizations array? (My guess is it's usually stable, but we don't guarantee the order) 3) it won't handler the showView case, with an optional parameter (my first one doesn't have the optional parameter). Show View Show the Error View 4) an extension of 1 and 3. A command with multiple optional parameters (say 3 optional parameters) wouldn't work, because {0} and {1} could be any combination of the 3. Updating and changing the algorithm to something more along the lines of ${parameter.id} and then not including that parameter.id later on would address #1, #2, and #4. That still leaves #3 as a problem that would need to be addressed before this would be accepted. I would also need to see a couple of the parameterized commands in the SDK switched to use this (we can't monitor if it works unless we're using it ourselves). A different approach: If this is about making it easy to find the command you want in Quick Access, perhaps the typing filter could be updated to work more like the one in Open Type (where the fragments that a user types produce appropriate choices). PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
