Abandoned?

[uncomfyhalomacro]

No description provided.

[jirutka]

It looks so. Thus I’ve forked this project to jirutka/swaylock-effects, merged all upstream (swaywm/swaylock) changes to the point of 1.6 (based on #86) and released it as 1.6.10. This is now the upstream for the Alpine Linux package swaylock-effects.

[aacebedo]

Shall we redirect PRs on your repo @jirutka ? Got a modification that was left unmerged too and needs it.

[jirutka]

@aacebedo, yop. :)

[mortie]

Hey, sorry for not being very active on here.

The truth is that I don't use a system with wlroots anymore; my desktop has an nvidia card and my laptop is a mac. For a while I told myself that I could just do swaylock-effects development in a VM, but that hasn't really panned out. I should've been forthcoming about that earlier -- though I wasn't sure how to approach looking for an alternative maintainer without risking an event-stream-like situation.

@jirutka If you're prepared to be the new maintainer, I can officially make your repo the new canonical swaylock-effects repo by marking this as archived and adding a notice to the readme. Are you comfortable with that?

[mindrunner]

Hi @mortie @jirutka
I would like to see this going again. Maybe you could add me too, so that we can start rebasing and integrating open Pull reuquests? I'd like to continue using swaylock-effects in favor of the vanilla swaylock. However, we need some sort of maintenance, otherwise it's getting really messy at some point...

[iamkarlson]

@mortie perhaps you can add @jirutka as a contributor so this project would continue its life?

Nevermind, it seems that aur package swaylock-effects-git retargeted to a new @jirutka's fork already

[hollisticated-horse]

Maybe this project should be archived to signal that the new maintained project is the @jirutka branch ?

[mortie]

I did try to work something out with @jirutka, such as through this comment: #92 (comment), but I haven't heard anything back, and his branch doesn't seem super actively maintained either. If there was a branch by a reasonably active maintainer who I managed to communicate with, I would be happy to let them take over the project, either through a fork or even through commit rights on this repository...

I'm a bit unsure of what to do. The current situation is messed up, with this repository being the "face" of the swaylock-effects name yet jirutka's fork is behind most of the packages and neither project is active.

I do wish Jirutka had either gotten in touch with me before creating his fork so that we could've worked something out, or named his fork something else.

[532910]

I believe @jirutka is not going to support his fork: jirutka#29 so I'm staying on this one.

[jirutka]

I'm very sorry for not responding; I'm still not sure what to do either. I don't feel competent to maintain this project, I have no experience with the Cairo and Wayland APIs. I've created the fork out of necessity, to collect existing merge requests and to provide a more up-to-date source of swaylock effects for package maintainers, especially for Alpine Linux. I want to keep it alive with the current feature set, only accepting fixes and backports from upstream. My fork works very well for me on the latest Sway, so I don't feel the need to put any effort into it at this moment. The important thing for me is that it works with the new session lock protocol. I'd like to backport other changes from upstream (e.g. jirutka#1), but this would require too much effort for me (as I said, I don’t have much experience with these APIs), so I’m hoping someone more experience will eventually help me with it, as did with fixing the session lock protocol :)

[jirutka]

When I look into opened merge requests, I’m interested only in jirutka#32 (and jirutka#1) at this moment. I just need to find some time to review and merge jirutka#32. The others are low-priority for me.

[jirutka]

I believe @jirutka is not going to support his fork: jirutka#29 so I'm staying on this one.

I consider this as a provocation. It just doesn’t make sense. If it’s not, then please explain yourself better.

[mortie]

Right, that makes sense... dropping the ball like I did put people in a tough position, which I apologize for. Given your goal was "fix swaylock-effects for alpine", not "become the new permanent maintainer of the canonical version of swaylock-effects", it makes sense why you'd just create a fork under the same name.

For what it's worth, my branch of swaylock-effects is working perfectly fine on the latest Sway for me as well, although without the latest session lock protocol.

In related news, this discussion made me install Sway again on my laptop (as I mentioned before, it's a Mac, but Asahi Linux has come quite far by now!). It's quite comfortable. Maybe I'll come back to Sway, and with it, swaylock-effects. We'll see. At the very least, it should be way easier to find the motivation to work on a project I'm actually using. Ideally I'd at least get this repo rebased on top of upstream swaylock-effects.

[532910]

Not a provocation, just my point of view, moreover you confirm it:

I don't feel the need to put any effort into it

[hollisticated-horse]

Thank you for you reponses @mortie & @jirutka. It's at least clear now what going on 😁

I don't know if it was explained anywhere else, but is there a specific reason why swaylock-effects is not part of swaylock ?

[532910]

swaylock will be kept as simple as possible, check emersion's answers:
swaywm#143
swaywm#50

[jirutka]

I’ve backported commits from the swaylock upstream up to b4e3a2b (the third commit before 1.7.1) and released 1.7.0.0-rc1. 🚀

It works well on Sway 1.8.1 for me. Can you please test it?