-
Notifications
You must be signed in to change notification settings - Fork 9
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
Release tag parity with Sway #35
Comments
Keeping parity with Sway releases was actually the intention, as per the README:
However, I just haven't been too happy with this fork. It... works (and I use it daily of course), but there's still some bugs and my intention is to redo most of the work in a way that also allows new features. When that will come I'm not sure, and it would be a breaking change, so maybe tagging a release wouldn't be a bad idea? I'd like to hear from other users before making a decision though, so please leave your comments below. |
definitely, it will be nice to have shadow/other additions which you can use selectively based on unique rules. One of the obvious gimmick is drop shadow of tiled applications going over taskbar which is not visually pleasing at all. |
I hope I can work on it soon! What are your thoughts about releases?
The current border images are drawn on the same layer as the window itself which I think makes sense. Take a look at if your taskbar has a way to draw on a different layer. For example, Waybar can have |
thanks I wasn't aware of that
you should take your time and go with your thoughts, I will prefer if we can see a good enough implementation of your ideal fork of sway |
I personally don't mind waiting till a release either, but personally how I use sway-borders is with nix (nix-flakes). With most packages, nix has a feature where you can match the fork's version with the version nixpkgs has. Since there hasn't been a release in a while, so Instead I just have it update with the latest commit. This works fine, its just a pain having to rebuild sway every few days. |
I would like tag release parity for the sake of non-Arch distros. At this time, Fedora 35 uses Sway 1.6. The sway-borders master is too new for the dependencies, and 1.4 is too old for the dependencies, with no releases in between. (But I'm seriously considering moving to Arch again for this. Awesome project. I wish they'd have taken something upstream.) |
It looks like there hasn't been a stable release tag since 1.4, would it be feasible to maintain release tag parity with Sway so we can have a stable AUR package and not have to rely on wlroots-git?
The text was updated successfully, but these errors were encountered: