[Qt-interest] Is Qt the best choice for cross-platform desktop GUI applications? Mac OS X (Cocoa, Aqua)? KDE, GNOME, Windows 7

[Nikos Chantziaras]

Today I took the time and uninstalled the 32-bit Carbon version of Qt, 
and then replaced it with the 64-bit Cocoa one.  All font problems went 
away just like that.  I didn't know that there's this big of a 
difference.  Since Carbon will be deprecated in the next Qt version, I 
guess this isn't worth reporting.

All I can say is that if you're using Carbon Qt, it's worth replacing it 
with the Cocoa version.  I wish someone had told me sooner :P


On 04/15/2010 01:54 PM, nobodyhere wrote:
> Excellent example (with both native and Qt using the same font - yet they still look very different).  I see how the paragraph in the Qt example is vertically shorter by an entire line of text.  And how the font is noticeably different when you juxtapose the two.  For example, the word "solid" for Qt looks more like "so lid" (with a space).
>
> I wonder if Qt knows about this.  I think for any bugs, including Mac OS X UI bugs, we should report them and/or check if they are already reported?
>
> http://qt.nokia.com/doc/4.6/bughowto.html
>
>
>
> ----- Original Message -----
> From: "Nikos Chantziaras"<realnc at arcor.de>
> To: qt-interest at trolltech.com
> Sent: Wednesday, April 14, 2010 8:56:38 AM GMT -06:00 US/Canada Central
> Subject: Re: [Qt-interest] Is Qt the best choice for cross-platform desktop GUI applications? Mac OS X (Cocoa, Aqua)? KDE, GNOME, Windows 7
>
> Here is a screenshot (attached) of the same text rendered with a native
> Cocoa application (top) and my Qt application (bottom), both using the
> Helvetica font at 16pt.  Notice the wrong spaces between character in
> the Qt app, for example in the words "lost", "permeated", and many
> others.  In the native app, the characters are evenly spaced, while in
> Qt they are not.
>
> On 04/14/2010 01:10 AM, nobodyhere wrote:
>> The screen shots are xcode, text wrangler, qt's sdi example.
>>
>> Are you saying that (xcode and text wrangler) font is correct, while (qt's sdi example) is somehow incorrect?
>>
>> ----- Original Message -----
>> From: "nobodyhere"<pem.accounts.spam at gmail.com>
>> To: "Jason H"<scorp1us at yahoo.com>
>> Cc: "Nikos Chantziaras"<realnc at arcor.de>, qt-interest at trolltech.com
>> Sent: Tuesday, April 13, 2010 5:05:13 PM GMT -06:00 US/Canada Central
>> Subject: Re: [Qt-interest] Is Qt the best choice for cross-platform desktop GUI applications? Mac OS X (Cocoa, Aqua)? KDE, GNOME, Windows 7
>>
>> I'm not sure what you mean?  I don't use email lists enough to know if they usually block attachments, so I'll try screen shots in the next email.
>>
>> ----- Original Message -----
>> From: "Jason H"<scorp1us at yahoo.com>
>> To: "Nikos Chantziaras"<realnc at arcor.de>, qt-interest at trolltech.com
>> Sent: Tuesday, April 13, 2010 2:50:56 PM GMT -06:00 US/Canada Central
>> Subject: Re: [Qt-interest] Is Qt the best choice for cross-platform desktop GUI applications? Mac OS X (Cocoa, Aqua)? KDE, GNOME, Windows 7
>>
>> Also, when printing letters run together. While this is a problem for rn (r n looks like m, in Arial) Qt will do it with 's' and 'e' in very inconsistent manner. Sometimes 's' and 'e' touch, sometimes they don't and that is true for the letter next to them as well. Sometimes "se" bleeds, and sometimes it doesn't. it makes it look really sloppy.
>>
>>
>>
>>
>>
>> ----- Original Message ----
>> From: Nikos Chantziaras<realnc at arcor.de>
>> To: qt-interest at trolltech.com
>> Sent: Tue, April 13, 2010 2:40:46 PM
>> Subject: Re: [Qt-interest] Is Qt the best choice for cross-platform desktop GUI applications? Mac OS X (Cocoa, Aqua)? KDE, GNOME, Windows 7
>>
>> On 04/13/2010 08:45 AM, nobodyhere wrote:
>>> Okay, so I actually tried out two Qt Creator sample projects on Mac OS X.  I don't know what you mean about this alleged font rendering problem...  The font looks correct to me.
>>
>> Don't you see broken kerning?  For example, when displaying the string
>> "Yo", the "o" should be under the "Y", but it isn't.  In text oriented
>> apps (where the focus is on actually reading text), this makes the
>> application look lame.