Re: HEAD 1.450 applet.c patch
- From: Dan Williams <dcbw redhat com>
- To: Bill Moss <bmoss CLEMSON EDU>
- Cc: networkmanager list <networkmanager-list gnome org>
- Subject: Re: HEAD 1.450 applet.c patch
- Date: Mon, 15 Aug 2005 14:37:00 -0400
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.
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]