Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wayland server side decorations #3425

Merged
merged 23 commits into from
Jul 2, 2024
Merged

Conversation

tarek-y-ismail
Copy link
Contributor

@tarek-y-ismail tarek-y-ismail commented Jun 14, 2024

Closes #3371

Had to move `XdgTopLevelStable` to its header file so I can include it,
and moved `from()` to be public.
@tarek-y-ismail tarek-y-ismail self-assigned this Jun 14, 2024
@tarek-y-ismail tarek-y-ismail requested a review from a team as a code owner June 14, 2024 09:39
Copy link

codecov bot commented Jun 14, 2024

Codecov Report

Attention: Patch coverage is 13.20755% with 46 lines in your changes missing coverage. Please review.

Project coverage is 77.40%. Comparing base (1398638) to head (faa1e16).
Report is 73 commits behind head on main.

Files Patch % Lines
...er/frontend_wayland/xdg_decoration_unstable_v1.cpp 8.00% 46 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3425      +/-   ##
==========================================
+ Coverage   77.31%   77.40%   +0.08%     
==========================================
  Files        1068     1074       +6     
  Lines       68284    68834     +550     
==========================================
+ Hits        52797    53282     +485     
- Misses      15487    15552      +65     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tarek-y-ismail tarek-y-ismail marked this pull request as draft June 14, 2024 11:07
Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a style guide at https://mir-server.io/doc/cppguide/

Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking the WAYLAND_DEBUG log, we're never sending a toplevel_decoration_v1.configure() event. The client needs this to know whether or not to draw decorations

Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like the basics are working. Once you're satisfied with "error handling" etc please mark the PR "ready"

As discussed, there should be some corresponding tests in wlcs.

@AlanGriffiths AlanGriffiths dismissed their stale review June 17, 2024 08:59

Comments addressed

@AlanGriffiths
Copy link
Contributor

Not needed for this PR

We should discuss a follow on PR that allows the decoration decision strategy to be customised by shells built with Mir.

There are eight possible strategies: the client has three requests (ssd, csd and unset) to which we can respond in two ways. But half of the "legal" strategies are perverse. What remains are:

  1. always-csd - whatever the client requests, send "csd"
  2. prefer-csd - if the client requests ssd then send "ssd", otherwise send "csd"
  3. prefer-ssd - if the client requests csd then send "csd", otherwise send "ssd"
  4. always-ssd - whatever the client requests, send "ssd"

@tarek-y-ismail tarek-y-ismail marked this pull request as ready for review June 25, 2024 09:07
Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to manage toplevels_with_decorations better. Stale entries are problematic for two reasons:

  1. decoration objects can be destroyed, leaving the corresponding toplevel incorrectly classified
  2. toplevel objects can be destroyed leaving an invalid pointer

Comparisons (during lookup) with invalid pointers are undefined behaviour

Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nits pending side-channel discussion

@tarek-y-ismail tarek-y-ismail force-pushed the wayland-server-side-decorations branch from eeaf76b to 0741868 Compare June 28, 2024 09:11
Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are also unresolved comments from an earlier review

tests/acceptance-tests/wayland/CMakeLists.txt Outdated Show resolved Hide resolved
tarek-y-ismail and others added 2 commits July 1, 2024 17:33
…able copying.

Co-authored-by: Alan Griffiths <alan@octopull.co.uk>
Also fixed a sneaky bug caused by checking if one toplevel was
registered instead of zero. toplevels should be already unregistered by
their decorations by the time they're destroyed, otherwise it's a
protocol error.
Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting there...

Comment on lines 148 to 149
const auto orphaned_decoration = !toplevels_with_decorations->unregister_toplevel(toplevel);
if (!client->is_being_destroyed() && orphaned_decoration)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const auto orphaned_decoration = !toplevels_with_decorations->unregister_toplevel(toplevel);
if (!client->is_being_destroyed() && orphaned_decoration)
if (!toplevels_with_decorations->unregister_toplevel(toplevel) && !client->is_being_destroyed())

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see what is achieved here other than saving a variable declaration (which the compiler likely optimizes anyway). I think the original might be a bit more readable.

Comment on lines 49 to 52
/// \return true if the toplevel didn't exist in the set, false otherwise.
/// The return value is used in the destroy callback of the toplevel to
/// check if the toplevel is destroyed before the decoration (orphaned
/// decoration).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This is a very weird semantic: returning false on success.
  2. It is normal to document the preconditions, action, and postconditions of a function. Not where its result happens to be used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I myself was a bit confused while using this method.

I've moved the explanation to where the mentioned case is actually handled. I might've detailed things too much, but I think this will save the next person (likely me :)) that works on this code some time.

Copy link
Contributor

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@AlanGriffiths AlanGriffiths added this pull request to the merge queue Jul 2, 2024
Merged via the queue into main with commit 6f465ad Jul 2, 2024
32 of 36 checks passed
@AlanGriffiths AlanGriffiths deleted the wayland-server-side-decorations branch July 2, 2024 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Wayland] XDG decoration protocol extension
2 participants