Re: Note about device activation in current trunk...

[Helmut Schaa <hschaa suse de>]

Am Sa 29 Sep 2007 07:06:14 CEST schrieb Dan Williams <dcbw redhat com>:
> 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