With qt apps in KDE, the OK button is on the left of the cancel button, but in gtk apps it’s on the right.
GNOME forces the OK button to the right regardless if the app is gtk or qt, but in KDE it changes on an app-by-app basis.
Though I’d prefer the OK button on the right, is there any way I could make it consistent, so the OK button always on the right or always on the left?
I don’t think this is possible.
Application developers will generally place the buttons in a specific order based on the context and sometimes the language. The idea is like… sometimes an application might want to suggest that you click OK and make it quick, or might want to suggest that you click Cancel to make it safe.
The user is probably going to start with one side or the other, based on the direction of their language, so the application can guide them toward selecting a certain action which is appropriate for the situation, by putting the most appropriate button in the first place a user would go to.
Because of this, it’s generally not advisable to mess with the order, as you’re very likely messing with safety mechanisms, and ease-of-use design.
I’m sorry, I don’t know why Gnome would do that.
Hi!
Are you referring to things like file open and save dialogs, by chance? Things like the below screenshot of KolourPaint running on an Ubuntu device:
If so, then for what it’s worth, that’s not necessarily GNOME changing where an application’s buttons are, but the application telling the desktop environment “I need a file picker dialog”, and GNOME providing its own.
If that’s not what you’re referring to, then it might help to see a screenshot of an application that shows different button orders depending on the desktop environment. The ultimate answer to changing the button layout of an application - outside of intentionally custom toolbars - would likely be getting into source code, though!
Hey,
The screenshot below is of a Qt program in KDE - In KDE, the buttons of Qt programs are always ordered so that the OK/perform action/confirm button will be the button to the left of the cancel button:
Thanks
The problem is that GNOME choose to change a fundamental part of UI-language without ensuring applications can adhere to it or not, whether or not they are GTK applications or not.
And this is not just Qt applications that look broken in GNOME but all non-GTK applications in general.
By all means the reverse order of the traditional button position is nice design-wise, but there is no standard for application/toolkits to know that “positive button” should be on the right, or so it can be controlled by the user and apps can adapt depending on the DE.
Think about reverse language (for arabic…) in comparison, Open/Save dialog, dark-theme where there are standards.
So you are asking KDE to adapt to GNOM-ism that Gnome community didn’t even try to standardize this in the first place.
KDE community has been pushing for standardization with GNOME (Wayland Server-side decoration, Global menu…), but GNOME community cares mainly (only?) about GNOME and GNOME applications, it seems to me.
I can’t really blame GNOME community for it, both community are fueled by good-will and collaborative work incentive is not high unfortunately.
Oh, I see - I hadn’t heard the backstory, so I just assumed it was a Qt/GTK problem.
I don’t really mind if it’s done the KDE way or the GNOME way, but is there a method to force all programs (including GNOME ones) to use the KDE ordering - maybe using the same method that GNOME uses to force every app to use its ordering?
It’s not the order of the buttons that bothers me, just that in KDE it changes on a app-by-app basis.
Thanks
Actually for dialogs it is most common for Qt based applications to use QDialogButtonBox which can handle different ordering internally depending on platform and style.
On a GNOME (and likely other predominantly GTK desktops) this will usually result in a Cancel/OK layout, while on a KDE desktop it is OK/Cancel.
See also here
It might be possible to influence this by choosing a different style so that Qt (and KDE) applications follow the GTK layout.
Or the other way around assuming that GTK has a similar capability.
I didn’t know about that.
QStyle::SH_DialogButtonLayout in QStyle Class | Qt Widgets 6.8.2
We could use that in KDE Frameworks 
Then in KDE way, we could let users pick the buttonLayout they prefer, or the Qt Application style.
There is Qml control also to think about 
There is also a similar hint in the platform theme API
No idea in which order these are evaluated to determine the layout of the button box.
There is also a QtQuick.Controls item for Dialog Button Box
I don’t fully understand this, but does it mean that it can’t be done without rewriting KDE’s code?
It might already be possible to do this through settings a different style.
What the developers are discussing is that it might be easy to have to have this as a specific option across all styles.
When you say a different style, do you mean themes - so picking a different theme could swap the buttons? I’m using the default theme right now.
Yes, it is the “Application Style” setting in “Color & Themes” section of the system settings application
Yep, I see now. I just tried the three styles (Breeze, Fusion, MS Windows 9x), but none of them styled the buttons - I also downloaded a few GTK themes from the “Get new GNOME/GTK Application Styles…” section, but I had no luck with that either.
You mentioned earlier that it might be possible to add a toggle to switch the button order across all styles - Do you know how I’d request this and who from?
Thanks
Probably as a wish on bugs.kde.org product “system settings”, maybe component “kcm_style”
