[RESOLVED] What GUI toolkit for my multi-threaded console app?

Hello,

I have a multi-threaded command line application written in C++ on Ubuntu that downloads data from a remote server over tcp sockets in one thread (receive_thread), processes those data in another thread (process_thread), and sends results to another remote server in a third thread (post_thread). Download, process, and post are done asynchronously and in real time. Each thread outputs data and error messages into stdout and stderr, so the messages from all threads are intermixed in the shell.

I want to develop a GUI that will display all those messages in separate windows, I will also need to input data. I see it as a parent window that launches multiple non-modal dialog boxes, each dialog displaying messages from each thread. I want to see the messages from all threads at the same time, I also want to be able to spread dialog boxes across multiple monitors. What toolkit would be the best and easiest for the task? GTK (I hear it does not support multi-threading), Qt, Tcl/Tk, anything else?

I'd appreciate your input. Thank you.

The GUI is not dependent on threading. If you use mutexes correctly, you will not have problems. GTK is Gnome Tool Kit. Yeah, it's thread-safe.

I recommend Qt personally.

Quote:

---

Originally Posted by ninja9578

The GUI is not dependent on threading. If you use mutexes correctly, you will not have problems. GTK is Gnome Tool Kit. Yeah, it's thread-safe.

I recommend Qt personally.

---

GTK is thread aware but not thread safe.

Right, I misspoke.

The easiest way I've found to make multi-threading work with a GUI is to package GUI-modifying events into functors, and then queue them up for processing by the main thread.

Quote:

---

Originally Posted by Lindley

The easiest way I've found to make multi-threading work with a GUI is to package GUI-modifying events into functors, and then queue them up for processing by the main thread.

---

Have you done it with GTK? (I have started making a pilot in GTK).

Could you elaborate?

If I have three threads: 1,2,3, where thread 1 is a parent thread, and threads 2,3 have strings to display in GUI. Should I declare a global array of strings, add strings from threads 2 and 3 to global array (use mutex here), then use parent thread 1 to output those strings to GUI? How do I tell parent thread that there is something to display?

Drawing and managing widgets (windows, buttons, menus...) should always be handled by a single thread. I'm not sure about GTK or Qt, but I know in wxWidgets, if you have multiple threads touching the interface you get really nasty results.

Lindley was suggesting an event queue, which is a fairly standard way of non-synchronous input and threaded apps. Windows has one, OSX has one...

How it works is that whenever you want to alter something on screen (in any thread) you create a message saying what needs to be modified and any parameters that it needs. It then gives that message to the message queue, which is just a thread that loops through a queue, when there is something in the queue, it pops it off, and handles it itself. This is all mutexed of course.

As a matter of fact, I just wrote a message queue for a side project some friends and I are working on. Here is an example of a message queue: http://sourceforge.net/p/ninjagameen...les/abstract.h

I don't have time now, but if you want me to explain how it works, let me know and I will tomorrow.

Quote:

---

Originally Posted by ninja9578

Drawing and managing widgets (windows, buttons, menus...) should always be handled by a single thread. I'm not sure about GTK or Qt, but I know in wxWidgets, if you have multiple threads touching the interface you get really nasty results.

---

It's also same in GTK and Qt - I've found out.

I am using POSIX threading hence I think I am going for POSIX Message Queues. Will it work?

The easiest way to do message queues using GTK+ is with the g_idle_add() function.

I've done pilot with POSIX messages, it works great. Thanks everybody for help!!

Quote:

---

Originally Posted by vincegata

I've done pilot with POSIX messages, it works great.

---

It may be accidental. It's not enougth to update the GUI from just any thread even if it's one thread and it's always the same thread. You must update the GUI from the so called event-dispatching thread defined by the GUI. In many or even most cases it's the same thread the OS itself uses to pass messages to programs. Most GUI toolkits provide a mechanism for how to update the GUI from other threads. Usually it involves sending an asynchronous message to the event-disptching thread where the actual update is made.

Quote:

---

Originally Posted by nuzzle

It may be accidental. It's not enougth to update the GUI from just any thread even if it's one thread and it's always the same thread. You must update the GUI from the so called event-dispatching thread defined by the GUI. In many or even most cases it's the same thread the OS itself uses to pass messages to programs. Most GUI toolkits provide a mechanism for how to update the GUI from other threads. Usually it involves sending an asynchronous message to the even-disptching thread where the actual update is made.

---

That's a mouthful :)

