Skip to content

KMessageBox/KMessageDialog: add API using "action" terms instead of "Yes" & "No"

Friedrich W. H. Kossebau requested to merge work/kossebau/deprecateyesnoonly into master

Using "Yes" & "No" text labels on dialog buttons is discouraged by not only the KDE HIG these days. Still the classic KMessageBox and the newer KMessageDialog API has been using these terms in the API in method and argument names, and also defaulting to using these labels.

This introduces a substitute API for both classes in separate commits along these changes:

  • Yes -> PrimaryAction
  • No -> SecondaryAxction
  • YesNo -> TwoActions
  • no default Yes & No labels

It also deprecates KStandardGuiItem::yes() KStandardGuiItem::no() in a final commit.

Compare the recommendations of the KDE HIG on Modal Message Dialog:

Buttons should clearly indicate the available options using action verbs (“Delete”, “Rename”, “Close”, “Accept”, etc.) and allow the user to make an informed decision even if they have not read the message text. Never use “Yes” and “No” as button titles.

Also see https://frinring.wordpress.com/2022/09/13/no-yes-no-yes/ for some more material driving this proposal.

Another motivation to go away from Yes & No is that in some languages those words alone seems not available. See https://en.wikipedia.org/wiki/Yes_and_no and the (sadly broken) extra hooks once added for KMessageBox (see comment in respective clean-up MR -> !150 (comment 536288)).

((I wanted to propose such an API change already for some time, but hoped I could do a full redesign of message dialogs across KF in general. Well, I tried multiple times and sketched quite some patches, but failed to come up with something satisfying myself. So remembering the perfect being the enemy of the better... this here now is at least the most basic thing to do: just a 1:1 replacement of any Yes/No API, to solve that bit)).

Edited by Friedrich W. H. Kossebau

Merge request reports