Community
Participate
Working Groups
I think it would be beneficial if we provide nicer API for our Viewer. For example, we should make it easier to read the input for a viewer asynchronously. I suggest to add a new input method to Viewer with takes a Completable and runs this and internal uses the thenApply method to set the calculated input in the main thread to the viewer. Something like: setAsyncInput(Completable c);
Of course I mean: CompletableFuture
Karsten / Andrew, WDYT?
I'm also thinking about more async APIs for parts where we can do non-UI computational stuff in the background and do the UI updates on the main thread. CompletableFutures can be executed on Executors. By default, this would be the common fork-join pool. I think we should have an explicit Executor that executes on the UI thread. This could be made available on the Display class maybe. I'm not completely sure yet how we should design these asynchronuos APIs, but there are plenty places where we could benefit. I'm not sure if Viewer#setInput is an appropriate place to do that. If you pass a Future here to retrieve the input for the viewer, then the input computation has to be done async by the client. That's the more critical part. I think most clients won't be implemented to do so. Do you have something specific in mind?
I'm not sure that's the right approach. Think more MVC here. You have a viewer, and you have a model. The content provider is just a glorified accessor to the model. What you want to do is compute/update your model asynchronously in whatever way you want (CompletableFuture, or Eclipse jobs, or whatever). That background task notifies your controller, which then refreshes the viewer (or sets a new input on it, if it's a completely new model), which then uses the content provider to get the bits of the updated model that actually should be displayed in the viewer. Don't try to lump it all into that poor content provider. It was never meant to do everything.
My proposal was not to modify the content provider. I upload later a patch to show what I mean.
There is already such an API. The deferred content provider. https://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fjface%2Fviewers%2Fdeferred%2FDeferredContentProvider.html Frank Appel has (almost) perfected it here: https://www.codeaffine.com/2014/12/02/deferred-fetching-with-jface-viewers/
(In reply to Wim Jongman from comment #6) > There is already such an API. The deferred content provider. > > https://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc. > isv%2Freference%2Fapi%2Forg%2Feclipse%2Fjface%2Fviewers%2Fdeferred%2FDeferred > ContentProvider.html > > > Frank Appel has (almost) perfected it here: > > https://www.codeaffine.com/2014/12/02/deferred-fetching-with-jface-viewers/ Can you provide a Gerrit to bring Franks changes into platform?
See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=509006 And the correct API is IDeferredWorkbenchAdapter. IDeferredContentProvider is a different beast IIRC. From Frank: Deferred fetching of content should not be confused with lazy loading of elements using the SWT.VIRTUAL flag. While there are similarities between both approaches, virtual table and trees are generally useful for partial on-demand loading of large datasets. Deferred loading is helpful for reasonable sized datasets, which nevertheless might be time consuming to retrieve and therefore would block the UI thread. Consider fetching of remote data for example. And in case you wonder, both approaches are of course mutally exclusive…
-1 on this API in the Viewer, provide utility-APIs if you want, but leave the Viewer-API as small as possible
(In reply to Thomas Schindl from comment #9) > -1 on this API in the Viewer, provide utility-APIs if you want, but leave > the Viewer-API as small as possible Lets wait with feedback on the implementation until we have a Gerrit to discuss. Also as potential followup we could deprecate the blocking API and only promote async API. Blocking API was hip last century. Wim, I assume you plan to work on this?
(In reply to Lars Vogel from comment #7) > > Can you provide a Gerrit to bring Franks changes into platform? Yes I was planning to get this in for 4.15 *** This bug has been marked as a duplicate of bug 509006 ***
(In reply to Lars Vogel from comment #10) > (In reply to Thomas Schindl from comment #9) > > -1 on this API in the Viewer, provide utility-APIs if you want, but leave > > the Viewer-API as small as possible > > Lets wait with feedback on the implementation until we have a Gerrit to > discuss. Also as potential followup we could deprecate the blocking API and > only promote async API. Blocking API was hip last century. > so if I have sychronous code you want to force me to change that to async? I repeat that I don't think the way forward is to push async support into the viewer. There are multiple ways to address async (CompletableFuture, reactive-streams, ...) and you can not put support for all of them into the JFace-Viewer interface and nothing more was said in my comment. I don't -1 async support I just -1 doing that inside the Viewer-API.
