After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 170663 - network-admin locations do not get saved correctly
network-admin locations do not get saved correctly
Status: RESOLVED FIXED
Product: gnome-system-tools
Classification: Deprecated
Component: network-admin
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: Carlos Garnacho
Carlos Garnacho
: 302159 318085 336354 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-03-17 12:18 UTC by Sebastien Bacher
Modified: 2006-11-14 12:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastien Bacher 2005-03-17 12:18:50 UTC
This bug has been opened here: https://bugzilla.ubuntu.com/7380

"When i configure multiple locations in network-admin (System -> Administration
-> Networking), it seems to save certain data to all locations when i select a
location. For example, i have a location 'home' in which i configure interface
'ath0' to be configured and active. Interface eth0 is not configured, and
disabled. I also have a profile called 'work' where ath0 is not configured and
not active, and eth0 is configured and active. After selecting a location,
somehow the interface settings of all profiles get saved to the selected
profile. /etc/gnome-system-tools/network/profiles.xml seems to confirm my
symptoms (<enabled> , <key> and <essid> are all set to the same values for every
location/profile)"
Comment 1 Frederic Parrenin 2005-03-21 09:42:42 UTC
I confirm this problem.
Comment 2 Ondrej Novy 2006-02-04 20:18:07 UTC
this bugs seems to be unfixed in upstream, where is problem?
Comment 3 Lionel Dricot 2006-03-30 10:12:50 UTC
This bug is a very long standing one and I was sure it was already discussed. I can't find the related bug so I confirm this one.

The Current Ubuntu bug is : https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/13727
Comment 4 Lionel Dricot 2006-03-30 10:13:20 UTC
*** Bug 302159 has been marked as a duplicate of this bug. ***
Comment 5 Lionel Dricot 2006-03-30 10:13:51 UTC
*** Bug 318085 has been marked as a duplicate of this bug. ***
Comment 6 Lionel Dricot 2006-03-30 10:14:21 UTC
*** Bug 336354 has been marked as a duplicate of this bug. ***
Comment 7 Paul Arthorne 2006-04-26 16:55:25 UTC
I have this bug. Thinkpad R40, Dapper Beta release
Same as above post. have tried;

activating from terminal with sudo
through network monitor applet
System->Administration->networking
Comment 8 Christopher Cox 2006-04-26 22:37:54 UTC
Had a posting battle on another forum with developers about this. The general response was that most of us are misunderstanding how the "feature" works. Here is how it is SUPPOSED to work:

User configures all of his settings the way he wants it ... and when a new location is created it takes a SNAPSHOT of the configuration and stores it.


This is how most people I chat with THINK it is supposed to work based on previous experience with countless other tools both in Windows and Linux ....

User creates a profile or chooses one he/she would like to use. While that profile IS THE SELECTED ONE, any change will effect THAT profile and is saved when I click close or okay or something.


Now, the way it is designed to work is COMPLETELY different from any other profiling software I have used and has a major disadvantage in that it does not allow me to make simple changes to that profile easily. If I need to make a simple change I have to configure and make a NEW location (in order to take another freaking snapshot) since it does not save under the current one when you press close ... which is demonstrated OVER and OVER.

Maybe it is supposed to save the location with the currently selected one when you make a change and click close? But if its supposed to do that it doesnt ... and other people can confirm it does not.

At any rate, the last developers essentially said that whomever is having this issue does not understand how it is supposed to work and that we are all idiots. General concensus is they don't care.
Comment 9 Carlos Garnacho 2006-04-26 23:55:18 UTC
Dear Christopher Cox,

please please please please please, do NOT put words in my mouth. 

First, IIRC you were claiming once and again that the feature was buggy, then I told you how it was supposed to work, also admitted that the thing is not perfect and told that I gladly accept suggestions. If you want to refresh your memory you can read [1]

If you care enough, if you haven't seen any progress there is just because I've been improving other areas, so just be patient or be nice with the people that's actually doing the work.

Second, since I've began doing free software stuff, I've *NEVER* felt the need to call someone idiot nor something similar, but in your case I can very well make an exception. If you read the link I'm providing, all I said is that you were lacking politeness, which was completely true, as it's now.

And now stop fucking around.


[1] https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/23137
Comment 10 Johannes Schmid 2006-04-27 06:00:53 UTC
OK, before starting useless discussion, this is how I would like it to work:

