[Debian-eeepc-devel] The future of eeepc-acpi-scripts notifications

Ben Armstrong synrg at sanctuary.nslug.ns.ca
Mon Nov 15 11:30:03 UTC 2010


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



More information about the Debian-eeepc-devel mailing list