Since I moved from the Evolution team to the desktop team at Novell, I have been looking at the desktop in a different way than before, looking for missing stuff, cool things that could be added, etc. The things that I miss the most, as a power user, is the access to many of the UNIX tools/commands from the desktop in an easy way. It makes a lot of sense to not complicate the interfaces much, but it also makes a lot of sense, at least IMO, to provide an easy access to the powerful stuff we have in UNIX systems.
So, since this weekend I had no plans at all (apart from some beers on Friday), I started hacking on one of those missing/cool things, which is a simple frontend to the crontab command. I didn’t finish it, but since it’s an easy task, I think I’ve done most of the stuff, missing only the dialog for adding/editing crontab jobs.
That missing dialog needs a bit of thought, since just providing a frontend to the crontab file format might be a bit overwhelming for most users. What I have done so far is this:
Next to the “On specific week/month days” labels, I was thinking on having a way to select any number of days to run the job at. The same for hour/minute, but I’m really short on ideas on how to make it simple but able to edit any kind of crontab entry.
You could probably copy a lot of the UI from evolution’s calendar setup for repeated events. That would at least make it consistent with something else.
vixie cron (which pretty much everyone uses) supports a few reasonably obscure events, @reboot being the most useful one, being able to support running a command on reboot is something that a lot of people want to be able to do.
Having a scriptable (dbus?) interface to the schedular is probably also important, as a lot of programs will probably want to schedule things (eg evolution may want to add a cron job to run every few minutes to send you an SMS if an event is about to fire).
For an interface perhaps have templates that administrators can add (perhaps stored in gconf?) for things like “Every Minute”,”Every 5 minutes”, “Every hour”, “Every day”,”Weekly”,”On Weekdays”, “On Weekends”, “The First Monday of every month” etc. Distributions/Administrators could add more options if there is a demand. Then an advanced interface could be used that is pretty close to the cron interface that hopefully users don’t have to deal with.
Great idea! I’ve been wanting something like this for ages.
Nice! I like the idea of providing useable gnome interfaces to all the components that make linux great in the first place! Cron is a big one too.
Hi Rodrigo !
I used to work on a similar project, called pyactron (http://www.nongnu.org/pyatcron).
The project is now more or less dead, but almost finished. Maybe you could get ideas from it, or just contribute to it.
The one thing I miss is the option to add arbitary pointers to the “places” menu in Gnome. It’s the one thing I miss the most when trying to do a Win -> linux migration. The user will have to learn where to find the “common files” area on his or her computer (f.x. /data/common) instead of just finding it where it should be…
Rather than copying or gaining inspiration from the Evolution calendar GUI, would it make any sense (other than in a corner of my brain) to write a cron backend for the Evolution calendar?
I think it is a good idea to have a nice and usable front-end for the crontab. Although I find that your application is not quite usable in this form. Let me give an example. I have about 10 entries in my personal contab file and I edit this file only few times per year. The edit process is usually as follows:
1. quickly review the crontab file to refresh my memory (what is executed and when)
2. make necessary changes (edit/add)
3. forget about it
In your application the first step is completely negleted. Should I separately check every item and take a note when it is exectuted? Thanks, no! I’ll rather use vim, because it is much faster in this old fashioned way.
Few comments about the second screenshot?
1. What the hell is “-1” supposed to mean?
2. You should use more meaningful window title (“Edit job properties”, for example).
3. Text field for editing the job command is too narrow. I prefer to have it fully visible when editing complex command line. Better make it much wider (or/and higher to make room for wrapping).
4. If this dialog is the only place for editing the command line, then there should be a button that will run the command. I don’t wan’t to edit command line, close the dialog, press “Run Now”, and go back to edit the command line. I will rather use the command line.
Good luck with your application. If you want really to succeed, consider that you have a two very strong competitors to beat, namely a terminal window and a text editor. I hope that you will kick some arse in the process 🙂
ss