Synchronize decorations buttons order in GTK headerbars
Needs ReviewPublic

Authored by gikari on Sun, Dec 1, 11:12 PM.

Details

Summary

Window decorations button order was applied only for window headers that was controlled by KWin, but not for GTK applications with CSD. Now it is no longer true - button order in CSD applications are in sync with the one used by KWin.

Only Close, Maximize, Minimize and Icon buttons are synchronized, because GTK supports only them.

Depends on D25695

Test Plan
  1. Open two windows alongside each other: window decorations button order settings and any gtk3 app with CSD (for example, Lutris)
  2. Restart kded5
  3. Apply any WD button order, apply settings
  4. The app should change its buttons order in headerbar (if xsettingsd is not installed, on X11 only after restart)

Diff Detail

Repository
R99 KDE Gtk Configuration Tool
Branch
gtk-decoration-order-sync (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 19410
Build 19428: arc lint + arc unit
gikari created this revision.Sun, Dec 1, 11:12 PM
Restricted Application added a project: Plasma. · View Herald TranscriptSun, Dec 1, 11:12 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
gikari requested review of this revision.Sun, Dec 1, 11:12 PM
gikari edited the test plan for this revision. (Show Details)Sun, Dec 1, 11:22 PM
cblack added a comment.EditedSun, Dec 1, 11:27 PM

You would probably want to use icon instead of menu, as menu is only rendered as a fallback for a pattern that most GNOME applications don't use nowadays.

Edit: Additionally, GTK apps that use an appmenu typically override the window decoration layout to reflect this. If they don't, then that's an issue on their end.

gikari added a comment.EditedMon, Dec 2, 4:26 AM

You would probably want to use icon instead of menu, as menu is only rendered as a fallback for a pattern that most GNOME applications don't use nowadays.

Edit: Additionally, GTK apps that use an appmenu typically override the window decoration layout to reflect this. If they don't, then that's an issue on their end.

I would like to say "It is their issue", but the thing is, if we remove appmenu from that apps, they will be unusable, because this menu contains important functionality, that is not present in the other parts of an app. If I choose to just grab icon instead of menu, apps would break and the user will be confused and unable to use these apps.

Edit: As I discovered, the BleachBit appmenu and Hambuerger menu duplicate each other, so for that app it would be safe to remove appmenu. However for Lutris it not true. They have an issue on their issue tracker about this.

broulik added a subscriber: broulik.Mon, Dec 2, 8:03 AM

It would be sensible to use an individual signal. I would like to hear an advice about its naming.

Alternatively you could have the KWin decoration KCM use writeEntry with Notify flag and then use a KConfigWatcher here instead of connecting to KWin's generic DBus signal.

gikari updated this revision to Diff 70778.Mon, Dec 2, 9:06 PM
gikari edited the test plan for this revision. (Show Details)
  • Use KConfigWatcher instead of KWin dbus signal
gikari updated this revision to Diff 70782.Mon, Dec 2, 9:28 PM
  • Change appmenu to icon
gikari edited the summary of this revision. (Show Details)Mon, Dec 2, 9:29 PM