Window title bar: follow system settings

[jpnurmi]

titlebar actions (lower, menu, minimize, none, toggle maximize, toggle maximize horizontally, toggle maximize vertically, toggle shade)

• double-click
• middle-click
• secondary-click

titlebar buttons

• maximize (show/hide)
• minimize (show/hide)
• placement (left/right)

see also

• https://docs.gtk.org/gtk3/class.Settings.html
• The Softwares Windows Titlebar Decorations doesn't properly allign with system settings app-center#792

[Feichtmeier]

Eventually we might need to increase the width of the very small compact sidebar by some pixels for this then

[jpnurmi]

Some issues highlighted by Tweaks.

With separated title bars, there's often no room in the leading area. Tweaks has to increase the width of the master pane...

Screencast.from.2023-01-16.09-21-26.webm

In portrait mode, the button arrangement gets a bit cumbersome. Notice also a rendering issue in the rounded top window corners.

Master	Detail

[12people]

Just submitted #762 , which would allow specifying a custom window control layout.

This way, a developer can choose to respect the platform's current window control layout — by using the YaruWindowControlLayout.parseGTKSetting(settingString) in combination with the gtk package, which can retrieve this GTK setting string.

There are several potentially controversial design choices I made that warrant additional discussion:

• Not including the gtk package. I decided to not add an extra dependency and keep the library lightweight, but it's worth considering whether Yaru shouldn't just always respect the appropriate GTK setting, without extra work by the developer.
• Removing isCloseable, isMaximizable, isRestorable, and isMinimizable. It seems to me that, with the new YaruWindowControlLayout and nullable onClose/onMaximize/onRestore/onMinimize callbacks, these attributes are no longer needed. These would also need to be removed from yaru_window_platform_interface, though.
• Reusing YaruWindowControlType for specifying layouts and treating "maximize" and "restore" as the same button. It didn't make sense to me to allow a different position for the "restore" button than for the "maximize" button, or to always specify both in the layout. That's why I treat this button type the same way and it doesn't matter if a layout specifies "maximize" or "restore" as long as it doesn't specify both. It might be worth creating a different enum for this altogether, with maximize/restore as a single entry.

What do you think about these points?

Let me know what the best way forward is.

[Feichtmeier]

Hi @12people
Thank you very much 👍
Generally not pulling more deps in is very wise.
I can not say much about the rest as what you say sounds plausible though needs maybe a bit more testing.
Or is this something that could be instead made in YaruWindow? (a dep of yaru widgets)

Even though this could take time or will happen never, I would prefer to see an opinion of @jpnurmi on this one.

[Feichtmeier]

@12people we def. want this in, thank you very much for your work. But since I did not write those parts but JP (which sadly left) we need to be sure that it works. I hope I will find soon time to properly review this

[12people]

No problem.

I should just mention that before this is merged, the issues brought up above need to be resolved and also tests need to be adjusted (at least goldens — there will be new ones needed).