DIDO?

No, not her.  But Distributed-In-Distributed-Out.  I’ve often thought that current cellular-derived systems (CDMA, EVDO, UMTS, LTE, etc) were insanely complex at the radio/protocol level.  WiMAX is less complex than the gigantic hairball of UMTS/LTE that all the telcos coughed up since it comes from the IEEE instead of the ETSI/3GPP groups, but it’s certainly not simple.  I mean, look at the AT command specifications for UMTS or LTE; there’s just so much there for setting up bearers for this and bearers for that, QoS for whatever, latency requirements, etc.  I can’t imagine having to program a radio protocol stack like the team at OpenBTS is doing.  It’s all there because the radio channel is shared spectrum and voice calls are still the most important part.  If you can’t make a voice call because some douchebag is watching Youtube, you’d be pissed.  And for whatever reason they still haven’t figured out how to reliably do VOIP over 4G networks leading to stuff like Circuit Switched Fallback and (for Verizon) using the CDMA 1x network for voice and the LTE network for data.  Wouldn’t it be great to keep things simple?

And that’s where Rearden and OnLive come in.  Over the past 10 years they decided to throw out everything the ETSI, 3GPP, and 3GPP2 think they know about wireless, and rebuild it from the ground up.  All because they need a really low-latency, cheap, reliable wireless medium to play games over.  And I hope they make it work because it would really disrupt the existing wireless incumbents with their layers upon layers of protocols and complexity and crap and eye-bulging prices for wireless data.  And the fact that it appears so freakishly simple on the client side makes my life easier since we don’t have to do all sorts of stupid setup just to send a single IP packet over the network.  Here’s to the future…

PSA: GtkBuilder, toplevels, and gtk_widget_destroy()

So this has nailed me twice and maybe this time I’ll remember.  If you have a toplevel (GtkWindow, GtkDialog, etc) in a GtkBuilder file, and you load that file into a GtkBuilder object, you need to remember to explicitly call gtk_widget_destroy() on it.  GtkBuilder will sink the initial GTK floating ref for you, but that means you now have widget with 2 references (object creation and the ref sink) and getting rid of the GtkBuilder will only remove one of those references for you.  You then need to remember to call gtk_widget_destroy() to get rid of the other one.  Not g_object_unref() apparently, as that’ll cause segfaults somewhere later on during widget destruction when something tries to disconnect some signal handlers somewhere, but gtk_widget_destroy().  This also removes the toplevels from GTK’s “toplevel_list” which, if you’re not careful and forget to destroy it, can lead to segfaults later when GTK tries to issue grabs when you’re scrolling.  Those are always entertaining to track down.  And when I say entertaining I don’t actually mean it.

GtkBuilder even has documentation about this:

For toplevel windows constructed by a builder, it is the responsibility of the user to call gtk_widget_destroy() to get rid of them and all the widgets they contain.

but somehow I keep forgetting.  And then I waste and hour figuring out WTF is going wrong.