Help answer threads with 0 replies.
Go Back > Blogs > rainbowsally
User Name


Rate this Entry

GUI coding: First Stop QT4

Posted 04-18-2012 at 02:55 PM by rainbowsally
Updated 04-18-2012 at 02:57 PM by rainbowsally (misspelled title)

First of all, let me say that I've needed a widget that acts like a terminal -- like forever -- and I've checked out a LOT of toolkits having various degrees of success with each.

Perhaps oddly, tk was the best. QT4 was the worst. I subclassed a text editor widget and YOW! was it ever slow!! But I think we'll give QT another look and this is why.

I've checked out many toolkits including
  • tcl/tk (and variants)
  • xclass and xforms and it's descendants
  • fltk v 1.x
  • fltk v 2.x
  • FTL (my own derivative of the once defunct fltk 2.0)
  • gtk/glade 2 (and a quick spin with glade 3)
  • Fox

These all have certain advantages and disadvantages. The X-based systems don't rely on any particular desktop manager, for example.

If you pretty well crash your system, there's a good chance they will still run. And they are fairly simple to understand (except xclass, which is somewhat buggy to boot).

TK is too hard to get at directly. We don't want to rely on the interpreter (tcl) because too much is impossible to trace with a debugger in interpreters. Same goes for all the GUI toolkits that are interpretive. No good for our low level Computer Mad Science experiments.

Fox is quite nice in its own way and I did like the file dialog. It's the old win-98 style file dialog, you can see everything laid out in a nice scroll widget. I don't like the gtk file dialog at all and fltk's was even worse. (They now accommodate a 'native' file dialog but it's missing the extremely easily implemented 'kdialog' version for some reason.)

I like a lot about Fox, but without a dialog editor (not nearly as simple to create as one might think -- I and others have tried), Fox is also out.

Hat's off anyway. It's a great little toolkit.

And all of these toolkits except GTK come in a single integrated download with at most a couple of additional small downloads.

But as a dialup user myself GTK is out. After the 15th download, and discovering new unexpected dependencies, some that are incompatible with my current system which would require even more wild goose chases, it's just not practical for me. So I'm afraid gtk is out of the race for now, though I appreciate their glade-3 having sensible shortcut keys and in fact having these small modules DOES make it easier to debug and contribute to their effort, once you are in sync with the developers.

I like the GTK concept but the 'dependencies' issue is a clincher, I'm afraid.

I must say, that in some ways, I like xforms a lot. It's versatile, though limited in its original state. But it would be too much work to get it up to the point where it could (let's say) "clone" other GUI's. GTK and QT4 can both mimick other GUIs by way of 'themes', though they don't tell us how to do that ourselves.

[With a good debugger we can find out though.]

In any case xforms is out due to it's being stuck with a clunky antique look. Same with xclass which has some cool demos but is in fact a bit buggy.

What about FLTK, then? It's a fairly painless download.

FLTK is backward compatible with xforms. It IS a toolkit. But the widget names are hard to type fast, being mixed case and with underscores, both making for something of a typists nightmare if you do much hand coding.

FLTK Version 1.3 is coming along (very slowly) with it's fluid interface, but it can't clone other GUIs and the buttons. But the buttons, at least, look a little nicer, but then again they are still drawn line by line instead of using image files.

Oh! Almost forgot. SPIF, a spinoff from FLTK, had the image files for buttons, tabs, etc. for and themes (nice too), but it didn't have a dialog editor and last time I checked, which was in fairness quite a while ago, the automatic layout wasn't problem-free.

SPIF is out too. We need our toolkit to have a graphical dialog/widget editor which I doubt they have yet but I may check again later.

FTL. FLTK version 2.0 was in complete shambles when I picked it up. It had been on mothballs for six years. I remade the makefiles with AutoBake (similar to mc2) and got all the examples working (including theme plugins), debugged what I could and converted it to at least being able to use images for buttons and borders. (If 2.0 now has the XT theme, I passed that to BigBen a while back. Not looking for credit here, just explaining what a mess it was.)

But FTL is not finished yet. FTL is out of the running along with FLTK.

Both have great widget description formats though. Similar the NextSTEP menu definitions which are human readable and manually editable while xml format (the OTHER main system being used) is a nightmare to read and nearly impossible to edit by hand.

