[Fwd: Re: HEAD 1.450 applet.c patch]

[Bill Moss <bmoss CLEMSON EDU>]

After discussions on the list, I had a better feel for the intended
usage of the timestamp. I would prefer that you revert the patch
mentioned below and instead apply the patches I submitted yesterday
(HEAD 1.451 gconf timestamp patch) which I think will return NM to its
original design or close to it.

Summary HEAD 1.451 gconf timestamp patches:
1. NM initiates a gconf write only the first time that a MAC address is
seen.

2. NMI initiates a gconf write everytime the user selects a wireless
network from the NM menu. There are two options here which I discussed
yesterday.

A. Wardriving mode: do not apply applet.patch. Every AP that ever
appears in the NM menu (including a lot of garbage from marginal APs)
will appear in gconf.

B. Apply applet.patch. If the users selects an AP from the menu, the
timestamp in gconf is updated only if the AP is already in gconf. This
way the only APs in gconf are ones you have actually successfully
connected to at some point in time.

I like option B.

Bill Moss

Dan Williams wrote:

>On Mon, 15 Aug 2005, Bill Moss wrote:
>
>
>
>>The 'Connect to Other Network...' dialog will add a menu item to
>>'Wireless Networks' and will add the entered ESSID and a timestamp to
>>GConf. If the user makes an error in typing the ESSID or is just
>>experimenting, he end up with multiple bogus entries in GConf. Following
>>the theme of not adding data to GConf until it has been verified by a
>>successful connection, I submit the attached patch to 
gnome/applet/applet.c.
>>
>>The call to nmwa_date_network_timestamp in nmwa_menu_item_active has
>>been removed. Since this is the only place the function
>>nmwa_date_network_timestamp is used, it has been eliminated as well.
>>
>>
>
>Ok, so I've actually applied & committed this patch along with the
>user_requested changes I outlined earlier. I think that's the approach 
I'd like
>to take, let's see how that holds up and if need be, we can change it 
later.
>
>Dan