See the commit messages for details.
Indeed, git log and gitk show the complete message. Then I vote for merging this.
The changes fix what you describe in the commit messages and I have nothing to add or complain about. I like the <<-overloading for easier debugging. Only the commit message of d72040f7 seems to be incomplete, could you check again?
Christoph Roick (6795582d) at 05 Jan 13:22
The Ninja configuration page offers to select a build environment. This setting is now applied when creating a corresponding NinjaJob.
BUG: 403769 FIXED-IN: 5.11.230400
Christoph Roick (6795582d) at 05 Jan 13:22
Apply Ninja environment settings
Christoph Roick (8a67c3cb) at 04 Jan 15:51
Apply Ninja environment settings
Yes, the check in effectiveEnvironment()
and a test show there is no need for that block. I'll make it a one-liner.
The Ninja configuration page offers to select a build environment. This setting is now applied when creating a corresponding NinjaJob.
BUG: 403769 FIXED-IN: 5.11.230400
Christoph Roick (ee388f82) at 04 Jan 14:34
Apply Ninja environment settings
Christoph Roick (7e2b4c72) at 04 Jan 14:34
kdevplatform/sublime: set parent widget for IdealDockWidget menu
... and 120 more commits
Christoph Roick (50cda668) at 26 Nov 17:26
Fix misleading comment about refilling the grep job history
Christoph Roick (5bbd3725) at 22 Nov 21:59
I think it would be reasonable to also include my adjusted comment about reloading the searches from the history in this commit (something like "Restore the grep jobs with settings from the history without performing a search.") to keep things together. Other than that, it's a good solution to the edge case in the bug.
Restoration of the search history of a session that does not contain projects happens before the construction of the UI is done. The search for the corresponding search toolview is aborted early in this case. Since the restoration of the search history via the hidden search dialog is invoked by the toolview itself, it can alternatively be accessed as the parent of the dialog.
BUG: 456767 FIXED-IN: 5.10.230370
I think both solutions end up with the same behavior. But your approach makes it more transparent under which circumstances there is a toolview attached to the dialog. I'll close this one.
Yes, by having a session without projects, but with searches in the history, the crash can be reproduced. I attempt a fix here: !404 (closed). It's not pretty, but currently I do not have the time to properly fix it.
Restoration of the search history of a session that does not contain projects happens before the construction of the UI is done. The search for the corresponding search toolview is aborted early in this case. Since the restoration of the search history via the hidden search dialog is invoked by the toolview itself, it can alternatively be accessed as the parent of the dialog.
BUG: 456767 FIXED-IN: 5.10.230370