Handle process prioritisation internally

[Plecra]

After seeing how you were using nice to treat wallrnd like a background process, I put together scrummage to do the same thing from Rust.

I think you could use it to simplify the UX, and avoid needing to call wallrnd from the script. It'd also work from Windows...

which I'm planning to implement tomorrow. Is there anything else you'd need from the API?

[Vanille-N]

That is very interesting, having the whole process handled by Rust is certainly tempting and would greatly simplify the setup.

From what I can see, the current obstacles to making wallrnd fully autonomous are :

1. nice, without which the user will experience a lag at every wallpaper change
2. the need to set the image as a wallpaper, which is a pain even in Bash and probably difficult to port to other OSes
3. a call to imagemagick through the convert utility. It's a shame, but Ubuntu doesn't handle SVG as well as imagemagick, so converting to a PNG first removes a few graphical inaccuracies (in particular when setting the stroke width to 0)
4. exiting early when using the battery

I know for a fact that 2 can be solved, I can probably recycle dyn-wall-rs or use it as a library. 3 could be addressed with magick_rust, or image-convert. Both require imagemagick itself to be installed, but that is acceptable. If 4 is the only remaining obstacle, I can do without it.

Although I said that actually setting the image as a wallpaper was not a priority of the project, if your library can solve 1 then I will certainly look deeper into how to deal with 2 and 3.

About the API, all I need is the ability to make a process lower priority than other processes completely external to the program.
If I've understood correctly the example in your crate Readme, you spawn a child process lower priority than the current process.

• is it possible to change the priority of the current process, or will I need to encapsulate the whole generation and conversion in a low-priority wrapper ?
• is it possible to set a priority lower than other tasks, not just those controlled by the script ?

Both of these questions come down to this : I want wallrnd to be able to run either with a lower priority than my text editor, browser, terminal, etc..., or with a higher priority. The first is for when it actually runs, the second is so that I don't wait a few seconds each time I try to debug. For now my solution is to have nice give the lowest priority in actual use and run it normally when debugging, if scrummage can fulfill both of these use cases then I will gladly make the switch.

[Plecra]

Yes, there'd be no problem doing that with the API as it is now:

let base = Process::current().priority().unwrap();
// This is a tad clunky. That's half-intentional to discourage blindly lowering priority, but
// needs some more design work too ^^
let lowest_priority_available = Priority::normal().lower().last().unwrap_or(Priority::normal());
// I'd lead towards this:
let background_priority = base.lower().next().expect("no lower priority available");
// ...which would pop `wallrnd` in the background relative to the script it was executed from,
// but give room for other programs to have an even lower priority (at the user's choice).
// To be clear: This prioritization level is still relative to all processes on the system, and would have the
// same effect since *most* programs don't mess with their priority level

Process::current().set_priority(background_priority).unwrap();
// ... idle work

Raising the priority is a little trickier, since normal processes don't have permission to raise their own priority - you need to be root. We could try shelling out through sudo/asking for a superuser login, but it's probably best to start the program with the highest priority level you want.

[Vanille-N]

Looks good.

For high priority, I can just leave it as-is and do the whole Process::current().set_priority(...) depending on a command line argument, i.e. raising priority is unnecessary, choosing not to lower it is enough.

This morning I essentially solved issue #3 (convert to PNG), I expect to be working on priority 2-3 days from now, and after that wallrnd will be a standalone.

[Vanille-N]

Thank you for your work, integrating the call to scrummage from wallrnd was almost too easy to be true.
I'll wait a few days to verify that there is no user lag, and then I'll publish the new version of wallrnd with scrummage as a dependency.

[Vanille-N]

I still plan to leave this issue open until scrummage is a bit more portable...

[Plecra]

For sure! I'm in the middle of some exams right now, but I should be able to push the windows support later this week. I'm trying to pin down Windows' permission system around user processes, and it doesn't look like it'll be a problem

[Vanille-N]

No worries, I also had exams a few weeks ago, and I'm not in a hurry.