libdecor should not interfere with client window size
As one of the developers of the FLTK GUI toolkit I'm involved in the port from X to Wayland (done mostly by @ManoloFLTK). We started using libdecor but we're facing a problem that libdecor and its plugin(s) set their own (minimum) window sizes.
@christian-rauch wrote in MR 92 "The reason for enforcing this plugin minimum size is that the plugin must make sure that its widgets will always be shown and useable in the minimum configuration".
Although this looks sensible from the plugin developer's view I don't agree with this statement for the following reasons:
The description on libdecor's main page is: "libdecor is a library that can help Wayland clients draw window decorations for them". From the view of a client this means that libdecor provides a service that adds decorations around the client area of the window. This should not affect the client area.
Users (program developers) migrating from X to Wayland would encounter a regression if they can't set the window size (particularly the width) to values smaller than what each plugin requires. This affects creating small windows (with decorations) as well as user resizing of windows to small sizes.
Such a regression would likely prevent wide usage of libdecor.
I'm aware that displaying only partial window titles (or no title at all) or no window buttons would be "not usable" directly but my point is that this must be the responsibility of the application developer and not of the decoration library.
I propose to add a statement to libdecor documentation (specification) that libdecor and its plugins must not interfere with the client's window sizes. This should be a requirement for all plugins as well. The minimum acceptable window size could be 1x1 (width x height) or even 0x0 pixels in extreme cases. This should be rare exceptions though. This choice is only meant for the specification because there can be no real "minimum size" for the client area of a window. Would it be 5x5, 10x10, or what else?
As a compromise I suggest an API that libdecor and/or its plugins can return their own optimal minimum sizes (depending on the currently active/visible buttons etc.) to the client so the client can adjust its window size - but the latter must be optional. The client must always control its window (client area) size.
Given the current status of only one integrated "Cairo plugin" and Christian Rauch's "Gtk plugin" and their different requirements leaving the decision to the plugins sounds like asking for chaos.
Particularly the minimum window height (set in the Cairo plugin IIRC) does not seem plausible at all. IMHO the window height (which is its client area height!) must be allowed to be 0. I can imagine a "window" that has no content and displays its information only in the title bar.
It should also be made clear that libdecor and its plugins must be able to use the available space (given by the client) w/o side effects like emitting warnings on stderr (as the Gtk plugin does when the window width drops below 124 or 134).
It is also not acceptable that the client would need to switch off some of the buttons (minimize, maximize) to be able to reduce the window width. The client can never know how much space particular decorations would need and the client should be agnostic of the loaded plugin. This can only be known in the plugin code, hence the plugin code would have to determine which items can be displayed and only draw those.
Christian Rauch referred me here from a discussion on Matrix to ask you (@jadahl) for your opinion on this topic and this was my reason to open this issue.
I apologize for the long description but it's not easy to describe why I believe that this is important, not only for FLTK but also for other program developers and the usability of libdecor.
Thanks for reading and considering this proposal.