[Qt-interest] Are there any disadvantages with OT

[BRM]

----- Original Message ----

> From: Scott Aron Bloom <Scott.Bloom at sabgroup.com>
> To: qt-interest at trolltech.com
> Sent: Fri, February 26, 2010 11:38:45 AM
> Subject: Re: [Qt-interest] Are there any disadvantages with OT
> > Daniel Price wrote:
> > > And it's based on a REAL compiled language not some slow Java-ripoff
> > that requires a runtime download and that's designed specifically to
> > lock you into one platform.
> > Actually, by design, C# is cross-platform, just like Qt.  In practice,
> > however, only Microsoft seems to be fully supporting it at a
> production
> > level.
> Microsoft is ideologically opposed to anything that runs on platforms
> other than what they control.

True. Microsoft also severely limits Mono, especially since while the Mono guys can develop the 'standard', most of .Net is hidden away in stuff Microsoft added that is not part of the standard, e.g. Windows Forms.
So there never will be cross-platform compatibility unless Microsoft wants to make it so.

Interestingly enough, Microsoft has their own in-house Linux native version of .Net outside of Mono. Personally, I think it's their backup plan should they ever have to consider supporting non-Windows platforms for products like Office, should they say lose their dominant position in the Desktop market (which will eventually happen, and looks like the cogs are starting to turn to make it happen; but we're still a long ways off).
 
> >
> > (No, I do not program in C#, and actually don't care for "managed" code
> > like C# or Java.  Just clarifying a fact. :)
> That's silly.  Never heard of Silverlight? Runs on Win/Mac/Linux and
> Mobile.
<snip>
> But in the .Net framework, you can code in C#, C++, or Vb if you 
want,
> get exactly the same Ui, for both desktop, win mobile AND 
the web.

Silverlight doesn't run under Mono. You have to get Moonlight for that. Even then, you don't have the full implementation that Microsoft provides in Silverlight.
So they are not quite the same.

> Unlike Qt, MS has invested in making their language of choice, your
> choice.. Look Im not blaming TT/Nokia, I love Qt...

Simply put, .Net was Microsoft's response to Java after the courts told them they couldn't Embrace & Extend Java; likewise, Silverlight is their response to Flash, this time without the court battle.
In both cases they want to lock people on Windows, and their non-Windows versions (e.g. Mono and the Mac version) are only supported enough to make it seem like they are being cross-platform and trying to be friendly with competitors.
They'll yank the plug as soon as they can, given a chance to do so.
 
> As has been said, in my view, Qt's biggest limitation is its lack of web
> application/service/page deployment.

I've been using Qt for about a year now. And it's hard to find any real disadvantages. It's one of the best platforms I've ever come across, and makes cross-platform development a breeze.
That said:

- I do have to agree that pimpl is way over-used. It also tends to break debuggers - including Visual Studios - and make it hard to debug even under GDB. For example, QString values are not shown directly under Visual Studios debugger - you have to go down several levels and search for a little bit. (Yes, I'm using the VS Add-in.) In GDB, I had to write my own user-defined functions, b/c otherwise you just get a the d pointer value. So now that's one more thing I have to remember - can't do p <qstring>, I have to use my p_qstring <qstring>. I haven't yet written one for the QByteArray or QList, or any number of others - so it's a little harder to get the data in debug mode without going back to qDebug() or something similar in the program.

- Some will complain that 'moc' is a disadvantage b/c its one more tool you have to use. But it more than makes up for that fact once you start using it.
- Some may complain about 'qmake' as well, but it's very much on par with most build systems, and in some respects far exceeds them. CMake is really the only fair comparison to Qmake b/c nothing else is quite as flexible; though CMake can make use of Qmake too....so if you're really comparing them, then you could just use CMake to start with. Probably my only real complaint about qmake is the lack of documentation for doing more advanced things; there's some documentation there but you really need a book and a lot of examples to really be able to take advantage of it; it seems to be mostly designed around listing headers and implementation files, and choosing a predefined template. For example, I'd really like to do some recursive projects - e.g. define a static library, and in the using application just include a file into its Qmake pro file. Sure there are ways, but it's not clearly documented on how to do it.

Really, that's about it. I've done Windows programming for quite a while, and have done Qt for about a year. In that time, I've done a number of things in Qt in short order (1-3 days) that would have taken months to do in MFC or Win32.

Ben