Standalone app

[will-moore]

This was originally #619 before it got split into #663 with this one on top.

This branch is also pushed to master, so that it's deployed to https://will-moore.github.io/omero-figure/

Testing the standalone app:
Need to test all actions that load or save to OMERO

• File > Open... Should ask for a local file OR a url to a file
  • The url should update to ?file=url so that refreshing will show the same file
• File > Save (or Save button) should download the figure.json
• Add Image - should only work for Zarr images
• Export PDF should show a dialog with info on how to export json to PDF as in Standalone python script #669
• Add Labels from Tags / KVP - either fail silently (same as in OMERO if no annotations) or hide/disable
• Other options hidden (Delete, SetId)

[pwalczysko]

This branch is also pushed to master, so that it's deployed to https://will-moore.github.io/omero-figure/

Thank you . How to deploy it anywhere else please ? (deployment instructions ?)

[pwalczysko]

File > Open... Should ask for a local file OR a url to a file

This workflow makes sure that I have only images from local or only images from remote storage (with urls). Can I have both ? This would need of course that there would be an option to "Add images" which would have a Browse button.

[will-moore]

If you push these changes to a branch called "master" then the github action will run... (see pages.yml).
This will build the app and push it to a gh-pages branch.
Then you need to have gh-pages enabled for your repo.
The guide for all this is at ome/ome-contributing#27

[will-moore]

The File > Open dialog that you see will depend on whether you are using Figure from OMERO or not. If it's being served by OMERO, then you will get the using dialog to browse figures from OMERO.
Otherwise you get to enter a URL or choose a local file. The contents of these figure.json file that you choose is not checked by the File > Open dialog, but since you are not logged-in to OMERO, they will have to be OME-Zarr images with URLs that you can access. These could be local images that you are serving with Fileglancer OR could be remote public images.

[pwalczysko]

These could be local images that you are serving with Fileglancer

That is not what I understood from the "Browse" button. Indeed, there is nothing to lead me to the conclusions that these local files must be served by Fileglancer. I guess there is a misunderstanding about which Browse button I am talking.... I am talking about the Browse button in the lower part of the screenshot below.

[pwalczysko]

@will-moore aha, sorry, my bad. I misread the dialog in #666 (comment) -> it wants me to open a JSON of a figure which is stored locally. I think the second line should read something like

... or select a local JSON figure file to open.. (i.e. add the hint that it is not an image which you should be opening)

[pwalczysko]

Add Labels from Tags / KVP - either fail silently (same as in OMERO if no annotations) or hide/disable

Adding Dataset or Dataset ID results in

Ditto for Project, Well, Field, Run acquisition, Well sample etc.

[pwalczysko]

Few points we could address:

1. github pages - lead through deployment using GitHub pages maybe let us not point to https://github.com/will-moore/ome-contributing/blob/6171192b2b12b6fda773bdf113bd446e06e3c335/docs/github-pages.rst please, it has plenty of redundant info (e.g. all the examples of ome pages which can be or were deployed, but not really explicitly telling how or indeed, that one does not need to establish any nojekyll file and build because all is already here, and not getting to the main point. Your four-liner in Standalone app #666 (comment) (actually 3-liner as the fourth one is the contributing which I would not recommend) is much more to the point. Also, the official GitHub guide about establishing GitHub pages is better and should be mentioned. Is there any other way to deploy this standalone figure ?
2. Standalone app #666 (comment) -
3. Standalone app #666 (comment)
4. This is overwriting the existing app. I have checked on merge-ci and all seems fine. But this is imho the main focus of the testing. I would think we shoiuld have one more look.

[pwalczysko]

Please see the last summary comment, thank you.

[will-moore]

I haven't focussed on how to deploy this since I don't expect users to do it. Or even other devs.
Are you wanting instructions in the README? for devs or users?

[pwalczysko]

since I don't expect users to do it. Or even other devs.

Ok. Surprising to me, but maybe that is what the users want. I would like to have my version in hand, when the app proudly says standalone.

[pwalczysko]

Are you wanting instructions in the README? for devs or users?

Yes, this was my idea. But maybe lets discuss, I am confused about why would anyone not want to deploy themselves. Possibly we have some examples of other apps which operate like this ?

[will-moore]

