Yearly Archives: 2008

Gtkmm/Glibmm Thread Example

September 30, 2008 » Geek

Heads Up!

This post uses a deprecated API. You can learn more here:

After dealing with threads in Qt and seeing how nice and simple it was, I decided to try again with the Gtkmm/Glibmm threading system. I think the crucial piece for me with the Qt threads was the excellent documentation, so I’m going to show you my full example here and document it in detail. As a quick disclaimer, I do not know if this is the 100% “right” way to do threads, but it matches up with everything I’ve read and, more importantly, it works.

Where to start…
I’m going to start with a brief description of what is going to happen. We will develop a threaded worker class, a trivial Gtk::Window class and a trivial main function. Let’s get the first two out of the way early, since they are the easy ones.

int main ()

This is a pretty standard main function, with one notable nod to Glibmm, and that is line 84.

You only ever call Glib::thread_init(); once, otherwise it will abort with an error. So what we are doing is asking Glib “Are you already handling threads?” and if it isn’t we initialize the threading system. This has the additional perk of aborting the program if threads are not supported at all.

If the rest of this function doesn’t make sense to you, walk away from this tutorial and go read the Gtkmm one.

Next we are going to implement that Gtk::Window class that we use in main, ever so imaginatively called MyWindow. There is nothing much special going on, so I’ll show you the full listing then pick out the important bits.

As you can tell, this is a simple Gtk::Window with just a single button (thrashHive) in it. In the constructor we connect this button to a method go() at line 52. go() is important to us because it is where we create and launch our thread, which is represented as the class Worker of which we have a pointer declared at line 78 called bee. Let’s run through go() line by line.

In lines 58 and 59 we are protecting our memory from trying to create multiple instances of a Worker thread, a good idea to stay safe in an asynchronous environment.

At line 61 we instantiate a new Worker class. Next at line 62 we connect the signal sig_done to our beeDone() method, which essentially just undoes everything we do in go(). We do this because this is a non-blocking, asynchronous working thread and we need to know when it is finished running. When we get to the implementation of the Worker class, you’ll see that this “signal” is not a given, but rather something we implement ourselves, and we can have as many “signals” for events as needed. Lastly we start our thread at line 63.

Here we disable our button and change it’s text. Why do this here and not before thread creation? In most cases that would be a good idea, but here we want to demonstrate that the main thread is still working, so we do updates to the GUI after we start the worker thread.

The Worker class is actually fairly simple. It has a basic set of steps:

  1. Create and wait to be started.
  2. Get started, create thread and run.
  3. Do work, emit signals, check for being aborted.
  4. Return when done, then wait around until cleaned up.

Just breeze over the full listing then we’ll go over each of those points one at a time.

We don’t have anything to deal with for the first point. In the constructor we just initialize the Glib::Thread to 0 and our sentinel boolean, stop to false.

For the second point, we need to look at start() and run().

start() is our public method, and it creates and runs the actual Glib::Thread. Doing that is fairly straight forward:

The run() method is where our blocking operations go so that we don’t have to worry about gumming up the UI, this is where the work actually happens (i.e. step 3).

In my run() I just wait five seconds and write to stdout, but if you are doing a lengthy process, you should occasionally check the stop variable for an abort condition by using lines 30 – 33. Always put your Glib::Mutex::Lock inside of their own block, it is easier to handle them that way as the destructor does the cleanup work for you.

On line 37 we see a “signal” being emitted. This is actually a Glib::Dispatcher, which uses pipes for asynchronous communication between threads. In practical application just treat it like a sigc::signal . If you need to communicate data, emit the Glib::Dispatcher and have the receiving thread do method calls to get the information from stored values in the sending thread.

One easy to miss caveat when using gthreads, you have to throw in some extra libraries with pkg-config --libs gthread-2.0, here is the command line to compile this demo application.

That is the guts of a simple Gtkmm/Glibmm worker thread, I hope that I was clear if not concise. Here is the complete listing of the program for your reading/borrowing/compiling pleasure.

Tags: , , , ,

SVN to Twitter

September 19, 2008 » Geek

I’ve been really getting into developing my KickTweet project and set up a Twitter account for it at I wanted to feed in my subversion commits so I did some searching.

What I found was twitvn a monstrous (50-ish ‘real lines) Python script that sends commits to Twitter. I find that ridiculous. So here is my version, it drops right into the post-commit script and could be reduced to 2-3 active lines.

