STEPS TO REPRODUCE 1. open Dolphin 2. select any file 3. press shift+del (a dialog with highlighted "Delete" button shows up) 4. press enter key OBSERVED RESULT nothing happens EXPECTED RESULT highlighted button id triggered SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.22.80 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.3 Graphics Platform: X11
This is a change in the new Breeze Evolution work. It was found during testing, but we decided not to return to the previous behavior because in some ways the previous behavior was buggy: 1. When the dialog has a default button, the return key should always trigger it; this did not happen before, and it should have. Now it does. 2. the key used to trigger the highlighted UI element is generally the spacebar, not the return/enter key. This was inconsistent before; now it is consistent.
*** Bug 439652 has been marked as a duplicate of this bug. ***
So what do we do about this? 5.23 is approaching and I still cannot hit return to confirm saving my unsaved changes upon exiting a KDE application.
I don't understand why we have: btn->setAutoDefault(false); in order to solve the bug "Make default button blue". The rest of the patch makes sense, but manipulating widgets from a style is generally an incredibly bad thing to do. Can we explain that please.
(In reply to Kai Uwe Broulik from comment #3) > So what do we do about this? 5.23 is approaching and I still cannot hit > return to confirm saving my unsaved changes upon exiting a KDE application. IMO, we should return the previous behavior because regardless of whether or not it's buggy, people will still expect to be able to press enter in dialogs. We've effectively traded one type of inconsistency for another and I don't think that's a good tradeoff.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/133
Apps need to set reasonable default buttons; this is an expectation from Qt. Fortunately, most do, as Qt's own dialog widgets set reasonable defaults. KF5 was an exception, as our widgets didn't set any default buttons. Now, we do set a reasonable default button, so the vast majority of apps should have default buttons set now. Marking as fixed since the bug was complaining about an app using KF5 widgets not having a default button, and now the KWidgetsAddons widgets set reasonable default buttons.
Please answer my question in #4
Best way we can replicate the behaviour on macOS (arguably in a less ugly manner than the official Qt stuff for macOS), where the default button isn't jumping around due to autodefault.
1.) it's different from any other QStyle (Fusion, even Oxygen) 2.) your patch for KMessageBox was only just merged, but Frameworks tagging for the version Plasma 5.23 will depend on has already happened 3.) The new KMessageBox behavior is different from how it has been for 20 years and how it is on e.g. Windows. Pressing Return on a "Save changes?" is now "Cancel" rather than "Yes." 4.) The "About Qt" dialog can no longer be closed by pressing Return and that is a dialog created by Qt, so they clearly consider default button behavior canonical.
>where the default button isn't jumping around due to autodefault. Telling me we turn off auto default do it doesn't use the auto default hasn't really explained anything. Why do we not want autoDefault? How does this relate to the original commit about default blue buttons? Define "jumping around"
(In reply to David Edmundson from comment #11) > Why do we not want autoDefault? > How does this relate to the original commit about default blue buttons? > Define "jumping around" See this thread: https://invent.kde.org/plasma/breeze/-/merge_requests/133#note_300460
Git commit c5171cf003aa8dd0028a14e5bba99002941b729e by Nate Graham, on behalf of Kai Uwe Broulik. Committed on 16/09/2021 at 15:26. Pushed by ngraham into branch 'master'. Restore auto default button behavior A style shouldn't mess with clients like this, especially if it behaves different from literally any other QStyle out there, and breaks decades of muscle memory. This partially reverts 00693ee5e715167d61d0014b9eb75ab3dbd31b51 M +0 -2 kstyle/breezestyle.cpp https://invent.kde.org/plasma/breeze/commit/c5171cf003aa8dd0028a14e5bba99002941b729e
Git commit f763f27ebf3bbb21235ab3df0f7b9ef035cc71b5 by Nate Graham, on behalf of Kai Uwe Broulik. Committed on 16/09/2021 at 15:27. Pushed by ngraham into branch 'Plasma/5.23'. Restore auto default button behavior A style shouldn't mess with clients like this, especially if it behaves different from literally any other QStyle out there, and breaks decades of muscle memory. This partially reverts 00693ee5e715167d61d0014b9eb75ab3dbd31b51 (cherry picked from commit c5171cf003aa8dd0028a14e5bba99002941b729e) M +0 -2 kstyle/breezestyle.cpp https://invent.kde.org/plasma/breeze/commit/f763f27ebf3bbb21235ab3df0f7b9ef035cc71b5
*** Bug 443428 has been marked as a duplicate of this bug. ***
*** Bug 443441 has been marked as a duplicate of this bug. ***