To fsmithred:
netman memory leak you mentioned in a previous email has been
resolved. It was caused by the commented (line starting with //) code:
begin
StatusPanel.Color := $53FF00;
btnConnectionStatus.Caption := 'Connected';
TrayIcon.Hint := 'Connected, Netman';
TrayIcon.Icon.LoadFromLazarusResource('network-transmit-receive');
//TrayIcon.Icons.GetIcon(1, TrayIcon.Icon);
TrayIcon.Tag := 1;
end
else
begin
StatusPanel.Color := clRed;
btnConnectionStatus.Caption := 'Disconnected';
TrayIcon.Hint := 'DISCONNECTED, Netman';
TrayIcon.Icon.LoadFromLazarusResource('network-wired-disconnected');
//TrayIcon.Icons.GetIcon(0, TrayIcon.Icon);
TrayIcon.Tag := 0;
end;
Edward
On 02/10/2015, Edward Bartolo <edb...@gmail.com> wrote:
> fsmithred wrote: "It looks nice. Upload it, and I'll try it."
>
> Before actually implementing the backend to handle wlanX and ethX and
> the new network device naming scheme, I had to plan how the GUI should
> look and work. This means, netman is still unable to handle devices
> other than wlan0 and eth0. The backend will have to be modified to
> enable it to handle such devices, and that takes time to do properly.
>
> I learnt it is more efficient for me to let a day or so pass, as that
> enables me to think of better algorithms, and effectively, I end up
> coding more efficiently as faster. It is how my mind works: if I give
> it time, ideas come with far less effort.
>
> Edward
>
>
> On 02/10/2015, Edward Bartolo <edb...@gmail.com> wrote:
>> Tilt wrote: " Does the button "New" take the user to a scan for
>> available WiFi networks?"
>>
>> The button New displays a dialog box which has that functionality, but
>> on demand by clicking a button. This avoid users having to wait for
>> scanning for wifi signals when they know to which wifi source they
>> want to connect.
>>
>> Tilt wrote: " I see there is a button "Delete" - does it enable the
>> user to delete the file /etc/network/interfaces?"
>>
>> No, till now, /etc/network/interfaces is prevented from being deleted
>> and I don't plan to enable such a deletion as that would effectively
>> break netman. However, if support for other wired connections is
>> implemented, it would mean eth1, eth2, eth3, ..., ethN would have
>> their interfaces files deletable.
>>
>> fsmithred wrote: " It won't disconnect my static connection, but if I
>> disconnect manually, then netman will connect and disconnect
>> correctly."
>>
>> That is a feature that I will probably remove when netman is capable
>> of ethX and WlanX, X in {1, 2, 3, ...}
>>
>> Edward
>>
>> On 01/10/2015, fsmithred <fsmith...@gmail.com> wrote:
>>> It looks nice. Upload it, and I'll try it.
>>>
>>> BTW, if I start netman in chroot, it does open, and the icon appears in
>>> the system tray of the host system. I just didn't think to look there
>>> when
>>> I tried it before. The gui comes up if I tell it to, and connection
>>> information window works. It won't disconnect my static connection, but
>>> if
>>> I disconnect manually, then netman will connect and disconnect
>>> correctly.
>>>
>>> fsr
>>>
>>>
>>> On 10/01/2015 01:16 PM, Edward Bartolo wrote:
>>>> Hi fsmithred,
>>>>
>>>> Please, take a look at this screenshot of the GUI modifications to
>>>> support network interfaces other than wlan0 and eth0.
>>>>
>>>> http://s28.postimg.org/9bn1t4wz1/2015_10_01_180401_1600x900_scrot.png
>>>>
>>>>
>>>> Edward
>>>>
>>>> On 01/10/2015, Edward Bartolo <edb...@gmail.com> wrote:
>>>>> or better wlan and eth are enough instead of long words.
>>>>>
>>>>> On 01/10/2015, Edward Bartolo <edb...@gmail.com> wrote:
>>>>>> This is a screenshot of the changes in the main window GUI to allow
>>>>>> for network interfaces other than wlan0 and eth0. The displayed
>>>>>> strings wlan0 and eth0 will be changed into wireless and ethernet
>>>>>> respectively.
>>>>>>
>>>>>> http://s28.postimg.org/9bn1t4wz1/2015_10_01_180401_1600x900_scrot.png
>>>>>>
>>>>>>
>>>>>> Edward
>>>>>>
>>>>>>
>>>>>> On 01/10/2015, Edward Bartolo <edb...@gmail.com> wrote:
>>>>>>> Hi Tilman,
>>>>>>>
>>>>>>> The backend will connect as I described.
>>>>>>>
>>>>>>> Yes, it will be an operation of the backend, but not new: connect
>>>>>>> and
>>>>>>> disconnect will work the 'new' way.
>>>>>>>
>>>>>>> This operation will be triggered by passing the network device name
>>>>>>> string to backend in addition to the usual parameters. To avoid
>>>>>>> malicious users from passing crafted strings to popen or execl, the
>>>>>>> same encoding algorithm that is used for essid encoding will be
>>>>>>> used.
>>>>>>>
>>>>>>> Edward
>>>>>>>
>>>>>>> On 01/10/2015, tilt! <t...@linuxfoo.de> wrote:
>>>>>>>> Hi Edward,
>>>>>>>>
>>>>>>>> i assume you want the backend to do this?
>>>>>>>>
>>>>>>>> Will this be a new operation of the backend?
>>>>>>>>
>>>>>>>> If yes, what will trigger this operation?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Tilman
>>>>>>>>
>>>>>>>> Am 01.10.2015 um 08:41 schrieb Edward Bartolo:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> This is the bewitched command that I need to do the above in a
>>>>>>>>> split
>>>>>>>>> second with the least of coding:
>>>>>>>>> sed 's/wlan0/new_device/g' /etc/network/wifi/interfaces_file >
>>>>>>>>> /run/netman/tmp_int_file
>>>>>>>>>
>>>>>>>>> new_device is the replacement network device and tmp_int_file is
>>>>>>>>> the
>>>>>>>>> new interfaces file that uses new_device
>>>>>>>>>
>>>>>>>>> To connect the backend would then use:
>>>>>>>>> ifup -i /run/netman/tmp_int_file new_device
>>>>>>>>>
>>>>>>>>> Edward
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 01/10/2015, Edward Bartolo <edb...@gmail.com> wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> I devised a simple algorithm that can survive any new device
>>>>>>>>>> naming
>>>>>>>>>> scheme: systemd & co can think of any naming convention they
>>>>>>>>>> dream
>>>>>>>>>> of,
>>>>>>>>>> the new algorithm will survive that. It also allows me to use the
>>>>>>>>>> same
>>>>>>>>>> configuration files as they are without modification. wlan0 and
>>>>>>>>>> eth0
>>>>>>>>>> will be simply placeholders for network device names. This means,
>>>>>>>>>> coding can be greatly simplified.
>>>>>>>>>>
>>>>>>>>>> The algorithm:
>>>>>>>>>> i) copy the essid/eth0 interfaces file to a temporary file system
>>>>>>>>>> like
>>>>>>>>>> /run/netman. During the copy procedure, replace wlan0/eth0 with
>>>>>>>>>> the
>>>>>>>>>> respective network device name.
>>>>>>>>>> ii) run the connect/disconnect function using the newly created
>>>>>>>>>> file
>>>>>>>>>> in the temporary file system and using the new network device
>>>>>>>>>> name
>>>>>>>>>> iii) delete the newly created file in the temporary file system
>>>>>>>>>>
>>>>>>>>>> Simply, easy and extremely flexible.
>>>>>>>>>>
>>>>>>>>>> Tilt and fsmithred, you will soon be able to connect to whatever
>>>>>>>>>> device you like.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Edward
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 01/10/2015, Hendrik Boom <hend...@topoi.pooq.com> wrote:
>>>>>>>>>>> On Wed, Sep 30, 2015 at 09:09:52PM +0200, Edward Bartolo wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> My next coding task is to implement support for other network
>>>>>>>>>>>> devices
>>>>>>>>>>>> besides eth0 and wlan0.
>>>>>>>>>>>>
>>>>>>>>>>>> Since supporting other network devices essentially is including
>>>>>>>>>>>> the
>>>>>>>>>>>> new device names in the essid interfaces file, I am thinking of
>>>>>>>>>>>> whether it is possible to hook the system file reader function
>>>>>>>>>>>> to
>>>>>>>>>>>> replace part of the read file so that I wouldn't need to change
>>>>>>>>>>>> anything in the files themselves. The reason is it shouldn't
>>>>>>>>>>>> matter
>>>>>>>>>>>> which wifi or wired connection one uses to connect a network.
>>>>>>>>>>>
>>>>>>>>>>> They may operate at different speeds.
>>>>>>>>>>> They may connect to different networks.
>>>>>>>>>>>
>>>>>>>>>>> -- hendrik
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Dng mailing list
>>>>>>>>>>> Dng@lists.dyne.org
>>>>>>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WWW: http://tk-sls.de
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
