Added support for the Scroll WM (Sway WM fork)

[Erothas]

Pull Request

Motivation

Scroll WM is a fantastic Sway WM fork that many people are using. Everything about is almost identical to its upstream window manager, except a very small part of its syntax. All I did was simply duplicate the SwayService.qml, and replace every instance of the word Sway to Scroll. That pretty much reflects how you would, in general, change the syntax from Sway's to Scroll.

Type of Change

• New feature

Checklist

• Code follows project style guidelines
• Self-reviewed my code

Additional Notes

I will apologise in advance because I don't know much about this ecosystem, and I have even never submitted a pull request in my life before. So, this may go wrong in many way. Or.. maybe my simplistic view on how things run, may actually be enough for the Scroll support I wish for :)

[ItsLemmy]

I tried Scroll the other day and yep it's 99% sway, so most things worked out of the box.

This is a good starting point but right now this PR won't do anything unless we implement a way to detect Scroll so that this compositor backend is loaded.

in CompositorService.qml function detectCompositor() maybe via XDG_CURRENT_DESKTOP as we do for mango? I'm not sure what Scroll sets as env var. If we dont have that then Scroll will be identified as Sway and this service will not be loaded.

[Erothas]

@ItsLemmy Thank you for taking a look at my very modest attempt toward Scroll support. To address your worries: Yes, every Scroll user is recommended (and has to) set his XDG_CURRENT_DESKTOP to Scroll. Please take a look at the Setting environment variables for Scroll link. That should be simple enough then, right?

Edit: I also forgot to mention that I have been experiencing noctalia crashing every time my system wakes up from sleep or screen idling, ever since I installed it. I believe that supporting scroll with the above needed changes would fix that.

[Erothas]

I took it upon myself to include the Scroll detection in the CompositorService file as requested. But I am so confused about why this PR got closed, or how the commits took shape. But I believe, after looking at the files changed above, that my small changes were the ones that went through, and nothing else was messed up... I hope.

[Ly-sec]

I took it upon myself to include the Scroll detection in the CompositorService file as requested. But I am so confused about why this PR got closed, or how the commits took shape. But I believe, after looking at the files changed above, that my small changes were the ones that went through, and nothing else was messed up... I hope.

Hey there, I'm just looking through it right now - while I have no idea about how scroll implements stuff I'm fairly certain it's basically the same as our sway implementation no? Couldn't we just check for sway and scroll (in CompositorService) and just use the SwayService?

[Erothas]

I took it upon myself to include the Scroll detection in the CompositorService file as requested. But I am so confused about why this PR got closed, or how the commits took shape. But I believe, after looking at the files changed above, that my small changes were the ones that went through, and nothing else was messed up... I hope.

Hey there, I'm just looking through it right now - while I have no idea about how scroll implements stuff I'm fairly certain it's basically the same as our sway implementation no? Couldn't we just check for sway and scroll (in CompositorService) and just use the SwayService?

I can see why you would prefer that approach. Basically, any work being done on Sway, instead of it being duplicated to a WM that functions the same exact way, it's better to consolidate them into one entity, and minimise future development time.

So, I agree.. That being said, that would require a bit of refactoring on the SwayService file. That's surely above my pay grade. I can imagine it being easy in theory. I will see if I could figure it out on my own.

[Ly-sec]

I took it upon myself to include the Scroll detection in the CompositorService file as requested. But I am so confused about why this PR got closed, or how the commits took shape. But I believe, after looking at the files changed above, that my small changes were the ones that went through, and nothing else was messed up... I hope.

Hey there, I'm just looking through it right now - while I have no idea about how scroll implements stuff I'm fairly certain it's basically the same as our sway implementation no? Couldn't we just check for sway and scroll (in CompositorService) and just use the SwayService?

I can see why you would prefer that approach. Basically, any work being done on Sway, instead of it being duplicated to a WM that functions the same exact way, it's better to consolidate them into one entity, and minimise future development time.

So, I agree.. That being said, that would require a bit of refactoring on the SwayService file. That's surely above my pay grade. I can imagine it being easy in theory. I will see if I could figure it out on my own.

If not I think we can just merge it as is for now (if @ItsLemmy tested it once more) and we can a look at it later :p

[ItsLemmy]

Added support for Scroll via a tiny customization of the existing Sway service to avoid code duplication.

[Erothas]

Added support for Scroll via a tiny customization of the existing Sway service to avoid code duplication.

You are the man! Thanks a lot =)