Re: Errors running current SVN code

[Dan Williams <dcbw redhat com>]

On Tue, 2007-02-06 at 00:46 +1300, Simon Geard wrote:
> On Fri, 2007-02-02 at 23:18 +1300, Simon Geard wrote:
> > On Thu, 2007-02-01 at 07:51 -0500, Dan Williams wrote:
> > > On Thu, 2007-02-01 at 21:49 +1300, Simon Geard wrote:
> > > > And as I think about it, is that a meaningful distinction if we're not
> > > > going to pretend SSID is a string?
> > > 
> > > That's exactly the reason.  Since we no longer care, orig_essid can go
> > > away and we'll just use ssid everywhere.
> > 
> > Thought so. Ok, I'll look at it over the weekend...
> 
> Ok, making progress on this - everything compiles, and NetworkManager
> starts. Can't do very much with it though, since the D-Bus interfaces
> between it and nm-applet are pretty thoroughly broken - basically,
> everything that passed essid as DBUS_TYPE_STRING is now DBUS_TYPE_ARRAY,
> DBUS_TYPE_BYTE.

Yes; I was expecting to change the interfaces to the applet as well to a
simple byte array like you suggest.  Basically, NM will end up providing
a function for the wireless interface that returns a dictionary of
key/value pairs, one of which will happen to be a bytes array with a key
of 'ssid'.

> Incidentally, what's happening with nm-applet at the moment? I went to
> try fixing the interfaces, but found everything had disappeared,
> apparently into a separate project? Is the network-manager-applet
> project in SVN basically everything that was in gnome/applet previously?

Yes; I finished the import this weekend and deleted the applet from the
NM module in SVN.  It's a pretty straight copy and extrication of the
sources from the NM module last week to a new module in SVN.

> One other question too - what exactly is the program nminfotest.c
> talking to? For example, if it complains that it can't find
> getNetworkEssid on org.freedesktop.NetworkManagerInfo, what should
> actually be providing that method when I run the test?

nminfotest.c will be talking to the info-daemon, which happens to be
implemented by applets.  These interfaces will change heavily in the
very near future when we start doing the dict-based configuration; we
need to map out those interfaces first, but that's not hard.

Dan