Here's some food for thought that came out of a private discussion with Luca about notification for the wireless key. Perhaps not so important to address right now with the Squeeze release so close, but we should definitely think about it for Wheezy.
I know we were motivated to make the notify-send change because we didn't want to take away the OSD from users without providing some replacement, but aren't we just perpetuating having eeepc-acpi-scripts provide something that is not eee-specific and should be handled in a more general way? Many devices have wireless kill buttons, but somehow they get away with not sending notifications when they are pressed. Typically the feedback is via some passive notification provided by the wireless manager itself (though that notification is just an announcement of the presence of wireless networks, not that the wireless device is turned off). Or do we justify this because of the hardware-specific and annoying double-duty of the blue light for bluetooth+wifi? Still ... the Eee may not be the only device in the universe to do this. And actually I am speaking of notifications in general, not just this one case. There is yet another problem with our notifications. The text of the messages is hard-wired in the code with no support for localization. And finally, our notifications are tied to button presses. Well, that is OK if you consider button presses to be the only way to change those things, but that is not, in fact, the case. You could issue 'rfkill block 0' and 'rfkill unblock 0', toggling wifi from program control. Why does the key press get special status and other toggles get ignored? Consider gnome-settings-daemon's handling of volume changes. The passive notification that appears will show you the volume changes no matter how you made them. If you open alsamixer and change the volume using its sliders, you will see the notification appear, just the same as if you used the Fn buttons to make those changes. I don't propose any further changes at this time, but we should definitely look at how the notification framework is developing and find a more supportable way to hook in any hardware-specific notifications we feel are necessary, and/or file bugs & patches against more general packages to provide such support. The whole thing is still very new and not very well supported in Squeeze. For example, over the past week, notify-osd, which promised to be an improvement over notification-daemon supporting passive volume notifications, among other things, was removed at the request of the maintainer because the version in Squeeze was over a year old and therefore not in good shape for the release. Perhaps in the next release cycle it will be re-introduced, or if not this specific package, then at least some packages providing the features the current system lacks in a way that isn't tied to one specific window manager or desktop environment. Ben _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
