On Sun, Jul 15, 2007 at 12:02:41PM -0700, Daniel Patterson wrote: > On Sun, 15 Jul 2007 14:33:08 -0400 > Ross Vandegrift <[EMAIL PROTECTED]> wrote: > > > On Sun, Jul 15, 2007 at 11:15:45AM -0700, Daniel Patterson wrote: > > > Using any Gnome daemon ties in gnome dependencies > > > > Nope. NetworkManager is designed to be agnostic to any particular > > environment. KDE uses it for it's backend as well. From my box: > > > > [EMAIL PROTECTED]:~$ apt-cache depends network-manager > > network-manager > > Depends: <not gnome> > > > > I suppose you might take issue with glib, hal, or dbus, but have fun > > with lots of things at that point... > > > > > > I stand corrected... what I said was based on personal experience with > it a while ago (around a year)... I tried to install it and it pulled in > twenty to thirty dependencies... perhaps something was wrong with it in > its early stages, or it was mistakingly pulling in something it did not > actually need.
NetworkManager consists of two independent pieces that communicate using dbus. A desktop agnostic daemon runs and does all the actual interface configuration, etc. A desktop specific application sits on top and provides an interface to switch wireless networks, enter wep keys, indicate that a wired network is available and being used, etc. So, although technically for NM to be *useful* either gnome or kde would need to be installed OR one would need to write an efl based frontend. If you are interested in the latter, the daemon side of the protocol (the org.freedesktop.NetworkManager interface) has been at least partially wrapped by the code in: e17/proto/e_dbus/src/libs/nm. This would be used for the applet to call methods on the daemon. The other half (daemon calling methods on the applet, like, 'give me the wep key for access point X), i sunder the interface 'org.freedesktop.NetworkManagerInfo', and has not been implemented. When I was looking at all this back in March, I believe there were plans to re-work the NetworkManagerInfo api. I'm not sure if that was ever done, or is still being planned. At the time, the existing API was undocumented, and had to be determined through dbus introspection and digging through the daemon / applet code. That said, I do think that utilizing NM is the correct way to move forward with such a 'network configuration' thing. The NM code in e_dbus atm is entirely untested, so feel free to take or leave it as you choose. (The code there at least needs to be moved from E_NM_Callback_Func -> E_DBus_Callback_Func). Brian ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
