Bug 291052

This problem just happens sometimes, I actually worked on it a bit during the last sprint, I think it works quite well at the moment, reducing priority.

This is still *veeery* slow for me. Taking up to 2-3 seconds to switch between 'Debug' and 'Code'.
Using the qtcurve style right now. Can someone confirm/reproduce?

Aleix, can you show me the commits that were supposed to improve this behavior? Might investigate it then.

You can for HoldUpdates in kdevplatform/sublime/mainwindow.cpp

If you want to look into this, maybe you could try to delay the document creation on display. Also a similar solution for Toolviews could be found, maybe.

The problem is that every time you switch area everything is closed and re-opened, even if there are repeated things...

Another thing you can do, is remove code from widgets initialization... It's not easy to profile GUI, but maybe it's worth it.

Good luck! :)

Git commit 8c22f2ffdc5b1df0c6b111868a5aca8debca5ced by Aleix Pol.
Committed on 28/11/2012 at 01:29.
Pushed by apol into branch 'master'.

Delay initialization of TextEditorWidget

This patch reduces the initialization of the loading a text document view
by delaying the initialization.
This is useful because when we change areas we close all the opened views
and then we reopen the new ones. The loading of document views was one of
the most expensive calls that happened there. This is now delayed to the
event loop so the view creation now is trivial by creating only an empty
widget that will be instantiated afterwards.

I'm not closing the bug for the moment, but it would be interesting to know
how it went, so feedback is welcome!

M  +38   -20   shell/textdocument.cpp
M  +6    -4    shell/textdocument.h

http://commits.kde.org/kdevplatform/8c22f2ffdc5b1df0c6b111868a5aca8debca5ced

Git commit cd3d48751c167ac547682a559e98e7dd7aa425a3 by Aleix Pol.
Committed on 28/11/2012 at 03:30.
Pushed by apol into branch 'master'.

Don't resize the vertical IdealButtonBarWidget when it's empty

This greatly reduces the flickering on area switching. What was happening
is that when changing areas all buttons were removed and re-added. In this
process the button bar would shrink when empty and that would trigger a
re-layout of the whole GUI. Now we keep the width of the buttons we've
added.

This won't be a regression given that my previous commit improves the
behavior when there are no buttons on the button bar, so we won't get
a big gray area.

Now all the flickering when changing area should be gone.

M  +6    -0    sublime/ideal.cpp

http://commits.kde.org/kdevplatform/cd3d48751c167ac547682a559e98e7dd7aa425a3

Great patch :-)

I didn't do anything for me at first, but after deleting everything beginning with "kdev*" in ~/.kde/share/apps and deleting old sessions the flickering is ultimately gone.

Guess a lot of stale config files had accumulated over the years.

Thank you the good work, KDevelop looks _much_ better now :-)

Git commit e0583cfbd36ade497039ae8464f876ab70b450b5 by Andreas Pakulat.
Committed on 10/12/2012 at 15:22.
Pushed by apaku into branch 'master'.

Revert lazy initialization of the Text Editor

This essentially reverts 8c22f2ffdc5b1df0c6b111868a5aca8debca5ced but without
reverting most of the actual code changes since in the meantime other changes
depend on the adjusted API. Instead the initialization call is just done
synchronously from the constructor instead of through the QMetaObject API.

This fixes the problem of context menus not being shown in the editor most
of the time after opening a file that happened since the above mentioned
commit. Neither keyboard nor mouse clicks where triggering a context menu,
only after switching to another tab and back did things work correctly. Its
unclear to me why that happens, but I'd rather have a bit slower area
switching than non-working context menus.

M  +1    -1    shell/textdocument.cpp

http://commits.kde.org/kdevplatform/e0583cfbd36ade497039ae8464f876ab70b450b5

Git commit e0583cfbd36ade497039ae8464f876ab70b450b5 by Andreas Pakulat.
Committed on 10/12/2012 at 15:22.
Pushed by apaku into branch 'master'.

Revert lazy initialization of the Text Editor

This essentially reverts 8c22f2ffdc5b1df0c6b111868a5aca8debca5ced but without
reverting most of the actual code changes since in the meantime other changes
depend on the adjusted API. Instead the initialization call is just done
synchronously from the constructor instead of through the QMetaObject API.

This fixes the problem of context menus not being shown in the editor most
of the time after opening a file that happened since the above mentioned
commit. Neither keyboard nor mouse clicks where triggering a context menu,
only after switching to another tab and back did things work correctly. Its
unclear to me why that happens, but I'd rather have a bit slower area
switching than non-working context menus.

M  +1    -1    shell/textdocument.cpp

http://commits.kde.org/kdevplatform/e0583cfbd36ade497039ae8464f876ab70b450b5