Jacob Peddicord

June 2009 Archives

Commandeer: Lock the display to run a command

| 1 Comment

Just to get this out of the way, I created this application this week as a Vala learning experience. It is by no means complete, but for the use cases I think it fits the bill nicely. Let's jump right in to those cases:

  1. Bill is a system administrator who needs to run a backup on the computers on the network, but employees can not be using them while this happens.
  2. Jane is running some important system operation and needs to make sure none of her friends use the computer.
  3. Bob wants to put his system on standby every night at 11 PM, but not if he is using it.

Enter Commandeer. It is a small application that is able to lock the display to run a command. Sounds simple, right? It is.

commandeer-example-backup

Commandeer allows commands to be started with a variety of options presented to whoever is currently using the computer. Commands may be optionally cancelled before they start, stopped and paused while running, and.. well that's all for the moment. Stopping and pausing are a little hacky; they just send SIGTERM, SIGSTOP, and SIGCONT to whatever child process is active. When the command starts, the above window becomes on-top, sticky, and fullscreen. Enough to keep out most users for now; hopefully I can improve on this "locking" support in the future.

For the first example: commandeer -d 60 --title "Backup" --text "Please save and close all work before the backup begins." /sbin/crazy-backup-plan. This would start a forced launch in 60 seconds.

The second: commandeer -d -1 important-command. A delay of -1 disables the timer, meaning that the Start button must be pressed to activate it.

And the last case, this could be started on cron: commandeer -c -d 30 --title "Standby" standby.sh.

For the above examples, the help output for context:
Application Options:
-d, --delay=SECONDS Delay before execution. If -1, disable the timer.
-p, --pause Enable execution pausing.
-c, --cancel Enable cancellation before command is run. Only valid if --delay is set.
-s, --stop Enable cancellation during execution. Implies --cancel.
-t, --title=TITLE Command title.
--text=TEXT Dialog text.

Commandeer will try to be somewhat smart about what to say and how the UI is presented, depending on what options are given on the command line. If --cancel is given but not --stop, then a Cancel button will appear and become insensitive when the command starts. If both --cancel and --stop (or just --stop) are given, the Cancel button will change to a Stop button on run. When --pause is active, a Pause button will be visible and will be enabled when the command launches. Pausing causes the Commandeer window to revert back to a small box to be resumed later.

A PPA is available here. Quite surprisingly, packages are only 11 KB, but are lacking some things (manpage).

Vala source is hosted, where else, on Launchpad, and is only about 300 lines long. I'm aware that I probably made some programming blunders with Vala -- for example, I'm still trying to figure out the whole construct statement vs a method with the class name... but hey, it's all working fine. I've been testing this code on my machine and it feels stable, but don't blame me if you somehow lock yourself out. If you want to play around with it, feel free. Got improvements? File a bug or merge request.

Enjoy it or not, I definitely had a good time learning how to write it.

Mono v. Vala: Fight!

| 26 Comments

Ignore the inflammatory title. I frankly don't care to hear more on the drawn-out debate about patents. Nothing has happened for a long time, just more people yelling at each other over who is right.

What I never hear brought up is the C#-like language Vala. For the uninitiated, it's a "self-hosting compiler that translates Vala source code into C source and header files" using GLib/GObject. So you feed it Vala code and it spits out C. Now what is so great about that?

1. No runtimes. When you run an application written with Vala, the OS has no idea. At runtime, Vala code is identical to C. No extra libraries, nothing needed to keep your program running. You could ship a version of your project with just the C code and have no extra build dependencies, though your recipients might question as to why there are a bunch of strangely-named generated variables (_tmp0_, _tmp1_, etc) in there. (Kidding about shipping generated C, see comments.)

2. Nearly infinite extensibility. Since Vala just generates C, the bindings can be derived from C. If you have Vala installed, take a look at /usr/share/vala/vapi/webkit-1.0.vapi. 200 lines! The WebKit bindings are only 200 lines long. And according to the file header, they were automatically generated. What's not to like?

According to the Vala roadmap, we may see 1.0 in time for the GNOME 2.28 release.

So I want to hear your thoughts: Does this compare, from a technical standpoint, to Mono? Will it become a widely-used language? Is it easy to port an application from Mono to Vala, and vice-versa?

I don't want to hear any complaining

| 4 Comments

..because I'm pretty sure I've got you all beat:

512k/512k

Feed identi.ca Twitter LinkedIn Launchpad OpenID