Long-running user query with busy indicator

[crapo]

@kittaakos , some of the user queries take long enough to answer that we need to give the user feedback that the process is running. I'm not sure how this can be done. I tried an approach where the DialogAnswerProvider has a method called from the AnswerCurationManager when doing a query. I thought I could use BusyIndicator.showWhile to call back to AnswerCurationManager to actually do the query while displaying a WAIT cursor, but I get an org.eclipse.swt.SWTException: Invalid thread access, I suppose because the thread running the AnswerCurationManager isn't a UI thread. Any suggestions on a solution?

[kittaakos]

Invalid thread access, I suppose because the thread running the AnswerCurationManager isn't a UI thread.

Correct. The current logic, which updates the text document during the build/validation, is already very complex. Since both the validation and the build run in a Job (another Thread), I am not sure if we can wait and sync the UI.

[kittaakos]

@crapo, are you aware of the "new" Eclipse Code Mining feature?

• https://www.eclipse.org/eclipse/news/4.10/pde.php#target-definition-code-mining
• Eclipse API: https://www.eclipse.org/eclipse/news/4.8/platform_isv.php
• A JDT example: https://github.com/angelozerr/jdt-codemining

We could do something similar. Instead of automatically inserting the answers to the document, we could make this as a user command. We could annotate the not yet answered statements and a user would actions in the editor: something like Answer this question, or Answer All. If a SADLModelElement is not followed by an AnswerCMStatement it is not yet answered. This would also work in the Web-world, once you want to use the Dialog language in another IDE than Eclipse.

• Language server protocol: textDocument/codeLens
• Code Lens in action (VS Code, Theia): https://code.visualstudio.com/blogs/2017/02/12/code-lens-roundup

Indeed it is a little bit bigger change, but if we could transform the user actions into text document modifications, with some extra work we could test it headlessly. We could resolve the busy indicator and all other threading issues. Just an idea though to keep it on the horizon.

[crapo]

It's kind of late in the game to make any big changes. We have another 6 weeks max to get to whatever will be our best end point. I don't think we care about waiting, but more like if the user doesn't do anything and the focus stays in the dialog editor window, any way to show a busy cursor?

[crapo]

or alternatively run the ACM process in a thread with a progress bar?

[crapo]

@kittaakos , have pushed grammar and code to master branch to test long running tasks. The statement to put in the Dialog Window is Long task 5000. The processing is in the AnswerCurationManager, starting at line 2758. The response to the Dialog when complete is CM: "Task took 5000 ms".

[kittaakos]

@crapo, do we work against SADL development? If no, which is the correct branch?

[crapo]

I'm using sadlos2 MissingPatterns right now

[crapo]

@kittaakos , have pushed grammar and code to master branch to test long running tasks. The statement to put in the Dialog Window is Long task 5000. The processing is in the AnswerCurationManager, starting at line 2758. The response to the Dialog when complete is CM: "Task took 5000 ms".

[kittaakos]

I'm using sadlos2 MissingPatterns right now

Thank you!

[kittaakos]

This won't work, unfortunately. As you can see, the long-running logic was triggered by Eclipse Jobs; I cannot call UI code from there.