GUI frontend is ready.
Now, it is time for users to discover deep bugs that only show their
heads when the user number increases.
A popup window has been provided to display detailed information about
any available wifi hotspots. This simplified the design and
implementation of the GUI.
Hopefully, users find it useful.
On 21/08/2015, Edward Bartolo <edbarx@???> wrote:
> I think, I can also upload the Lazarus code of the frontend. I am
> using the application, and for those who love the principle of "Keep
> it simple stuptid", it is a nice simple application which is run on
> request. It is also controlled by the user, instead of automatically
> making decisions behind the scenes.
>
> Automation will definitely take more time to do, but for the KISS
> lovers, the application can be provided as is, with a version number
> of 0.1 or something similar.
>
> When the C backend is hardened enough, it will be time for upload to
> git.devuan.org.
>
> Cheers, and may DEVUAN be enjoyed by anyone wanting software freedom.
>
> Edward
>
> On 21/08/2015, Edward Bartolo <edbarx@???> wrote:
>> At long last, the backend runs without the frontend having for it to
>> finish as I wished. This got rid of frontend hangs.
>>
>>
>>
>> On 21/08/2015, Steve Litt <slitt@???> wrote:
>>> On Fri, 21 Aug 2015 06:47:13 +0100
>>> Edward Bartolo <edbarx@???> wrote:
>>>
>>>> Parsing headaches:
>>>>
>>>> I have this chunk of data retrieved from the backend which I need to
>>>> parse *reliably*. The goal is to read the SSID and the corresponsing
>>>> signal strength.
>>>>
>>>> How should I proceed. This part of code will be done from within
>>>> Lazarus. Please, be informed that Lazarus generated GUI uses GTK* as a
>>>> base. The executable can is also statically built which means an
>>>> increased portability. Executables are about 3 MB. In the past I have
>>>> written such applications that dwarf what I am doing and still the
>>>> size is small.
>>>>
>>>> Here is what I want to parse:
>>>>
>>>> root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -B 4 ESSID
>>>>
>>>> <<<<<<<<<
>>>> Channel:1
>>>> Frequency:2.412 GHz (Channel 1)
>>>> Quality=70/70 Signal level=-34 dBm
>>>> Encryption key:on
>>>> ESSID:"EB-TP-LNK67"
>>>> --
>>>> Channel:6
>>>> Frequency:2.437 GHz (Channel 6)
>>>> Quality=24/70 Signal level=-86 dBm
>>>> Encryption key:on
>>>> ESSID:"TNCAPA0332D"
>>>> --
>>>> Channel:11
>>>> Frequency:2.462 GHz (Channel 11)
>>>> Quality=30/70 Signal level=-80 dBm
>>>> Encryption key:on
>>>> ESSID:"Home WiFi"
>>>> >>>>>>>>>>>>>>>
>>>
>>> :-)
>>>
>>> Hi Edward,
>>>
>>> At this point you're a lot more knowledgeable on this situation than I,
>>> but I'll give you an opinion. If this problem were any more complex,
>>> I'd suggest spawning awk, but it looks to me like as long as you can
>>> get these lines into Lazarus, I think you're golden.
>>>
>>> Please refer to http://dpaste.com/0FZE769 ...
>>>
>>> First thing: By using grep -B, you're throwing away some information
>>> you need: Specifically, encryption type. I'd recommend you pull *all*
>>> the output from iwscan $device scanning into a Turbo Pascal (you know
>>> what I mean) file linked into your Lazarus program,
>>> except "^\s+IE: Unknown".
>>>
>>> It's pretty easy to parse:
>>>
>>> * Throw away anything beginning with "^\s*IE: Unknown"
>>> * Throw away ^$device\s+Scan completed
>>> * Every ^\s*Cell \d starts a new record, record the cell number
>>>
>>> Every line is one of the following:
>>>
>>> 1. ^$device\s+Scan Completed
>>> 2. ^\s+Cell
>>> 3. ^\s+IE: Unknown
>>> 4. ^\s+\S.*:
>>> 5. ^\s+\S.*=
>>> 6. Everything else
>>>
>>> #3 can be avoided by having your original command be the following:
>>>
>>> root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -v "^\s+IE:
>>> Unknown:"
>>>
>>> #4 are the key/value pairs comprising most of what you need
>>>
>>> #6 are all additional information appended to the #4 item preceding
>>> them. So you need a somewhat stateful algorithm. You may or may not
>>> need a Group Cipher, Pairwise Ciphers, and/or Authentication Suites. If
>>> you don't need those three things, I think you can throw away all #6.
>>>
>>> #2 separates records
>>> #5 is the signal quality/level line. Give it its own subroutine.
>>> #1 gets thrown out
>>>
>>> Anyway, you definitely need to capture the encryption type, and by
>>> using your grep -B4 ESSID you're throwing that away. NetworkManager and
>>> Wicd both show encryption type on the ESSID list, and when I use
>>> either of this, I want to know which ones are WPA as opposed to
>>> (eeeuuu) WEP and which are (be very careful) unencrypted.
>>>
>>> HTH,
>>>
>>> Steve
>>>
>>> Steve Litt
>>> August 2015 featured book: Troubleshooting: Just the Facts
>>> http://www.troubleshooters.com/tjust
>>> _______________________________________________
>>> Dng mailing list
>>> Dng@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>>
>>
>
::
Re: [DNG] Systemd Shims
