Description of problem: A dialog is at the wrong menu command. Version-Release number of selected component (if applicable): Component and component version are unknown. One hypothesis (not mine) is that the problem is with an ambiguous .desktop file in Fedora. How reproducible: Go to System menu > Preferences > Network Configuration. Actual results: Get Network Connections dialog. Expected results: Get Network Configuration dialog. Additional info: --- The Network Configuration dialog is really at System menu > Administration > Network. --- The Gnome version is 2.24.1. --- I reported this initially to Gnome Bugzilla; see <http://bugzilla.gnome.org/show_bug.cgi?id=590487>, as accessed today. For the hypothesis about an ambiguous .desktop file in Fedora regarding a similar problem, see their comment in <http://bugzilla.gnome.org/show_bug.cgi?id=592350#c1>, as accessed today. --- The similar problem is to be reported into this Bugzilla momentarily.
(In reply to comment #0) > Version-Release number of selected component (if applicable): > Component and component version are unknown. Correct component in this case is NetworkManager-0.7.1-1.fc10. For an explanation on how to get the proper component, please look at bug 518780 comment 1. > Actual results: > Get Network Connections dialog. > > Expected results: > Get Network Configuration dialog. Sorry, I cannot follow you: The entry in Preferences is "Network Connections" and calls nm-connection-editor. "Network Connections" is also the title of the nm-connection-editor window. So menu entry and window title match, although you claim something different in the bug summary. The entry in Administration is named "Network", calls system-config network and it's window title is "Network Configuration". Ok, there is a mismatch, but you really consider this a bug? I don't think mentioning the term "Configuration" again is necessary because *all* entries in the menu are configuration programs. > Additional info: > --- The Network Configuration dialog is really at System menu > Administration > > Network. First of all you need to understand the difference between 'Preferences' and 'Administration': * Administration is for the whole machine and affects all users. Root password is required to change settings. * Preferences are per user settings that don't require authentication. So the menu entry is correct. Second there are two different network stacks: NetworkManager is best for mobile computers like notebooks. The traditional network stack (/etc/init.d/network) on the other hand is better for servers because it offers additional functionality like bridging, aliases and so one. I really don't understand what you consider a bug here, so I'm closing this one. Please reopen if you really think there is a bug.
I'm using a laptop; maybe you're using a desktop or tower; is that causing my menus to differ from yours? Or is your setup more recent than mine? When I'm in Main Menu > System > Preferences, the only entries in all the submenus there that begin with the word Network are: --- Network Configuration --- Internet and Network > Network Proxy I don't have an entry that says Main Menu > System > Preferences > Network Connections. When I select Main Menu > System > Preferences > Network Configuration, I get the Network Connections dialog. But if I want the Network Configuration dialog, the way to go is via Main Menu > System > Administration > Network. That looks to me like a misnaming of menus. That's a usability issue. Two menu names need correcting: --- In Main Menu > System > Administration, the Network command should be renamed Network Configuration, to match the dialog it'll call. --- In Main Menu > System > Preferences, the Network Configuration command should be renamed Network Connections, to match the dialog that one will call. If the problem was only of Network calling Network Configuration, I wouldn't worry much about it. But because both errors come up, when I'm trying to solve a network problem I have to go all over the place to make sure I got what I needed, because two mismatches on the same topic raise quality concerns and I don't remember what's not written down if I don't invoke it often. I'm glad someone like RH is competing in the mainstream market against the little boys from Redmond. I hope you give them what they deserve. But it does mean that more of your new users expect more polish, because more of them don't understand interior technicalities. They mainly use computers to work, and maintaining technical knowledge is secondary. So menu commands should match dialog names, if not exactly then at least nonconfusingly (e.g., N. Config. should not be the route to N. Connections if there's also a N. Config. dialog reachable by another route). Whether a command pointing to a dialog is reachable through Prefs or Admin is not my issue. Your explanation on that is fine and not inconsistent with what I raised. As long as it's not necessary for nonroot users to understand the distinction before they use the menus, I see no problem. If a menu command's response to a nonroot user is a request for root authorization, that's good enough, regardless of which menu invokes it. I'm unclear (after reading replies in this bug report and 518777) whether a nonroot user needs to know the differences between the two stacks for networking. If nonroot users do need to know the differences between the stacks, then more clarification is needed where nonroot users will likely see it. But I'm unclear why a difference in stacks led to calling N. Config and N. Connections dialogs from nonintuitive commands if one stack is applicable but the other is not. If the issue is about hardware form factor for laptop vs. tower/desktop, that should be built into a Bugzilla setting. I'll take your word on which component and version applies, since the method for finding out didn't work for me (as noted in the other bug report), and I would have thought it's in the menus. I set the Bugzilla's Status menu to Assigned since I didn't see a separate Reopen option. And if you're using a later Fedora version and the two menu commands have already been edited (and stack issues clarified if necessary), that's good enough, and closing will be fine. Thanks. -- Nick
*** Bug 518777 has been marked as a duplicate of this bug. ***
basically, we get to enhance nm-connection-editor to the point where it's viable enough to replace system-config-network for most people, and then we can remove system-config-network and the "Network Device COntrol" stuff
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.