Right, I did a pilot with POSIX messaging, I haven't hooked it up to the GUI yet. I guess I'll have some more things to work out, I might post more detailed questions how to implement it on GTK+. Thx for input, nuzzle.

I highly recommend agains GTK, purely because it's not portable. I've always found Qt to be very user friendly, and even comes with a nice IDE called Qt Creator that does syntax highlighting for all of Qt's non-standard-c++ stuff like slots. That way if your customer comes to you and says "we also want it on OSX, Windows, and KDE" you don't have to re-write the gui. It also has a very active community (I would guess probably even moreso than GTK.) I've asked a number of questions on Qt forums and always got prompt replies.

Quote:

---

Originally Posted by ninja9578

I highly recommend agains GTK, purely because it's not portable. I've always found Qt to be very user friendly, and even comes with a nice IDE called Qt Creator that does syntax highlighting for all of Qt's non-standard-c++ stuff like slots. That way if your customer comes to you and says "we also want it on OSX, Windows, and KDE" you don't have to re-write the gui. It also has a very active community (I would guess probably even moreso than GTK.) I've asked a number of questions on Qt forums and always got prompt replies.

---

Hi, ninja9578, I am actually using Qt Creator for my C++ development on Ubuntu (not GUI). I am not worried about porting my app to other platforms, but I do want it to be portable to other flavors esp. CentOS. I asked my question on Qt forums so it looks like Qt provides some means to facilitate developing GUI on multi threaded apps:

"
Qt provides a QThread class to manage threads. As with all GUI frameworks that I am aware of, you can’t access GUI widgets directly from any thread, except for the “main” thread (i.e. the thread that processes the event loop). That’s no different with Qt. But Qt’s signals and slots [qt-project.org] concept provides a very elegant solution: Simply make your threads (derived from QThread) emit signals to “post” status updates (e.g. log messages). The Dialog box (derived from QDialog) will then process the status updates with a suitable slot function. Now you only need to connect the thread’s signal to the dialog box’ slot. As these objects live in different threads, use a queued [qt-project.org] connection! This makes sure the slot is executed in the context of the “main” thread and can access/update the GUI widgets safely. Of course you can have multiple threads and multiple dialog boxes at the same time. And they can be connected as needed. I have implemented several applications this way.
"

Quote:

---

Originally Posted by vincegata

Qt provides a QThread class to manage threads.

---

Qt provides a lot. In fact it's more of an application framework than just a portable GUI. Qt doesn't support threading only. You'll soon realize you could replace a lot of what you've done already much simpler with Qt supplied communications features for example.

What you should have in mind though is that the more you use of Qt the more dependent on Qt your application becomes and the less standard C++ it will be. Qt isn't your ordinary support library. It tends to dominate applications very much like the MFC do.

So if you accept to give up independence in exchange for a cozy life within a framework it's time to consider the ultimate (portable) application framework I think, namely Java. If you stick with C++ you should be careful not letting some framework take over your application. It's a technical and commersial risk. That's my two cents on this.

Quote:

---

Originally Posted by nuzzle

Qt provides a lot. In fact it's more of an application framework than just a portable GUI. Qt doesn't support threading only. You'll soon realize you could replace a lot of what you've done already much simpler with Qt supplied communications features for example.

What you should have in mind though is that the more you use of Qt the more dependent on Qt your application becomes and the less standard C++ it will be. Qt isn't your ordinary support library. It tends to dominate applications very much like the MFC do.

So if you accept to give up independence in exchange for a cozy life within a framework it's time to consider the ultimate (portable) application framework I think, namely Java. If you stick with C++ you should be careful not letting some framework take over your application. It's a technical and commersial risk. That's my two cents on this.

---

That's very true! I want my logic to be C++ only (I am staying away from Boost for that reason) and use third library for GUI only.

It's a good idea to also use the other items the library gives you too. Lots of times there are optimizations internally for things interacting with each other. For instance, you should use QString over std::string if you plan on using the string in the GUI, because converting between the two is slow.

Quote:

---

Originally Posted by ninja9578

I highly recommend agains GTK, purely because it's not portable.

---

Sure it's portable. It may not be implemented on every single platform ever, but it's on Linux, OSX and Windows.

Oh, my mistake, I was thinking GTK stood for Gnome ToolKit for some reason. Yes, GIMP ToolKit, now I remember :P Windows and Linux yes, OSX, no. Not by default anyway, X is in the additional installs of OSX, most people don't install it.