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

Add CSD to border modes #2703

Merged
merged 5 commits into from
Oct 3, 2018
Merged

Add CSD to border modes #2703

merged 5 commits into from
Oct 3, 2018

Conversation

RyanDwyer
Copy link
Member

@RyanDwyer RyanDwyer commented Sep 24, 2018

This replaces view.using_csd with a new border mode: B_CSD. This also removes sway_xdg_shell{_v6}_view.deco_mode and view->has_client_side_decorations as we can now get these from the border.

You can use border toggle to cycle through the modes including CSD, or use border csd to set it directly. The client must support the xdg-decoration protocol, and the only client I know of that does is the example in wlroots.

If the client switches from SSD to CSD without us expecting it (via the server-decoration protocol), we stash the previous border type into view.saved_border so we can restore it if the client returns to SSD. I haven't found a way to test this though.

Closes #2429.

Copy link
Contributor

@ddevault ddevault left a comment

Choose a reason for hiding this comment

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

I suppose I can throw out my WIP xdg-decoration branch 😄

* Updates the view's border setting when the client unexpectedly changes their
* decoration mode.
*/
void view_set_csd_from_client(struct sway_view *view, bool enabled);
Copy link
Member

Choose a reason for hiding this comment

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

I tried to use "set" for the server-side and "update" for the client-side. Is it possible to rename this to view_update_csd_from_client?

WLR_XDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE;
struct sway_view *view = decoration->view;

view_set_csd_from_client(view, csd);
Copy link
Member

Choose a reason for hiding this comment

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

current_mode isn't the client preference, it's the current mode as chosen by the compositor.

To get the client preference, listen to request_mode.

@RyanDwyer RyanDwyer force-pushed the csd-border branch 2 times, most recently from 8e46f5d to 212eede Compare September 27, 2018 12:47
@RyanDwyer
Copy link
Member Author

RyanDwyer commented Sep 27, 2018

Copying my latest commit message into here...

This does the following:

  • Removes the xdg-decoration surface_commit listener. I was under the impression the client could ignore the server's preference and set whatever decoration they like using this protocol, but I don't think that's right.
  • Adds a listener for the xdg-decoration request_mode signal. The protocol states that the server should respond to this with its preference. We'll always respond with SSD here.
  • Makes it so tiled views which use CSD will still have sway decorations rendered. To do this, using_csd had to be added back to the view struct, and the border is changed when floating or unfloating a view.

Also note that when testing with the wlroots toplevel-decoration example, that example does not support server-decoration, so according to the server-decoration protocol we assume the client is using CSD. However, the example client believes it's using SSD as that's sway's default, so there's a mismatch there until the first time you change the border. Fixed by removing server-decoration assumption if view supports xdg-decoration.

This replaces view.using_csd with a new border mode: B_CSD. This also
removes sway_xdg_shell{_v6}_view.deco_mode and
view->has_client_side_decorations as we can now get these from the
border.

You can use `border toggle` to cycle through the modes including CSD, or
use `border csd` to set it directly. The client must support the
xdg-decoration protocol, and the only client I know of that does is the
example in wlroots.

If the client switches from SSD to CSD without us expecting it (via the
server-decoration protocol), we stash the previous border type into
view.saved_border so we can restore it if the client returns to SSD. I
haven't found a way to test this though.
This does the following:

* Removes the xdg-decoration surface_commit listener. I was under the
impression the client could ignore the server's preference and set
whatever decoration they like using this protocol, but I don't think
that's right.
* Adds a listener for the xdg-decoration request_mode signal. The
protocol states that the server should respond to this with its
preference. We'll always respond with SSD here.
* Makes it so tiled views which use CSD will still have sway decorations
rendered. To do this, using_csd had to be added back to the view struct,
and the border is changed when floating or unfloating a view.
@ddevault
Copy link
Contributor

This can be a separate patch, but I wonder if we should make XDG windows tiled on all four sides if they're floating with a server-side border. Then GTK for example will stop using rounded corners.

@emersion
Copy link
Member

I wonder if we should make XDG windows tiled on all four sides if they're floating with a server-side border

If we do, we should only do so if server-decoration says the window is using CSD and xdg-decoration isn't supported.

@ddevault ddevault merged commit 06c214a into swaywm:master Oct 3, 2018
@ddevault
Copy link
Contributor

ddevault commented Oct 3, 2018

Thanks!

@RyanDwyer RyanDwyer deleted the csd-border branch October 3, 2018 11:07
@Dudemanguy Dudemanguy mentioned this pull request Oct 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants