I really might be misunderstanding something here, but deactivating
wireless through nm-applet should in fact (as things are currently
with NM from svn), do a ifconfig wlan0 down? Is this correct? Because
doing that manually, my wifi doesn't suck battery power anymore.
However, nm-applet seems to take down the wireless device _only_ when
I deactivate network completely, that is, when I deactivate wireless,
wired and GSM capabilities. Only deactivating wireless leaves the
device up, and hence reduces uptime on battery.

We do need to mark the device down when it's disabled; that somehow went
away when rewriting the device state handling. Should be a pretty easy
fix in nm-device-802-11-wireless.c::nm_device_802_11_wireless_set_enabled().
I was going to change that code to set the TX power of the card off
instead of taking it down, because some hardware (iwl3945) needs
firmware loaded to notice rfkill changes, and setting the device down
unloads the firmware. So at least on some devices you need to always
keep the card up. But HAL isn't smart enough yet to distinguish between
soft rfkill and hard rfkill, so setting TX power off, to HAL, looks just
like a hard rfkill and you can't turn the rf back on in software :(
That's a fairly easy patch to HAL though.

I've been following this thread with interest because I've recently
implemented this feature on top of network-manager-0.6.6~rc2 ( the
version in Ubuntu 8.04 ) as part of some custom Ubuntu Mobile work.

I added logic to invoke the Hal KillSwitch::SetPower method from within
the wireless_set_enabled() function. I also added a sw_rf_enabled flag
to handle allowing the user to re-enable wireless ( otherwise as Dan
pointed out, the hw_rf_enabled flag would prevent this ).

One caveat...it appeared to me as if the NM code in 0.6.6 was
interpreting the GetPower return values incorrectly( ie. it looked like
interpreted TRUE as killswitch ON, as opposed to power ON ). I had to
reverse the value returned by my KillSwitch::GetPower method, otherwise
NM disabled wireless on startup.

I additionally implemented a power-saving feature using some of the same
logic. I modified the scanning code so that when the scan_interval gets
bumped to INACTIVE ( ~2min ), I disable the interface at the beginning
of the interval and then wake it up right before the next scheduled scan.

Note - the one caveat is that my Hal KillSwitch method utilizes a
private DeepSleep ioctl, so the card isn't totally powered off, but is
close enough to show some substantial power-savings.

I plan on publishing my work via my launchpad PPA ( personal package
archive ), and will drop a note to the list when the code's available (
hopefully tomorrow ).