https://bugs.kde.org/show_bug.cgi?id=456767

Igor Kushnir <igor...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |5.10.221200
      Latest Commit|                            |https://invent.kde.org/kdev
                   |                            |elop/kdevelop/commit/a2b3b7
                   |                            |7fea8147878ac727e7e5f8c4f3b
                   |                            |bfce573
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #17 from Igor Kushnir <igor...@gmail.com> ---
Git commit a2b3b77fea8147878ac727e7e5f8c4f3bbfce573 by Igor Kushnir.
Committed on 25/11/2022 at 10:44.
Pushed by igorkushnir into branch 'release/22.12'.

Display GrepDialog results in the GrepOutputView that creates it

GrepOutputView creates a hidden GrepDialog on start to restore search
settings from history. GrepOutputView also creates a hidden GrepDialog
when its Refresh action is triggered. In both cases the GrepOutputView
becomes GrepDialog's parent, and thus will be valid when the dialog is
ready to display results. Also in both cases the search results should
not be displayed in a GrepOutputView from another area if that area
becomes active before GrepDialog::startSearch() is invoked. And there is
no need to raise the GrepOutputView in these cases either.

GrepViewPlugin creates and usually shows GrepDialog for various reasons.
The dialog is modeless, so the user can activate another area before
starting a search in it. The results should be displayed in a
GrepOutputView within the area active at the time of a search start.
Therefore the old IUiController::findToolView()-based implementation
remains for this case.

Restoring search history in a session that contains zero projects (all
closed), could cause a crash in a nested event loop inside
UiController::loadAllAreas(), because UiController::findToolView()
returns nullptr then and GrepDialog::startSearch() does not check the
returned pointer. OktetaDocument can create such a nested event loop if
a binary file is open in the session.
FIXED-IN: 5.10.221200

M  +11   -4    plugins/grepview/grepdialog.cpp
M  +6    -1    plugins/grepview/grepdialog.h
M  +2    -2    plugins/grepview/grepoutputview.cpp
M  +1    -1    plugins/grepview/grepviewplugin.cpp

https://invent.kde.org/kdevelop/kdevelop/commit/a2b3b77fea8147878ac727e7e5f8c4f3bbfce573

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to