Qt with visual studio 2010

[Suzie999]

Hi daniwebbers.

I've been hearing a lot about Qt when searching for a library to ease my pain of creating GUI's with native windows API.

I'm hoping folks here might be able to offer some sage councel before I do something irreversible to my IED environment (vs 2010) that I'll regret so the more personal experience you have with this subject the better (well for me :)) but I appreciate all help and advice.

This is not my first place of call, I've had a good read on the Qt forums and FAQ's where I've learned a lot and had a go at installing Qt with VS add-in in a VM.

However after a bit of testing, I've decided I'm going to want to build from the Qt source code so as to get it how I want, which a major point is the ability to statically link as many of the Qt libraries as is possible.

This is where the Qt documentation became a little convoluted in my opinion, the most daunting of them all was choosing which sources to get ref http://qt-project.org/wiki/Get_The_Source

To be honest I thought there would be a self extractor with a "windows7 32bit-visual studio 2010" Title and I'd click download.
Of course that is not the case and there is all kinds of lingo such as "building from git", "graphics drivers", "perl", "ANGLE" and Direct x SDK's" (the list goes on) and I don't know what to.

For a start, I don't even know what git is. All this is what has me running back to where I know there are very knowledgable and trustworthy people, from whom I'm not afraid to take advice.

Hope someone can help me, and thank you for reading my requests.

[Ancient Dragon]

Your link doesn't work.

Why start a new program using pure win32 api? It is a lot easier just to use Windows Forms and CLR/C++, C# or VB.NET. Visual Studio will create a basic windows GUI app for you in just a few seconds.

[Suzie999]

Not sure what happened with the link sorry (fixed)

I was informed (read somewhere) that CLR/C++ is a massive bloat and slows apps down, as well as not compiling to native code, and I'm hoping to learn more of win32 programming before .Net.

I'm not closed to CLR, I'd just not thought that much about it really after my reading some time ago.

I have to say though, I was very impressed with Qt and it simplicity, and very intrigued by it's signal/slot graphical programming.

I'll stop there before I come across as advertising it.

[Ancient Dragon]

and I'm hoping to learn more of win32 programming before .Net.

IMO learning win32 api us only useful for maintaining lagecy (existing) code -- not for starting new project. win32 api could be deprecated sometime in the not-too-distant future.

(read somewhere) that CLR/C++ is a massive bloat and slows apps down

That may have been true at first, but it has evolved since then, and is still evolving. It uses the same identical .NET functions as C# and VB.NET.

I'll stop there before I come across as advertising it.

No need to worry, QT is recommended by almost everyone for writing cross-platform programs.

[Suzie999]

Thanks for your clarification, my I enquire whether you know if CLR/C++ compiles to native code or interpreted?

I'd really rather not get into my issues as to why, but it's quite important to me.

[Ancient Dragon]

Neither -- all .NET languages are compiled into what is called Common Intermediate Language (CIL), conceptually similar to .obj. Then it uses a Just In Time (JIT) linker to produce the final executable. I have not done it but I understand CIL code can be easily disassembled back into its original source code, either CLR/C++, C# or VB.NET. On some platforms I suppose CIL could be just interpreted, but normally it's compiled.

Visual Studio (and probably other .net compilers as well) does all that for you if you tell it to create an executable.

[mike_2000_17]