Why would you want to use https://pwalczysko.github.io/omero-figure/ rather than https://ome.github.io/omero-figure/ (which is where this will be deployed once this PR is merged)?

Other examples of apps that you use in their existing locations (don't need your own deployment):

• https://ome.github.io/ome-ngff-validator/
• https://hms-dbmi.github.io/vizarr/
• https://neuroglancer-demo.appspot.com/ (don't know if this is served by github or not, but makes no difference)
• https://bff.allencell.org/app
• etc

[pwalczysko]

Why would you want to use https://pwalczysko.github.io/omero-figure/ rather than https://ome.github.io/omero-figure/ (which is where this will be deployed once this PR is merged)?

Yes, if we have the url under ome org, then this is more authoritative. And I can see that having it on my own github pages (e.g. pwalczysko...) is not giving me much assurance either over the what I thought will be ...will-moore.. (thanks for explaining that it will be on ome) . That is why I was asking about other deployment methods. Relying on others is great... but it has its drawbacks - change in code which I did not expect, availability guarantee for my users etc.
I was mainly protesting against "relying on a private branch" e.g. will-moore.

[will-moore]

File > Open dialog tweaked:

[will-moore]

To summarise:

• Is the deployment OK? Once deployed to https://ome.github.io/omero-figure/ will this be acceptable? (apologies for not mentioning this in the description)
• File > Open dialog has been improved.
• I might need @Tom-TBT's help / advice on how to handle dynamic labels when we don't have various OMERO metadata - see above: Standalone app #666 (comment)

[Tom-TBT]

I might need @Tom-TBT's help / advice on how to handle dynamic labels when we don't have various OMERO metadata

I implemented this to disable suggestion of screen/plate/well or project/dataset

omero-figure/src/js/views/right_panel_view.js

Lines 653 to 682 in 46ba7b1

	var parents_flags = {"project": false, "dataset": false, "screen": false, "plate": false};
	var parents_defined = false;
	selected.forEach(function(p){
	dTs = p.get('deltaT');
	if (dTs && dTs.length > 0) {
	have_time = true;
	}
	var parents = p.get("parents");
	if (parents) {
	Object.keys(parents).forEach(function(parentType){
	if (parents_flags.hasOwnProperty(parentType)) {
	parents_flags[parentType] = true;
	}
	});
	parents_defined = true;
	}
	});
	if (have_time) {
	$(".add_time_label", this.$el).removeClass('disabled');
	} else {
	$(".add_time_label", this.$el).addClass('disabled');
	}
	// Update label suggestions with time availability
	if (this.labelSuggestions) {
	this.labelSuggestions.have_time = have_time;
	if (parents_defined) {
	this.labelSuggestions.parents_flags = parents_flags;
	}
	}
	}

used here

omero-figure/src/js/views/label_suggestions.js

Lines 540 to 545 in 46ba7b1

	// Filters out labels
	if (key === "time" && !this.have_time) continue;
	if (key === "project" && !this.parents_flags.project) continue;
	if (key === "dataset" && !this.parents_flags.dataset) continue;
	if (key === "screen" && !this.parents_flags.screen) continue;
	if (["plate", "well", "field", "run"].includes(key) && !this.parents_flags.plate) continue;

if parents doesn't exist (var parents = p.get("parents"); ), the flags are not set and use the default true

So you could simply define an empty parent metadata and that would skip those parent suggestions.
But if there's more metadata to disable we could add a broader flag for the standalone app, and use that instead of an empty parent dictionary.

It's important that the flags are not passed if parents is not defined, for compatibility with older versions (better too much choice than no choice at all in those case).

[pwalczysko]

• Is the deployment OK? Once deployed to https://ome.github.io/omero-figure/ will this be acceptable? (apologies for not mentioning this in the description)

• File > Open dialog has been improved.

1. The File > Open dialog lgtm.
2. The deployment: I think ok for this PR, but actually note that for Ad 1., I was only able to test at https://pwalczysko.github.io/omero-figure/ -> of course, because the change is not deployed on https://will-moore.github.io/omero-figure/ -> I think this is natural. This shows that there is a strong case to have a deployment workflow at least for developers.

[pwalczysko]

@will-moore do you want to implement @Tom-TBT 's suggestions before I approve ?