Month: February 2012

Debugging Qt’s signal-slot connections…

What do you do if you think you’ve correctly connected a signal to a slot and yet your slot’s not being fired? I ran into that Friday at 5:30pm, just about the time I hoped I’d call it a day and go home. Fortunately in my case, I was simply passing null to connect, and I got a message in the debugging log about trying to connect a signal from a null object. (Unfortunately for me, I didn’t see the log right away, because of all the other stuff I was dumping to the log.)

If you’re in the same boat, what do you do to debug the situation? Here’s a bunch of things to try:

  • Check the compile log for error messages about undefined signals and slots.
  • Check the run-time log for errors on connection. If need be, ensure that connect succeeds by testing its return value (it should return true.
  • Check to make sure that the connect code is reached, that the emit code is reached, and the slot code. (Odds are one of them isn’t.)
  • Make sure you declare the connection like this:

    connect(sender, SIGNAL(someSignal(type)), receiver, SLOT(received(type)))

    The signal and slot specifications should have the argument types, but not the arguments themselves. Moreover, you can omit const and reference specifications in the arguments; the meta-object compiler strips them anyway.
  • Check the parameters of the signal and slot and ensure that they match precisely
  • Check to be sure that you’ve correctly declared the signals and slots portions of your header correctly.
  • For that matter, be sure that your sender and receiver both inherit from QObject, and that you have Q_OBJECT declared in your class definition. (Remember, you need to do both.)
  • If you’ve forgotten part of the QObject declaration in your header, re-run qmake and rebuild.
  • Make sure you make the connection with connect before you invoke any functions that fire the signal. Signals may fire synchronously.
  • Make sure you’re not disconnecting the signal anywhere with disconnect.

Usually, the problem’s pretty easy to track down, especially if you check the log and the signal and slot declarations closely. A common mistake is to try to wire a signal to a slot that’s not been declared a slot, too, so check your headers closely!

Some musings on the Kindle Fire…

So, I’m flattered to have been asked by the dynamic Conder/Darcey pair to be a tech reviewer on an upcoming book for writing applications for the Kindle Fire, which runs Android 2.3 (Gingerbread, SDK level 10, as I recall). Of course, to do the job correctly, I needed a Kindle Fire.

I’ve been an ebook fan for many, many years, having pressed my first books for the Newton Book format back in ’94, and read ebooks on nearly every handheld computing platform since then. I was a happy user of Sony’s ereader products (as previous blog posts can testify to), although this last fall I gradually switched to using Amazon as my provider-of-choice for new ebooks, because I can read them using either the cloud reader or my Windows Phone and iOS devices. I generally seek out books without DRM where I can (like the excellent offerings from O’Reilly), but will tolerate DRM when it’s thrust upon me. So I was excited to have the opportunity to get my hands on a Kindle, both from an end-user as well as a developer perspective.

The Device and its UI
For the money, it’s definitely a good deal. I’ve been quite happy with it for book reading, casual browsing — it’s replaced the iPad as my go-to device for Twitter and Facebook in the evenings, although I still use the iPad more for checking news sources like NPR, BBC, and such, as well as general browsing. It’s also definitely become the official ebook reader; I’m a little self-conscious about how many ebooks I’ve bought since I got the thing.

A noteworthy UI departure from the plethora-of-icons on most handheld devices is the main screen, which provides a most-recently-used Cover-Flow style view, with a few pinned items below that. I really like that; my usage is typically clustered around two or three different pieces of content (a couple Web pages and a book), and it’s very fast.

As much as I like books on it, magazines suck. The problem is the screen size, as others have observed. You just can’t format an 8 1/2″ x 11″ magazine for a 6″ display and expect it to be legible, and if I wanted to spend an evening pinching and zooming to read something, I’d just go get a smart phone out. I’m going to cancel the one magazine I subscribed to before the trial is out; I think the iPad would do much better.

Developing for the Fire
I’d done some puttering with Android before, of course, so the environment’s not new. Having spent more time in it, I’d have to say that it’s on a par with Qt Creator, except that the Eclipse IDE is far, far more cluttered. I had about the same amount of difficulty getting the Kindle to talk to the debugger as I’ve had with Symbian and MeeGo devices — a bit of grumbling and some Googling as a result — but no real difficulties. It’s certainly a change from the pre-iPhone devices, when most mobile devices required all kinds of magic to connect reliably to a development workstation.

I don’t love Java, and I don’t love the various SDK levels and API confusion of Android, but it’s actually not a bad platform for writing software. The APIs mostly make sense, and when they don’t, there’s usually copious documentation and sample code available. I’m rapidly moving from feeling like a newbie to feeling comfortable, and wondering whether I should invest more in Android for my own skillset or Windows Phone 7 for work skills as I poke away at the thing. It helps that I’m only targeting one device with one specific API level. I don’t envy professional developers targeting Android as a whole.

Anyway, when their book is available I’ll be sure to post a link so people can check it out!