Note that the use of the ‘${TWEET:0:139}’ is a definite bashism, and not portable.

Update (2008-09-22)
Little tidbit to add into the script right before the curl call. If you want ellipses on commit messages over 140 characters, use this version.


September 19, 2008 » Life

This is a little out of date, but Darcy and I got two kittens a little over a week and a half ago. They are a brother and sister named Pickwick and Spatula respectively. Pickwick is Darcy’s cat and a little monster, I am covered in a profusion of small scratches inflicted by him. Spatula is my cat and a good deal calmer and less inclined to use her claws. They are a bit over two months old now.



More photos…


KickTweet or Creating a KDE3 Panel Applet

September 18, 2008 » Geek

I started using Twitter again last week and wanted a Linux GUI client. I looked at the standard bunch, but none of them did it for me. I wanted something small and easy. Some had system tray modes, but I decided to make my own that would reside as a panel applet.

Doing the API interaction is easy, it’s just web services and I’ve used libcurl enough before to have that down. It’s the Qt/KDE piece that I wasn’t so sure about. I got started with my good friend Google, and found a few resources. If you are interested in creating a panel applet for KDE 3.5 or so, ignore the Google results they will only serve to lead you in the wrong direction!

Getting Started
I got started by firing up KDevelop and selecting “Project -> New Project” then choosing the “C++ -> KDE -> Kicker Applet” project. This will generate a nice framework for you to start developing your application on. It’s just like creating any other Qt application, but in a smaller space.

There are a few small things that you won’t get unless you poke around a bit. The biggest problems I had were getting the applet to expand properly and getting my input text box to accept focus. Both of these problems were solved by reading the code from “mathapplet.cpp” by Andrew Coles in the KDE source tree.

I’ll start with the expanding issue. The first fix is to change the constructor to pass KPanelApplet::Stretch instead of the default KPanelApplet::Normal, as shown below.

This only fixes part of the problem though. If you load it into the panel as it is now, it will keep resizing until it has pressed all the other applets aside. This is because we need to fix the default implementation of widthForHeight(int height) and heightForWidth(int width). My fix here was to just feed back a standard value regardless of the current size requests. I copied mathapplet in sending back 110 for width and 22 for height. It doesn’t seem to be causing any problems yet.

The next issue is the input box focus. Again, this is taken from the mathapplet code and it is a simple if non-obvious fix. Just add watchForFocus(tweetText); to your constructor, where tweetText is your QLineEdit or derived. This is of course only relevant if you are using a text entry widget.

You can test your applet the easy way or the hard way. I tried it the hard way for quite a while, then when I got fed up I found the easy way.

the hard way is to do “make install” then add the applet to your panel. You will not notice changes if you do this version, because even if you add and remove the applet from the panel, it is not unload from memory. To get it unloaded you must restart the panel, easily done with a call to “dcop kicker default restart” This is slow an unwieldy however, and I recommend you only use it for testing the actual integration into the panel.

The easier way to test your applet is to still do “make install” but then to run your associated desktop file with appletproxy, like so “appletproxy /opt/kde3/share/apps/kicker/applets/kicktweet.desktop“. This lets you do quick and easy debugging and will send your cout and cerr to the terminal if you run it from one.

Creating a kicker applet is not nearly as hard as I thought it might be. After several missteps I now have “KickTweet” which readily scratches my Twitter itch.

KickTweet in action

Trash, like safeRM but different…

September 9, 2008 » Geek

I had a bad morning today. I was working on a script that parses out log files and ran it from my desktop. It’s supposed to change to a specified directory and check for, then delete, any logs that are over a month old. Unfortunately I didn’t have that directory on my machine, and I didn’t exit the script after a failed directory change. Poof, there go my desktop documents.

As an impulse reaction I looked for something to replace ‘rm’, and found safeRM. I was not impressed. Why have a ‘dustbin’ folder if we already have that built into the desktop environment, i.e. the Trash can?

Here is my own brief script that (on openSuSE) moves things to the trash. Note that it is not set up for moving directories and does not emulate ‘rm’ entirely.

By the time I got this far I decided that this wasn’t worth pursuing. I’ll just try to be more careful and will absolutely run backups. I thought I’d publish it anyway just in case someone wants a safeRM alternative or to be able to put things in the trash from the command line.

Tags: ,