ParaView and VisIt viz services depend on specific connection services

[anarak]

ParaViewVizService and VisItVizService classes extend from ConnectionVizService<T> and both pass to parent class the type IParaViewWebClient and VisItSwtConnection respectively that have been provided to EAVP by the owners of the viz tools. To run these services without Eclipse tools (swt), the class types must not be hardcoded but passed dynamically depending on the execution environment or new web services created instead.

VisItVisService: https://github.com/eclipse/eavp/blob/master/org.eclipse.eavp.viz.service.visit/src/org/eclipse/eavp/viz/service/visit/VisItVizService.java

ParaViewVisService: https://github.com/eclipse/eavp/blob/master/org.eclipse.eavp.viz.service.paraview/src/org/eclipse/eavp/viz/service/paraview/ParaViewVizService.java

[SmithRWORNL]

@anarak IParaViewWebClient is one of our classes. Unlike the VisIt server, it's a part of EAVP, and can be found in the o.e.e.viz.service.paraview.web bundle.

[anarak]

@SmithRWORNL I was about to add that, thanks. I wanted to note that VisIt's connection service should be mostly in the focus.

[jayjaybillings]

We're co-authors on the VisIt package, which is here: https://github.com/visit-vis/visit_java_client

@SmithRWORNL and I both have write access to that repository, I think, and if needed I'm sure @HarinarayanKrishnan would be happy to point us in the right direction.

[HarinarayanKrishnan]

@jayjaybillings is correct, he has co-ownership rights to this repository. I also added @SmithRWORNL as an owner.

[SmithRWORNL]

In response to the questions about the createAdditionalPages() function on the interface from this morning, createAdditionalPages() is specific to the use case of a MultiPageEditorPart, providing the extra pages needed for e.g. the graph and text pages of a CSV Plot Editor.

As part of the refactoring to decouple pure EAVP from SWT implementations, it should be removed from the interface and be made part of the RCP specific drawing handler implementations as required.

[jayjaybillings]

Does it need to be public? That is, do we need to expose it outside of the handler?

[SmithRWORNL]

It needs to be public to the other RCP implementation classes so that it can be called, and so might be a good candidate for a function on a IRCPPlot interface. The issue is that a MultiPageEditorPart, which is the native way to have multiple tabs for our Plot Editor, has multiple Composites on which to draw, one for each page, so the naive approach of invoking draw() on a Composite is insufficient to populate one with different content on each tab.

[jayjaybillings]

Okay. Hm.

I take it that like most EditorParts it is called in a lazy fashion, so we don't know when it is called in advance, right? That is, we can't draw all of our pages a priori.

[SmithRWORNL]

I suppose technically we could pre-render and save a reference to e.g. a CSVPlotComposite and a Composite with a TextEditorPart and save them to our class, but we would still need some function that returns each tab's contents individually for when addPage() is invoked on each one to populate the MultiPageEditorPart.

[jayjaybillings]

I don't think that is necessary. I'll ponder it tonight.

[SmithRWORNL]

VisIt and ParaView will no longer be supported in 0.3