Am Sa 29 Sep 2007 07:06:14 CEST schrieb Dan Williams <[EMAIL PROTECTED]>: > On Fri, 2007-09-28 at 08:21 +0200, Helmut Schaa wrote: >> Hi, >> >> Am Freitag, 14. September 2007 22:22:33 schrieb Dan Williams: >> > On Fri, 2007-09-14 at 11:49 +0200, Helmut Schaa wrote: >> > > Am Donnerstag, 13. September 2007 19:15:13 schrieb Dan Williams: >> > > > Yeah, I know this is a problem at the moment, because it's unlikely NM >> > > > has gotten the configuration info for the connection yet. >> This is what >> > > > I'm fixing today; I believe the issue needs to be solved in NM itself >> > > > to keep the APIs and interface behavior simple for clients >> like knm and >> > > > nm-applet. >> > > >> > > Agreed ;) >> > >> > Committed to svn. Can you test out and report? Make sure knm emits the >> > NewConnection signal on it's settings service when it adds the >> > connection it's just created before calling device.Activate(). >> >> Works for me/KNM now :) > > Tambet has a patch to change the activation call a bit. Basically, the > code sucks in NM right now to handle the deferred activation, so we'd > like to move the Device.Activate() method to the NMManager object, where > you would call NMManager.ActivateDevice() instead. The Deactivate() > call would still be on the Device object. Sound OK? It makes the > internal NM code for deferred activation a lot cleaner.
ActivateDevice would then take the device's object-path and the connection's object-path as arguments, right? Not sure about this. The interface would be much more obvious if Activate would stay as a device-method. >> Yippee, yesterday I was able to create a new wired connection on the fly and >> directly activate it. > > Awesome :) > >> Static IP configuration does not work yet (even if I send an IPv4 setting), >> right? > > Not yet, but it's likely easy to do. Helmut _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
