Open with

[will-moore]

"Open With" plugins allow configuration of additional viewers etc for objects in web.
In this PR, we define the open_with setting and implement this in right-click menu of jsTree.

Docs at ome/omero-documentation#1543 are the starting point for testing this PR. More (same) details below if needed.

In the simplest case, viewers are specified as a url that takes no IDs, E.g. webtest/myViewer/ and when an image(s) is opened with the viewer, webclient will open the url as webtest/myViewer/?image=1.
This allows the reverse(url_name) to be called without any image IDs and selected images etc can be added by JavaScript.

The minimum needed to specify a viewer is "label" and "url_name".

$ bin/omero config append omero.web.open_with '["My viewer", "url_name"]'

We use reverse(url_name) to resolve viewer.
The 'Open With...' > viewer will only be enabled for single images by default and will be opened in a new window (same as standard viewer).
To allow multiple images or other objects to be opened in the viewer, the open_with config can include an options dictionary with:

• supported_objects: list of supported types. E.g. ["dataset", "images"] will enable the viewer when a single Dataset or 1 or more Images is selected.
• target: set this to "_blank" to open the viewer in a new tab (instead of new window).

E.g. OMERO.figure - enabled with multiple images selected.

$ bin/omero config append omero.web.open_with '["OMERO.figure", "new_figure",  {"supported_objects":["images"],"target":"_blank"}]

Further customisation can be provided by including a script with JavaScript functions to define whether the plugin is enabled (for a selected set of jsTree nodes) and how to handle the menu "action".

To test 'open with' with script. E.g. with viewer-ng installed:

• create a file omeroweb/webclient/static/webclient/viewer-ng-openwith.js with this to provide custom Url provider:

OME.setOpenWithUrlProvider("viewer-ng", function(selected, url) {
    url += selected[0].id + "/";
    return url;
});

• Config:

$ bin/omero config append omero.web.open_with '["viewer-ng", "viewer_ng_index", {"script_url": "webclient/viewer-ng-openwith.js"}]'

You can see the config that the webclient consumes by visiting:
webgateway/open_with/

[gusferguson]

@will-moore

Tested with https://cowfish.openmicroscopy.org/merge/webclient/ user-3 read-only-1

The workflows all make sense and are good. Cuts out a few steps creating a figure and should make sense with use of different viewers.
Behaves as expected.
Screenshot below shows "Test" window.
Good to merge.

[joshmoore]

Before merging, I'd be up for a design discussion on this (sorry if I already missed one) similar to the API one. For example, is there any potential for allowing the registered functions to filter themselves out of a list, for example if a 3D viewer doesn't want to show up for 2D images? Do external URLs work as well or must they be installed as an app in OMERO.web? Will the menu be available for all elements in the UI or just for the images in the left-hand panel? Can we do anything with PDF file annotations or OMERO.tables down the road?

[sbesson]

Also before merging anything on develop, we should have a conversation on the timeline/plan for splitting dev_5_2/develop now 5.2.3 is tagged and we do not have an active 5.2.4 release planned.

[jburel]

Actually I wanted to have a call about it this am

[jburel]

card https://trello.com/c/RLvGaXUK/16-list-of-available-viewer-plugins for further discussion

[will-moore]

