Bug 337891

+1. I also find that highly annoying. We need to fix that behavior.

*** Bug 345308 has been marked as a duplicate of this bug. ***

Hi Kevin,

I am working on this bug.I just wanted to know which file i should open to correct the bug.

Hi Priyanka, you'll find the area switching logic in kdevplatform:./sublime. Unfortunately the code is not easy to follow I'm afraid, lots of abstractions involved here.

@apol, @adymo: Maybe you can give a hand?

This can be done only as a hack. The whole architecture is built with an assumption that different areas will have different set of editor and tool views.

The place to hack it is probably MainWindow::setArea in sublime/mainwindow.cpp. You'll have both old and new area objects. Then you'll need to:
- remove all "views" (not the "toolviews") from the new area (in case there are views there from previous switch)
- traverse all views in the old area and ask their documents to add views to the new area (make sure to do this in a tree-like fashion to preserve split window configuration, Area::walkViews is the way to do this)

I think I'd do this after line #121 HoldUpdates hu(this);

This hack is not too bad for production use. View creation is super fast. And this won't actually create any KTextEditor::View instances until they need to be displayed on the screen.

Hi,

Can i know which value corresponds to old area and new area because i can't find any views corresponding to new area.

Thanking you,
Priyanka Bandaru

Is this still being worked on? It annoys the crap out of me that every time I start debugging, I completely lose track of where in the code I am.
One more thing that annoys me is that the view doesn't automatically jump to the current line when stopping at a break point or crashing. I always have to open the Frame Stack window (which also isn't opened by default and quite hidden inside the menus) and click on an entry in the stack trace first.

Hi,
I try out the solution proposed by @Alexander Dymo and it works partially because in addition we need to synchronize a new created view->widget with the active widget in code are. That makes code quite complicated and not readable

As for me the working solution is to have a property "Switch to Debug Area" setting to true by default that you could configure by yourself if you are annoying with this issue

Git commit 74548158dc6d43a7b202a7a34e1e48d9a3f21a8e by Christoph Roick.
Committed on 23/05/2021 at 11:28.
Pushed by croick into branch 'master'.

Maintain working set state when switching between areas

Save the working set state before switching areas (i.e. from code
to debug). This allows restoring the order of the view tabs and the
current cursor positions in the new area.

M  +4    -1    kdevplatform/shell/areadisplay.cpp
M  +2    -2    kdevplatform/shell/debugcontroller.cpp
M  +4    -2    kdevplatform/shell/tests/test_workingsets.cpp
M  +1    -0    kdevplatform/shell/uicontroller.cpp
M  +18   -15   kdevplatform/shell/workingsetcontroller.cpp
M  +5    -2    kdevplatform/shell/workingsetcontroller.h
M  +1    -1    kdevplatform/shell/workingsets/closedworkingsetswidget.cpp
M  +1    -1    kdevplatform/shell/workingsets/closedworkingsetswidget.h
M  +2    -2    kdevplatform/shell/workingsets/workingsetwidget.cpp
M  +1    -1    kdevplatform/shell/workingsets/workingsetwidget.h
M  +5    -4    kdevplatform/sublime/area.cpp
M  +3    -3    kdevplatform/sublime/area.h
M  +1    -1    plugins/patchreview/patchreview.cpp

https://invent.kde.org/kdevelop/kdevelop/commit/74548158dc6d43a7b202a7a34e1e48d9a3f21a8e

Thanks, Christoph!