Community
Participate
Working Groups
At the moment every backend job is marked as system=false and user=false therefore the job is listed in the progressbar and can be aborted if the ProgressView is started. This is fine but... 1. If a ClientSyncJob with a backend call is executed the user should be blocked. In fact he can still click on GUI components which should not be possible. -> Blocking jobs must really block, no interaction with the gui should be possible beside aborting the job. This can be achieved with the following mechanism: IWorkbenchWindow activeWorkbenchWindow = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); activeWorkbenchWindow.run(true, true, progressBarJob); or with a progress dialog if a modal dialog prevents from aborting through the progress bar. ProgressMonitorDialog dialog = new ProgressMonitorDialog(PlatformUI.getWorkbench().getActiveWorkbenchWindow().getShell()); dialog.run(true, true, progressBarJob); 2. Backend calls of a smartfield should not be marked with system=false because they should be abortable anyway (with the ESC button). At the moment lookup calls are set to system=true but this has no effect since not the lookup call is visible in the progress view but the Backend Call. -> Maybe the properties system and user should be passed to the backend job? 3. ClientAsyncJobs should not block but they should be abortable and listed in the progressView. So they need to be system = false and user = false. -> Backend Calls of clientSyncJobs and ClientAsyncJobs must be distinguishable in order to block the GUI on clientSyncJob calls but not on ClientAsyncJob calls. 4. It must be possible to create a job which shows a progress, is blocking and abortable without necessarly calling the backend. Imagine I have a long running file system operation on client side which must be abortable.
Parts of this bug have been fixed in bug 362687. system=false/true
Solution proposal: IPingservice.ping is never visible and never cancellable (as it is now). Adding a job decoration service IRemoteServiceCallJobDecoratorService to support for custom implementation (RJ=remote service call job). Default implementation Swing for sync ClientJob: Job creates RJ with system=false (thus cancellable), since the sync job is never cancellable. Default implementation SWT/Workbench for sync ClientJob: Job creates RJ with system=true (not cancellable) but adds a phantom job with IWorkbenchWindow.run(true, true, progressBarJob) to block the ui after a certain amount of time. This blocking job is cancellable in the status bar. Default implementation for all other jobs: Job creates RJ with system=true (not cancellable), since the calling job can set itself to system=false to be cancellable. This is detected by the remote service facility (HttpServiceTunnel) and sends a transcation cancel to the back-end. Hint for developer using eclipse jobs: In order to create a job that is cancellable and does something when cancelled (i.e. interrupt): create a Job, set system=false, override the method canceling, call getThread().interrupt();
Checked possibilities in swing and swt: Added busy handling base to scout client as IBusyManagerService and IBusyHandler with AbstractBusyHandler convenience. ClientSyncJob is the scout concept of "blocking" ui without loosing responsiveness. Swing and SWT attach a default implementation in their AbstractSwingEnvironment / AbstractSWTEnvironment. Swing uses a glass pane, SWT uses the form head section with body disabling to show blocking.
Fixed these issues and unified in a busy concept where the scout ClientSyncJob represent ui processes that are automated to show busy and after a long time block the form. Then the form header shows a cancel button to cancel then action. That way if multiple scout apps run in the same workbench, only the effective scout app that is running a long Client SyncJob is busy/blocked. Other parts are still idle and editable.
ticket closed. deliverd as part of eclipse scout 3.8.0 (juno release train)
