Align main editor focus frame with other text boxes

[mjuhasz]

The focus frame of the main subtitle edit box was inconsistent in two ways: its thickness varied depending on whether color tags were enabled, and it did not match the focus frame used by other edit- and text boxes in the app.

Changes

• Make the focus frame thickness uniform regardless of color tag mode.
• Match the focused border style used by other text boxes (e.g. the Fix Common Errors or OCR window).
• Prevent layout shift when focus changes by compensating border thickness with padding.

edit.box.focus.frame.mov

[OmrSi]

@mjuhasz In dark mode, when the line in the list becomes unfocused, the color is very close to the default color, anyway to change that?

As you can see, you can barely tell that line 12 is selected but unfocused.

Also, I think it might be a good idea to keep the border color of the focused textbox blue, it doesn't clash with dark mode and makes it clearer that the textbox is focused. Right now, the border just becomes not white.

[mjuhasz]

@OmrSi This is not intentional.

It should look like this:

Screen.Recording.2026-06-12.at.9.21.05.PM.mov

I have to verify this but I think what's happening is that for the unfocused state Avalonia is pulling the System accent color which is not blue on your machine.

I'll investigate this.

[OmrSi]

@mjuhasz You are correct; that is my System's accent color. :D

When I changed it from the settings, it changed in SE right away.

[mjuhasz]

@OmrSi Right, what I can do here is that I make the unfocused row use the same color as the focused row. That focused-row blue comes from Avalonia so the focused and unfocused rows will be using the exact same blue, just lower opacity (same but faint color) for unfocused rows.

I verify this for list boxes and the edit box focus indicator as well (the components I touched earlier today).

It's an unfortunate coincidence that my system color is so very close to the Avalonia blue because of which it was not noticeable that the focused/unfocused colors were coming from different sources.

[OmrSi]

@mjuhasz No, no. I think they are coming from the same source, so I'm not sure that it's the code that needs to be changed, but rather my accent color.

To clarify, here is a focused line with my accent color:

So I think it's working as intended, when getting unfocused, it uses the same color but lighter.
I initially thought it was set like this manually for dark mode, and didn't know it came from my own PC.

[mjuhasz]

@OmrSi Yes, I've been looking into this and reviewed pretty much the entire application, as the saying goes, "measure twice before you cut once".

I think they are coming from the same source

You are right, I verified this.

There is only one place I found where the color is not coming from the system color: the main window edit box when color tags are enabled is hardcoded to DodgerBlue. Other than that, the focus button background color is not following the system accent but that is configurable in Settings.

So I think it's working as intended, when getting unfocused, it uses the same color but lighter.

Pretty much.

What needs to be fixed is the hardcoded blue focus indicator around the edit box -> it should use the system accent color. I fixed it here: #11576

What could be tweaked is how faint the unfocused state should be: less faint -> you will hardly see if the subtitle grid is active; more faint-> you will hardly see which row is selected. It looks pretty decent to me currently but time will tell.

I'm not sure that it's the code that needs to be changed, but rather my accent color.

Agreed. That accent color is not a great choice for the dark theme. I can replicate your case by choosing Graphite system accent color which naturally is a poor fit for the dark color scheme. If I insisted on using Graphite for some reason I'd adjust the dark theme background color in Settings (it's configurable). Hard-coding colors here and there in the app would make it look like a Frankenstein-product. Like the bug I fixed above.

[OmrSi]

To be honest with you, it would be cool if we could set the highlight color manually.
The default could be the accent color, but then you can change it to blue or something if you'd like, so you don't have to change the whole accent color to make it look good.

In SE4, it used to be Blue even in dark mode:

Though I'm not sure if @niksedk would be okay with that, maybe a hidden option like DarkThemeSelectedBackgroundColor in SE4, but called HighlightColor or AccentColor?

Anyway, worst-case scenario, I can make my own version with a custom color. :D

[mjuhasz]

@OmrSi

To be honest with you, it would be cool if we could set the highlight color manually.
The default could be the accent color, but then you can change it to blue or something if you'd like, so you don't have to change the whole accent color to make it look good.

That is the way to go, indeed.

The starting point is UseFocusedButtonBackgroundColor / FocusedButtonBackgroundColor in SeAppearance — a setting that fills the button background with a custom color when a button has keyboard focus (:focus pseudo-class).

Based on my understanding of why it's there (but I'm mostly inferring this since I'm not a SE maintainer), Avalonia (Fluent theme) renders a thin rectangular focus adorner for keyboard-focused buttons. On many theme combinations (especially dark themes or custom backgrounds), this rectangle is invisible or barely visible. There's no built-in system-accent-color integration for buttons on Windows/Linux the way macOS has. So instead of the Fluent rectangle ring, UiUtil.MakeButton injects a per-button :focus style that fills the button background with the configured color — a visible, color-based keyboard focus indicator.

The default is a semi-transparent dodger-blue (Color(99, 30, 144, 255) = A:99/~39%, R:30, G:144, B:255 = #1E90FF at ~39% opacity) — enough to show focus without being garish.

So we already have a place to define a color that affects part of the look of the application:

• Users can disable it entirely (for those who prefer the default Fluent ring or are on macOS, where UiTheme.Mac.cs already handles focus via SystemAccentColor independently).
• Users can pick a color that doesn't clash with their chosen theme.
• It doubles as the app accent color — PluginThemeColorsFactory.cs maps it directly to AccentColor exposed to plugins.

The last point is interesting here: that color is being treated as the accent color in plugins. It's irrelevant for you, but just noting here that macOS is handled separately: UiTheme.Mac.cs uses :focus-visible filled with GetMacAccentColor() (the OS SystemAccentColor), so macOS never needs this setting for its own focus ring — it reads the real system accent color instead.

So if I were to design something here, I would consider a setting to define a color that is by default the system accent color, but can be configured and then the whole app uses that accent color override. And this new setting could perhaps be unified with this button highlight override.

This mockup is not Subtitle Edit but to give you the idea, there's the accent color setting:

it would be cool if we could set the highlight color manually.

I want to point out that the highlight color is not the same as the accent color, even though they are often backed by the same color. In what I wrote above I assumed that you want to change the accent color because that's what we've been discussing so far.

You get the accent color for things like the focus ring around components, and the highlight color is for selected text for instance.

Such an app-level modification would require consultation with the maintainer. We should no go against whatever design plans he has in mind, and I would not want to spend my time on non-trivial changes, like this one, only to see it never merged.

[OmrSi]

@mjuhasz Yes, I meant the accent color indeed.

And you are right; I've fallen into the trap of working for a long time on something only to find out it's not wanted before. :D

@niksedk Would this be something you'd accept?