Tag: Qt

KolorTool For KDE 4

July 17, 2009 » Geek

Update (2009-07-25)
Turns out what I needed was KColorChooser in KDE4. Oh well :-)

Maybe I’m blind, but I can’t find a nice, simple color tool on KDE 4 for my life. The color picker Plasmoid is okay, but it doesn’t do what I want: to mangle colors and get the resulting hex values.

To fix this, I threw together this little Python bit and installed it as KolorTool. Does what I need, just throws up a color dialog for me to play with.

Pretty simple...

KolorTool

#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
from PyQt4 import QtGui
from PyKDE4 import kdeui

app = QtGui.QApplication(sys.argv)
picker = kdeui.KColorDialog();
picker.show();

sys.exit(app.exec_());

KolorTool.desktop

[Desktop Entry]
Comment[en_US]=
Comment=
Exec=~/System/bin/KolorTool
GenericName[en_US]=Color Picker Dialog
GenericName=Color Picker Dialog
Icon=kcolorchooser
MimeType=
Name[en_US]=KolorTool
Name=KolorTool
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=

Enjoy, modify and let me know if there is an existing, standard tool like this please!

Gtkmm/Glibmm Thread Example

September 30, 2008 » Geek

Heads Up!

This post uses a deprecated API. You can learn more here: https://developer.gnome.org/glibmm/stable/group__Threads.html

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 ()

int main (int argc , char ** argv) {

  if(!Glib::thread_supported()) Glib::thread_init();

  Gtk::Main kit (argc, argv);
  MyWindow win;
  Gtk::Main::run (win);
  return 0;
}

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

if(!Glib::thread_supported()) Glib::thread_init();

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.

MyWindow
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.

class MyWindow : public Gtk::Window {

  public:
    MyWindow () : thrashHive("Go!") {
      bee = NULL;
      thrashHive.signal_clicked().connect(sigc::mem_fun(*this, &MyWindow::go));
      add(thrashHive);
      show_all();
    }

    void go () {
      if(bee != NULL)
        return;

      bee = new Worker();
      bee->sig_done.connect(sigc::mem_fun(*this, &MyWindow::beeDone));
      bee->start();

      thrashHive.set_sensitive(false);
      thrashHive.set_label("Working");
    }

    void beeDone () {
      delete bee;
      bee = NULL;
      thrashHive.set_sensitive(true);
      thrashHive.set_label("Go!");
    }

  private:
    Gtk::Button thrashHive;
    Worker * bee;

};

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.

      if(bee != NULL)
        return;

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.

      bee = new Worker();
      bee->sig_done.connect(sigc::mem_fun(*this, &MyWindow::beeDone));
      bee->start();

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.

      thrashHive.set_sensitive(false);
      thrashHive.set_label("Working");

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.

Worker
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.

class Worker {
  public:
 
    Worker() : thread(0), stop(false) {}
 
    // Called to start the processing on the thread
    void start () {
      thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
    }
 
    // When shutting down, we need to stop the thread
    ~Worker() {
      {
        Glib::Mutex::Lock lock (mutex);
        stop = true;
      }
      if (thread)
        thread->join(); // Here we block to truly wait for the thread to complete
    }
 
    Glib::Dispatcher sig_done;
 
  protected:
    // This is where the real work happens
    void run () {
 
      while(true) {
        {
          Glib::Mutex::Lock lock (mutex);
          if (stop) break;
        }
        sleep(5);
        std::cout << "Thread write!" << std::endl;
        sig_done();
        break;
      }
    }
 
    Glib::Thread * thread;
    Glib::Mutex mutex;
    bool stop;
};

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:

    void start () {
      thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
    }

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).

    void run () {
 
      while(true) {
        {
          Glib::Mutex::Lock lock (mutex);
          if (stop) break;
        }
        sleep(5);
        std::cout << "Thread write!" << std::endl;
        sig_done();
        break;
      }
    }

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.

g++ -Wall -o bee gthread.cpp `pkg-config gtkmm-2.4 --cflags --libs` `pkg-config --libs gthread-2.0`

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.

#include 
#include 

class Worker {
  public:

    Worker() : thread(0), stop(false) {}

    // Called to start the processing on the thread
    void start () {
      thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
    }

    // When shutting down, we need to stop the thread
    ~Worker() {
      {
        Glib::Mutex::Lock lock (mutex);
        stop = true;
      }
      if (thread)
        thread->join(); // Here we block to truly wait for the thread to complete
    }

    Glib::Dispatcher sig_done;

  protected:
    // This is where the real work happens
    void run () {

      while(true) {
        {
          Glib::Mutex::Lock lock (mutex);
          if (stop) break;
        }
        sleep(5);
        std::cout << "Thread write!" << std::endl;
        sig_done();
        break;
      }
    }

    Glib::Thread * thread;
    Glib::Mutex mutex;
    bool stop;
};

class MyWindow : public Gtk::Window {

  public:
    MyWindow () : thrashHive("Go!") {
      bee = NULL;
      thrashHive.signal_clicked().connect(sigc::mem_fun(*this, &MyWindow::go));
      add(thrashHive);
      show_all();
    }

    void go () {
      if(bee != NULL)
        return;

      bee = new Worker();
      bee->sig_done.connect(sigc::mem_fun(*this, &MyWindow::beeDone));
      bee->start();

      thrashHive.set_sensitive(false);
      thrashHive.set_label("Working");
    }

    void beeDone () {
      delete bee;
      bee = NULL;
      thrashHive.set_sensitive(true);
      thrashHive.set_label("Go!");
    }

  private:
    Gtk::Button thrashHive;
    Worker * bee;

};

int main (int argc , char ** argv) {

  if(!Glib::thread_supported()) Glib::thread_init();

  Gtk::Main kit (argc, argv);
  MyWindow win;
  Gtk::Main::run (win);
  return 0;
}

Tags: , , , ,

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.

Caveats
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.

extern "C" {
  KPanelApplet* init( QWidget *parent, const QString& configFile) {
    KGlobal::locale()->insertCatalogue("KickTweet");
    return new KickTweet(configFile, KPanelApplet::Stretch, KPanelApplet::About, parent, "KickTweet");
  }
}

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.

Testing
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.

Conclusion
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