Community
Participate
Working Groups
To further move away from the legacy action concept I propose to extend the Jobs API to allow a ParameterizedCommand to be added to a job instead of an IAction in IProgressConstants.ACTION_PROPERTY. The new property IProgressConstants.COMMAND_PROPERTY would either accept a String or a (Parameterized)Command. If the user sets a string it must be a valid deserialized command String. The command would be executed with the workbench evaluation context snapshot taken when the user calls the setProperty method on the job. Or would that drag in to much workbench code into the Jobs API?
>Or would that drag in to much workbench code into the Jobs API? Yes, the jobs API can't have a dependency on the commands API. However, I don't think it's needed here. IProgressConstants is defined at the UI level, and they can store/retrieve any objects in a job property, so what you suggest is possible without changes at the job API level (jobs don't know anything about JFace actions either, which is what is currently used here).
*** This bug has been marked as a duplicate of bug 206403 ***