The profile support should have these features:
- New Profile: Creates a new empty profile
- Save Profile: Save the changes to the selected profile
- Apply Profile: Apply the profile to the network configuration
- Delete Profile: Remove the profile from the list and the xml file

This does of course not mean to have four button I someone finds a better UI design. Apply could for example just mean "select from list" like it is in the moment.

In some cases an integration with gnome-network-manager might also make sense!

Regards,
Johannes
Comment 11 Michael Gratton 2006-04-27 08:26:03 UTC
I think the principal of least surprise could apply here: Any change made by the user is immediately applied to whatever location is currently selected (or, if no location is selected, to some "default" location).

If this was the case then the common usage scenarios (creating new location, changing location, modifiying a location) would work as follows:

Creating a new location:
1. Open Network Settings
2. Configure it so that the connection is working
3. Create the new location (displayed settings get used for the new location)
4. Click OK

If the user does (3) first, then it is just the same as modifying an existing location.

Changing location:
1. Open Network Settings
2. Select the desired location (displayed settings get changed to reflect the location's settings)
3. Click Ok

Ideally, there would be some some sort of menu or applet for changing locations, apropos MacOSX's Location menu - but that is another bug for another day.

Modifying a location:
1. Open Network Settings
2. Make needed changes (current location is automatically updated using the displayed settings)
3. Click Ok

If the user needs to change the settings of a location other than the current one, they would select the desired location after (1) and before (2).

I think this is how many people would expect it to work, and does not need any changes to the UI to implement. All that needs to happen is that network-admin needs to be able to remember it's current location (or more likely divine it from the system's current settings) and immediately save any changes the user makes to the currently selected location.
Comment 12 Julien Olivier 2006-04-27 08:42:58 UTC
Just one thing:

what if you want to modify an existing location, and save it into a new one (without modifying the old one) ?

The logical way would be to:
 - select the existing location
 - modify it
 - click on "add a new location"
 - click on OK

But if this works the way you described it, the existing loation will be saved before the new one is created, and thus you'll have two similar locations.

I think there should be a kind of confirmation dialog before automatically saving a location, asking you whether you want to save the modifications to the current location, or save them to a new one, or cancel them.
Comment 13 Michael Gratton 2006-04-27 08:55:58 UTC
(In reply to comment #12)
> 
> But if this works the way you described it, the existing loation will be saved
> before the new one is created, and thus you'll have two similar locations.

True, but the fact that they are modifying an existing location would be apparent to the user because that location would be displayed to the user in the Location drop-down menu, prompting them to create the new one first.

For example, if the last location I had selected was "Home", then when I re-open network-admin that location is still selected. I would then expect any changes I make to be applied to that location. To make a new location based on Home, I would make sure it is selected first, then create the new location.

> I think there should be a kind of confirmation dialog before automatically
> saving a location, asking you whether you want to save the modifications to the
> current location, or save them to a new one, or cancel them.

Maybe, but why would you want to save changes to a location other than the currently selected one, without selecting (or creating) that location first?
Comment 14 Julien Olivier 2006-04-27 09:46:35 UTC
(In reply to comment #13)
> (In reply to comment #12)

> > I think there should be a kind of confirmation dialog before automatically
> > saving a location, asking you whether you want to save the modifications to the
> > current location, or save them to a new one, or cancel them.
> 
> Maybe, but why would you want to save changes to a location other than the
> currently selected one, without selecting (or creating) that location first?
> 

You're right. In the context of network locations, there is hardly any reason why a user would want to have two almost-identical locations. So I guess it's reasonable to assume that users will always create new locations from start instead of trying to start from an existing one. And thus there is no need to have a "save to a new one" option.
Comment 15 Romano Giannetti 2006-07-12 12:34:26 UTC
(In reply to comment #14)

> You're right. In the context of network locations, there is hardly any reason
> why a user would want to have two almost-identical locations. 

Hmmm... I beg to differ. I often has to change here from a wifi configuration 
as a teacher to a wifi configuration as a student (different password, ESSID, etc) to test things. But yes, one way or another is the same. 

Comment 16 Carlos Garnacho 2006-11-14 12:01:18 UTC
The whole code has been completely rewritten, the UI has been modified, the locations are now easier to overwrite, etc... closing as FIXED