@AD: I don't think that the OP is really interested in a Qt vs. .NET debate in this thread. It would be like answering a question about a problem with some C++ code, and recommend as an answer to opt for a completely different language instead. It's off-topic. In any case, any .NET code is definitely never completely compiled to "native" code, this is by design of the whole .NET framework. When writing programs or libraries for the .NET framework (through C# or C++/CLI, or whatever), the "compiler" will compile that code to CIL, which is a high-level pseudo-assembly code that acts as an intermediate language. A .NET "executable" is actually just a launcher that launches the .NET framework (if not already running) and launches the execution of the CIL code embedded in that "executable". When CIL code is "executed", it is, in fact, interpreted on the fly (also called Just-In-Time compilation). There is a world of difference between CIL and actual native code (like you would find in an object file (.o/.obj) from some C/C++ compilation, you could say "conceptually similar" but certainly not similar in practice). And yes, to answer the OP's concerns, .NET programs will be bloated and slow, non-portable and heavy-weight (heavy distributables), due to the reliance on the .NET framework and JIT compilation.

before I do something irreversible to my IED environment (vs 2010)

Installing the Qt add-on for Visual Studio is neither irreversible nor is it gonna interfere with anything else, in general. It only adds some options and some optional toolbars / configuration parameters that are relevant to Qt. If you decide not to use Qt after that, you can simply ignore those additional options / functions or uninstall the add-on. Don't worry.

I've decided I'm going to want to build from the Qt source code so as to get it how I want, which a major point is the ability to statically link as many of the Qt libraries as is possible.

Oh... that could be an issue. Qt is a dual license library: commercial and LGPL. If you use the commercial license, you can do pretty much what you want (I think) in terms of linking (static / dynamic) and additions to Qt's source, but all under a licensing fee (royalties). If you use the LGPL license, then if you want to use it in a non-commercial project that is not licensed under GPL, you can only link dynamically to the Qt library and leave its source code un-modified. Otherwise, you will have to commit to using GPL license. This is something to keep in mind, and could make the static linking option much less attractive.

This is where the Qt documentation became a little convoluted in my opinion, the most daunting of them all was choosing which sources to get ref http://qt-project.org/wiki/Get_The_Source

First of all, you should try to refer to the "official" reference pages, like these instructions. But, nevertheless, compiling a library of the magnitude of Qt is no small task. Don't expect this to be easy. Especially in Windows + Visual Studio, which combines two of the worst development environments (but sadly, very popular). Personally, I very rarely compile foreign major libraries from source, unless there is a very good reason to do so, because it will always be a daunting task. In Windows (and worse, with Visual Studio), this can get so convoluted and difficult that I often gave up when I tried, my success rate is probably around 50% with major libraries. Qt should not be too bad though (relatively-speaking).

To be honest I thought there would be a self extractor with a "windows7 32bit-visual studio 2010" Title and I'd click download.

No, there will almost never be such a thing. In cross-platform libraries like Qt, you generally have only one set of source files (one source directory) for each major version of the library, but not for every target platform, that's the meaning of "cross-platform" code. So, the same source files can be compiled on any platform (that the library supports), and this is why you won't find a different "download" for each platform or IDE.

Generally, you start out with the source directory that you downloaded / extracted. Then, you run a "configure" (or "cmake") to run a number of configuration scripts that look for dependencies (libraries) and other platform-specific features to set up the way that the source code needs to be compiled (what compiler program, compiler options, linking directories, linking libraries, include paths, compilation flags, etc....). And then, you would run a build script (usually using "make") to actually carry out the compilation of all the code and bundling everything into appropriate libraries. And finally, you "install" the binaries (executables or libraries) that were generated by the compilation. As you see in these instructions, that is what is described (the configure script and the "nmake / jom" part). These build-systems take care of activating all the platform-specific configurations automatically, so that the same source can be used on any platform.

Of course that is not the case and there is all kinds of lingo such as "building from git", "graphics drivers", "perl", "ANGLE" and Direct x SDK's" (the list goes on) and I don't know what to.

I suspect you are quite a way over your head with this. In general, building a major library from source should come with a "experts only" warning label. But if you feel up to it, you can give it a shot. But you have to understand that instructions on building such a library from source are generally addressed towards "experts", they are rarely written for beginners, and hence, all the "lingo". Experts who have done this many many times and are familiar with all the tools being used are generally not interested in a long and detailed tutorial page, but prefer a clear and succinct explanation of the steps. This means that each sentence is telling you what to do, not announcing something that will be explained (as usual in detailed tutorials), no explanation will follow, so keep that in mind. You have to pay close attention to the instructions, and fill in many of the gaps on your own.

The first thing to worry about is the set of dependencies that Qt has. For one, Qt depends on a reasonably recent version of OpenGL installed on the platform, which can be a source of trouble in Windows (i.e., Microsoft hates OpenGL, because it competes directly with one of their products: DirectX). This is what the instruction page calls "Graphics drivers" (a rather confusing name for it!). So, you will have to check your version of OpenGL by compiling and running the simple program in that link. If the version is below 2.1, you will have to install the "ANGLE" library and follow the instructions. The ANGLE library just makes DirectX look like OpenGL, and thus, supplementing for a lack of support for a recent version of OpenGL on your platform.

There are a number of dependencies too. For the most part, these are classic dependencies (again, "experts" recognize them all). The dependencies on "ActivePerl", "Python", "Ruby", "Bison", "GPerf", "Flex" and "OpenSSL". These are all things that you will need to install in order for the compilation process for Qt to work. Most of these are just scripting engines that are used in various script-driven configuration systems used to configure the compilation. These should not be too difficult to install, they are all classic and widely used libraries.

After that, you can start figuring out how to get the source files.

For a start, I don't even know what git is.

Alright, that's another piece of "expert lingo". Git is a version control system. Reading the wiki page might be a good start. In essence, this is a software that manages the source code, and does things like watching for differences between versions, merging contributions by different people, managing different development branches, and allowing for the easy sharing of the source code between programmers, library users (like you), and the servers that host the files.

So, all you need to know for now is that git is the program that you use to "download" the source code. The initial download of the source code using git is called a "clone" of the repository, and is done with a command like this (in Git-Bash):

$ git clone git://gitorious.org/qt/qt5.git qt5

where the last "qt5" in that line is the name of the directory on your computer where you want the downloaded source files to go to. Once you have "cloned" the repository, you can update the source files to get latest version whenever you want, at which point, you simply do:

$ git pull origin master

which means that you "pull" (or fetch-and-merge) the changes that exist on the server (gitorious, named "origin" here), on the branch called "master". This is the basic stuff you need to know about Git, although I highly recommend that you take some time to get to know Git, because it is an extremely cool and useful tool for source code management.

Once you have cloned the Git repository, you have the source code on your computer, and you can start going through the steps to build the sources. If you did everything correctly in terms of getting the dependencies and feeding the correct options to the "configure" program, then the compilation should work very well (but it could take a long time to finish). But I doubt that this will be the case, as it rarely is, in fact, this is probably where it starts to get complicated (up to now, it was "easy"). But don't be discouraged, because very popular libraries like Qt are generally very trouble-free from this point on, so, there is a good chance that it will just compile without trouble, but just be sure you have carefully followed all instructions on installing dependencies

Good luck!

[Suzie999]

Thanks Ancient Dragon, Mike 2000 17.

Mike, I've been reading the Qt documentation all day, so luckil all of what you wrote there (which I'm immensely appreciative of) makes a lot more sense to me now, than it would have yesterday.

