Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)

[Peter Robinson <pbrobinson gmail com>]

> On Fri, 2011-03-11 at 11:25 -0600, Dan Williams wrote:
> > On Fri, 2011-03-11 at 17:21 +0300, Mikhail Efremov wrote:
> > > On Fri, 11 Mar 2011 14:58:09 +0100 Michael Biebl wrote:
> > > > Am 11.03.2011 14:26, schrieb Mikhail Efremov:
> > > > > On Fri, 11 Mar 2011 10:28:58 +0100 Michael Biebl wrote:
> > > > >> Am 11.03.2011 09:49, schrieb Michael Biebl:
> > > > >>>
> > > > >>> Been testing the 0.8.996 packages. Looking quite ok so far.
> > > > >>>
> > > > >>> Some impressions:
> > > > >>>
> > > > >>
> > > > >> The online/offline (D-Bus) API seems to be broken.
> > > > >> firefox always starts in offline mode now when using
> > > > >> toolkit.networkmanager.disable false
> > > > >
> > > > > Values of NM states have been changed. See commits ec115ed4 and
> > > > > 11a68133. So all applications which uses that API should be rebuilded.
> > > > > But firefox uses its own hardcoded constants (see
> > > > > toolkit/system/dbus/nsNetworkManagerListener.cpp).
> > > >
> > > > I don't think NM should break that specific D-Bus API and be backwards compatible.
> > >
> > > Yes, I agree with you. I see no reasons to change these values, except
> > > for cosmetic. But maybe Dan will explain why this was done.
> >
> > Patches have been submitted for most of the affected programs that I
> > could find (including Firefox).  For any others, the changes are quite
> > minimal and the patch is able to preserve backwards compatibility in the
> > same code.  That's only possible because the old states are all < 10,
> > which is one reason the new states are numbered the way they are.
> >
> > States are renumbered since there are now 3 connected states (LOCAL,
> > SITE, GLOBAL) depending on the network connectivity.  There's also a new
> > DISCONNECTING state that will eventually facilitate Debian's
> > long-standing request for a "pre-down" event.  There's also space
> > between the states in case in the future we want to add more without
> > breaking API.
>
> I assume that most KDE apps would be using whatever abstraction Plasma
> provides over top of NM and other network daemons.  Perhaps that's
> completely wrong.  The actual KDE plasma networkmanagement story is
> being hashed out right now.
>
> But anyway, that leaves desktop-agnostic apps and GNOME apps:
>
> empathy: https://bugzilla.gnome.org/show_bug.cgi?id=644412
> geoclue: http://cgit.freedesktop.org/geoclue/commit/?id=f2f988bfdda6a347a8190612af1501466b64d76b
> krb5-auth-dialog: http://git.gnome.org/browse/krb5-auth-dialog/commit/?id=3deb396641e2e28a6637d3f57af27aebfd7882a8
> libsocialweb: http://git.gnome.org/browse/libsocialweb/commit/?id=da899278ae076972cd1fa15142b8a79a6be3000f
> liferea: http://sourceforge.net/tracker/?func=detail&aid=3203121&group_id=87005&atid=581684
> tracker: http://git.gnome.org/browse/tracker/commit/?id=6a73ff3929f87d734abfdb21c8a20bab5a9c2cc1
> evolution: http://git.gnome.org/browse/evolution/commit/?id=8a81ec271ed0ab05b8fdfb5cbf374867b3906352
> firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=639959
>
> Packages that simply install dispatcher scripts likely don't need
> changes because they probably don't do that much with NM.
>
> What other apps are out there that  might be using libnm-glib or talking
> to NM via D-Bus for network state?

Sorry for the delayed response

Sugar is the other one that comes to mind. It seems to partially work
if you have a system connection like either a wired ethernet or
connect to a connection using gnome3 and then login to the sugar
interface it partially works. I think the issues are two bits. Firstly
the ability to detect a connection and that its online, secondly
moving the user settings code over to systems code. Any assistance or
patches would be welcome (I'm only new to python), sample code in
python would be useful too (I've only managed to find the anaconda
patch and it's not much use for the use case).

Regards,
Peter