GNOME Bugzilla – Bug 634700
What future for nm-applet?
Last modified: 2011-02-25 22:19:24 UTC
GNOME 3.0 will feature GNOME Shell as its primary UI, and this shell wants to have integrated indicator for system components, including network. This means that in the OpenGL-enabled GNOME 3.0 UI, nm-applet cannot (or should not) used as such, it needs further work. A long time ago it was decided that we could not kill nm-applet altogether, as it was the user settings daemon, as well as providing some polishing over raw NM data and some useful function (like "create new wireless network"). A DBus API is proposed on http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/Network, to be exported by nm-applet, which then stops showing its UI when the Shell is active. At the same time, a lot of code has been written to completely kill the user setting daemon, which would make moot the main point for keeping nm-applet alive as a separate daemon. So here I am asking: will the rm-userset branch land in a decent time before GNOME 3.0? is there any other reason for nm-applet to remain a daemon, or can we kill and replace with an introspected library (which would be used by both the Gtk and the shell UIs), like it was done on gnome-bluetooth? has any one started reviewing and/or implementing the proposed DBus API? and in the end, what should I, as a developer of the network UI, do?
Here's the plan: 1) rm-userset will land in master in the next few weeks 2) I'll port the existing applet over to the changes from rm-userset 3) in parallel, we can work on a native JS implementation of the applet for the shell using Jon McCann's mockups 4) we write a new C-based control center applet from scratch (using pieces of nm-connection-editor where appropriate) A lot of the point of the rm-userset branch is to make it a lot easier to write new UIs for NetworkManager, work with will hugely benefit the shell UI too. So while it's pretty hard to write a JS-based implementation for the shell right now, it'll be very easy soon. So I think we have a good way forward: 1) we can start writing a shell-native JS network status menu based off McCann's mockups *already* since the NM D-Bus status API hasn't changed from 0.8.x. This can just show what network devices NM knows about, the status of each device, the wifi AP list, etc. It won't provide a user-settings service at all or allow changing network connections yet. It will still have to care about the system/user settings split, but we can easily remove the user settings pieces when rm-userset lands 2) when I've landed rm-userset we can strip out the user settings stuff and then add the bits that make NM connect to different networks 3) The designs for the control center piece isn't finalized yet, so we continue to iterate those and when we've got something more or less final we can push forward on that piece Sound like a plan? I think it'll be a lot less complex and more efficient to just write a JS-based shell native applet than try to run both that piece and the existing nm-applet at the same time.
(In reply to comment #1) > Here's the plan: > > 1) rm-userset will land in master in the next few weeks Perfect. > 2) I'll port the existing applet over to the changes from rm-userset > 3) in parallel, we can work on a native JS implementation of the applet for the > shell using Jon McCann's mockups > 4) we write a new C-based control center applet from scratch (using pieces of > nm-connection-editor where appropriate) > > A lot of the point of the rm-userset branch is to make it a lot easier to > write new UIs for NetworkManager, work with will hugely benefit the shell UI > too. So while it's pretty hard to write a JS-based implementation for the > shell right now, it'll be very easy soon. > > So I think we have a good way forward: > > 1) we can start writing a shell-native JS network status menu based off > McCann's mockups *already* since the NM D-Bus status API hasn't changed from > 0.8.x. This can just show what network devices NM knows about, the status of > each device, the wifi AP list, etc. It won't provide a user-settings service > at all or allow changing network connections yet. It will still have to care > about the system/user settings split, but we can easily remove the user > settings pieces when rm-userset lands Good, because we already have one, in the dependent bug. > 2) when I've landed rm-userset we can strip out the user settings stuff and > then add the bits that make NM connect to different networks > > 3) The designs for the control center piece isn't finalized yet, so we continue > to iterate those and when we've got something more or less final we can push > forward on that piece Not the main point of this bug, but nice to see a NM more integrated in the control center. > Sound like a plan? I think it'll be a lot less complex and more efficient to > just write a JS-based shell native applet than try to run both that piece and > the existing nm-applet at the same time. That's what I wanted to hear. Let nm-applet die then! If no DBus API changes are planned, I think this can be RESOLVED FIXED. If on the other hand talking to the system settings daemon will not involve just org.freedesktop.NetworkManagerSettings and PolicyKit magic, then please leave this bug open and please notify of deviations from current behaviour or API changes. Thanks!
A new question, before I start writing a lot of possibly duplicate code. Where will the secret agent live? Will it be in nm-applet, even in gnome-shell (in which case no problem for 3.0, and will hook up UI for 3.2)? Or I need to write a separate secret agent inside gnome-shell, immediately using the native UI? Is there some kind of library to ensure consistent access to the keyring (like same id/attributes)?
Closing as I think we've covered this already. Plan of Record for GNOME 3 is: 1) we'll still have nm-applet around for a few different things 2) we'll add D-Bus methods to nm-applet for connecting to hidden networks and stuff 3) eventually for maybe GNOME 3.2 we'll add most of the functionality like secret agent stuff to the shell's indicator icon, and then we wont' need to run nm-applet anymore