Settings saved in one window are put back by the Settings dialog of another window #216

New Issue

2026-11-11T14:28:09Z

james.maes commented

2026-11-11 14:28:09 +00:00

What

Two gclo windows can be open at once (there is no single-instance rule). Each reads settings.json when it starts and keeps its own copy.

Since #212's review, what a window remembers by itself (the workspace that was open, Quick Sync's connection) is written over the file as it is on disk at that moment, so a window that closes no longer puts its older copy back.

The Settings dialog still works on the window's own copy:

it shows the values that window read at start, not what another window saved since;
its Save writes that whole copy, so settings saved in another window in the meantime are put back to the older values (theme, default folder, the address of the default Gitea server).

For the Gitea default this can leave the token in Credential Manager with no address in the file. The token is then taken up again when its address is entered in Settings (#212), so it is recoverable, but the user has to know to do that.

Wanted

One of:

the Settings dialog reads the file fresh when it opens, and Save writes only the fields the user changed over the file as it is then; or
one gclo window per data folder (a second start brings the first to the front).

The second is the simpler rule and also settles the same question for accounts.json prompts and the activity log, but it is a behavior change that needs the owner's decision.

Notes

Found by the review of #215. Not a regression: Settings has always been saved this way.

## What Two gclo windows can be open at once (there is no single-instance rule). Each reads `settings.json` when it starts and keeps its own copy. Since #212's review, what a window remembers by itself (the workspace that was open, Quick Sync's connection) is written over the file as it is on disk at that moment, so a window that closes no longer puts its older copy back. The Settings dialog still works on the window's own copy: - it shows the values that window read at start, not what another window saved since; - its Save writes that whole copy, so settings saved in another window in the meantime are put back to the older values (theme, default folder, the address of the default Gitea server). For the Gitea default this can leave the token in Credential Manager with no address in the file. The token is then taken up again when its address is entered in Settings (#212), so it is recoverable, but the user has to know to do that. ## Wanted One of: - the Settings dialog reads the file fresh when it opens, and Save writes only the fields the user changed over the file as it is then; or - one gclo window per data folder (a second start brings the first to the front). The second is the simpler rule and also settles the same question for `accounts.json` prompts and the activity log, but it is a behavior change that needs the owner's decision. ## Notes Found by the review of #215. Not a regression: Settings has always been saved this way.

james.maes referenced this issue from a commit

2026-11-11 14:31:55 +00:00

fix(app): a window that closes does not put older settings back, and a token typed behind the mask is not rewritten in its box

james.maes referenced this issue

2026-11-11 14:31:55 +00:00

feat(app): Settings holds a default token per forge, and a default token is used only for the place it was saved for #215

james.maes commented

2026-11-11 14:43:21 +00:00

One more case of the same subject, from the last review of #215: if the Settings dialog stores a Gitea default token and the write of settings.json then fails, the token is in use with no address on disk. The window that later closes does not write the address either (it writes only what the app remembers by itself). The token can be taken up again by entering its address in Settings. Whatever is decided here should cover it: the dialog could store the token only after the settings are written, or put the token back when the write fails.

james.maes referenced this issue

2026-11-11 22:21:47 +00:00

Release v1.2.0 #200

james.maes commented

2026-11-11 22:21:48 +00:00

Owner's decision (2026-11-11): one gclo window per data folder. Starting gclo again brings the open window to the front. The dev build beside the stable one keeps working, because it has its own data folder. This also covers the case in the comment above.

james.maes referenced this issue from a commit

2026-11-11 22:28:21 +00:00

fix(app): a window that closes does not put older settings back, and a token typed behind the mask is not rewritten in its box

james.maes referenced this issue

2026-11-11 22:29:09 +00:00

Gitea organizations and accounts beside GitHub #201

james.maes referenced this issue from a commit

2026-11-11 22:37:17 +00:00

feat(app): gclo opens one window per data folder, and a second start brings the open one to the front

james.maes referenced a pull request that will close this issue

2026-11-11 22:37:17 +00:00

feat(app): gclo opens one window per data folder, and a second start brings the open one to the front #217