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

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:

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),

Not yet, but it's likely easy to do.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]