The order is determined by the Qt platform plugin. This means if you have Qt installed correctly, including a plugin for the Desktop/OS you are using, the button order should match the platform defaults.

I am aware of that - the point of this ticket is to change platform defaults for KDE, i.e. to change hard-coded QDialogButtonBox::KdeLayout to work similar (same?) as QDialogButtonBox::GnomeLayout, so we would have same button-order while running applications from KDE (right now GTK apps share widget style but have different button order).
At the very least it would be nice to have it configurable:).

Does Windows use the same button order as those platforms, or as us? Or something else?

Regardless, it seems like this change would have to be made in Qt.

Windows is still using "old" layout but it is the only one (in the mainstream) I am aware of.
It would be nice to have it at least configurable (I think it was possible back in KDE3 days) so we could experiment with that. Currently this is hard-coded in source code and users have to resort to workarounds to achieve what they want (https://unix.stackexchange.com/questions/149818/how-to-give-the-same-order-for-ok-and-cancel-buttons-in-kde-and-gnome-applic).

So basically this boils down to whether we should be more like Windows, or more like everyone else in the industry besides Windows.

Personally I would be okay with this, but I suspect it would be very controversial.

Basically yes. As noted before I am a long time user and as such I am used to current layout, but I believe it would be better in grand scheme of things to change time. Time has changed and now there is much more KDE users that are also using Android (or iOS) than users with KDE+Windows. Not to mention KDE+GTK.

KDE also supports GTK applications by trying to make them look as native as possible and I think such change would reduce uncanny valley for layman users of KDE+GTK apps in KDE session.

Yeah, in general I agree that it makes sense to align with the de facto standard in the rest of the industry.

I guess it just depends on whether you consider "the rest of the industry" to mean "Windows" or "everything else apart from Windows." :)

> I guess it just depends on whether you consider "the rest of the industry"
> to mean "Windows" or "everything else apart from Windows." :)

10 years ago it would be Windows, but nowadays I believe not so much. I think it is better to be more familiar for FSF users (e.g. AOSP) and have more unified user experience on Linux Qt+GTK desktop as Windows is no longer as ubiquitous as in the past - there is new generation growing up for which mobile OSes (and maybe Chrome OS, which also uses "OK on the right - https://o.aolcdn.com/hss/storage/midas/c15853eddb12fc3ac8c9dfc2cd8b3948/205362663/chromeos-printer-ipp.jpg) are point of reference.

Thanks, your arguments make sense to me.

This small quality-of-life change would be perfect to feature in the Plasma 6 release ;)

For implementation, we should probably have a toggle between "OK/Cancel" and "Cancel/OK", with pictures of the layouts on each button. We could have advanced settings that would allow the user to choose any [QDialogButtonBox::ButtonLayout](https://doc.qt.io/qt-6/qdialogbuttonbox.html#details). We need to expose this value somewhere in System Settings and patch plasma-integration's [Qt5 khintssettings.cpp#L116](https://invent.kde.org/plasma/plasma-integration/-/blob/master/qt5/src/platformtheme/khintssettings.cpp?ref_type=heads#L116) and [Qt6 khintssettings.cpp#L116](https://invent.kde.org/plasma/plasma-integration/-/blob/master/qt6/src/platformtheme/khintssettings.cpp?ref_type=heads#L116). Additionally, we need to change the gtkrc to set [alternate-button-order](https://docs.gtk.org/gtk4/property.Settings.gtk-alternative-button-order.html) to true, if the user chooses "OK/Cancel", and to false, if the user chooses "Cancel/OK". I might try to work on this, but I don't really know enough of how System Settings and the Gtk integration works.

It looks like QQC2 and Kirigami applications should use the layout we set for Qt Widgets: https://doc.qt.io/qt-6/qml-qtquick-controls-dialogbuttonbox.html#buttonLayout-prop

I don't know how we can configure the other GUI toolkits, such as EFL, Tk, Flutter, GNUstep, MauiKit, Winelib, etc. I think some of those are not configurable.

For Gtk integration, I think we'll need to add a config value in some config file somewhere, add a method to retrieve the value to https://invent.kde.org/plasma/kde-gtk-config/-/blob/master/kded/configvalueprovider.h?ref_type=heads and a method to set the gtk configuration to https://invent.kde.org/plasma/kde-gtk-config/-/blob/master/kded/gtkconfig.h?ref_type=heads . If I'm missing something here, please tell me.

For years, since switching from MATE (GNOME 2) to KDE, I've patched my copy of `plasma-integration` with this command:

    sed -i 's/QDialogButtonBox::KdeLayout/QDialogButtonBox::GnomeLayout/g' {qt5,qt6}/src/platformtheme/khintssettings.cpp

I agree with the UX point of view that primary actions are better / more optimum on the right - due to eyes scanning in a zig-zag pattern. However, it is also a good point that KDE for the longest time declared [in Qt] the primary button being first (like Windows), so transition could be more involved. For the most part, Qt Widgets and GTK apps were consistent on my system, but I just realised in this report Qt Quick (e.g. configuring an applet) was not [OK/Apply/Cancel].

Like with the "single click" and "double click" default, I think having an option in System Settings to choose would be good to start with, since it is currently hardcoded. There is a secret plan for KDE world domination, right? :)

I should note that since Plasma 6, KFileWidget is hardcoding the button order [OK, Cancel] in `src/filewidgets/kfilewidget.cpp`. (It probably should be using a QDialogButtonBox)

```
--- a/src/filewidgets/kfilewidget.cpp
+++ b/src/filewidgets/kfilewidget.cpp	
@@ -1473,8 +1473,8 @@
                              q->style()->pixelMetric(QStyle::PM_LayoutBottomMargin));
 
     hbox->addStretch(2);
-    hbox->addWidget(m_okButton);
     hbox->addWidget(m_cancelButton);
+    hbox->addWidget(m_okButton);
 
     m_opsWidgetLayout->addLayout(hbox);
 ```

I am likely not going to be able to work on fixing this until the summer, and I'm not sure if I'll work on it this summer. If anyone wants to pick up this issue that'd be great.

I now have enough disk space to build KDE on my laptop, so hopefully that won't be a blocker as it was before. However, I still am quite busy.

I think the right approach would be to port it to QDialogButtonBox, and then it will respect the upstream positioning from Qt automatically. Then we can patch Qt to change the positioning everywhere.

Just noting here some history of QDialogButtonBox in KFileDialog:

- https://invent.kde.org/frameworks/kio/-/merge_requests/1461 last touched these "Cancel" and "OK" buttons. Revealing:
- Nate, you had a MR: https://invent.kde.org/frameworks/kio/-/merge_requests/1243 to switch to QDialogButtonBox, but it was closed in favour of the above and may be revisited.

Also an observation: In KDE Discover, the top-right buttons to "Install" and "Launch" are already positioned to the far right. While not exactly styled like a primary button, they're like the primary action (→) nevertheless, in case it comes up in discussions.