which gui library and programming language

Hello,

I don’t know which forum is the right one for my question, so I am putting it here.

Most OpenGL programs are written in C++, but C++ is a little bit outdated… another point is which GUI library to choose. At the moment, our application is written in C++ under linux with motif. I have to port it to windows. My first idea is to use MSVCPP and MFC, but I am absolutely not sure… C++ seems “out”, so does MFC. A cross platform GUI library like QT would be nice, but is not neccessary. So what is “the one” to choose? Can we assume that our MS VC++ IDE with MFC will be supported for the next decades, or is it more intelligent to choose something different? Does MFC even work with Vista/Aero?

I guess this is an important topic for all designers of applications like CAD software and things like that. So what are the right tools to choose?

Thanks and regards,
Jan

why is c++ outdated? just because there is something newer (java)? personally, i would always prefer c++ before java (although i have to admit that i haven’t done so much java yet)- because i can do anything i want with c/c++. i will go on in c++ until there is a new language which allows me to do something that i cannot do in c++. but actually i think there are things in c/c++ that you cannot do in java.

a plus for java is the platform independence. but if you use qt with c++, it is independent too.

i use c/c++ and motif in my apps too, but i have also thought about switching to qt. it seems to have more (and nicer) widgets. one thing you could be worried about is that qt is controlled by a company, not by a community. and i think you have to pay a fee to them if you use qt in a commercial product.

The last point is in fact important, you have to pay for it… MFC comes with VC++.

C++ is “out” (or at least, there is such a tendency) because a) it is not very clean in terms of design, and b) the model of “compiling to native code which runs on one specific platform” is out, too. Bytecode and virtual machines are “in”.

Some years ago, c++ was THE ONE language for windows apps, but this is not the case any longer, it is more and more replaced by C#/.net. Of course I agree that “c++ is a good programming langauge and I would choose it as long as I can do anything with it that I want to”, but that is not the point in my decision. Someone is paying money for my work (even if not much ), so there has to be choosen something which will definitely last in the future, which I am not sure about with C++/MFC.

But I guess if the GUI code and app code are cleanly separated from each other by clean OO design, it is not too much work to repace MFC and motif with another GUI lib which is yet to come.

agreed, virtual machines are a nice concept. but i don’t think compiling to native machine code is really out. i am not so familiar with VMs, but i guess that native code will always have a better performance. it can use cpu registers, cpu extensions like mmx, sse etc.

concerning the gui independence- all the gui stuff is probably less than 10% of the total source code, so it should not really be a problem to do something like

void CreateWindow(

#ifdef LINUX
XCreateWindow(…)
#else
// whatever windows needs
#endif
}

for the few hundred lines which are concerned.

I don’t use QT because of the licensing problems mentioned above. My choice is wxWindows - it’s open source.

As for comparing C++, C# and Java I think it’s just a matter of programming practices you prefer. My choice is C++ because of many optimization opportunities.
Pointers - some say then can cause a lot of trouble. I say that it’s not true if you just follow few simple rules. In my framework and game I had no single bug caused by using pointers.
Of course if someone is running larger company then you simply can’t trust that every single one of your programmers will make no exceptions in following these rules.
So I guess C++ is good for individuals and small companies while C# and Java may be more suitable for larger ones.

Basically, if you want more flexibility and faster developement times, use .net or java. If performance is very important, use C++. Java applications run at about 80% speed of C++ in average but can be much faster in some scenarious.

@RigidBody: I believe that VMs have more potential then the native code. The VM code be compiled at runtime, using all features of the current machine. It can automatically group objects in the memory based on usage patterns, resulting in better cache behaviour. It can perform massive inlining with all possible optimizations. Actually, vector by matrix multiplication in java 6 was faster then my hand-written SSE2 code!

The reason why java is still slower is the complicated programming model. They have no stack storage, everythign is in heap, everything is an object, each method is virtual, methods are generally very small. Java compiled to native code by GCJ is at least 2 times slower then java run by JVM. Still, if microsoft would deliver as good JIT compiler as SUN did, .NET applications would be on par or faster then the native code.

The point is not what one prefers, what is better, what is faster, etc., but simply what has more future. It is pointless to port the code to something we will not be able to buy compilers for in 3 years, and so will not run on the OS versions we will have then. And C++ and MFC is very old.

