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

Release tag parity with Sway #35

Open
nboughton opened this issue Jun 5, 2021 · 6 comments
Open

Release tag parity with Sway #35

nboughton opened this issue Jun 5, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@nboughton
Copy link

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?

@nboughton nboughton added the enhancement New feature or request label Jun 5, 2021
@fluix-dev
Copy link
Owner

Keeping parity with Sway releases was actually the intention, as per the README:

Releases will follow Sway's.

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.

@Iss-in
Copy link

Iss-in commented Jun 15, 2021

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.

@fluix-dev
Copy link
Owner

definitely, it will be nice to have shadow/other additions which you can use selectively based on unique rules.

I hope I can work on it soon! What are your thoughts about releases?

One of the obvious gimmick is drop shadow of tiled applications going over taskbar which is not visually pleasing at all.

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 "layer": "top" set to draw above and thus your shadows (and window) will indeed be lower.

@Iss-in
Copy link

Iss-in commented Jun 15, 2021

Waybar can have "layer": "top" set to draw above

thanks I wasn't aware of that

What are your thoughts about releases?

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

@shaunsingh
Copy link

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.

@wattahay
Copy link

wattahay commented Dec 13, 2021

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants