Ximba Radio: Developing a GTK+/Glade GUI to XM Satellite Radio

code:
gtk_image_set_from_stock(GTK_IMAGE(XR_Status_Image),
   GTK_STOCK_APPLY,
   GTK_ICON_SIZE_BUTTON);

The use of global variables is not the only issue experienced developers might take with my methodology. Another is my choice of using a deprecated GTK+ widget: the CList, also known as the columned list widget. Deprecated implies that the widget, while still part of the current distribution, is no longer being developed actively and may be removed from the GTK+ distribution in the future.

The current replacement for the CList widget is the Tree and List widget. Ximba Radio requires list entries to be added and removed dynamically on a frequent basis. Neither the CList nor the Tree and List widget were helpful with this requirement. However, because the CList was designed specifically for handling lists and not expandable trees, I found it the less complex of the two choices. By definition, prototypes require getting an application up and running quickly with a standard or typical interface. CList support in Glade makes this possible without having to learn the complexities of the Tree and List widget. The trade-off will come later when I have to deal with the eventual disposition of the CList.

Ximba Radio makes heavy use of lists. All channel, category and favorites information is kept in columned lists. While the complete channel listings and the favorites are static lists that never go completely away, the category lists are dynamic. Users can enable or disable them from the display, making it easier to find stations based on their own preferences. To manage the dynamic nature of the category lists, I made use of GLib's doubly linked list, the GList. Few applications of any complexity can avoid the use of linked lists, and GLists are extremely easy to use. A one-way link list option exists, the GSList, but it costs little to have the two-way links in a GList, and reserving the option to travel in both directions in a list is worth any extra weight a GList might add.

code:
void
XRUSavePrefs()
{
   ...

   /* Write the preferences to it. */
   fprintf(fd, "hostname:%s\n", prefs.hostname);
   if ( prefs.daemondir )
      fprintf(fd, "daemondir:%s\n",prefs.daemondir);
   else
      fprintf(fd, "daemondir:\n");
   fprintf(fd, "favorites:%d\n",
      (int)prefs.enable_favorites);
   fprintf(fd, "channels:%d\n",
      (int)prefs.channel_windows);
   fprintf(fd, "performance:%d\n",
      prefs.performance);

   /* Run the list of categories and save them
    * and their states
    */

   g_list_foreach(prefs.categories,
      SavePrefsCategory, fd);

   ...
}

static void
SavePrefsCategory(
   CatEntryT   *catentry,
   FILE        *fd
)
{
   fprintf(fd, "category:%s:%d\n", catentry->name,
      catentry->state);
}

One other pitfall to avoid comes with testing your application if you use pixmaps. Ximba Radio uses a logo pixmap in several places. The pixmap is not found if you run the application from the default src directory unless you first do a complete build:

./configure --prefix=<install directory>
make
make install

This process copies over pixmaps to a pixmap directory under the install directory prefix. For example, if <install directory> is set to /usr/local/ximbaradio, the pixmaps are installed in /usr/local/ximbaradio/share/ximbaradio/pixmaps. Once installed, the compiled program finds the pixmaps correctly. If the pixmaps are updated, the make install step needs to be rerun. Switching to compiled logos—that is, making them part of the binary so relocation issues are not relevant—is possible with modifications to the support.c file. I've done this for previous applications, but the technique is beyond the scope of this article.

I managed to get the complete application written in approximately 30 hours of total work. Most of that was spent on core code. UI code was completed in perhaps ten hours of total work. The application matches the Windows UI in all major features and the Preferences are easy to manage. The UI code is independent of the core code, although some dependency on the callbacks.c file still is present.

Development of Ximba Radio continues. Plans include adding audio control options and a GStreamer-based reflector. The reflector, Ximba Radio and OpenXM will combine to allow remote access to PC-based XM Radio satellite service.

Glade 3 is under development, and it's expected that the code generation feature will be removed. Because this upcoming release has been long in development and its release does not appear to be close to the horizon, working with generated code remains a viable option for Glade-built prototypes for the near future. That said, prototype development does remain fast and painless with GTK+ and Glade.