New name?

[1player]

This being a new WM, having a name that is a word used by all other scrollable WM is a major negative, especially when googling for answers. Calling it scroll is akin to calling it window or desktop. Please consider a more memorable and searchable name to help the project grow. Even a word of random characters is much better.

[voidstar-null]

Yeah, even the author agrees with this (#41 (comment)).

Please consider a more memorable and searchable name to help the project grow. Even a word of random characters is much better.

Do you have something in mind??

I'm not good at naming either, but here's what I came up with: scrowll/scrawll ( sound like scroll but a bit edgy), swirve, slyde(r)

[dawsers]

I am torn about this. When I chose the name I was aware of this possible problem, but I thought it wouldn't matter much. Popularity is not important. The idea was the WM would become only as popular as it deserved to be. If the project is crap, then it would have a few users (because at least I am going to use it), and if it is great, it could grow deservedly. Hell, look at Windows :-) there is no more common name!

However, there are also practical problems that support a name change.

Supporting a Name Change

Bugs and New Features

Even though I don't care about popularity, having a strong user base helps a lot with new ideas and bug discovering. Until recently, I was basically on my own with respect to finding bugs My use case only covers a small fraction of what scroll can do, so many edge cases or even simple things like @voidstar-null can attest to, are left undiscovered. I don't even use a wallpaper! (#49). Lately, there have been very patient people like @hadarvc, @voidstar-null , @mecattaf, @kidofcubes and others who have been kind enough to go through the process of filing bugs, instead of simply moving on to greener pastures, but I am sure there are still many issues left.

Distribution

Currently, I maintain two AUR packages, @mecattaf kindly maintains a Fedora stable package, and @brihadeesh was nice enough to try his luck on sending a request to Void Linux. It was rejected, but he maintains a template for possible users under that platform. Having more users is a good way to solve this problem. More people would want to maintain packages for other distros, or simple ask their distros to distribute scroll.

Chaging the name also makes it easier to have a package for any distribution. I had to name my package sway-scroll because scroll was taken.

Against a Name Change

• Having to work on it :-) instead of cooler features/bug fixes.

• Finding a name: finding a name that is not the name of something else that is popular or a word in any language, or hard to type without mistakes. Unless there is some really eye opening proposal, I would favor something following my sad and practical personality like wscroll . I searched for variations of scroll and wm and wayland or similar in search engines to avoid the current problem, and it seemed the most appropriate.

• Attracting too much noise: looking at popular projects' issues, you will know what I mean. Having a niche project that is not cool has certain advantages, people who interact do it because in general they care, or at least have tried to make it work.

[mecattaf]

Personally I like scroll and was surprised that it didn't already exist. It's 6 letters and captures what this scrolling manager does. I feel like it would be too much work for too little reward to change it.

[amichaitea]

My first suggestion if you decide to change the name is Wayscroll. That's not something with many Google results (it's uncommon enough that Google thinks I might be looking for Wayscral instead). I'm not sure if it's taken for a non-public repo?

[dawsers]

wayscroll was my first choice, but I saw there is some Kung Fu game that uses the name for some item, the "Nethershade Cult Wayscroll" and it shows up in Google.

[AsahiRocks]

I agree, scroll is fine. If people want to use it, they will, the name is not relevant. It will either be known if it solves people's needs, or ignored if it doesn't. There is no need for marketing. Even though I would like to have some more users (hundreds instead of dozens) to help with QA, I don't really care about popularity for the project. It is not getting much traction, so it must be it is either too complicated, or there are better options out there.

I already seen your stance on project popularity in multiple threads, and I do definitely agree with you. There being "better options" out there is definitely subjective to every person. While I might like scroll the most out of every scroller I tried before, some other person might still disagree.

When it comes to the difficulty, I do think there might be something we could do about it. Currently, the only documentation we have is a man page, the default config, and maybe the readme. While this is enough for people already invested into the project, for others that are just getting started it could be very intimidating. I feel like a wiki or some other form of proper documentation would greatly benefit with solving this issue. Even if you wouldn't want to maintain one yourself, there could always be a community-driven one, which I think is how Sway already does this to a lesser extent. (at least on their github)

[dawsers]

I think the main problem is not documentation. In fact, I think documentation is quite good, because every command is documented to their spec in the manual pages. I inherited that from sway and try to keep things up to date. That is not so common on other compositors, because scroll also has full offline documentation, so you can configure it without Internet connection. There is also an introduction (or first steps) in the README, and a TUTORIAL page with some videos. The config file is also good for documentation and exploration. And I am currently writing a very big FAQ with tips etc.

I think the main burden for adoption is it is quite complex with lots of default key bindings, so people need to invest more time to understand it than they usually want to dedicate to something they are simply trying out. Other options may be easier out of the box, and totally enough for most people. In fact, I don't even use 20% of what scroll does.

And you are also probably right, maybe we need a friendlier tutorial for configuration and first steps.