People like us who are writing realtime performance-critical stand alone applications are a decreasing species… everyone is writing web service applications with java enterprie editions (me too). So the design of programming languages and development tools is more and more turning towards that, what we are doing is becoming more and more exotic. As an example “gui library”: The most common GUI lib today are HTML forms.

I am very sure that C++ will have a long lasting future, simply because of the large amounts of C++ code existing. With MFC I am not so sure (I am not really sure if it is still supported by MS anymore, but I guess it is). As the code already exists and is in C++, this will not be changed.

In terms of GUI, I now am sure that the best choice is to do a clean OO design which makes it possible to change the GUI library without much work. The #ifdef-example given by RigidBody (thanks anyway) is a good example of the things that are “out”: This is NOT clean OO design. You rather would use the abstract factory design pattern to do it. Simply the fact that C++ allows such things makes it “out”. You can write terribly designed software with C++. Of cours you can do this with java as well, but the cleaner design at least makes it more probable that better design comes out (and at least, you have to UNDERSTAND OO completely to use java).

But VM code being faster than native code sounds like a miracle (or like lousy compilers). But i agree that the newer java versions are very fast.

Originally posted by JanHH:
In terms of GUI, I now am sure that the best choice is to do a clean OO design which makes it possible to change the GUI library without much work. The #ifdef-example given by RigidBody (thanks anyway) is a good example of the things that are “out”: This is NOT clean OO design. You rather would use the abstract factory design pattern to do it. Simply the fact that C++ allows such things makes it “out”. You can write terribly designed software with C++.
using #ifdef allows me to compile an app for linux/unix and for windows with just changing a single line. i don’t see what’s not “clean” in that approach, maybe it would help if could give an example of “clean oo design”. i’m never too old to learn.

btw: you can write terribly designed software with any programming language. it depends on your experience and how much you know what the user needs.

talking about the future…jup, java will have a bright future- we’ve been told that for 10 years or so. but how come that most of the applications everybody use are not programmed in java? maybe i’m the wrong guy to talk about future anyway…i don’t even understand the term “buy” in conjunction with “compiler”…

Another aspect is your history.
I started with turbo basic, switched then to turbo pascal and next step was MSVC C++ and now I am using Qt with MSVC 2003 and SUN-Studio.
Rendering I did manual (Basic/Pascal) then with MFC (first GDI then OpenGL) and now with Qt.

All “steps” give me more productivity and flexibility.

In terms of variability, performance and platform independance I can only choose Qt.
My Experience with Java are to small, and the problem with Java I see is the bad performance in history. So many tools so terrible slow, this is allways in my head and not easy to remove (especially when you have to work with such tools daily).
Some years ago, I run into some trouble running a javeprogram on windows, linux and solaris, so I tried qt and it really runs fine from the first day on all my platforms.
.Net makes its way, and there are good wrapper for linux, but at my work, there is also solaris and so .Net is not my friend :rolleyes: .

Being a team member on a big software development, you havn’t always the time to make the perfect design. This is bad, and many hacks will be a pain in the future, but you have milestones and ready to release dates to reach, and a language like c++ may help you in such situation. (To say it clearly: Its really NOT nice, but sometimes you may have no choice.)

Qt (in my point of view) is a fantastic gui and now (4.x) also nongui-API. At my work, I need explicit platform independence (especially on exotic sun sparcs).

Qt may be a little bit costly, but you only need a development license (very company friendly). There are NO runtime license (except embedded systems I think…). Don’t forget, you have the complete source code, this may be a key/killer feature!!!

A lot of other nice guis need’s cheep runtime license, but the handling of these license can be hard and painfull (especially harddrive boundings on laptops).

RigidBody:

AbstractFactory:

you define a class (this is java-like code)

abstract class MyOpenGLGUI
{
public abstract void createWindow(…);
}

another class for Windos:

class MFCGUI extends AbstractGUI
{
public void createWindow(…);
}

and one for linux:

class MotifGUI extends AbstractGUI
{
public void createWindow(…);
}

the OpenGL App has the GUI stuff in an Object of type MyOpenGLGUI:

