[arch-projects] [netctl][PATCH 0/2] wifi-menu: handle rfkill switches.

[Ivan Shapovalov]

Ok, I will make it a dialog.

However, I seem to miss the idea:
netctl already automatically turns the radio on when asked to connect.
What's wrong with doing the same when asked to scan networks?

We're assuming that RFKill= is specified, which can be IMO understood as
"user has granted netctl permissions to manage their rfkill switches".

Regards,

-- 
Ivan Shapovalov / intelfx /

On Thursday 24 October 2013 at 10:28:20, Tom wrote:
> On Thursday, October 24, 2013, Jouke Witteveen <j.witteveen at gmail.com>
> wrote:
> > As you can see, your first patch inspired a rewrite. I prefer my
> > version, as it has a little less duplicate code.
> >
> > The discussion is thus on whether we want wifi-menu to unblock the
> > wireless signal. I still think this kind of defeats the idea of
> > rfkill. Its not hard to unblock outside of wifi-menu, agreed?
> 
> 
> At least make it an explicit choice: 'cannot scan, should I enable the
> WiFi?'.
> 
> Cheers,
> 
> Tom
> > Regards,
> > - Jouke
> >
> >
> > On Thu, Oct 24, 2013 at 7:20 AM, Ivan Shapovalov <intelfx100 at gmail.com>
> wrote:
> >> On Saturday 21 September 2013 at 19:37:21, you wrote:
> >>> This is an usability improvement that makes wifi-menu to temporarily
> enable
> >>> the interface's rfkill switch before doing a network scan.
> >>>
> >>> I don't think that this is too much of automatism and "software being
> smart",
> >>> because it honors existing per-interface rfkill settings, so it is just
> in line
> >>> with the rest of netctl's wireless support.
> >>>
> >>> Ivan Shapovalov (2):
> >>>   rfkill: add rf_is_enabled (query current rfkill state)
> >>>   wifi-menu: handle interface's rfkill switch
> >>>
> >>>  src/lib/rfkill | 13 +++++++++++++
> >>>  src/wifi-menu  | 19 ++++++++++++++++++-
> >>>  2 files changed, 31 insertions(+), 1 deletion(-)
> >>>
> >>>
> >>
> >> Any news on this?
> >>
> >> Regards,
> >>
> >> --
> >> Ivan Shapovalov / intelfx /
> >