Move Ollama server configuration to the Plug-in Manager settings pane

[LostOne1000]

Priority

High

Summary

Move Ollama server-address configuration out of the single-photo and batch-generation dialogs and into a dedicated Lightroom Llama section in Lightroom’s Plug-in Manager.

This issue is exclusively about the Ollama server address and connection validation.

Model selection, model persistence, model capability handling, and default-model configuration remain in issue #8.

Issue #8 should be blocked by this issue because model discovery and persistence need a single authoritative server configuration.

Current behavior

Both generation dialogs currently expose:

• An Ollama Server text field.
• A Save Server button.
• Model-refresh behavior tied to saving the server.

This duplicates server-management UI and server-saving behavior across the single-photo and batch workflows.

The server is stored under:

prefs.ollamaServerHost

Desired behavior

The Plug-in Manager should contain a Lightroom Llama settings section with:

• Ollama server address.
• Save or Apply action.
• Test Connection action.
• Connection status.
• Restore Default action.
• Default-address explanation.

The generation dialogs should no longer contain an editable server field or Save Server button.

They should use the server address saved through the Plug-in Manager.

Proposed implementation

1. Register a Plug-in Manager information provider

Add a provider to Info.lua, for example:

LrPluginInfoProvider = "PluginInfoProvider.lua"

Create PluginInfoProvider.lua to build the Lightroom Llama settings section.

The provider should own only Lightroom view construction and UI event handling.

Server validation, persistence, and connection testing should remain in testable services.

2. Add ServerSettingsService.lua

Create a pure-Lua service responsible for:

• Returning the default server address.
• Loading the saved server address.
• Validating server-address input.
• Normalizing optional schemes and trailing slashes.
• Persisting only validated values.
• Restoring the default server.
• Keeping the last valid value when new input is invalid.

Suggested interface:

local result = ServerSettingsService.validate(
    "http://192.168.1.10:11434/"
)

Successful result:

{
    ok = true,
    host = "192.168.1.10:11434"
}

Invalid result:

{
    ok = false,
    message = "Server address must use host:port format."
}

Reuse or extract the existing validation behavior from OllamaClient.validateServerHost() rather than maintaining two implementations.

3. Add a strict connection test

Add a client operation dedicated to testing the configured server.

Suggested interface:

local result = client.testConnection(prefs)

Success:

{
    ok = true,
    message = "Connected to Ollama."
}

Failure:

{
    ok = false,
    errorKind = "connection_failed",
    message = "No response received from the Ollama server."
}

The connection test may query an existing lightweight Ollama endpoint such as the model-list endpoint, but it must not:

• Persist model selection.
• Select a model.
• Configure a default model.
• Replace a failed response with the code-level default model.
• Implement any behavior assigned to issue Persist model selection and improve vision-model handling #8.

4. Make connection testing asynchronous

Run Test Connection through LrTasks.startAsyncTask() so the Plug-in Manager remains responsive.

While testing:

• Display a working status.
• Prevent overlapping tests.
• Disable Apply if the address is invalid.
• Preserve the last valid persisted address until the new address is accepted.
• Display a clear success or failure result.

5. Remove server controls from generation dialogs

Remove the following from both single-photo and batch dialogs:

• Ollama Server text field.
• Default-server helper text.
• Save Server button.
• Server-refresh status handling.

The dialogs should read the saved server preference through the shared settings service or client configuration.

They should not allow per-run server overrides.

6. Simplify controllers

Remove server-editing state and actions from:

• SinglePhotoController.
• LlamaDialog.
• BatchLrLlama.lua, or its future extracted controller.

The single-photo controller should no longer need:

state.serverHost
controller.saveServer()

Saving photo metadata should not validate or persist the server address. Server configuration should already have been validated in the Plug-in Manager.

7. Preserve existing preferences

Continue using the existing saved value:

prefs.ollamaServerHost

No destructive preference migration should be required.

Existing users should see their current configured server in the new settings pane after upgrading.

An invalid legacy value should:

• Be shown with a validation warning.
• Not be silently overwritten until the user applies a corrected value or restores the default.

Testing

Add unit and wiring tests covering:

• Info.lua registration of the information provider.
• Loading the existing server preference.
• Default-server behavior.
• Server normalization.
• Invalid-hostname handling.
• Invalid-port handling.
• Restore-default behavior.
• Invalid input not overwriting the last valid preference.
• Strict connection-test success.
• Connection-test failure.
• Malformed Ollama response.
• Plug-in Manager status transitions.
• Prevention of overlapping tests.
• Removal of server state from the single-photo controller.
• Removal of server controls from both generation dialogs.
• Generation requests continuing to use the saved server address.
• No model-selection logic being introduced by this issue.

Out of scope

• Persisting the selected model.
• Choosing a default vision model.
• Model capability detection.
• Model filtering.
• Remembering single-photo or batch model selections.
• Managing multiple named servers.
• HTTPS certificate settings.
• Authentication.
• API tokens.
• Starting or stopping Ollama.
• Installing or deleting models.

Those model-related behaviors remain in issue #8.

Dependencies

This issue has no dependency on #8.

Issue #8 is blocked by this issue.

The intended implementation order is:

1. Complete this issue and establish one authoritative server preference.
2. Implement Persist model selection and improve vision-model handling #8 against that centralized server configuration.

Acceptance criteria

• Lightroom’s Plug-in Manager displays an Ollama Server setting for Lightroom Llama.
• Existing prefs.ollamaServerHost values are preserved.
• Users can validate and save a server address.
• Users can test the connection without blocking the Lightroom UI.
• Invalid input does not overwrite the last valid server.
• Users can restore the default server address.
• Single-photo generation no longer displays server controls.
• Batch generation no longer displays server controls.
• Server saving and validation are no longer duplicated across generation dialogs.
• Photo metadata saving does not alter server preferences.
• Generation continues to use the saved server.
• No model-selection or model-persistence behavior is implemented in this issue.
• Issue Persist model selection and improve vision-model handling #8 is documented as blocked by this issue.
• Unit and wiring tests cover the new preference-pane behavior.