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]

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 ?

[will-moore]

@pwalczysko I've created an issue to improve labels autocomplete with reference to the discussion above.
#678

But let's not consider it a blocker for the "standalone" app - Actually, it's not really related to this PR or even strictly due to adding OME-Zarr images.

[pwalczysko]

From https://merge-ci.openmicroscopy.org/jenkins/job/OMERO-plugins-push/112/consoleFull

Merged PRs:
  - PR 652 kaabl 'Add export option for PNG (72 dpi), fixes #394 '
  - PR 666 will-moore 'Standalone app'

This PR is in the merge build today.

[pwalczysko]

Tested again, mainly with the OMERO-based images on merge-ci. All good.

[will-moore]

@Tom-TBT @Rdornier I've just updated the development section of the README according to the updated behaviour from this PR. You'll see that the previous option of vite dev server deployment with connection to OMERO no longer supported. If you run npm run start (or npm run dev - both commands do the same thing, but npm run dev is the "standard" behaviour on all other apps now) then you are in the standalone app with OME-Zarr images, and if you do npm run watch then you are deploying from OMERO.web. There's no CORS-based connection from the vite-deployed app to OMERO.web now.
I think that this is OK, as both dev deployments exactly match the "real" deployment scenarios (standalone app or OMERO.web app). We no-longer have a dev hybrid behaviour.
Most features that are not specific to OMERO connection can be developed in the npm run dev standalone app workflow. Let me know what you think and if the README makes sense, Thanks

[Rdornier]

Hi @will-moore

README look good to me. One question: if I'm using the standalone app, can I still import images in figure from my docker? The docker creates a localhos:4080, and OMERO-figure will be available on localhost:8080. Is it still possible to create figures with images coming from localhost:4080, now the CORS is not supported anymore ? If not, how can I do ?

Rémy

[will-moore]

@Rdornier Actually, that "CORS" workflow of adding Images from OMERO.web on 4080 still works fine. Maybe I shouldn't remove it from the README, although it's less necessary now that you can also add OME-Zarr images.