(migration) Move to a graphical interface #16

Closed
opened 2025-09-24 11:22:57 +02:00 by kir68k · 2 comments
kir68k commented 2025-09-24 11:22:57 +02:00 (Migrated from github.com)

I think moving from plain CLI prompts to a cross-platform GUI, like Iced, would make developing a bit easier for me. I'm currently making a separate branch with a prototype version before making a PR.

I haven't worked much with interactive CLI prompting and printing before this project. I think that can be easily seen with the hard-coded stdout().execute() calls to MoveTo and Clear. I don't think CLI/TUI is inherently hard, but I've had more experience with making graphical stuff.

So for a new version, maybe v0.2.0 as this would be a relatively large change, I think the best would be:

  • Graphical mode using iced
    • Easier to separate UI code from the rest. (Currently it's a mess)
    • Cross-platform. GTK simply doesn't feel right on Windows.
    • Easier to add features like a QR code picture for cross-signing.
  • Headless/CLI mode using the config file
    • No prompts or output (unless a -v flag is set, maybe?)
    • Config creation either from the GUI or maybe a secure prompt, that would be fine.
      • Ideally the password should be encrypted somehow (#13), using arguments is insecure due to shell history. Password env var is not an option.

So if the GUI doesn't work (like right now during my testing), there's a fallback method.

For the headless method, if I want to avoid interaction, I think the session and verification status should be stored like a full client would. Otherwise, with an ephemeral session, cross-signing wouldn't be available.

The SAS (emoji) method can be printed, but the main goal of headless is to be used as a long-running service to keep a track of new events.

I think moving from plain CLI prompts to a cross-platform GUI, like Iced, would make developing a bit easier for me. I'm currently making a separate branch with a prototype version before making a PR. I haven't worked much with interactive CLI prompting and printing before this project. I think that can be easily seen with the hard-coded `stdout().execute()` calls to `MoveTo` and `Clear`. I don't think CLI/TUI is inherently hard, but I've had more experience with making graphical stuff. So for a new version, maybe v0.2.0 as this would be a relatively large change, I think the best would be: - Graphical mode using [iced](https://github.com/iced-rs/iced) - Easier to separate UI code from the rest. (Currently it's a mess) - Cross-platform. GTK simply doesn't feel right on Windows. - Easier to add features like a QR code picture for cross-signing. - Headless/CLI mode using the config file - No prompts or output (unless a `-v` flag is set, maybe?) - Config creation either from the GUI or _maybe_ a secure prompt, that would be fine. - Ideally the password should be encrypted somehow (#13), using arguments is insecure due to shell history. Password env var is **_not_** an option. So if the GUI doesn't work (like right now during my testing), there's a fallback method. For the headless method, if I want to avoid interaction, I think the session and verification status should be stored like a full client would. Otherwise, with an ephemeral session, cross-signing wouldn't be available. The SAS (emoji) method can be printed, **but** the _main_ goal of headless is to be used as a long-running service to keep a track of new events.
kir68k commented 2025-09-25 09:35:26 +02:00 (Migrated from github.com)

So if the GUI doesn't work (like right now during my testing)

This was due to Vulkan/Wayland/GL runtime dependencies from winit and wgpu, which Iced uses.
Had a bit of a pain trying to make it all link properly through nix. I prefer using nix build over nix develop -> cargo build in these projects.

The final solution was a runtimeDeps var added to buildInputs + a wrapper:

postInstall = ''
  wrapProgram $out/bin/matrix-export-tool \
    --prefix LD_LIBRARY_PATH : "${pkgs.lib.makeLibraryPath runtimeDeps}"
'';

Now to actually make the UI work :D

> So if the GUI doesn't work (_**like right now during my testing**_) This was due to Vulkan/Wayland/GL runtime dependencies from winit and wgpu, which Iced uses. Had a bit of a pain trying to make it all link properly through nix. I prefer using `nix build` over `nix develop` -> `cargo build` in these projects. The final solution was a `runtimeDeps` var added to `buildInputs` + a wrapper: ```nix postInstall = '' wrapProgram $out/bin/matrix-export-tool \ --prefix LD_LIBRARY_PATH : "${pkgs.lib.makeLibraryPath runtimeDeps}" ''; ``` Now to actually make the UI work :D
kir68k commented 2025-11-19 23:55:15 +01:00 (Migrated from github.com)

Was thinking about this while working on github.com/kir68k/matrix-export-tool@643ab9a8bb, between the last comment and today I tried egui/eframe for a small private project. I might use it instead, if it's viable.

Was thinking about this while working on https://github.com/kir68k/matrix-export-tool/commit/643ab9a8bb5ccd0dffeae6e82f5ca73041ea5e0f, between the last comment and today I tried egui/eframe for a small private project. I might use it instead, if it's viable.
kir68k changed title from Move to a graphical interface to (migration) Move to a graphical interface 2026-04-26 00:41:04 +02:00
Sign in to join this conversation.
No description provided.