The licencing issue is a dissappointment, but not so much so that I wouldn't go with the LGPL if I decide to go with it, which I'm really considering more and more as I play with it in my VM.

I can scratch the building of the sources now, as I'm too poor to be paying for licences when my applications and tools are only likely to cross the screens of no more than a dozen people or so.

I'm going to continue my search for something similar to Qt, though I doubt I'm going to find anything that comes close really.

Anyway It's been a tiring couple of days, and just installing Qt and getting it to work with Visual Studio was a crazy learn rollercoaster, so it's been very productive for me in the long term.

Thanks again folks, I'm quite overwhelmed with the human info I've gotten.

If you have any suggestions of libraries close to par with Qt, I'd be delighted to hear them.

Cheers.
Suze.

[Ancient Dragon]

You might investigate wxWidgets -- another cross-platform GUI library. I don't know if it can be statically linked or not.

[mike_2000_17]

I doubt that you will be able to find any decent GUI library/toolset that can be statically linked with your application. All the GUI libraries that I know of are dynamically linked, including Win32, MFC, WinForms, VCL, Qt, wxWidget, GTK+, and SDL. Some of these are open-source, and thus, could be re-compiled into static libraries (which, btw, will require significant tweaking of the build script). This is simply one of these cases where the demand for static library versions of the libraries is so low that it really doesn't make sense to provide and maintain it.

I would ask: Why do you absolutely want a statically-linked GUI library?
Because I cannot see any reason why you would want this.

[Suzie999]

It's just a preference, not an absolute requirement.
I'm fine with using the dynamically linked modules, It's just that the people who use the sotware are used to stand alone binaries with no externel dependancies.

Not a big deal.

[Ancient Dragon]

Then the people are apparently not using MS-Windows at all, but some other operating system. Nearly all programs that run on MS-Windows and *nix use shared libraries, if they didn't then the hard drive would fill up pretty quickly not to mention tripling the RAM requirement.

[mike_2000_17]

Yeah, as AD says, the dynamic linking option may seem like more troublesome in terms of distribution, but it is the only viable option in the broader context. You can't have the users re-install a statically-linked version of Qt for every new Qt application they install. The same principle goes for every other major library or framework.

In fact, one of the major criticism about Windows is that it does not have a proper package management system (like all Linux, BSD, Unix-like, and Mac OSes) that can manage all the libraries installed on the system, and also its culture of proprietary (not shared) software means that there is a lot of repetitive installations, a lot of "reinvent the wheel" work, and very bloated systems for the users who install many applications. This is how Windows gets incredibly bloated and slow over time. Try to reuse things using dynamically linked options, and you'll be part of the solution, as opposed to being part of the problem.

And if your users are tired of complicated installation processes and bloated systems, just tell not to use Windows. ;)

[Suzie999]

Then the people are apparently not using MS-Windows at all, but some other operating system. Nearly all programs that run on MS-Windows and *nix use shared libraries, if they didn't then the hard drive would fill up pretty quickly not to mention tripling the RAM requirement.

I mean the only thing they get from me is one executable, and a standard windows install has the rest of the files already.

[mike_2000_17]

Yes, but if you develop in Visual Studio, you are assuming that they have a number of Visual C++ redistributables already installed. The CRT is often dynamically linked too (unless you change the option). And then there could be many other stuff, some of which may not be there in a "standard windows install". Normally, you would have to package your application in an installer that would check all those things and install distributable versions of them. That's the "burden" of creating distributable applications.

Frankly, this is a bridge you should cross when you get to the river. In general, figuring out how to distribute the application has little if any impact on the actual code, it is only a matter of compilation options and what libraries you link to. For Qt, this is rather straight-forward (they recommend just putting the few Qt DLLs in the directory of the executable). For now, I think you should just concentrate on coding up the application, and worry about deployment if and when you get to that point.

[Ancient Dragon]

In fact, one of the major criticism about Windows is that it does not have a proper package management system (like all Linux, BSD, Unix-like, and Mac OSes

Hallelujah! I have found *nix a lot more difficult to install new programs because it gives me a list of packages that are not installed. That's one reason I don't even use *nix when I don't have to. Just too damned complicated.

On the otherhand, I have to agree with you a little -- anyone who has experienced "DLL Hell" knows all about that.