Devlog 3: Settings and Customisation

Hello everybody! @yf here with the third devlog. Thankfully, there was not much change to the project purpose (phew) so I can jump straight into what I did. A quick snapshot: I implemented a working settings panel that allows users to customise their experience and saves it to a temp file in the app via tauri-plugin-store.

What did I do?

I:

1. Created a settings panel that allows customisation of the following values:
   (For Dev mode:)

• temperature (float, 0.0-1.0)
• top_p (float, 0.0-1.0)
• top_k (int, 1-100)
  (For the everyday user, dev mode values are hidden, and the following values are the changeable ones:)
• streaming (bool, true/false)
• thinking (bool, true/false)
• theme (string, not implemented yet)

1. I then stored the values as a single json structure options structured in the following way:

{
  "temperature": 0.7,
  "top_p": 0.9,
  "top_k": 40,
  "streaming": true,
  "thinking": true,
  "theme": "default",
  "model": "Qwen3.5:0.8/2/4B"
}

(i.e.)

1. Then, I ditched yet again the rust backend message structure to make way for this new chat structure. I basically added a new key-value pair to the ChatMessage struct, which is options: ChatOptions, and fed it into ollama by flattening it using serde’s flatten attribute, structured the same way as the json above. Models cannot be changed as of the moment.

2. Made the settings panel collapsible via the simple classList toggling.

3. Implemented a simple tauri-plugin-store to save the settings to a temp file in the app, and then read it back on app start. This allows users to have their settings persist across sessions.

What’s next?

Of course, to truly streamline the user experience, I will have to install Ollama with the application. My next priorities are:

1. To bundle Ollama bin with the application and install it on the user’s machine WITH the model. (This will use quite a lot of space, but I guess the installer file will be small enough to accomodate this.)
2. To spawn the ollama process automatically rather than user required, and to kill it when the app is closed. I will do this all in the backend for security purposes.
3. I could realistically just use ollama.cpp, but this means users have to download models themselves, so I think, at least for now, I will stick with the ollama binary. I will consider this in the future.