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 <[email protected]> > 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 <[email protected]> > 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 / > >
