Now, hear me out. I am personally used to current OK/Cancel layout but I have been looking around and it seems KDE is inconsistent with most of software used Today. Changing layout would improve consistency with GTK3/Gnome applications which would give Linux distributions more consistent overall user experience and reduce tension between Qt/GTK apps. It would also improve consistency with Android, iOS and macos and appears to be also good idea from pure UX design point of view (https://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-best-on-the-right/). GTK/Gnome layout example: https://developer.gnome.org/gnome-devel-demos/stable/media/messagedialog.png Android layout example: https://i.stack.imgur.com/S4gZj.png macOS layout example: https://user-images.githubusercontent.com/6248794/61572704-43717680-aa91-11e9-94b8-23226ad88545.png iOS: https://i.stack.imgur.com/rXujp.png I know this change would be painful during the transition/accommodation period but I believe it is worth it and would be beneficial at the end of the day.
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.