kbrgl
Combine scroller and zscroll?
I don't know how minimal you want to keep your project, but would you have any interest in collaboration/consolidation? Zscroll doesn't have any tests currently, and the code probably isn't that pretty since I haven't written much python. It doesn't have a "reverse" option either, but it is more mature with regards to some other functionality and documentation:
- it has a man page
- it is packaged for arch and nix
- it provides several ways to intelligently deal with full width characters
- it provides options for padding text before and after the scrolling section (in addition to a separator within the text)
- it allows dynamically updating the text and scroll options
- it can be piped into or take the text as an argument
If the text piped into scroller contains full width characters, the length of the scrolling text will change, leaving trailing garbage characters. The speed will also look off when full width characters come into and out of view. The default way zscroll handles this is to count full width characters as having length two and to phase them in and out in two steps. When a full width character is about to come into view, it will insert a space at the end for the first iteration and then insert the actual character in the next. It does the same when full width characters leave the displayed section. This ensures that the length of the entire scrolling text is consistent and that the length of the new text coming in and leaving is always the same (so the visual speed is the same).
As for the dynamic updating, this makes it very easy to change the text and options (such as swapping out a pause and play button) without the need to constantly kill and restart the scroller.
In my opinion, there's no need to have more than one scroller like this. Ideally, there would just be one that had the current functionality of both the zscroll and scroller. If you see the extra features that zscroll provides as useful, I'd be happy to help consilidate the two. I wouldn't care which is used as the base. Since you are more familiar with the code you wrote (and it is better tested), I'd be fine declaring zscroll as obsolete if you decided you'd like to implement the features it is missing from zscroll. I'd be happy to help write a man page and package scroller as well.
If you don't like the features I've mentioned, I can at least mention scroller as a more minimal alternative in the readme. Still, zscroll is not even 400 lines, so I don't think there is really any benefit to minimalism here.
That does sound like a good idea. Some of the features you've mentioned are, in fact, present in Scroller. Others can be easily implemented.
If you're okay with keeping Scroller as the base, then I can implement the missing features and, as you suggested, you could write the man pages and package Scroller.
Some of the features you've mentioned are, in fact, present in Scroller.
Which ones? To clarify on the padding/separators, zscroll allows putting non-scrolling text on either side of the scrolling text. To clarify on the dynamic updating, scroller does have the --open option, but zscroll makes it so that settings can also be changed with every update and doesn't require any scripting. I don't know if you've looked at the examples in zscroll's readme, but it provides two basic ways to dynamically update. The first is with the -u/--update flag alone which will simply change the text whenever the provided command changes:
zscroll -u -b "window title: " "xtitle"
This specific example of the dynamic updating can be done just by using xtitle's -s flag and scroller's -o (like the example in the readme), but not all commands have such an option. A generic utility (similar to watch) could be created to do this for an arbitrary command, but the second method zscroll provides wouldn't be as simple. Zscroll also has the -m/--matchtext and -M/--matchcommand flags. Basically these allow the user to specify a command and a regex to search for in the output of that command. Combined with -u, it is possible to, for example, switch to a pause icon automatically when the song is paused. You could also do things like stop the scrolling, change the speed, change the separator, etc.
The rules for how these work are a bit complex. For -M, there can either be one command which is searched with all -ms or there can be an equal number of both. Changing options based on the matched text works like this:
| Times a Setting is Specified | Result |
|---|---|
| 0 | always use the builtin default |
| 1 | use the setting value over the builtin default when no text is matched |
| n | for the nth -m, use the nth specification of the setting |
| n+1 | for the nth -m, use the n+1th specification of the setting |
| (cont.) the first specification of the setting is used when no text is matched |
Since there is overlap between the 1 and n case when -m is specified once, the 1 case takes precedence (the user can specify the setting twice for the n+1th case if they want).
This makes it unnecessary to do any scripting for all common situations. It's perfectly readable when the flags are specified in a sane order (see the example in the zscroll readme), but you might have an idea for a better way to do this. It might be nice to have some special syntax for the text piped into scroller to set options. This in conjunction with --open would make scroller fully scriptable. Maybe there could be a separate utility to prepare the text for the scroller instead of directly adding the equivalents of -m/-M and multiple settings, but either way, I think it's best to make things as simple as possible for the user.
If you're okay with keeping Scroller as the base, then I can implement the missing features and, as you suggested, you could write the man pages and package Scroller.
That's fine with me. :+1: