Add control buttons

[elinorbgr]

Add a "close" button on the upper-right corner, to close the window.

A "maximize/unmaximize" and "minimize" button can most likely be considered too.

[elinorbgr]

(I can mentor anyone who would be willing to attack this but is not familiar enough with wayland)

[dns2utf8]

Sounds interesting. I have no clue how this works 😜

[elinorbgr]

(sorry for the late answer, I was away from computer)

The rough idea here is that wayland does not handle decorations, so we are forced to draw them oursleves. This means there are a few substeps to this:

• First, alter the drawing code to actually display buttons (the logic handling the drawing is in the DecoratedSurface::resize(..) method, here). The drawing is done by writing pixel values to a shared memory location (self.tempfile in this code), and then sending views to this data to the compositor to define the surface contents. Currently, the shared memory is just filled with grey pixels and the 4 views for the 4 borders overlap a lot. This will likely need to change given the surfaces will now have different contents (the top one will have buttons).
• Second, figure out where the pointer is when a click is done, to decide whether a button was clicked or not. This will probably be an extension of the code figuring where the pointer is to update the pointer image to suggest resizes. This code is in the implementation of the private PointerState struct, here.
• Finally, update the handler trait for the use to add the new possible events associated to maximizing / minimizing / closing

The wayland-specific stuff is mostly in the last part, for merging events generated by our decorations with events coming from the server.

[dns2utf8]

Okay, sounds like some work. I am setting up an Arch VM for the development, have not switched my main desktop to wayland.

[dns2utf8]

My current problem is funny/strange: I can not run the example.
It hangs in the ´event_queue.dispatch().unwrap()´.
My setup is Arch Linux with KDE plasma.

[elinorbgr]

Oh well... This kind of issues occur way too often :(

Can you run the example with the env variable WAYLAND_DEBUG=1 set and provide the output here?

[emersion]

A better solution would be to use server-side decorations for DEs that implement it. That's a wayland extension: https://cgit.kde.org/kwayland.git/tree/src/client/protocols/server-decoration.xml

[elinorbgr]

For now KDE is the only compositor to implement server-side decoration AFAIK.

So yes, it'd be good to use them when available, but we still need to be able to draw our own. Client-side decoration is still the "official" way of doing it.

[emersion]

Is this bug fixed?

[elinorbgr]

Basic control buttons exist with the latest version of wayland-window (which is used by the latest version of winit). So this can be closed, yeah.