BC3 not respecting QT settings

[MyXelf]

Hi:

First of all BC is a great application. Congrats on such a wonderful work.

I'm using Linux (Kubuntu Natty Narwhal, 64 bits), and no matter which QT3 style I choose in the qtconfig-qt3 configuration tool, BC defaults to the 'Platinum' style. I tried Polymer, Keramic, Plastik (from kdelibs4c2a), to no avail.

Doing some 'strace' on BCompare binary, I'm able to see the application looking for the polymer.so file and founding it. But the UI remains the same despite the style I choose.

I could provide more information, or do more testing if necessary

Best Regards

MyXelf

[Chris]

Thank you for reporting the problem. We've tested BC 3.2.4 in Gnome with Ubuntu Natty Narwhal (11.04), but we haven't tested Kubuntu yet. I'll setup a test system and let you know what we find out.

[MyXelf]

Good to hear that. Please let me know anything you may need. I'm going to report another issue related to KDE and the dark color schemes.

Thanks a lot!

MyXelf

[MyXelf]

Any progress on this?

Thanks

MyXelf

[Chris]

I talked to our Linux developer David about this.

It's possible your system has a newer version of the QT3 theming libraries than Beyond Compare was built with. BC will try to load themes, but if the versions don't match it will fall back to the Platinum theme included with the BC install.

There isn't a workaround for this issue.

[LovesTha]

Wouldn't a valid work around be to install that version of the library locally? If you could tell us the library version you link against that would be nice.

It is disappointing to see that you have made your Linux port be hard to integrate into a Linux environment. It is really jarring to have applications bucking the theme of a system and I find it quite distracting.

[David]

We do install a local library with the BC Install. This is the theme that BC falls back to if the Linux distro has a non-compatible QT library. Unfortunately all newer Linux distro's will have non-compatible QT as we are currently stuck at QT3.

Our product is built with Delphi Pascal. Several years ago a Linux compiler and libraries (Called CLX) were issued by Delphi that allowed cross-porting to Linux. The libraries relied on QT3. BC was ported at that time. Since then Delphi has ceased to support CLX and has not provided a replacement Linux tool yet.

We wish to update the Linux product and have looked at FreePascal/Lazarus as a possibility. Delphi/Embarcadero is also coming out with a new environment to replace VCL that would be cross-platform. Neither of these options is quite ready for us and when they are it will take awhile to modify our source to work with the new libraries (Beyond Compare has a large source base).

I apologize that for now we are stuck with QT3 and not very pleasing theming.

David

[graemeg]

Hi David,

As you might note for the rest of this message, I am a software developer too. I must say, I am very impressed to hear that you guys still use Kylix 3 (considering how long ago it was canned). I guess you must be using a old Linux distro too, to get the Kylix IDE to run. :-) Is BC3 using QT3 (or CLX) under both Linux and Windows platforms, or do you use VCL under Windows and CLX / QT3 under Linux?

As for your comment about Free Pascal / Lazarus not being quite ready. Could you ellaborate on this. What is not ready? The Free Pascal compiler or the Lazarus LCL or both? I contribute to both projects from time to time, so if there is something critically missing, maybe we can make a plan to implement that functionality.

Also, Lazarus LCL uses the Qt4 bindings to Object Pascal - which is a independent project from Lazarus. I know there was a major changes between Qt3 and Qt4, so I guess the upgrade path is not as simple as one would hope for. Here are two URL to information about it.

http://wiki.freepascal.org/Qt4_binding
http://users.telenet.be/Jan.Van.hijf...pc/fpcqt4.html

I'm not sure what GUI toolkits you use under Linux and Windows for BC3, but if the problem is purely the GUI toolkit, and not the compiler (eg: FPC), there might be another alternative too, the fpGUI Toolkit. It's a cross-platform GUI toolkit which does 100% custom painting (thus no large 3rd party libraries are required for deployment), is similar to the VCL or CLX so is easy to learn (but wasn't meant to be a clone like Lazarus LCL), comes with plenty of examples and applications (GUI Form Designer, Documentation Viewer etc), is free and open source, and has been used in commercial desktop applications for over 3 years.

As for the cross-platform toolkit (FireMonkey) released in Embarcadero's Delphi XE2 product... Well, it doesn't support Linux yet, is missing a lot of critical functionality at the moment, and not sure how well it is suited for desktop applications - it looks more like a mobile devices toolkit (iPhone, iPad, Android etc).

Graeme.

[Aaron]

Hey Graeme,

Thank for the very detailed reply. Would you be able to email us at [email protected] with a link back to this forum thread, and I'll be sure to pass this along.

[Zoë]

Hi Graeme,

David wants to go over specifics via email (hence Aaron's post), but I can cover the general questions here.

BC3 for Windows uses the VCL and is compiled using Delphi 2007, with the TNT controls for Unicode support. The Linux version is compiled using Kylix 3 with Andreas Hausladen's Qt3 updates. We have our own wrappers over the top of both, so we actually compile both platforms from the same DFMs, without any pre-processing or conversions. All of the design-time work is done in Windows. We have Kylix running in a SuSE 10 VM (circa 2005), but, since we don't need design-time support, it's really just an editor and debugger.

Right now we're only looking at switching compilers/widget sets for the Mac build. Aside from theming, the Linux build works, and updating it would just take resources away from the Mac version. Once the Mac build's released I'm sure we'll update the Linux build to use the same backend.

As for Windows, I can't see replacing the VCL anytime soon. Delphi's IDE and debugger are much nicer than Lazarus, BC is a mature product, and we have a lot of custom controls and customizations to the standard controls. Porting it to anything else would require a ton of work get it to the same level of polish.

The biggest reason we wanted to stay with Delphi was so we could standardize on a single compiler, IDE, RTL, and, eventually, widget set. The current setup works, but it's not ideal.

I agree with your assessment on FireMonkey, and would further critize it for moving away from native controls. I understand why they did it, but I really don't like the headache of worrying about buggy 3D drivers, especially since, even with the GPU acceleration, it's still slower than the VCL. I have hope for it, but it definitely needs more time in the oven.