It's hard to keep up with new dms or window managers, they pop up constantly, same with compositors etc.
This is particularly the case when people make new dms out of old ones, this is the second slim based one I've heard of recently, the other one was covered partially, but not completely.
Since it's impossible for me to keep up with everything, ideally what people would do when they discover an unhandled item is to report the issue at github inxi.
For a full display manager report, I need the following information, using slimski as the sample:
- Does it have a --version type output, if so, what is the switch, it can be many things, --version, -v, -V.
- What is the output of that version switch? I looked at the slimski man page, so it does have it: slimski -v [show the full complete output, don't make me guess]
- Does that output get redirected to stderr, which several dms do: slimski -v 2>/dev/null - if that is empty but the first one shows version, then it's redirecting to stderr.
- how do you detect it is running, usually it's in /run or /var/run, what is it called in there?
- What is the official name, upper lower, etc? According to the gitlab page, it's slimski, all lower case. In other words, how does the project itself refer to it. This is what inxi should show in the output.
slim based things do have -v but I cannot guess at what that output might look like, nor can I guess about some other things inxi needs to know which part is the version number based on the real output.
The more of these items I get, the better the dm data will be.
What is the official name, upper lower, etc? According to the gitlab page, it's slimski, all lower case.
Since I can never guess at --version stuff, that remains blank, marked as unverified internally, until it's verified, which usually ends up with me having to do all the work and testing and installation of these endless things.
If it has no --version, or if it's unverified, I leave a placeholder that contains only its official name syntax, like SLiM.
I'll be adding this to pinxi and since someone found a bug in the refactor 3.3.17 this morning, should be out soon.
Another SLiM based one I ran across recently, also without -v output samples, is brzdm.
The more info you provide, the better the inxi data will be. Note that Slim did not output to stderr according to my internal data so it's very unlikely slimski does either.
The ideal is that when a projects forks or launches a new dm, they provide that data to me so that inxi can include it before the product ships. Ly did that, amazingly, one of the only to do it.
Note that this stuff gets sort of tiresome to always have to do myself, so it would be nice if projects could be a bit more proactive, I'm not going to be doing this stuff forever, nor will I always be interested in doing all the work for people. I'm seeing a disturbing trend in inxi where people are adopting an increasingly passive role, with a few noteable exceptions, expecting that this stuff is 'just done' by 'someone out there', and not actually doing anything to help themselves.
This is particularly the case with people reporting issues on local forums that have nothing to do withi inxi, and which I only visit randomly and occasionally. If you find an issue with inxi, don't report it to your distro or local forum, report it to inxi, lol, otherwise it's a total random whether I see it. I saw this one because a guy emailed me about it, otherwise I would never have seen it. After updating to current master branch inxi, of course, because stuff gets found and fixed constantly.