You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
It doesn't pass the build tests.
It uses KDE's obsolete server_decoration protocol. It'll have to use the official xdg-decoration protocol.
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).
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:
There are merge conflicts.
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.
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).
The text was updated successfully, but these errors were encountered:
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:
git clone
in$XDG_DATA_HOME
/themes (or$prefix
/themes)).Additional problems now:
yes
andno
, as well asclient
(always use client-side decorations, even if server-side decorations were requested) andserver
(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
).The text was updated successfully, but these errors were encountered: