The Humble Geek

Stuff I write.

Keyword - python

Entries feed - Comments feed

Cross-Platform Graphical Library Maddness

An application that provides the user a window with buttons and input boxes is a given in today's graphically driven computer universe. Operating systems of all shapes and sizes provide a programmer the tools and libraries to accomplish their goal of providing such an application. Most of them are pretty boring or are too specialized to be worth taking time to study. The libraries that people should familiarize themselves with are those that can be utilized across operating systems, which include being able to run across multiple types of hardware devices. Two libraries come to mind - GTK+ [has a very interesting history] and Qt (pronounced "cute").

library-maddness

Today, both libraries offer very simple methods of creating a GUI. So, depending on what language your project requires, either one would be able to provide you with a robust and full featured set of options. The current drive to use Qt is entirely commercial driven - by Nokia - who owns Qt. It's the same drive that Sun made with Java. There's no logical reason to use Java. People have just be taught that it [Java] is the best and there is no other language that can do the same job (read: subjective).

I believe the "Qt hate" or "GTK+ hate" stems from the past when Qt didn't offer as many cross-platform routines as Glib (from GTK+) did or vice versa. It has been my observation that people have not spent any time with both libraries and make rash statements about the other library out of ignorance. Most Qt developers view GTK+ as a legacy library that should be abandoned. Don't tell them that there is still active GTK+ development (GTK+ 3.0 is coming soon) driven by a large community, which includes Red Hat.

Need a simple OpenGL widget in your window? There's GtkGLExt, or Clutter for GTK. Starting with Qt 4.0 a similar API for OpenGL handling was implemented.

Need video/audio capability? GTK+ apps can use GStreamer. Qt has phonon.

Need XML or HTML handling? GTK apps can use libxml or GtkWebKit while Qt apps would need to use the Qt APIs.

Nokia is also attempting to drive Qt as a "write once, run anywhere" library. This is great in that it some-what promotes FOSS, but if you wish to use GTK+ you can write once and run anywhere, too. I have done so with a GTK+ app for my $DAYJOB that can compile under Fedora and Windows and does advanced things like TLS encrypted XML packets over a TCP connection and scanning documents (using SANE). Neither library has an advantage.

More recently, Nokia has tried to push the mantra that you can write a Qt app quickly and simply. GTK+ developers can also use Vala to write a GTK+ app quickly and simply. The amount of code to write to accomplish the same goal in each library also ends up being about the same.

I can come up with any more number of examples, but those are ones I have seen used in arguments lately. The person arguing for using Qt has no idea about the matching GTK+ API and vice versa. I think it's great that both Qt and GTK+ offer such a wide range of features that are easy-to-use. You can choose a language (C, C++, Vala, Python, PHP) and write a program that could be used by thousands or millions of people across many different types of devices. Now get out there and start programming.

Nokia and Python, a Tight Pair [Part 2]

Woo hoo!? I read my battery voltage. Take that $300 OBD readers. Success is brewing on the application front. I took some time today to rewrite more of the garmon "port" and got some positive feedback. All that really remains is to write the UI part that will display each sensor reading. Hm...

P.S. Don't mind the "RPM" text, I was going to do an RPM reading first, but a battery reading was much easier. >.<

UPDATE: I posted a much nicer screenshot.

Nokia and Python, a Tight Pair [Part 1]

Little, neat gadgets are sometimes necessary to keep life from being a complete drag. That's where the ELM327 OBD-II device comes in. A mouthful? OK, sue me. It's a chip that can read your car's information, such as MPH, RPM, air temperature, water temperature (yes, your car uses water), and all sorts of other goodies. The chips sell for around $60 on eBay for Bluetooth versions. Normally OBD-II readers sell for hundreds of dollars and are standalone products, which are very limiting in what you could do. The catch? It's just the chip - no software. However, since the chip has open specifications there are a dozen or so different softwares that are ELM compatible. Garmon is one such software.


When I first got the device I had a dilemma. I could either drag my desktop computer out to my car and ran a long extension cord for power, bought a laptop, or borrowed a friend's laptop. I chose the third option, thinking I was looking to buy a laptop in the future. But wait! I have my Nokia N95 don't I? The only thing that kept me from thinking of my phone is that I would have to write a program in Symbian C++ - a task I wouldn't do unless I was paid a cool mil or two. So for a while I could only use my ELM reader when I was with my friends.

A few days ago my brain finally clicked into gear: Garmon is written in Python and Nokia has released Python libraries for their phones. I could certainly port Garmon to my phone. No need for a stinking laptop! After installing the libraries and running a "Hello, world!" program I knew it would be possible, with a little help with Google, seeing as this was my very first Python program (I'm a C junkie). Stay tuned for the results...