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

Distinguish between "should it be decorated" and "should it use SSD" #1724

Closed
wants to merge 6 commits into from

Conversation

xi
Copy link
Contributor

@xi xi commented Apr 18, 2024

The ToggleDecorations action in Openbox was used to decide whether decorations should be drawn or not. The keepBorder setting is used to decide whether "undecorated" windows should still have a border or not.

In Wayland this is more complicated because we have to consider client side decorations (CSD) in addition to the traditional server side decorations (SSD).

Initially, ToggleDecorations in labwc toggled SSD on and off. Since support for keepBorder was added in #876, ToggleDecorations cycles through full SSD, only borders, and no SSD. This approach has some issues:

  • Whether SSD is enabled initially is negotiated for each window individually, there is no way to know what <windowRule><action name="ToggleDecorations"/> would do.
  • It is not clear which of the 3 states the Decorate and Undecorate actions are supposed to transition to

My proposal is to split this into two different topics: ToggleDecorations, Decorate, and Undecorate toggle SSD on and off, like before. Adding Decorate and Undecorate allows to target a specific state without needing to know the initial state.

In addition to that, the new set of actions ToggleTitlebar, ShowTitlebar, and HideTitlebar can be used to modify the SSD. If keepBorder is off, the border will be hidden along with the titlebar.

This gives us all the combinations there are. However, there is some redundancy:

  • HideTitlebar with keepBorder=no is effectively the same as Undecorate
  • <windowRules><action name="Undecorate"> is effectively the same as <windowRule serverDecoration="no"/>

i therefore went ahead and removed keepBorder again. I did not remove serverDecoration because I figured that it is more performant/causes less flicker than the corresponding actions.

Some examples:

<!-- hide titlebar for all windows -->
<windowRule identifier="*">
  <action name="HideTitlebar"/>
</windowRule>

<!-- hide titlebar on maximize -->
<keybind key="W-Up">
  <action name="HideTitlebar"/>
  <action name="Maximize"/>
</keybind>

@ahesford
Copy link
Member

I like the idea of Decorate and Undecorate, but think that the *Titlebar actions are redundant and unnecessary. Also, we need to keep around the current ToggleDecorations and theme.keepBorder behavior for a long time, because we don't want to break existing configurations.

My proposal would be:

  1. Add the new Decorate and Undecorate actions.
  2. Support a new keepBorder argument to both the ToggleDecorations and Undecorate actions. If keepBorder is yes on a ToggleDecorations action, then ToggleDecorations cycles through the three states (full decoration -> border only -> no decoration); when its keepBorder action is no, it cycles through only two states (full decoration -> nodecoration). [This is the current behavior, just with keepBorder becoming an argument to the action itself.] In the Undecorate action, keepBorder will behave intuitively: when yes, Undecorate will remove only the titlebar; otherwise, it will remove the border and titlebar. The Decorate action should always show both the titlebar and border.
  3. Make the existing theme.keepBorder field the default value of the keepBorder arguments for any ToggleDecorations and Undecorate actions that do not provide a specific value.

@ahesford
Copy link
Member

I find #1725 preferable, but let's see if others agree.

@ahesford ahesford marked this pull request as draft April 19, 2024 12:17
@xi
Copy link
Contributor Author

xi commented Apr 20, 2024

Closed in favor of #1733

@xi xi closed this Apr 20, 2024
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.

None yet

2 participants