emateli added a comment.
Hey @subdiff, thanks for your input on this. Whether this patch goes in or not, I still think that this "odd" behaviour is something that the frameworks should fix or change rather than relying on the developer of each application to do this. However I never expected this to stir up such a conversation given that I thought this was the normal behaviour in Plasma, given that all(?) the other dialogs created by the framework have the default button focused (See: Konsole close dialog w/ multiple tabs open (the exact same dialog as Dolphin's), or Konversation after having joined a channel. ) Since these functions internally all rely on `createKMessageBox` and work properly so to say, I dug a bit deeper into this and found out the following why Dolphin's close dialog is the odd one out: If no parent window is specified when calling this function then the checkbox will be focused, if one is passed then the focus shifts onto the buttons. Current call: `QDialogButtonBox* buttons = new QDialogButtonBox(QDialogButtonBox::Yes | QDialogButtonBox::No | QDialogButtonBox::Cancel);` "Fixed" call: `QDialogButtonBox* buttons = new QDialogButtonBox(QDialogButtonBox::Yes | QDialogButtonBox::No | QDialogButtonBox::Cancel, dialog);` This leads me to believe that the checkbox having the focus is an irregularity, whether one would consider it a bug is a matter of prespective. But i would expect the frameworks to be consistent in what it does and whether the dialog has a parent or not should not affect what widget is focused. But just like @aacid mentioned, we should not look to break existing code, so given the new information on why this occurs, then perhaps a new implementation might be needed or simply a fix for this change in behaviour when a parent widget is present or not. REVISION DETAIL https://phabricator.kde.org/D7828 To: emateli, #frameworks, ngraham, aacid, #vdg Cc: abetts, subdiff, ngraham, aacid, #frameworks
