Summary: | Kate sometimes loses edit panel when switching sessions | ||
---|---|---|---|
Product: | [Applications] kate | Reporter: | Nick Coghlan <ncoghlan> |
Component: | application | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | christoph, fbfree1 |
Priority: | HI | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Katesession file with no edit panel
Working katesession Buggy anonymous.katesession |
Description
Nick Coghlan
2016-05-19 12:02:31 UTC
This seems to have now progressed to Kate simply not creating the edit panel when opening an existing session, even on a fresh login. This problem then persists even if opening a new session. (I've turned off SELinux and the behaviour persists, so it isn't anything related to that). Running Kate from a console window, I get this output: ================== $ kate & $ QObject::connect: invalid null parameter QObject::connect: invalid null parameter QObject::connect: Cannot connect (null)::returnPressed() to KUrlRequester::returnPressed() QObject::connect: Cannot connect (null)::returnPressed(QString) to KUrlRequester::returnPressed(QString) Attempted to re-run an already running session. QObject::connect: invalid null parameter QObject::connect: invalid null parameter QObject::connect: Cannot connect (null)::returnPressed() to KUrlRequester::returnPressed() QObject::connect: Cannot connect (null)::returnPressed(QString) to KUrlRequester::returnPressed(QString) Attempted to re-run an already running session. Attempted to re-run an already running session. ================== The first "Attempted to re-run..." is from choosing a session at start-up, the second pair is from an attempt to switch sessions. It's looking like the problem may be specific to something in the saved session state - I deleted the anonymous session state from ~/.local/share/kate/anonymous.katesession and new sessions are working properly again, while the behaviour of existing sessions depends on which session I start with. Is there specific setting I can check that might be a potential culprit? I tried diffing a working session against a broken one, but there was too much noise from the actual differences in the opened files for me to spot anything that might potentially be significant. I just noticed I hadn't reported the Kate version affected: $ kate -v kate 16.04.1 $ rpm -qa kate kate-16.04.1-1.fc24.x86_64 Can you attach a minimalistic .katesession file that has this issue? I have once seen this as well... Created attachment 99402 [details]
Katesession file with no edit panel
"broken.katesession" is edited down from a session that had lost its edit panel.
I did the same thing with a session that was still working (which I'll upload in a moment), and the most suspicious part of the diff was this section:
[MainWindow0-Splitter 0]
-Children=MainWindow0-ViewSpace 0
+Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-ViewSpace 0
Orientation=1
-Sizes=1758
+Sizes=0,0,0,0,0
Setting aside the multitude of splitters, the broken session has Size 0 for the ViewSpace.
Created attachment 99403 [details]
Working katesession
Based on the diff between the broken session and this working session, I tried changing the Splitter 0 definition in the broken session to:
[MainWindow0-Splitter 0]
Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-ViewSpace 0
Orientation=1
Sizes=0,0,0,0,1665
The only change was to force the ViewSpace to a non-zero size, which was enough to bring the edit panel back.
Running grep over my session files then suggests that the problem is consistently:
- MainWindow0-Splitter 0 has ended up with multiple children (generally ViewSpace 0 + other splitters)
- the Sizes of all children, including the ViewSpace, have been set to zero
So, as a workaround, going into the session file and fixing that manually seems to do the trick.
However, it doesn't explain how the incorrect setting is getting into the session file in the first place.
If the mainwindow is empty, there in fact is a splitter that can be dragged which makes the editing widgets appear again. The splitter is either on the left or the right. I added a workaround for the Applications 16.08 release that removes hidden/invisible editing areas. By default if all are hidden, we should still get one editing area. I won't backport to 16.04, though, since I am not sure it might introduce regressions. And yes, the issues is indeed the "Sizes=0,0,...". The remaining question is now: How are these 0,0,... introduces in the first place? Because this is the real bug, which is still not fixed. If you find that out (I already tried quite a bit), that would be really cool. I have been experiencing this bug using kate 16.04.2, and possibly earlier versions. The bad split pane size originates from the anonymous.katesession file. The bad settings are contagious when opening new sessions. I.e. if I start a new session in kate, the edit pane disappears. If I then open an existing session, the bad edit pane settings are preserved from the first session, and are saved to each subsequently opened session. Created attachment 100562 [details]
Buggy anonymous.katesession
Source of buggy settings leading to a missing edit pane.
After manually cleaning up all my broken session files a while ago, I managed to break a couple of them again today by doing: - start Kate, selecting a particular session from the pop-up window (no problem) - use Sessions->Quick Open Session to switch to a different session (no problem) - use Sessions->Quick Open Session to switch back to the original session (problem) At that point, the original session had no edit panel. I hand-edited the session file, and restarted Kate, and it was working again. However, switching to the other session showed that it had *also* acquired the bad settings, and switching back to the original session again also recreated the problem there. After doing that a couple more times, here's what the "MainWindow0-Splitter 0" section looked like: [MainWindow0-Splitter 0] Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-Splitter 5,MainWindow0-Splitter 6,MainWindow0-Splitter 7,MainWindow0-Splitter 8,MainWindow0-Splitter 9,MainWindow0-Splitter 10,MainWindow0-Splitter 11,MainWindow0-Splitter 12,MainWindow0-Splitter 13,MainWindow0-Splitter 14,MainWindow0-Splitter 15,MainWindow0-Splitter 16,MainWindow0-ViewSpace 0 Orientation=1 Sizes=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 Meanwhile, the other session (the one I was switching *to* each time, before switching back to the original) looked like: [MainWindow0-Splitter 0] Children=MainWindow0-Splitter 1,MainWindow0-Splitter 2,MainWindow0-Splitter 3,MainWindow0-Splitter 4,MainWindow0-Splitter 5,MainWindow0-Splitter 6,MainWindow0-Splitter 7,MainWindow0-Splitter 8,MainWindow0-Splitter 9,MainWindow0-Splitter 10 Orientation=2 Sizes=0,0,0,0,0,0,0,0,0,0 So it seems something is going wrong with the splitter and viewspace definitions when switching back and forth between sessions (in case its relevant - each of the two sessions has 30-60 files currently open, but more than that recorded in the session file) Updated version info, since Fedora's pushed a few updates through since I first encountered this issue: $ rpm -qa kate kate-16.04.3-1.fc24.x86_64 => Fixed post 16.04, should be in current 16.08 release, see bug 358266 *** This bug has been marked as a duplicate of bug 358266 *** |