MyOpenGLGUI myGUI;

to create a Window, it calls
myGui.createWindow(…);

it does NOT have to know wether this object is a MFCGUI object or a MotifGUI object. It is created at startup:

if(windows)
myGui=new MFCGUI();
else if(linux)
myGui=new MotifGUI();

if you need Mac, simple create a class MacGUI which extends MyOpenGLGUI and use that instead. You still can change the OS with changing a single line of sourcecode, but this approach is “the way” this is usually done, if clean design is desired.

My most thrilling experience with that was creating an abstract GUI lib for java which allows you to switch between Swing and AWT.

“but how come that most of the applications everybody use are not programmed in java?”

this is not true - most new applications ARE written in java, in the shape of java enterprise web service applications. This is the way things go at the moment. New stand-alone-applications like office stuff is more and more implemented in .net/c#. C++ is rather an unlikely choice if an application is completely new written.

sorry, but i still see no advantage. maybe my example implied to use #ifdef for each system dependent command- but actually one is enough:

#ifdef linux

void CreateWindow() {
…
}

void DestroyWindow() {
…
}

void ResizeWindow() {
…
}
#else
…
#endif

and- there may be kinds of applications which can be made easily with java and therefore are programmed in java. but apparently that is stuff which i do not use, neither at work (automotive engineering) nor at home. i’m also almost sure that my computer is free of .net and c# apps.

JanHH: I agree with the idea of preferring clean oo code, but I think the example you presented is ok for Java but not for C++.
What I mean is this piece of code:

if(windows)
myGui=new MFCGUI();
else if(linux)
myGui=new MotifGUI();

That means you compile for all platforms and select proper platform at runtime? Somewhow I don’t believe it’s gonna work with any C++ compiler

I’d rather use factory method and class factory for other purposes than platform independency.

My proposal is more less what you can find with wxWindows. You simply do not put code for different platforms in one file. The example above would look like this:

// File: openglgui.h
class MyOpenGLGUI
{
  protected:
    std:string windowName;
  public:
    void CreateWindow(...);
    std::string GetWindowName(void);
}

// File: generic/openglgui.cpp
std::string MyOpenGLGUI::GetWindowName(void) {...}

// File: windows/openglgui.cpp
void MyOpenGLGUI::CreateWindow(...) {...}

// File: motif/openglgui.cpp
void MyOpenGLGUI::CreateWindow(...) {...}

Now you only use different makefile or project settings for different platforms. So it’s either:
openglgui.h, generic/openglgui.cpp, windows/openglgui.cpp
or:
openglgui.h, generic/openglgui.cpp, motif/openglgui.cpp

Note that all your .h files are platform independent so if you need some platform dependent member (like HWND) then you should put only interface in this .h file.

My code was just an example of this pattern, of course it will not compile. Probably using #ifdef for creating the GUI object is more suitable.

#ifdef windows
myGui=new MFCGUI();
#endif
#ifdex linux
myGui=new MotifGUI();
#endif

and so on. If it were java, you could in fact decide which platform it runs on at runtime (the call to “new MotifGUI()” would simply not be executed on a windows platform, and so, no error occurs. It would compile).

The difference in the solution with different source files is that all methods seem to be class methods (static), in my example, the GUI stuff is in an object.

But I did not intend to start a discussion on the advantages of design patterns.

The difference in the solution with different source files is that all methods seem to be class methods (static), in my example, the GUI stuff is in an object.
There is no such difference. In my version you call:

myGui = new MyOpenGLGUI();

So it’s the same but instead of if/#ifdef I just use different makefile. Well it could also be done automatically with #ifdef around #include.

Well, changing to:

#ifdef windows
myGui=new MFCGUI();
#endif
#ifdex linux
myGui=new MotifGUI();
#endif

Won’t help alot in C++. Simply, when you compile under Windows you don’t want the compiler to even process motif realted files. After some experiences one would eventually come ip with his “ultimate” solution and it’s very likely it’s gonna be the one used in wxWindows.

As I said - your approach (runtime selection) seems best for any language that runs on top of virtual machine.
What I proopsed seems better for C++.
The goal is the same - to remove all if/#ifdef from the code and leave just one place where you choose proper implementation either at runtime or at compile time.