Bug 437337 - When the app crashes, last-used sets of tabs is lost
Summary: When the app crashes, last-used sets of tabs is lost
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: application (show other bugs)
Version: Git
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-19 02:01 UTC by Nate Graham
Modified: 2023-02-26 10:49 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 23.04
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2021-05-19 02:01:05 UTC
It appears that the set of active tabs is saved to the config file only when the app quits cleanly. Therefore, when it crashes and you re-open it, you'll get the set of tabs that you had the last time it did quit cleanly. This set of tabs is likely to be quite out of date.

I would recommend writing the current set of tabs to the config file every time a new one is opened or moved.
Comment 1 Christoph Cullmann 2021-06-01 19:28:50 UTC
That would imply that on each file open you will write the session to the home, I am not sure that is really a good idea, given e.g. on NFS homes that will stall.

Perhaps one could just start some "sync me" timer there and batch that together in xx second slices, I assume that would be good enough.
Comment 2 Nate Graham 2021-06-01 19:45:45 UTC
Yeah, there are definitely trade-offs involved. However I don't know how common the NFS home directory use case is, and perhaps we could optimize it. And I think writing to the config file every time a document is opened is likely to be less costly than writing based on a timer, unless the timer avoided writes when nothing has changed and determined this in a way that didn't involve reading the config file at all. But even then, you'd lose any tabs that were open after the last sync.
Comment 3 Christoph Cullmann 2021-06-01 19:48:02 UTC
:P Unfortunately I use NFS homes daily :P

e.g. if you open your session and it has 100 files open, you will now write 100 times the full session config back in worst case.

If we just delay that with say a 10 seconds timer, it will be one write in most cases.
Comment 4 Nate Graham 2021-06-01 20:04:18 UTC
That seems easily optimizable by only writing to the config file when a new file is opened, not when the session itself is loaded, no? And in the case where multiple files are opened by the same action, they could be batched up and result in only one write not n writes.

But a 10 second delay timer would probably be okay.
Comment 5 Bug Janitor Service 2023-02-18 15:07:21 UTC
A possibly relevant merge request was started @ https://invent.kde.org/utilities/kate/-/merge_requests/1115
Comment 6 Waqar Ahmed 2023-02-18 18:30:14 UTC
Git commit 3d520e79e4b52c009b55982ad3816e6e2f913749 by Waqar Ahmed.
Committed on 18/02/2023 at 15:02.
Pushed by cullmann into branch 'master'.

Sessions: Save session on document open and close

M  +32   -0    apps/lib/session/katesessionmanager.cpp
M  +5    -0    apps/lib/session/katesessionmanager.h

https://invent.kde.org/utilities/kate/commit/3d520e79e4b52c009b55982ad3816e6e2f913749
Comment 7 Waqar Ahmed 2023-02-26 10:49:41 UTC
Git commit a11139306939baf66d566de60a5a1e11df53db65 by Waqar Ahmed.
Committed on 26/02/2023 at 10:43.
Pushed by waqar into branch 'release/22.12'.

Sessions: Save session on document open and close

M  +32   -0    apps/lib/session/katesessionmanager.cpp
M  +5    -0    apps/lib/session/katesessionmanager.h

https://invent.kde.org/utilities/kate/commit/a11139306939baf66d566de60a5a1e11df53db65