Wednesday, October 07, 2009
Learning Qt4.5 - Qt4 SDK and Qtcreator 1.2.9
** Warning: this is a very geeky posting for developers and other IT professionals. **
I've been learning the Qt4 version of C++ programming for the last few weeks. I started playing with qtdesigner last spring and then dropped it. A newer version called Qtcreator came out recently, so I picked up where I left off. The relevant links are Qt4 download page for SDK, Qtcreator, etc. and bleeding edge Qtcreator 1.2.9 snapshot. I'm using The Book of Qt4 as a reference. It's not the best manual for learning an SDK, but it's pretty much all that's available. It's rather a shame since the Qt4 toolkit is well designed and it is easy for even novices with some help to code a small decent graphical C++ program or GUI front-end for a console application. There are some decent tutorials at tuxradar.com. One of the tutorials, the media player, leaves out some key information that's in the code, and I could not get the two media based programs to function properly on my x86_64 Linux laptop due to the fact that the tutorials were created on a Mac. The ffmpeg program failed because it didn't recognize a program option which was not the fault of the Qt4 application. GTK failed on the media player which was also not the fault of the Qt4 application. Qt4 is supposed to be multiplatform, but if the underlying software fails the developer is screwed unless he can find a workaround. The tutorials are still quite useful, more so than some of the book examples which are scattered piecemeal throughout the book and therefore difficult to assimilate or understand. It's difficult to capture a visual workflow or process in a book, and the toolkit is intensively visual.
With Windows, one will need to install the SDK first, then Qtcreator. It is also best to install the SDK twice, and custom install the second copy. One will need to bring up the qtconsole on the second copy and run the following commands:
configure -static
mingw32-make or mingw32-make sub-src
(Info from qtnode.net and trolltech, and from sourceforge.net.)
The first make command statically compiles all of the SDK source code and examples while the second version mingw32-make sub-src only statically compiles the SDK source code and takes significantly less time to build if one is in a hurry. However, the latter command still takes 30 or more minutes on a dual-core system. You will then need to point Qtcreator (via Tools-> Options) to the static version of the SDK, though it's pretty good at autodetecting the needed files. I still had to include the mingw32.dll with my Windows programs to get them to work, but the statically compiled versions were significantly smaller (10-fold) and more portable than the dynamically linked and compiled versions.
I primarily develop on Linux and then port the code to Windows. The problem with Windows is that the application paths and environmental variables are different which means that one has to change some code (see below) unless one is smart enough to create portable code. (Conditional if or switch statements which check to see which platform the code is being compiled on can be used.) I spent 2-3 hours last night trying different variations of code portability and failed due to variable scope limitations in the conditional statements which was a bummer indeed. I ended up putting Windows specific code in comments. I will likely have to post something on the Qt specific forums to find the answers I need.
Coding differences with Linux and Windows:
On Linux/Unix:
QString program = "program name";
On Windows:
QString program = "absolute path of program";
e.g. QString program = "C:/Tools/scalpel/scalpel.exe";
args << "-c";
args << "C:/Tools/scalpel/scalpel.conf";
So, I have to add two extra lines and modify a third line of code to get the same program to work on Windows. This is not even taking into account differences in the Windows version of the program my program is accessing.
Addendum: Found instructions for installing and running the latest version of ffmpeg and x264 on a Debian based systems. There is also this ffmpeg cheat sheet. The ffmpeg front-end program now works when built on my AMD64 laptop.
I've been learning the Qt4 version of C++ programming for the last few weeks. I started playing with qtdesigner last spring and then dropped it. A newer version called Qtcreator came out recently, so I picked up where I left off. The relevant links are Qt4 download page for SDK, Qtcreator, etc. and bleeding edge Qtcreator 1.2.9 snapshot. I'm using The Book of Qt4 as a reference. It's not the best manual for learning an SDK, but it's pretty much all that's available. It's rather a shame since the Qt4 toolkit is well designed and it is easy for even novices with some help to code a small decent graphical C++ program or GUI front-end for a console application. There are some decent tutorials at tuxradar.com. One of the tutorials, the media player, leaves out some key information that's in the code, and I could not get the two media based programs to function properly on my x86_64 Linux laptop due to the fact that the tutorials were created on a Mac. The ffmpeg program failed because it didn't recognize a program option which was not the fault of the Qt4 application. GTK failed on the media player which was also not the fault of the Qt4 application. Qt4 is supposed to be multiplatform, but if the underlying software fails the developer is screwed unless he can find a workaround. The tutorials are still quite useful, more so than some of the book examples which are scattered piecemeal throughout the book and therefore difficult to assimilate or understand. It's difficult to capture a visual workflow or process in a book, and the toolkit is intensively visual.
With Windows, one will need to install the SDK first, then Qtcreator. It is also best to install the SDK twice, and custom install the second copy. One will need to bring up the qtconsole on the second copy and run the following commands:
configure -static
mingw32-make or mingw32-make sub-src
(Info from qtnode.net and trolltech, and from sourceforge.net.)
The first make command statically compiles all of the SDK source code and examples while the second version mingw32-make sub-src only statically compiles the SDK source code and takes significantly less time to build if one is in a hurry. However, the latter command still takes 30 or more minutes on a dual-core system. You will then need to point Qtcreator (via Tools-> Options) to the static version of the SDK, though it's pretty good at autodetecting the needed files. I still had to include the mingw32.dll with my Windows programs to get them to work, but the statically compiled versions were significantly smaller (10-fold) and more portable than the dynamically linked and compiled versions.
I primarily develop on Linux and then port the code to Windows. The problem with Windows is that the application paths and environmental variables are different which means that one has to change some code (see below) unless one is smart enough to create portable code. (Conditional if or switch statements which check to see which platform the code is being compiled on can be used.) I spent 2-3 hours last night trying different variations of code portability and failed due to variable scope limitations in the conditional statements which was a bummer indeed. I ended up putting Windows specific code in comments. I will likely have to post something on the Qt specific forums to find the answers I need.
Coding differences with Linux and Windows:
On Linux/Unix:
QString program = "program name";
On Windows:
QString program = "absolute path of program";
e.g. QString program = "C:/Tools/scalpel/scalpel.exe";
args << "-c";
args << "C:/Tools/scalpel/scalpel.conf";
So, I have to add two extra lines and modify a third line of code to get the same program to work on Windows. This is not even taking into account differences in the Windows version of the program my program is accessing.
Addendum: Found instructions for installing and running the latest version of ffmpeg and x264 on a Debian based systems. There is also this ffmpeg cheat sheet. The ffmpeg front-end program now works when built on my AMD64 laptop.
Labels: Learning C++ and Qt4 SDK
Comments:
<< Home
Here's the snippet I include in my cross-platform apps.
void APPNAME::setOS()
{
/*
Look we are only gonna do this once.
Don't be sprinkling around the ifdefs and hiding the ugly platform specific parts.
If you gotta use em then you aren't thinking hard enough
However... Many of the external tools APPNAME depend on have diferent binaries for each OS.
thus we need to identify what we are running on to call the correct one.
QT does a good job of abstracting away teh platform specific parts of things like PATHs and the /\ slashes
Thus try to not use this variable If at all possible.
*/
#ifdef Q_OS_UNIX
OS = "Linux";
#endif
#ifdef Q_OS_WIN32
OS = "Windows";
#endif
#ifdef Q_OS_MAC
OS = "Mac";
#endif
If you install the tool you want to use in the binary's directory. Use something like this.
QString BinaryName=QDir::currentPath+"tool/toolname"
if(OS=="Windows")
{BinaryName.append(".exe");
Works for just about everything I've needed. I alway start from the assumption that its Linux and modify as needed.
Good Luck.
Post a Comment
void APPNAME::setOS()
{
/*
Look we are only gonna do this once.
Don't be sprinkling around the ifdefs and hiding the ugly platform specific parts.
If you gotta use em then you aren't thinking hard enough
However... Many of the external tools APPNAME depend on have diferent binaries for each OS.
thus we need to identify what we are running on to call the correct one.
QT does a good job of abstracting away teh platform specific parts of things like PATHs and the /\ slashes
Thus try to not use this variable If at all possible.
*/
#ifdef Q_OS_UNIX
OS = "Linux";
#endif
#ifdef Q_OS_WIN32
OS = "Windows";
#endif
#ifdef Q_OS_MAC
OS = "Mac";
#endif
If you install the tool you want to use in the binary's directory. Use something like this.
QString BinaryName=QDir::currentPath+"tool/toolname"
if(OS=="Windows")
{BinaryName.append(".exe");
Works for just about everything I've needed. I alway start from the assumption that its Linux and modify as needed.
Good Luck.
<< Home
