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