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

Server-side decorations support #31

Closed
keithbowes opened this issue Feb 26, 2022 · 0 comments
Closed

Server-side decorations support #31

keithbowes opened this issue Feb 26, 2022 · 0 comments

Comments

@keithbowes
Copy link
Collaborator

A while back, @icedman created PR #24, but never addressed the problems. If someone wants to pick this up and make it possible to merge, that would be great. The problems with the PR upon its creation:

  1. It doesn't pass the build tests.
  2. It uses KDE's obsolete server_decoration protocol. It'll have to use the official xdg-decoration protocol.
  3. Some of the source files are huge (so huge that GitHub won't even show them). If that's necessary, that's OK, but I have a feeling it's not. In particular, rendering XPM files shouldn't be something to do. XPM files can easily be converted to SVG and windowing system-agnostic libraries can be used for them (instead of adding a bunch of code to Waybox to handle a legacy format).
  4. It adds a lot of new themes. I don't think these should be added to the Waybox repo. Maybe the default theme should, but largely, I'd rather a different repo for themes (ideally, one arranged so that someone could just use git clone in $XDG_DATA_HOME/themes (or $prefix/themes)).

Additional problems now:

  1. There are merge conflicts.
  2. It relies on the wlroots gles2 renderer (optional since wlroots 0.14.0), so it's not renderer agnostic. I suppose we could change meson.build to build it only when wlroots has a gles2 renderer, but I'd prefer something that could be used with any renderer.
  3. It forces server-side decorations. Client-side decorations should be used if the client requests them. I think we should use Openbox's <decor> element (only making it global, instead of only possible in <application>), with the Openbox values yes and no, as well as client (always use client-side decorations, even if server-side decorations were requested) and server (always use server-side decorations, even if client-side decorations were requested). However, I'd be implementing that option and it would only be the job of whoever takes this up to make sure that client-side decorations are used if they're requested (it's easy to detect: wlr_xdg_toplevel_decoration_v1.requested_mode).
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

No branches or pull requests

1 participant