Re: G-S-D support wireless/touchpad switch

[Dan Williams <dcbw redhat com>]

On Thu, 2008-11-27 at 10:30 +0800, Lin Ma wrote:
> Jens Granseuer wrote:
> > On 26.11.2008 19:36, Bastien Nocera wrote:
> >> On Wed, 2008-11-26 at 18:40 +0100, Jens Granseuer wrote:
> >> <snip>
> >> > One alternative way to do it might be to show a
> >> > "do you want to kill wireless?" popup, and only if the
> >> > hotkey is pressed a second time while the window is
> >> > visible actually kill it.
> >> >
> >> > I think that's at least better than adding controls.
> >> > The question is whether it's feasible to do it that
> >> > way without adding text to the OSD, though.
> >>
> >> NetworkManager and bluez-gnome already have support for killing those
> >> network interfaces. Why do we want another handler?
> Do they support hotkey? Furthermore do they support the input of 
> switching on/off from Hal or X server?
> I hope g-s-d to support hotkeys rather than the functionality to 
> "killing them". If these tools export the interfaces, g-s-d hotkey 
> implementation should use them.

NM (via the kernel and HAL) supports 3 of the 4 types of killswitches.
The fourth type (like Fn+F5 on Thinkpads), which are pure input buttons,
are not currently handled by anything that I know of.

Supporting pure input button killswitches requires something in the user
session (bluez?  nm-applet?) intercepting the key event from X or
wherever and performing a particular action.  On Windows, that usually
means bringing up a dialog asking you exactly which devices you want to
kill.  Maybe we can improve on that, I don't know.

I tend to think that neither nm-applet nor bluez should handle the pure
input key killswitch case, because it's not any one type of device that
may need to be killed.  Hitting Fn+F5 isn't tied to a physical switch,
thus it could mean Wifi, WWAN, or Bluetooth, or all at the same time.
Whatever handles that keypress could certainly use D-Bus to poke both NM
and Bluez to turn stuff on/off as appropriate.

Dan


> >
> > I suppose we don't. To arrive at that conclusion one
> > has to know that somebody else is doing the job already,
> > though. Which is (among other things) why we're having this
> > discussion on the ml.
> >
> > Cheers,
> > Jens
> Thanks,
> lin