[AsahiRocks]

I think the main problem is not documentation. In fact, I think documentation is quite good, because every command is documented to their spec in the manual pages. I inherited that from sway and try to keep things up to date. That is not so common on other compositors, because scroll also has full offline documentation, so you can configure it without Internet connection. There is also an introduction (or first steps) in the README, and a TUTORIAL page with some videos. The config file is also good for documentation and exploration. And I am currently writing a very big FAQ with tips etc.

I think the main burden for adoption is it is quite complex with lots of default key bindings, so people need to invest more time to understand it than they usually want to dedicate to something they are simply trying out. Other options may be easier out of the box, and totally enough for most people. In fact, I don't even use 20% of what scroll does.

And you are also probably right, maybe we need a friendlier tutorial for configuration and first steps.

I didn't really think it's bad per say, I think it's really great, in fact. As you said though, it needs to be friendlier, and minimizing the default config burden is definitely another good way of solving it. Hell, I still remember my first experience of spending a couple days just parsing the stock configuration to pick out the options I want, and I'll admit, I haven't even gotten around to doing much else x). Now, I probably took a bit too much time with that than I should have, but it still gets the point across.

I suggested the wiki thing really spontaneously, as I thought it might be a good way of giving a quick overview of all the little features we have. It wouldn't ever replace the man page, which is really good for searching all of the options and giving a detailed description of them. A tutorial video certainly works for that (I haven't watched the one you mentioned), but one possible concern is that it could get outdated with time, while a markdown document can get easily updated. At the same time though, it might not be that needed after all. Again, like you said, no one's gonna use all of the options in scroll anyway. As such, we can showcase all the basic ones, but if you wanna see more, we can tell you to RTFM like every Linux user ever. ;) (obviously joking)

[dawsers]

I am writing a longer document (and the README is already quite long!) with lots of information, as well as a short intro. The problem is most people don't even read the README, so this document will also be ignored by new, trying out, users. They just want something quick that works. Well, their prerogative, I will finish the document for those who persevere and are really interested in the few tips I have used since I started scroll, including some sway stuff, of course.

[AsahiRocks]

Unfortunately, that's just the direction where the world is going in general. And it has been impacting many people, to a bigger or smaller extent. I myself will probably want to dedicate time to read the entire manual page at some point and finish my scroll config, but that will have to wait until I get my NixOS config in a good shape first 😄

I'll still look forward to your new document, though!

[hadarvc]

I'm fine either way. I know it's longer, but if you're going to change it, sway-scroll or swayscroll is the most descriptive. wscroll is cool, as would be swscroll. If you think you might ever change it, then obviously, the sooner the better.

[voidstar-null]

+1 for wayscroll, finding a unique name that fits the criteria but is also not used anywhere else would be near impossible. Also wayscroll would be like 100x times more discoverable in google search than just scroll. Also the nethershade think seems like way too obscure.

[voidstar-null]

Also, imo if you decide to go with wayscroll, the change in name should not affect the binary helper names such as scrollmsg -> wayscrollmsg, scrollnag -> wayscrollnag would be a bad idea (longer binary names don't feel right for some reason, I hope I am not alone ;-D ), as it would require too much config fiddling.

[theNoof]

well if i now search for wayscroll this discussion is the third result:

[dawsers]

Yes, the long binary names is something that throws me back.

Also, changing the name of the project but keeping the names of the executables is convenient, but a bit weird. I mean, you don't know anything about the project,and you download something called wayscroll. Then you try to run wayscroll or check its manual man wayscroll, and nothing happens because everything is named scrollxxx. And if only the main executable gets renamed to wayscroll, suddenly scrollmsg, scrollnag or scrollbar seem out of place.

[voidstar-null]

Yeah, we might have to settle with a shorter name here, I guess. Like you mentioned , wscroll with a hard W , seems like a valid candidate here, since this is a W project

[abhbh]

Why not scrollway? Like it's the scroll way.

[theNoof]

just wanted to comment that. +1 for that one

[theNoof]

scwoll :3

[dawsers]

I think it is too late to change the name, it will be scroll, we even have an icon now :-)

It is hard to find the project: yes.
It won't be popular: probably not, but not because of the name, there is a lot of choice out there.

It is true the lack of popularity also brings distrust toward the project, things like "I won't install it until it is in official repositories", or "it is a fork of sway, so it must be just a couple of extra features". It is a catch-22 type of situation, where people don't install it because other people don't install it, so it never ends up in official repos.

That is fine, we will keep on progressing, maybe at a slower pace, and bugs will be harder to find, but too much popularity isn't good either.

[theNoof]

@aabbcceedddd what?

[markstos]

Perhaps it's too late, but I would recommend the boring name of swayscroll which signals-- correctly-- that this is a Sway fork and largely compatible with Sway configs and the Sway IPC. It could still be referred to as simply "scroll" informally.