got-feedBack/feedBack-desktop
1
0
Fork 0
mirror of https://github.com/got-feedBack/feedBack-desktop.git synced 2026-07-19 19:31:31 +00:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity

fix(panes): a minimized pane window was unrecoverable — remove the button

Browse Source 
Reported in testing: pop out the stem mixer, minimize it, and it is gone. Not
hidden — gone. It appears in no taskbar, no alt-tab list, nothing.

The chain:

  - A pane window is skipTaskbar, so it never masquerades as a second fee[dB]ack.
  - It is parented to the main window (so it can't go behind the app), which makes
    it an OWNED window — and Windows will not give an owned window a taskbar
    button in any case.
  - On minimize we then hid it "to the tray".

So a minimized pane had no taskbar entry and no alt-tab entry, and the only route
back was the tray — which Windows tucks behind the overflow chevron by default.
"It's in the tray" is not an answer when the user cannot see the tray.

The window is no longer minimizable. Every remaining way to put a pane away is one
the user can undo from something visible:

  - close it        → the panel returns to the app, where it came from
  - the tray        → per-pane toggle, plus Show/Hide all panes
  - the chip's stub → in the app, exactly where the panel used to be

Plus a restore() on 'minimize' in case anything else (a window manager, a
shortcut, a future code path) minimizes it anyway.

This is the same class of mistake as hiding the panel behind the pop-out chip: a
place to put something, with no way back that the user can find.

Signed-off-by: topkoa <topkoa@gmail.com>
This commit is contained in:
topkoa 2026-07-12 22:36:53 -04:00
parent 0878ae2682
commit 47fe1492a6
1 changed files with 23 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
src/main/pane-hosts.ts
View File

@ -209,14 +209,30 @@ export function adoptPaneWindow(win: BrowserWindow, paneId: string): void {
win.on('moved', save);
win.on('resized', save);
// Minimize sends a pane to the tray, not the taskbar. Panes are small and
// numerous; a taskbar full of them is noise, and the tray already lists them.
// Electron's 'minimize' is not cancellable here (the listener takes no event),
// so we hide right after rather than preventing it — and the window is
// skipTaskbar, so there is no animation to see.
// NO MINIMIZE BUTTON. This is a safety rail, not a style choice.
//
// A pane window is skipTaskbar (it must not masquerade as a second fee[dB]ack)
// and, since it is parented to the main window, an OWNED window — which Windows
// will not give a taskbar button to in any case. So a minimized pane has no
// taskbar entry and no alt-tab entry. The only route back is the tray, and
// Windows hides new tray icons behind the overflow chevron by default.
//
// Net effect if we allow it: the user clicks minimize and the window is gone.
// Not hidden — gone, with no affordance anywhere on screen to bring it back.
// That is exactly what happened in testing, and no amount of "it's in the tray"
// makes it acceptable.
//
// So the button is removed. Every way of putting a pane away that remains is one
// the user can undo from something they can see:
// - close it → the panel returns to the app, where it came from
// - the tray → per-pane toggle, and Show/Hide all panes
// - the chip's stub → in the app, dead centre of where the panel used to be
win.setMinimizable(false);
// Belt and braces: if something else minimizes it anyway (a window manager, a
// shortcut, a future code path), restore it rather than leave it unreachable.
win.on('minimize', () => {
win.hide();
refreshTray();
win.restore();
});
// 'close' fires while the window still exists; 'closed' after it is gone. The