Le 03/05/2016 20:03, Steve Litt a écrit :
> On Tue, 3 May 2016 11:53:33 +0200
> Didier Kryn <kryn@???> wrote:
>
>
>> Yes, I know. All these front-ends use wpa_supplicant in their
>> kitchen. I just wonder why they find it more clever to re-do on their
>> own what wpa_supplicant can do alone.
> I think I can answer that.
>
> Wpa_supplicant has three front ends that I know of: wpa_cli, wpa_gui,
> and wpa_passphrase. Wpa_passphrase' capability is limited to taking an
> SSID and password and making something that can be appended
> to /etc/wpa_supplicant/wpa_supplicant.conf in order to interact with
> that SSID.
>
> Wpa_gui, and *especially* wpa_cli, are structured so the human must
> give information in wpa_supplicant API terms, rather than in human
> terms. Wpa_gui does one of the worst jobs of human engineering of any
> software I've seen.
>
> The ideal interface would be an nCurses thing that is structured pretty
> much like Network Manager. Network Manager got the human engineering
> almost completely right. Too bad about all the dbus and X requirements.
>
>
Steve, I don't understand a bit of what all these psk and other
crypting and authentication mechanisms are. This is why I like wpa_gui:
it fills all fields for you, only leaving empty the
password/passphrase/what-the-fuck-key you need to provide to
authenticate. Then you have the opportunity to save the config in the
config file in a click and it's there forever. Everytime I install a new
laptop, I just copy the wpa_supplicant config files and never think of
it anymore. I have spent much more time speaking of this on this forum
than doing it in reality.
The only thing I had read up to now against wpa_gui was that it's
using Qt, which is written in C++. I dislike C++ but I wouldn't get rid
of mail clients or web browsers because they are written in this
language; I think it explains why they have so many bugs, but I'm sure
there would be even more if they were written in C.
I agree with you 200% that a Curses User Interface would be very
attractive.
Didier