[ Design Thread ] UI proposals from Omkar: Night mode, resizable Local/Remote split, Lock Now shortcut

[axpnet]

This thread is for designing a Night mode: a theme setting that turns AeroFTP dark in the evening and light in the morning, on its own clock, whatever the operating system is set to.

The idea and the first implementation are @Omkar-Wagholikar's, in #1101, with a screencast that shows it working. Thank you, Omkar. For UI changes I prefer to settle the design in a thread first and then implement it, so the PR is closed and the work continues here. @EhudKirsh, your eye on this would be very welcome, as on the other Design Threads.

What #1101 does

• Adds a night value next to the existing themes and Auto (System).
• Night resolves to Dark from 7pm to 7am local time and to Light otherwise.
• A timer re-checks every minute, so the switch happens at the boundary while the app stays open.
• A new checkbox in Settings > Appearance, under Auto (System), with two new English strings.

What a complete version needs (found while reviewing #1101)

These are not criticisms of the idea, they are the places that read the theme today and would need to know about Night:

1. Secondary windows: the AI approval window (src/ai-approval-main.tsx) and the extract window (src/extract-main.tsx) resolve the theme on their own, and would always open light while Night is active.
2. Icon theme: src/hooks/useIconTheme.tsx resolves Auto by itself and would receive night as if it were a concrete theme.
3. Settings panel: the dark mode check in SettingsPanel.tsx (around line 2111) covers Auto but not Night.
4. Theme cycle (Ctrl+T and the titlebar button): Night is not in the cycle, and cycling from Night jumps to Light.
5. Translations: the two new strings exist only in English; AeroFTP ships 47 languages and every key must be present in all of them.
6. Unchecking Night picks Dark or Light depending on the time of day when you click, so the result is hard to predict. Going back to the theme used before Night would be more natural.

Design questions

1. Fixed hours or configurable? 7pm to 7am fits some people and not others, and in summer or winter it can be far from actual daylight. A simple start and end time is the obvious option. Sunrise and sunset would need a location, and I would not ask for one in a file manager.
2. Which themes for day and night? feat(theme): add Night mode (dark on a fixed 7pm-7am schedule) #1101 pairs Light with Dark. AeroFTP has several dark themes (True Dark, Tokyo, Cyber, Green, Red Horse) and Ice as a second light one. Should Night be a pair the user chooses ("day: Ice, night: Tokyo"), or stay a fixed Light/Dark pair?
3. Night and Auto (System): both are automatic modes. Should they be two checkboxes, or one choice among Manual, Follow system, and Schedule? Some desktop environments can already switch between light and dark on a schedule, and Auto then follows them: is Night still useful there, and how do we explain the difference in one line?
4. Where it lives in Settings: a checkbox under Auto, or a small section with the schedule and the pair of themes, only visible when Night is on.
5. Timer: a one-minute check is simple and cheap. Scheduling the next switch exactly is more precise but has to handle sleep and resume, and daylight saving changes. Either is fine for me as long as the switch is correct after the machine wakes up.

Mockups, screenshots of how other apps handle it, and opinions on any of the points above are welcome.

[axpnet]

Omkar also opened #1102 and #1103, so as he suggested by email I am keeping all his proposals in this one thread. Night mode stays in the opening post; these are the other two.

Resizable Local/Remote split (#1102)

In connected mode the Local and Remote panels are a fixed 50/50. #1102 adds a drag handle (also usable from the keyboard), a 160 px minimum per pane, and remembers the position. Long or deeply nested paths are the use case, and it is a good one: the dual local panel can already be resized, the connected layout cannot.

Questions:

1. Should double-clicking the handle reset to 50/50, as in most split views?
2. One saved position for the whole app, or one per tab/connection?
3. The handle should look and behave exactly like the existing dual-panel resizer, so the two layouts feel the same.

Lock Now shortcut (#1103)

Ctrl+Shift+K locks the app from anywhere, including while typing in a field. An instant lock is useful, and I like the reasoning that it must work mid-typing. Points to settle before it can ship, since this touches security:

1. Ctrl+Shift+K is already taken in the editor: in Monaco it deletes the current line, and the shortcut also fires inside inputs. A different combination, or one that leaves the editor and terminal alone, is needed.
2. The UI must never show "locked" when the vault is not. In feat(security): add a Lock Now keyboard shortcut (Ctrl+Shift+K) #1103 a failure of the lock command is ignored and the lock screen appears anyway. The lock screen should follow the backend result, and a failure should be visible.
3. Which lock: the account lock and the vault lock are different things. Should the shortcut do exactly what the titlebar Lock button does, so there is one meaning of "lock" in the app?
4. macOS: Cmd+Shift+K or Ctrl+Shift+K, and does it collide with anything there?
5. As with Night mode, the shortcut label needs to be in all 47 languages.

[Omkar-Wagholikar]

Hi @axpnet, thanks for pointing out so many aspects that I had missed. It helped me channel my thoughts and articulate them as well!

These are the answers to the questions you had raised, please tell me your thoughts on the same:
Night mode

• Hours: making them configurable rather than a fixed 7pm–7am, different people might have different preferences.
• Relation to Auto: standalone option, mutually exclusive with Auto (picking one turns off the other) keeps everything more simple.
• Placement: same Appearance section as Auto (right below it).
• Unchecking: will restore whatever theme was active before Night mode was turned on, instead of re-deriving from the clock as it does now. I agree that's the right behavior.
• Timer: keeping the 1-minute poll rather than scheduling to the exact second; imprecise by at most 60s on a cosmetic flip isn't worth the extra complexity.
• Will also fix the gaps you flagged: secondary windows (AI approval, extract window), icon theme, Settings panel's dark-mode checks, and Ctrl+T cycling all need to know about 'night'. Will add the two new strings across all 47 locales before resubmitting (or maybe figure out a way to do it more efficiently).

Resizable Local/Remote split

• Double-click already resets to 50/50, so that one's covered as-is.
• Split persistence: keeping it app-wide (single stored value), consistent with how the existing dual-local-panel divider already works, rather than per-connection. Also relatively simpler.

Lock Now shortcut

• Thanks for catching the Monaco collision, I totally missed it. Would rather you suggest the replacement (and weigh in on the macOS equivalent as I only have access to a Linux machine) than guess at something that might collide with an editor binding I haven't hit yet.
• Whatever the final combo is, it'll match the titlebar Lock button's behavior exactly same backend-driven lock state, no separate "locked" UI state that could show true before the backend actually confirms it.
• As a side note, What are your thoughts on letting the user choose one? (We would need to build something like a parser to resolve the user defined hot keys but might help with the customization.

[axpnet]

Hi @Omkar-Wagholikar, thanks for working through the questions. My design preferences are:

Night mode: one choice between Manual, Follow system and Schedule in Appearance, with schedule controls shown only when selected. I would make both the hours and the daytime/nighttime themes configurable, defaulting to Light/Dark. A one-minute check is fine, with a fresh check when the app becomes active again. Leaving Schedule should restore the previous mode, including Follow system; explicitly choosing a theme should switch to Manual while preserving the schedule settings. Theme resolution should be shared across the main window, secondary windows, icons and editor.

Local/Remote divider: app-wide persistence and double-click to reset to 50/50 sound right. It should reuse the existing divider's appearance and keyboard behavior. Minimum widths should also hold when the window is resized or a saved position is restored, with matching accessibility values.

Lock Now: the shortcut should share the relevant backend action with the existing lock controls, show the lock screen only after confirmation, and report failures. Opening the account-lock screen alone does not lock the account session. My candidate is Ctrl+Alt+Shift+K on Linux/Windows and Cmd+Option+Shift+K on macOS, pending conflict checks. Custom shortcuts can be considered separately.

Contribution process: I think there is still a misunderstanding. As explained in my earlier email, UI proposals, including behavior changes, are discussed and agreed first. I closed the PRs and opened this thread for that purpose. Once the design is agreed, I will handle implementation and integration, with you credited as co-author. Please do not reopen or submit replacement PRs for these proposals unless we explicitly agree otherwise here. There is no need to revise the code or translate the locales yourself.

Next step: feedback on these design choices and a simple Appearance mockup would be useful before Ehud and I settle the design. I appreciate the work you have already put into the proposals and want to make the next step clear.

Ale

[Omkar-Wagholikar]

Thanks Ale, all of this makes sense. I agreed across the board on Night mode, the divider, and Lock Now, and understood on the process (no PRs, no locale work from my side).

Since you and @EhudKirsh will handle implementation from here anything further you need from me, or good to leave with you two for now?

[axpnet]

Dear Omkar, yes, you can leave these with me for now. Thank you for the proposals and initial implementations. They have already helped identify useful improvements, and you will be credited for your contribution as discussed.

Our contributor guide could have made the UI process clearer, and I’m clarifying it in #1106. At this stage, I prefer to handle implementation and integration myself: even small changes need to fit together across themes, translations, secondary windows and existing interactions. I should have explained that more clearly.

You’re very welcome to keep contributing with ideas, examples from your everyday use and feedback as the changes take shape. Your perspective as someone using AeroFTP for real work is valuable, and I’d be glad to keep working through proposals with you. We may also open up more UI contributions through pull requests as the workflow becomes easier to share.

I’ll move ahead with implementing the agreed changes as soon as possible and aim to include them in the next release, so you can see your contribution in action. There’s nothing further you need to prepare for these three proposals right now, and I look forward to hearing your next ideas!

Thanks again 🙏🏽
Ale

[Omkar-Wagholikar]

Dear Ale, Thank you for the kind words 😄
I do have some ideas mostly UI and some more specific 'under the hood' changes specific to the way I use AeroFTP.
I'll organize them and discuss about them here.

Thanks again,
Omkar