Make each desktop session be contained in its own config

[rbuels]

All tracks and assemblies will be session tracks and assemblies.

After discussion in our meeting, we want to explore having each session be in its own config, so it would still be running in "admin mode."

[garrettjstevens]

I think the goal here could be accomplished in another way. What if we said that each config only had a single session, so instead of having a bunch of sessions that all have session tracks, session assemblies, etc., we have a bunch of normal configs that each have a single session. Maybe there would be a base config with a handful of settings that could get copied into each new config as well.

[garrettjstevens]

Following up on above, it would make #2190 easier since opening a CLI-made data directory would just mean opening the CLI-made config file in that directory, you wouldn't have to convert it to a session or anything.

Also, we could give the config files a custom file extension and associate that file extension with the desktop app, and you should be able to then click on a config file in your file manager to open it in desktop.

[cmdcolin]

One idea for sessions is that when you select that you want to open e.g. hg38 from our preconfigured list, then it would open a session with hg38 and a gene track, and it would not necessarily modify our root config.json

I haven't created a workflow in my head yet that would work with multiple configs in a similar way

[cmdcolin]

e.g. if it did a similar thing with multiple configs would it download a full config.json each time? that would probably be fine, but would just be a little different of a workflow

[garrettjstevens]

If each desktop session is a config and session all bundled together, then it would probably be good to have some way of applying global settings to each config. One thing we discussed was having a shared config that didn't have tracks, assemblies, session, etc., but could have the "configuration" sections of the config that has things like theme, etc. That could then be merged in to each config when it is opened.

If we do this, should anything else be in the shared config besides the "configuration" section? Plugins, maybe?

[cmdcolin]

I tried to go out on a limb and take a crack at this. It's still experimental but it seems like it is maybe getting towards this goal

This is an experimental branch but it can be seen here
https://github.com/GMOD/jbrowse-components/compare/electron_ts?expand=1

has thumbnail view and grid view on start screen, kinda like a file browser with thumbnail and detail view

With this branch it is possible to launch the preloaded hg38 config from the start screen (recent sessions table and other start screen functions are non-functional at this point)

Technical note:

If we are loading a new config after the start screen, then we don't really have a valid rootModel or pluginManager at that point. Therefore, the Loader for desktop needed some reorganizing so that it only tries to create a pluginManager after the start screen. This also sort of opens the door to perhaps maintaining the "theme" config separately from the other config stuff, since we do want the theme to exist at the start of the app.

[cmdcolin]

The branch noted above now has the ability to functionally do all the functions of the start screen

The pre-loaded datasets are hardcoded in the app, but could be downloaded from a remote server possibly

The function to "Open pre-existing config" can open e.g. the config.json from volvox, and it works fine. This is an interesting case perhaps because on load, it actually attempts to translate any uri entry into a localPath if it does not start with http. Then, the jbrowse autorun actually automatically copies this config into the UserData e.g. ~/.config/@jbrowse/core/sessions/sessionname.json (so it is no longer reading or writing to the original file you opened)

The "Open sequence file" is similar to the assembly add form.

[cmdcolin]

added in #2247