feature request: syntax highlighting for the .config file in vykar-gui

[goebbe]

Using and testing Vykar for a couple of weeks now and I
have a growing config.yaml with

• many comments
• several repos
• several hooks (some span several lines)
• exclude_patterns

Working with the config.ymal, syntax highlighting (yaml) would be a helpful feature:

• It is easier to separate comments from actual configs
• It helps to avoid errors (brackets not closed, closing quotation marks missing)
• It helps to orientate in large config files

The following Rust project might be helpful and aims to facilitate the use of syntax highlighting:
https://github.com/trishume/syntect
I did not check if this would be compatible with vykar-gui.

Edit: Apparently slint is aiming for a rich text editor: slint-ui/slint#2723 (comment)
However, this is not fully implemented, yet.

The following screenshot shows Vykar-gui and the xed-editor, next to each other.
Both look at the same config.yaml:

[m3nu]

Editing the config in the GUI is just a temporary thing. I plan on moving most settings to the GUI over time.

[goebbe]

I certainly hoped for the config.yaml to stay in "advanced"-mode.

For advanced configs, in a certain respect .yaml-files provide a better UI than most GUIs:

With a GUI for "everything":

• you have your own dialog (and quirks) for each config aspect,
• you cannot put comments,
• it is harder to test variants,
• it is often harder to get an overview about all configs, (many views/ panes/ subdialogue)
• users are easily confused since the GUI expose (possible) complexity - even for users with simple use cases.

I don't even want to think about a GUI for hooks, exclude patterns, global vs. per repository settings. This
could easily become overwhelming/ confusing / messy. 😢

Where most GUIs shine:

• provide easy access to monitoring
• easy access to existing snapshots
• easy access to most common actions
• provide a familiar interface for common tasks (e.g. select elements like several folders as sources)

I would prefer a relatively simple GUI, that is limited to the most essential tasks:

• Add/delete backup repositories (with labels)
• set/ change a passphrase
• Select sources/ paths
• A simple schedule dialogue (with on_startup)
• A simple retention dialogue

With good defaults, this should be good enough to get everybody up and started.

The complicated advanced configs could then be done/changed directly in the config.yaml, e.g.

• hooks (requires text editing anyway)
• exclude_patterns (requires text editing)
• advanced settings for scheduler (e.g. cron-like) (requires editing?)
• limits (for advanced users only)
• compression settings (advanced only)
• passcommand:

Vykar could put/ keep (commented) examples for advanced configs, which would make advanced configs accessible.

[goebbe]

Just to complete my thoughts about the use of a config.yaml for advanced configs:

As an example I take Vortas GUI:
I like most of Vortas config possibilities, however there are some shortcomings that vykar-gui should avoid:

• the settings are scattered over a total of 4 tabs plus a separate setting/about button
  • a single tab can have different sub-panes, e.g. "Schedule" has 4 different views, for Schedule, Networks, Log and Shell Commands
  • these sub-panes are ordered from the top to the bottom - which make them hard to navigate
  • The "Sources" pane has the "Manage Exclude Items..." button at the bottom - which opens a new dialogue with another five(!) tabs.
  • As a result of the many tabs/ views/ panes/ dialogues it is really hard to get a quick overview of the settings, even for relatively simple setups. Essential settings are hard to navigate/ to spot.
• the most advanced configs have a GUI that is hard to use:
  • Schedule > Shell Commands: (the equivalent of vykar hooks?)
  • There are only a one-line text fields for Pre-backp, Post-backup, Extra arguments
  • Sources > Manage Excluded Items
  • The 5 tabs try hard to make excludes easy but are more confusing than anything else, despite the fact that re-includes are not even possibles.
• Vorta provides many config possibilities, but there are still advanced configs that are not integrated in the GUI. Try to change the advanced options for a repository-setup (e.g. remote_path). It is not in the GUI.
  • It is really hard to integrate all possible advanced configs in a GUI

In short:

• There is a price to pay, if you try to integrate every possible config into a GUI: GUIs tend to become complicated and confusing. Configs are hard to navigate. Settings are hard to spot or hidden in submenus/ dialogues.
• It is worth to think about what degree of possible complexity you want to expose in the GUI.
  • Would it make sense to expose the cron-like specs for schedule in a GUI? Or is this an advanced feature that would confuse most users?
• In my experience, advanced configs are often better off with an advanced / flexible interfaces.
  • yaml provides a good balance between nice readable structure and the possibility to express advanced settings. e.g. multi-line hooks.

For advanced setting, I would, hands down, prefer a commented yaml (with syntax highlighting) where I could just comment/ uncomment/ adapt in a multi-line "Text-editor like" UI.
My yaml.config provides a very good overview about my actual settings, since it reflects what actually matters in my scenario. Whereas a complex GUI would also expose a large set of options / possibilities that are not relevant, for me.

Perhaps it is also worth to think about user scenarios? Target user groups and their requirements?

Sorry for the long text. Hope this is helpful anyway.

[m3nu]

It's a good perspective and I generally agree.

[m3nu]

Thanks for the detailed write-up — and you're right that working with a multi-repo / hooks / excludes config is much nicer with syntax highlighting. I dug into what it would take to add this in vykar-gui, and the short version is: the right answer for now is let your real editor do it, and I'll fix what's keeping you from doing that today.

Why we won't embed syntect (yet). vykar-gui is built on Slint 1.15. Slint's text widgets — TextEdit and Text — only support a single global color/weight per string; there's no concept of styled spans or rich text. So syntect would happily produce highlight tokens, but we'd have nothing to render them with. The realistic ways to display them are (a) hand-rolling a code editor on top of Text runs (cursor, selection, IME, undo/redo, scrolling, accessibility — months of work and a permanent maintenance load), or (b) waiting for upstream rich-text support, which is tracked in slint-ui/slint#2723 and currently lives on a "very raw" wip/cosmic-text branch. Adding syntect (or tree-sitter-yaml) before Slint can render the output would be ~1 MB of dependencies producing tokens we can't display. We'll revisit when Slint ships styled runs.

What we can fix now. The Advanced page already has a clickable config path that's supposed to open the YAML in your system editor — which gives you proper YAML highlighting, search, fold, etc., for free. Looking at the code, that handler hardcodes the macOS open command, so it silently fails on Linux and Windows (which is exactly your screenshot). I'll route it through the opener crate instead so it uses xdg-open on Linux and ShellExecuteW on Windows, surface launcher errors in the log, and reword the help text so it's clear that the embedded editor is for quick edits while the link is the recommended path for larger config work. That should give you the workflow you described — edit in xed (or any other editor) with full highlighting, hit save, and have vykar-gui pick it up.

Tracking the toolkit-side work in slint-ui/slint#2723; when it lands we can reconsider in-app highlighting.