What a notion. Wouldn't that be a kick in the pants if we could port linux applications to linux? :-) I'd like to see a universal GUI description, not in xml format, that could be used to generate (at a minimum) QT ui forms from glade generated UI's and visa versa. And if this were done in a NextSTEP-like format, or like FLTK, it would be much easier to convert other UI description files to the same format.


What does that leave?

QT has a few problems in my opinion (their thread implementation looks to be insane if it really IS based on timer widgets which in the impression I got last time I played with it several years ago), but it's accessible and in fact ubiquitous among KDE users and has a very interesting 'inheritance' scheme that is worth taking a look at even if we didn't want to play with their GUI.

We'll check out that inheritance scheme shortly.

Also, QT4 has an outstanding dialog/widget editor. The best of all them in terms of simple setup of forms and widgets but I don't like their qtcreator. (And I don't have to use it, thank goodness.)

Also, for my own purposes, since I now have a debug version of QT4 installed that I can trace, though it isn't compatible with my very slightly older qt4 that runs my KDE system. (It's a long story.)

So for our first round we will go with QT4 and see where we end up.

Notes re. my QT4 demos, examples, with debug info:

Let me start by explaining that by compiling from sources, I was able to install THOUSANDS of demos and examples that had been missing from RPM and DEB packages.

Let that suffice as a reason to explain how I did this.

For my own setup I set up qt4 configure with debug info to put qt4 in prefix=/UsR with sysdir=/EtC (which wasn't used), both of which belonged to my normal user so that attempts to install into other system folders would fail as I installed as a normal user.

I tarred up the result in /UsR and moved it to a directory where I unpacked it into TREE created by 'new.make'.

Using UsR2usr I checked and changed all the rpaths and paths in the script files (bear in mind the package is pushing 20 thousand files) and after several relocations using the make-based system (new.make) I finally decided to put the debug version in /opt/qt4 which I add to LD_LIBRARY_PATH in kdbg (gdb) environment, not in the regular LD_LIBRARY_PATH, so that the debugger and the targets both load the right libs from the right folders and so I can trace into the deepest parts of QT4 without any hangups in the debugger.

I cannot, however, install the compiled QT4 into the root file system (/usr) yet though. There are problems with phonon missing certain functions and also dbus which requires the newer QtCore lib which is incompatible with the rest of the system leading to a huge problem of what order to install things in.

But for now that doesn't matter.

Let's dig into a somewhat typical though a bit large GUI toolkit. QT4.

Coming up... The 4 main parts of a typical GUI using a typical GUI toolkit.
Posted in Uncategorized
Views 9044 Comments 2
« Prev     Main     Next »
Total Comments 2


  1. Old Comment
    By "widget that acts like a terminal" you mean a more tightly integrated form of what might otherwise be done by launching xterm and having it launch the application that wants to work on a terminal ... something that can run in an event loop, but still has terminal semantics to its output?
    Posted 04-19-2012 at 04:04 PM by Skaperen Skaperen is offline
  2. Old Comment
    Actually, I was working on a Forth compiler/interpreter and needed a terminal where I could copy/paste stuff in with the more or less standard keys (Ctrl-C, X, V, Z and stuff).

    The interpreter was integrated into the terminal.

    I got it working with QT4 but I had to set up a separate key buffer (private event queue). The whole process was pretty complicated.

    So... no not exactly. By terminal I just mean io for a keyboard, I guess. Not tied to a shell in any way.

    And xterm is horrible. The scrollbars are a pain, the clipboard in awkward, there is no paste key and junk ansi codes if you press a wrong key...

    And though ncurses is an improvement it's still unacceptable for my (erstwhile) purposes, starting with the oddball treatment of the left and right alt-keys as though they had different functionality, never mind the icky appearance. ;-)

    I did write a forth using termios (non-canonical) and with a separate thread to queue keyboard input while the Forth ran in its own thread though. And it was what I used for my terminal for a while. It was much faster than the QT implementation at least.

    Thanks for the comment.

    Posted 04-20-2012 at 08:48 AM by rainbowsally rainbowsally is offline


All times are GMT -5. The time now is 05:39 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration