Why QT3?

[ericjs]

Just out of curiousity, why QT3, and not QT5 or at least QT4?

Is QT only used for the linux solution? If so, I can understand why you might be reluctant to invest the time to upgrade your code, except that in that case it could be an even bigger win because you could use QT to build all your platforms versions instead of maintaining 3 flavors of UI code.

[David]

QT3 is not by choice. Our code base is in Delphi Pascal which is mainly supported on windows. Years ago they provided the Kylix compiler and run time library to allow Delphi apps (with some adjustments) to be compiled and run on Linux. This is QT3 based and has not been updated since QT3 was fresh.

There are some possible alternatives appearing that we are examining that would allow us to get away from Kylix and QT3. However we are a small company with limited resources and have been putting our current effort into upgrades for windows and doing a port to OSX. Once we get that behind us then we will be looking to spend time on Linux.

The compiler / real time library issue actually affects all 3 platforms (Windows, OSX, Linux) to some extent and we would like to move to something that provided easier cross-platform support. Our main developer (there are 3 of us) has spent lots of time looking at options and unfortunately he has not found an obvious path yet that fits all the constraints we are dealing with. It could be freepascal / lazarus / QT for OSX and Linux. If Embarcadero gets it together it could be Delphi for all platforms (doesn't seem to be happening). Or we might decide to move to something like C# (major rewrite of the whole code base). Tough questions for us.

Meanwhile I apologize for QT3. As the developer tasked with the Linux port I am not a fan either and will be very glad to get moving on making a change.

[jezzer]

we might decide to move to something like C# (major rewrite of the whole code base).

Really hope you don't go the C# route - slow startup being one of the main issues.

[kohenkatz]

slow startup being one of the main issues.

With the new Roslyn compiler, this is nowhere near as big of an issue anymore.

More importantly though, GUI toolkit support for cross-platform development is still pretty lacking, except for GTK# (which still has problems on Mac).

[Zoë]

Cross-platform GUI toolkits have been one of the major sticking points. Delphi has hardly been idea for that, but with it, Kylix, and Lazarus we've been able to target Windows, OS X, and Linux with a single codebase, a very small development team, and reasonably native UIs. Qt seems best from a toolkit standpoint, but C# would be easier to train everybody into and would have fewer language gotchas to deal with.

[ericjs]

Oh...I feel your pain.

I don't blame you for wanting to avoid moving to C++, though I understand QT's framework is rather more than just a GUI framework and has a lot of stuff to ease some of the hardships of C++. (I don't speak from experience, though. The last time I worked in C++ was many many years ago when my previous language was, believe it or not, Delphi.)

There are also Python bindings for QT.

Also I would think you should be able to keep backend code in Delphi and link compiled object modules with QT-based GUI code which should be a lot more QML and framework than straight up C++, no?

[ericjs]

I can't believe I failed to plug the language I mostly work in, Java. (Probably because I haven't worked on Desktop apps for years.) It's actually a decent choice for desktop apps these days, and I'm speaking as the happy user of several Java-based desktop apps. From a Linux standpoint, it makes it painless even if your distro doesn't have a package for it, you just download it and it works.

The biggest uncertainty there is probably what GUI framework to use. I'd recommend you take a look at Apache Pivot.

[Aaron]

Thanks for the pointers. We're still early in this process, but we'll investigate these as options.

[jezzer]

With the new Roslyn compiler, this is nowhere near as big of an issue anymore.

Don't know much about C#, but had a quick look at Roslyn compiler and it seems to be more related to compilation rather than the runtime. Given this would the new Roslyn compiler really affect/improve startup performance ?

Re. Java, not really a fan of that either for desktop apps - also quite slow on startup.

Modern C++ with all the extra libraries makes programming in C++ much easier than it used to be. Combined with something like QT would probably be my preference, with the added side-effect that performance would also likely be improved a bit.

[Zoë]

.NET does have NGEN, which can pre-JIT everything and I know there's at least one commercial static linker out there, both of which would probably help with startup performance, but yes, that is a concern, especially for an app like BC that can be launched dozens of times a day.

One thing I really liked when I was using Java, and which would apply to .NET but not Delphi or C++ as much, was all the extra tooling that was available because of the RTTI and easily extensible compilers. Thinks like aspect oriented programming and the memory tracker being able to tell you the type for every allocated block.

Honestly though, the thing that makes me the most leery of C++ is just how complicated the language can be. I knew it was hairy previously, but Raymond Chen's recent blog post on post-classical compilers and undefined behavior introduced a whole new world of hurt I didn't even realize was possible.