History

I started developing When years ago, because it was a kind of tool that I needed to automate things during my desktop sessions. Most of the things I needed to automate were related to organization of documents – that is, moving them to the directories they belonged to, backing up stuff, cleaning up, and so on. At the time I used to stick to Linux (specifically, Ubuntu) desktops for my work, and one thing I noticed is that it lacked a tool as flexible as the Task Scheduler in Windows: this scheduler, which is part of Windows itself, and is used by the OS to perform certain actions either on a time schedule or at the occurrence of a plethora of events, has a relatively modern user interface which is not too user-unfriendly and is highly configurable. All we had on Linux was cron, which has been around for some years now: it is a very powerful tool, yet it has some disadvantages over something like the above mentioned Task Scheduler. The most evident of these disadvantages is that it is exclusively time based. Of course, playing with time schedules and scripting can lead to every possible kind of tuning in order to decide what had to be met for certain actions to be performed. However, not everyone likes to build a complex script to automate routine actions that could have been kept simple. The second disadvantage is that there was no suitable desktop interface for cron: of course there were GUI cron editors, but most of the ones I have tried were actually mere substitutes of vi (or nano for the ones who prefer it) in the sense that they possibly used a form to let you enter what you would have typed in your crontab file: nevertheless you had to know how the crontab file works in order to enter something correct in the input fields.

Thus, I started working on When: it was a Python application, with a not-that-terrible UI, which allowed to define tasks that could be triggered by specific conditions: these were something that resembled the events and time schedules found in the Task Scheduler on Windows, but sported maybe some more flexibility in the sense that When could also be active in looking for verified conditions, by running commands and scripts but also checking directly (for instance via DBus queries) the session or system status. It has been useful to me, thus I kept updating it and it has supported mainly Ubuntu based distributions, from version 14.04 to version 18.10. After that I started using Windows too (especially on laptops). On the other hand, the services offered by DBus evolved a lot and many times their interfaces changed: it became difficult to keep the pace, especially without help, and redesign the hardwired event listeners in order to be available on the latest Ubuntu desktop and possibly at least the LTS editions which still had support. The only possibility was to redesign When to be more generic, remove these hardwired listeners and some of the specialized tasks and conditions and rebuild a more general (and flexible) scheduler that could support the features that were available at the time via some extra configuration and modules. This would have been easy with Python: the plan was to separate the main scheduler from the GUI, and let it run in the background as a smaller application which could be controlled by a GUI application (for example via DBus) and configured or reconfigured dynamically. This would have reduced the complexity of the scheduler at the expense of handling more complexity in the GUI, and would have reduced the memory footprint of the scheduelr itself when running alone – with no GUI around.

However this remained a plan, mostly because I was gradually abandoning Linux (also driven by some of the choices that were made by the developers of desktop environments) in favor of Windows, and When remained quiescent for a while. Until I realized that I found it more flexible for my way of automating stuff, compared to the Windows Task Scheduler.

I started looking at When again, trying to imagine a way to port it to Windows (and maybe other Linux distributions), and one more time the only solution seemed to separate the scheduler logic from the configuration and controlling utilities. Almost at the same time I started developing an interest in Rust as a development tool and stack. I rebooted When from scratch, although the concepts (mainly: tasks, conditions, and events) are the same as previously: the scheduler (it is called whenever now) had to be written in Rust, while the controlling GUI could be anything – for instance, a Python application. And so it is now: whenever is generic and flexible, it compiles and runs on Linux and Windows, and is extremely lightweight. When too has been rewritten from scratch, especially because the Gnome API is not supported so well on Windows, but also because a prominent part of the application was the scheduler implementation. So When now is nothing more than a GUI shell around whenever: being possible to concentrate on this aspect, this shell can be more composite and focus on cross-compatibility, ease of use, and (last but not least) definition of specialized items that can be implemented in whenever.

I use When and whenever on a daily basis, on several PCs, for the same types of actions that I used it for when I first started developing it.