@joshmoore There's not been a design discussion yet since this was initially considered to be a very simple "list of image viewers". In this PR I've gone a bit beyond that to support all objects that are in the left-hand tree (E.g. "dataset" in the example above).
We could go further to allow adding a JavaScript function that is passed the currently selected tree nodes and returns enabled true/false. This is similar to what we do for the centre/right panel plugins.
However, it will only have the info that is in the jsTree (which currently includes dtype, id, name, sizeX,Y,Z).
I can't imagine how you'd open something in OMERO using an external URL (unless some external site knew how to access your server - E.g. you're using a public repo) but this is way beyond what we're planning here.
We could potentially add the "Open with..." options to anything in the UI including annotations if we want.
Happy to discuss this anytime. I guess @chris-allan might be interested too?

[pwalczysko]

The workflow for Figure works for me as well and seems logical. I suppose the Dataset on Figure makes no sense, as it does not open anything, but I understand this is just for now and just for testing.

[jburel]

Marking it as onhold so it is not listed. Further discussion to happen

[will-moore]

Updated description with how to use JavaScript to handle enabled status and "Open With" action.

[joshmoore]

Open with "Genbank Protein" will only be enabled when a single object is selected and the name of the object is a number. The action will be to open http://www.ncbi.nlm.nih.gov/protein//
See example in ee70460

A possible next step for the IDR metadata, @will-moore, might be to convert the multiple map annotation rows for a gene (name, URL, identifier, etc) into a single-annotation with a given namespace. For something like this, would using the namespace and/or the contents of the map annotation be possible for triggering the open with?

cc @eleanorwilliams

[manics]

You could add a namespace attr to NamedValue

[joshmoore]

You could add a namespace attr to NamedValue

That'll need a design issue itself 😄

[will-moore]

@joshmoore You'd need to have the "Open with" menu on the annotation itself, not on the parent in the tree, since the tree has no knowledge of annotations.
Probably the biggest issue is adding a drop-down / context menu to annotations in the right panel. We don't have an easy way to add menus - each needs a bit of JavaScript hand coded etc.

[will-moore]

@joshmoore With that last commit, I added experimental support for File Annotations. I've used a simple select chooser (we might want to make a nicer dropdown in due course) that uses the same 'Open With' list as in the jsTree. The json data that is passed to the isEnabled() and handleAction() javascript functions is the same format for the jsTree menu and the FileAnnotation menu. E.g.

# Image
{
    type: "image",
    id: 3727,
    date: "2014-08-22T00:30:14Z",
    name: "a-range-start CSFV-GFP09_1_R3D_D3D.dv_proj-1",
    ownerId: 3,
    sizeX: 552,
    sizeY: 552,
    sizeZ: 1
}

# File Annotations
{
    type: "fileannotation",
    id: 17557,
    file: {
        path: "",
        size: 8958,
        id: 22757,
        name: "demo - paris"
    },
    ns: "omero.web.figure.json"
}

Since there's quite a bit to digest here, I think the easiest would be for me to demo this to those interested and we can discuss where we go from here. cc @aleksandra-tarkowska

[joshmoore]

Nice, @will-moore. Looking forward to it.

[will-moore]

@waxenegger I made supported_objects OR script_url required and updated docs at ome/omero-documentation#1543

[waxenegger]

@will-moore: that's working nicely. and if there is a script error in the handed in script the option is disabled which is good as well I'd say.

[will-moore]

Thinking more about making this re-usable by other apps, such as OMERO.figure.
I think that instead of an 'action' handler for when the user clicks on the 'Open With' option, plugins could instead implement a 'get_url' function, and then the webclient / figure etc could open that url or provide a link for users to click on. This would mean that the 'Open with' list could be a list of links, instead of dynamically handled actions (as in the jsTree menu).
Question is, do we want to restrict 'Open with' plugins to simply providing a url (instead of doing something fancy in JavaScript)?
I think we can do everything we want to with a url. We could always add back an 'Action' handler later if needed?
cc @waxenegger @joshmoore @aleksandra-tarkowska @jburel @chris-allan.

[will-moore]

I changed the setOpenWithActionHandler() to instead use setOpenWithUrlProvider() and the function you provide here should return a url instead of actually opening a tab/window with that url.
This allows the script to be used to provide links as used in OMERO.figure ome/omero-figure#179.
Need to update docs...

[joshmoore]

@will-moore : What impact does that change have on some of the as yet unimplemented ideas expressed earlier like #4630 (comment)?

[will-moore]

@joshmoore The last change doesn't affect extending the Open With functionality to other types or use in other places. In fact, it will make it more versatile.
Removing the exclude label...

[will-moore]

Updated docs at ome/omero-documentation#1543 to use setOpenWithUrlProvider(). Docs can be used in re-test of this PR along with ome/omero-figure#179

[waxenegger]

Open With works perfectly within the webclient, I used both figure and viewer-ng (incl.setOpenWithUrlProvider) to open an image.

I could not manage to set it up for figure as shown in ome/omero-figure#179. The only option available in the info tab was to open it in the webclient.

[will-moore]

@waxenegger I tried with your config but didn't see any problems with omero-figure. Maybe we can try again next week?

[waxenegger]

no worries, perhaps I was not quite up-to-date with the code, although I did use the latest master.

[will-moore]

So, I think we are "Good to merge" on this PR. Let's move discussion of OMERO.figure open_with to ome/omero-figure#179.
@waxenegger Also, if you could comment on the updated docs at ome/omero-documentation#1543 with any suggestions etc that would be great.

[waxenegger]

Sounds good @will-moore.

I believe the documentation is good, in general. I like the code snippets, they helped me most.

I did forget about syncing after I created a script file in the plugin which is something that I do naturally when I develop. Perhaps it's that this was more of a configuration task almost that I forgot it was necessary. People who might approach it from that direction could forget as well and think all that was needed is call set/append config although one could argue that ideally the files for open with are/should be already part of the plugin.

Don't know of if a mention of restarting/syncing web is useful or not...up to you.

[will-moore]

Thanks @waxenegger I'll move your comment to the docs PR and update the docs.
@jburel It would be great to get this merged now, as it's conflicting with #4708 webgateway_api which is otherwise 'good to merge'. Thanks.

[jburel]

Merging: Further improvements can be done in subsequent PRs