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

[Peter Robinson <pbrobinson gmail com>]

Hi Dan,

On Wed, Apr 27, 2011 at 8:18 PM, Dan Williams <dcbw redhat com> wrote:
> On Mon, 2011-04-25 at 23:13 +0100, Peter Robinson wrote:
>> > 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).
>
> Yeah, Sugar would need a patch.  The first part (porting to NM 0.9 for
> status information) is pretty easy, the second part where Sugar acts as
> an applet is harder, but actually might be fairly simple with NM 0.9.
> It's been in the back of my mind for a while, but I haven't gotten
> around to doing a proof-of-concept even though I wrote a lot of the
> original code for it 5 years ago :)

If you know of some sample python code I could look at for the first
part it would be great.

If you could possibly find the time for a proof of concept / initial
patch for the wireless applet stuff I would be most appreciative. In
F-15 its pretty useless at the moment on netbooks the way it is and
while I might eventually be able to hack something together I fear it
won't be quick or eloquent.

Cheers,
Peter