| Summary: | crash after theme change | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | ederag <edera> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | kde |
| Priority: | NOR | Keywords: | drkonqi |
| Version First Reported In: | 5.18.5 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
ederag
2020-09-11 15:58:55 UTC
Fixed by the following change in ~/.config/kdeglobals -widgetStyle=bb10dark +widgetStyle=Breeze Yep, it's a crash in BB10 style. The "resolved upstream" resolution is surprising. Couldn't systemsettings catch the crash and revert ? No, crashes caused by a broken QStyle can happen any time later in any application, not just in systemsettings. Sure, but since the buggy theme change was made in systemsettings, I expected to be able to revert that change, in systemsettings as well. Or by "upstream" do you mean that there is a general "theme handler" that should catch the crash and allow to revert ? That would be even better of course. (a quick "kde theming development" search did not show that information) Locally run systemsettings --style breeze to be able to reload I don't see how we could technically catch this in systemsettings. If we crash, We crash. We can't exactly analyse why. Upstream in this case is the BB10 style. |