Re: HEAD 1.450 applet.c patch

What I really objected to in the current behaviour was the 'forced writing of the ESSID' to GConf by the nmwa_date_network_timestamp function if the ESSID does not exist. I have no problem with updating the timestamp on an existing network that has a defined ESSID but why use the nmwa_date_network_timestamp function to write a new ESSID to GConf? So I would be happy if the nmwa_date_network_timestamp were modified so that it does what its name says; i.e. it updates the timestamp but it does force write new ESSIDs to GConf.


Dan Williams wrote:

On Mon, 2005-08-15 at 10:47 -0400, 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.

Hmmm.  Ok, the reason this was initially in the place it was, was to
make sure that network timestamping was done only by the user, and not
by whatever NetworkManager decided the network of the week was.  i.e.,
imagine this situation:

1. User selects network 'preferred', it now has the highest timestamp
and is the network the user really wants
2. User shuts down, goes away
3. User comes back, starts up.  'preferred' isn't noticed in the first
couple scans (which is just the way wireless works), so NetworkManager
connects to the 'less-preferred' network instead.  Highest timestamp is
on 'less-preferred', which is wrong since the user did not explicitly
select 'less-preferred' to connect to.
4. Next time user starts up, it will default to 'less-preferred'

I'm curious how we fix that in this scenario.  In NetworkManager, we
know if the user explicitly requested connection to the access point, or
whether NM just decided to use the next-best-one.  So we could add a
boolean to the update-network-info dbus call that would indicate as
such, and the applet/info-daemon could do whatever it wanted to, right?
That sounds plausible to me and preserves the current behavior.


Bill Moss
Professor, Mathematical Sciences
Clemson University

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]