{% extends layout|default('base.html', true) %} {% block style %} {% endblock %} {% block content %} Plexora - Settings {# The rail is rendered from settings_routes.SECTIONS and the panels are written by hand below, keyed by the same id. That split is deliberate: a section's NAME and ORDER are one line of Python, so adding one never means editing three places to keep a list in step, while its CONTENT is markup and belongs in a template rather than in a string in a route module. Panels are all present in the DOM and shown one at a time. With one section that is indistinguishable from rendering only the active one; with six it is what keeps switching tabs instant, and it is the arrangement the CSS and the JS below are written for. #}

Settings

Preferences for this copy of Plexora.

Data directory

Every project you import, and every figure you build, is written here. Plexora reads this once when it starts, so a change takes effect the next time it is launched.

{# Filled by settingsPage.js from /settings/data. Rendered empty rather than server-side because the same markup has to be redrawn after a save, and one renderer beats a Jinja copy and a JS copy that drift. #}
Current location
Loading…
{# Shown only when the settings file and the running process disagree -- i.e. a change was saved and nothing has restarted yet. Both paths are named, because "pending" is meaningless without saying pending FROM what. #} {# An environment variable beats the settings file (see paths._candidate_data_root), so when one is set the form is not merely disabled -- the server refuses the write too. Two places, because a disabled control is a hint and the 409 is the rule. #}
{% if not data.notebook_mode %} {# Opens a picker on the SERVER's machine, which is why it is not offered in notebook/hosted mode -- /browse_path refuses it there for the same reason. #} {% endif %}

Existing projects stay where they are unless you choose to bring them along on the next step.

{# The review step. Nothing is written until the button in here is pressed, so this is the only place the consequences of the choice are stated -- what is already in the target, whether a move would be a rename or an hour of copying, and what would collide. #} {# Migration progress. Counted in projects rather than bytes -- see data_migration's module docstring for why a byte total would cost a full tree walk before anything visibly starts. #}
{# Remote servers. The same job `plexora connect` does, with the ssh command lines replaced by a saved profile and a button. There is no form here: adding a server means answering questions about somebody else's cluster, and those answers are properties of the SITE -- so the page offers the sites instead, and the questions that genuinely differ are asked on the preset's own form. See settingsPage.js's drawCatalogue for what used to be here. #}

Remote servers

{# The one sentence this panel needs before either box: which machine Plexora is, and which machines these are. Running Plexora ITSELF somewhere else is a launch decision made on that machine, not a setting inside a running Plexora, and the panel says so rather than leaving somebody to look for the field that would do it. #}

Plexora runs on one machine and reaches every other one over SSH.

{# Two things, boxed apart. What you have saved and what you can add were a run of cards and a heading on one flat background, so the presets read as more saved servers with the wrong buttons on them. The saved half gets a container with its own title; the catalogue below stays on the page's own ground, which is the whole of the distinction. #}

Saved connections

Save a remote connection once, then reconnect by name.

Loading…
{# The catalogue, drawn by settingsPage.js from the same cards the connection dialog uses. Empty in the markup on purpose: this list is a static description of other people's clusters and is fetched once, by whichever surface asks first, rather than being rendered into every page that has a Settings link. What stood here was a hand-written form of twelve boxes and a "Use preset..." button beside it. Seven of those boxes asked what a preset asks, with a second set of defaults to keep in step; the three that were genuinely its own -- the data directory, extra port forwarding, and forwarding from the login node -- moved into the preset form's Advanced section, which is where the rest of that question already lived. Two grids, not one: the five kinds of machine anyone can have, and then the named institutions behind "Additional presets". See connectionModal.js's recipeGrid. #}

Add a New Connection

Start from the kind of machine you use. Plexora fills in what it knows; you can change any of it afterwards. If your institution's cluster is one Plexora already knows, it is under Additional presets.

Loading…
{# Data nodes: what is CURRENTLY reachable, which is a different question from which servers are saved next door. Most entries here now appear and disappear on their own -- a data field's Remote option opens one, `plexora connect` opens one on the user's laptop -- so this section reads as a status board first and an address book second. The manual form stays because a node somebody started by hand is still a thing that exists, but it is behind a disclosure: it is now the exception. #}

Data nodes

Machines that are handing this Plexora data right now. Most of them arrive by themselves: choosing Remote on a data field opens one on a saved server, and plexora connect opens one on your own computer. Nothing here needs setting up before you import.

Which files a project reads from a node is chosen on that project’s own page. This is only the address book.

Loading…
Add a node by hand

For a node you started yourself with plexora node serve on a machine this one can already reach. A node opened from a data field or by plexora connect registers itself.

{# remoteState.js is loaded by base.html, above and deferred, so it is parsed before this file runs -- the Remote servers section is one of its subscribers rather than a poller of its own. #} {% endblock %}