Qt 5.1 Adds Android and iOS Support

colinneagle writes "This week, the team at Digia rolled out the first alpha release of Qt 5.1, which is slated to have the first round of support for Android and iOS, with full support coming in 5.2. The goal is to make 5.1 completely usable for building complete, shippable apps for both mobile platforms. That means Qt can now be used to build native, smooth applications on Linux, Windows, Android, iOS, MacOS X and even BlackBerry 10, all with an excellent integrated development environment – QtCreator. Coming with version 5.1 is also something called 'Qt Quick Controls' — which is a set of nice, reusable user interface controls. Currently, it is focused on Desktop applications, but is expanding to add touchscreen-specific features. And, importantly, this release also brings 'Qt Sensors' into play. 'Qt Sensors' are pretty much exactly what they sound like — access to hardware sensors on devices where they are available, with built-in motion gesture recognition. Definitely a big plus for Android and iOS applications."

Comments

Not native

[Anonymous Coward]

There is nothing native about a Qt app. You can spot one a mile away cause they stand out like a sore thumb.

Re:Not native

[Anonymous Coward]

Really? How? Without looking to see if they come distro'd with Qt*.dll that is.

Re:Not native

[vivek7006]

WTF are you talking? Qt use the native style APIs of the different platforms to query metrics and draw most controls. On some platforms (such as MeeGo and KDE) Qt is the native API.

Re:Not native

[Anonymous Coward]

Are you sure you aren't confusing QT with GTK?

Re:Not native

[Anonymous Coward]

Native App
Qt App
There are huge differences. Qt doesn't do tool bars correctly. The text isn't aligned correctly in the ring menu. It uses a non-native widget to resize the tool bar. The icons look all out of place, doesn't used the native platform standard icon for the printing.

Re:Not native

[robmv]

Native controls means more than to have the same look, if that is the way to measure "nativeness", then Java Swing UIs (Windows/GTK L&F) are native because they call platform theme APIs.

When a toolkit draw controls by itself, the applications normally lose a lot of UI functionality, for example, if Android/iPhone controls add proper default assistive technology metadata to their controls, the toolkit (QT in this example) need to do the same for each control they draw, because the OS don't see buttons as buttons, It see them as a custom control. If the platform control change behaviour in a new OS release, the QT control will not see it, for example when Windows added default context menus to the text fields, self drawed controls don't expose that behaviour until applications are updated with a new version

Re:Not native

[interval1066]

Intertesting, in some apps the only way I was able to tell it was a Qt app was by noting the "About Qt" help menu item. You must be looking at ancient versions of the Qt libs. Or something. Qt is really slick these days.

Re:Not native

[Anonymous Coward]

Here
You can tell this is in Qt because the text on "Button 1" and "Button 2" aren't centered in the button correctly. The icons in the tool bar don't follow cocoa conventions and look out of place.

Re:Not native

[interval1066]

Qt doesn't do tool bars correctly.

Yes, it does. Love your narrow test case of OSX, which I have used briefly and not in this context, and don't anticipate using again unless prodded. Try looking at Qt on Windows, Gnome, or KDE, guy.

Re:Not native

[Anonymous Coward]

The fact is the Qt isn't using the correct widgets for the tool bar on Mac OS X.

Try looking at Qt on Windows, Gnome, or KDE, guy.

Why the hell would I care about how it looks on platforms I don't use?

Re:Not native

[doti]

^ the only informative and correct comment in this thread.

Re:Not native

[FooBarWidget]

Unfortunately - on platforms where Qt isn't the native UI already - Qt just emulates (draws) the native UI, it doesn't actually use the native UI controls.

On Windows, Qt does a very good job of emulating the native UI. But then again I'd argue that Windows has few truly native UIs. You always notice small differences in how controls behave between different apps. I guess all the different versions of MFC, WPF, VCL, WinForms and whatever implement controls slightly differently from what the Win32 API offers and even between different versions of itself. But users are used to these inconsistencies, so no big deal.

On OS X, the situation is unfortunately a lot worse, probably because Cocoa is so different from everything else that it's hard to emulate properly using primitives from other toolkits. For example you can notice that Qt draws the focus border around buttons differently than Cocoa does. The biggest difference being that Qt buttons are focusable but Cocoa buttons are not. Toolbars also look different: in Cocoa they blend in with the window title bar. Qt doesn't do this - the toolbars look very much Windows-like. The border spacings and alignment are also off. Developers often don't take time to align and space all the controls properly to give them a Cocoa look.

Re:Not native

[Anonymous Coward]

I guess Apple just needs to catch up so we can have standardized UIs.

Re:Not native

[gmhowell]

Qt doesn't do tool bars correctly.

Yes, it does. Love your narrow test case of OSX, which I have used briefly and not in this context, and don't anticipate using again unless prodded. Try looking at Qt on Windows, Gnome, or KDE, guy.

I tried, but the blood in my eyes made it hard to evaluate after a few seconds.

Re:Not native

[interval1066]

Exactly.

Re:Not native

[Mr. McGibby]

A particular developer's inability to use Qt properly to create native-looking apps on each platform, that's hardly Qt's fault. You can get the native printing icon if that's what you want, but this developer clearly didn't bother to do it properly. Creating cross-platform apps isn't magic. That's what Java wanted to do, but it's just plain impossible. You are going to have to occasionally be aware of the quirks on each platform you're targeting. An occasional #ifdef OSX or whatever is going to be necessary if you want your app to look great. Qt doesn't purport to allow you to write your code on one platform and magically having it look fantastic on all the other platforms. It *does* purport to allow you do that by spending a little time to tweak things. Nothing you mentioned isn't fixable using Qt. But it can't do everything for you because the platforms are different, by definition.

Re:Not native

[am 2k]

For example you can notice that Qt draws the focus border around buttons differently than Cocoa does. The biggest difference being that Qt buttons are focusable but Cocoa buttons are not.

Actually, that's a user preferences setting (I keep it turned on all of the time, since I want to use the keyboard as much as possible). Unfortunately, this setting is ignored by Qt.

Re:Not native

[Anonymous Coward]

There's a history behind this going back to the 1980s, when UNIX vendors decided to adopt the IBM/Microsoft "common user access" spec.

Since then, *nix interfaces have always been very similar to MS Windows, although they've adopted some Mac conventions in the last couple years.

Re:Not native

[tibit]

The problem with a lot of native controls is that they are hopelessly limited in what they can do. For example, on Windows the classic controls can't really be used outside of a classic application - not without a huge amount of kludgery. When you get to modern UIs on Windows, you get WPF and that doesn't reuse any native control code AFAIK. It just re-implements everything and the kitchen sink -- just like Qt does (correct me if I'm wrong, please).

With Qt, you can rather trivially render the controls offscreen, generate mock events for them, etc, all in a cross-platform way. With native controls, you're pretty much stuck with whatever functionality is there and there's no way to use them any other way. If the platform doesn't provide a blended rendering model for the UI, you can't get that functionality using native controls. If the platform doesn't provide for an easy way to decouple the controls from a physical screen under control of the OS apis, you can't use them on custom LCD screen attached via USB (a screen otherwise invisible to the OS as a screen).

Yes, it would be possible for Qt to do more to cleanly run native controls behind the scenes so that "arbitrary" changes in behavior would propagate. This would most likely be way too much work for the limited benefit it provides. It may well be that whatever services the OS provides behind native controls can be rather simply reproduced in Qt proper. Yes, it requires tracking the platform you claim to support :)

Re:Not native

[tyrione]

Qt doesn't do tool bars correctly.

Yes, it does. Love your narrow test case of OSX, which I have used briefly and not in this context, and don't anticipate using again unless prodded. Try looking at Qt on Windows, Gnome, or KDE, guy.

The guy is right, you are wrong. Native is Cocoa, end of story. In order for iWorks to be native in GNOME it would have its interfaces rewritten in GTK+ with C/C++ and not C/ObjC, and not leveraging AppKit and Foundation Kit. None of these GTK+ and Qt for OS X are remotely first class, native solutions. At best they are newer versions of Carbon. They expose as little as humanly possible to the dynamic runtimes required in OS X and call themselves native.

Re:Not native

[Anonymous Coward]

So what is your definition of 'native' applications then?

Re:Not native

[TrollstonButtersbean]

The OS X support for Qt is quite rubbish. Including that I know no one that can successfully compile Qt in a current version of XCode, nor have ever seen any working instructions for doing it.

Re:Not native

[Anonymous Coward]

There is no language called C/C++. Either way, whatever you are rewriting, language itself does not matter as long as it can produce native binaries.

Re:Not native

[BlueLightning]

Have you (or someone else) filed a bug about this?

Re:Not native

[sproketboy]

That's what Java *does*. FTFY.

Re:Not native

[macson_g]

This is a screenshot from experimental desktop UI components for QtQuick, not Qt widgets.

Re:Not native

[Stele]

You don't compile Qt in Xcode. You use the build scripts, just like you do on Windows and Linux.

You can build Qt *applications* in Xcode. I do it all the time.

Re:Not native

[Anonymous Coward]

because OSX is not like the others because Apple makes life difficult for anybody who tries to create platform independent software.

Re:Not native

[hackula]

That's what Java *does* poorly. FTFY.

FTFY. Java apps look notoriously crappy and barely make an attempt at looking native to the platform. Qt may not be perfect, but it looks like the best attempt so far from where I sit. I have been using PySide which is a Qt Python wrapper. It could not be a whole lot easier, and looks pretty good on Windows, Ubuntu, and OSX. Cannot really ask for a lot more than that. No framework is going to make sure you are using the appropriate icons or whatever for each platform. No Java GUI framework nor Qt.

Re:Not native

[Anonymous Coward]

Native App
Qt App
There are huge differences. Qt doesn't do tool bars correctly. The text isn't aligned correctly in the ring menu. It uses a non-native widget to resize the tool bar. The icons look all out of place, doesn't used the native platform standard icon for the printing.

Actually most of the faults you mentioned in that example are are more to do with the program itself and not Qt. Qt does in fact do toolbars correctly on OS X (see the Qt documentation for specifics) but for some reason the TeXworks developers chose not to do it that way. Also, since icons are just loaded from image files there is no reason the OS X standard icons can't be used (I do agree that Tango icons look rather out of place there and I think some of them like the hand are even thr wrong resolution).

Re:Not native

[sproketboy]

It's all a matter of effort. See http://jshot.info/ for an example. And AVG is written in QT and is awful in Windows.

Re:Not native

[interval1066]

Being a hardware vendor can do that to you.

Re:Not native

[pherthyl]

>> Qt doesn't do tool bars correctly.

Wrong. Qt is perfectly capable of doing the integrated toolbar on Mac. Just because Texworks chose not to do it that way (because they wanted additional flexibility in the toolbars which a unified toolbar doesn't offer) doesn't mean Qt can't do it.

>> The icons look all out of place

Icons are 100% the responsibility of the software creator, not Qt. Clearly you don't understand how software works.

Re:Not native

[Anonymous Coward]

That doesn't seem to bother all of the people using MS Office and Adobe products, among other things.

Lots of great new stuff!

[simula]

Digia and the Qt Project has been exploding with great new work.

Qt 5.1 is adding initial support for Qt Quick Controls formerly "Desktop Components". These are packaged Qt Quick controls such as sliders and tables with skins for each of the different platforms.

The Qt Project has just recently started shipping the Qt Installer Framework which is a cross-platform installer framework (that is used by the Qt installers). After managing multiple installers on different platforms for my own open source work, I'm really looking forward to digging into this.

Another huge project is the new Qt Build System or qbs. This is a replacement for QMake and I'm really excited to see how it shapes up against CMake.

With the recent advancements in the C++ standard and Qt, it is a very exciting time to be a C++ developer.

Re:Lots of great new stuff!

[Anonymous Coward]

it is a very exciting time to be a C++ developer.

You now owe me a replacement keyboard and half a can of coke.

Re:Lots of great new stuff!

[iliketrash]

This is the best comment on this entire page. LOL.

Re:Lots of great new stuff!

[Anonymous Coward]

Only retards spit out drinks when they laugh.

Re:Lots of great new stuff!

[Anonymous Coward]

Well, if you are not fed up with "programmers", who do not know how to code in C++(but "know" .NET) and are not enlightened about standarts that come along with C/C++, then you can laugh. Rest of us - not only programmers, but users as well will have to cry every time we got into some trouble with bad coding, because user support in these cases do not really help, even if among them are shiny diamonds, who actually try to help... most of the times it is just embarasement :/

Qt in my humble opinion is one step away from MS practices of bad monopoly on PCs, because future is mobile phones. Nokia had Qt(MS at that time was driven out of mobile phone business, because with Qt who really needs Windows phones?) and it worked great - it was exiting time at that time as well, because I could run the same code(yes!) on Windows, Linux and Symbian phone and it worked great on all of them - I wasn't chained anymore to one device and one platform. And I could spill my coke on replacement keyboard and my mobile phone anytime I wanted... Geez - you need some variety in your life(also sex life if you have one) - that is exitement for most of us ;)

Re:Lots of great new stuff!

[Anonymous Coward]

I dunno, but it appears it more of a catch up. Cause it's about mobile UIs.

What these efforts are in a race is against Javascript/JQuery, JavaFx, Opera UI, HTML5, TouchWiz, Inflexion, and whatever Ubuntu comes up with (if not Qt),

Objective-C and Cocoa really hold the prize for on-board apps and UI since Apple was the 1st to successfully create a UI for the mobile world. Otherwise it was PalmOS, which could never use Qt.So if Qt wants to create a C++, heavy UI client application framework, they are playing catch up to Apple.

Re:Lots of great new stuff!

[loufoque]

The right approach to software development is to do one thing and do that thing well. Qt is becoming more and more bloated and duplicates a lot of other better and more specialized tools. It's shaping up to be a framework for everything, almost a variant of the programming language. And Qt still doesn't even use C++03 correctly, why do you expect it to make good use of C++11 or future standards?

Re:Lots of great new stuff!

[jma05]

> The right approach to software development is to do one thing and do that thing well.

There is no right approach. While that is the Unix philosophy, it does not suit every project's needs. Some projects like to have a most functionality to come from a single/few quality assuring source/vendor. This gives consistent quality, less updates to keep track of, consistent documentation, common interfaces across sub-components, one place to ask for help etc.

> Qt is becoming more and more bloated and duplicates a lot of other better and more specialized tools. It's shaping up to be a framework for everything

You can make the same arguments against most popular application (as opposed to system) programming languages. They all have, at varying degrees, wide reaching unified SDKs. Qt provides that aspect to C++ and many see that as an advantage. So yes, Qt moved from the GUI toolkit market space to a full stack C++ SDK market space. They now have a full suite, much like Java/.NET - complete with a modern IDE. Without it, C++ simply can't compete in this space... and IMO they should do a lot more to be a realistic alternative.

If all this does not appeal to you, you just aren't among the intended audience.

Re:Lots of great new stuff!

[hackula]

Good luck fending off the javascript hordes. Innovation in the js oss community is at an insanely fast pace at the moment. Who knows, it might all crumble, but I have a hard time believing a particular native UI framework could compete any time soon. Check out the github traffic on the node.js core to get an idea of the pace. On top of that, the js community is moving towards small modularized packages and away from big frameworks, so you have wayyyy more people actually contributing their own work. Check out @substack on github https://github.com/substack . He is just one guy and has nearly 5000 checkins in the last year across hundreds of libraries and he is not even that unusual in the community. IDK how a C++ framework could really keep up at this point.

Re:Lots of great new stuff!

[bill_tvm]

Are they done with their moc madness yet?

Re:Lots of great new stuff!

[pherthyl]

>> Good luck fending off the javascript hordes.

No luck needed. JS/HTML5 apps are essentially dead for everything except really simple things. It's no coincidence that Facebook dropped their HTML5 apps completely and replaced them with native. Every developer I've talked to that started with HTML5 for mobile apps has been completely disillusioned by the lack of tools, performance problems, and general buggyness and limitations. It's not a serious way to develop apps unless your app is essentially a repacked website.

Official Support

[ClayDowling]

There has been somewhat hackish support available for a while to use it on Android. Having official support will be nice. Now I just have to write my killer app and live the lifestyle of the idle rich.

Re:Official Support

[SwedishPenguin]

Last time I tried it, there was no hardware acceleration and no access to sensors though. Has that changed?

Re:Official Support

[interval1066]

Yeah, it wasn't as bad as all that, but 5.2 will really make it shine. I hope. Hopefully they will do something slicker than Maestro II's need to download a flurry of libraries into your phone every time it encounters a new api.

Re:Official Support

[Deus.1.01]

Yeah, the QT Sensor module is fully implemented now.

And all the rage lately has been about hooking rendering to OpenGL.

How heavy is it?

[MouseTheLuckyDog]

My understanding is that the Qt libraries are on the order of hundreds of megabytes. Bit large for a library on a machine with 16G storage,

Re:How heavy is it?

[EmperorArthur]

That's for everything. Every window decoration you could ever want, every button, etc...
If you strip out everything that's not being used by the current program, you get something that's much smaller.

Re:How heavy is it?

[Anonymous Coward]

On Win platform:
QtCore 2.6MB, QtGui 8.5 MB, QtNetwwork 0.9MB, QtOpenGL 0.8 MB, QtWebkit 13.1MB
+ MSVC++ Runtime libs: 7MB

So it is in the few 10's MBs range

Re:How heavy is it?

[Anonymous Coward]

lame. if it isn't all rolled into one binary file then it sucks. if it is five times larger than it needs to be, then it sucks.

Re:How heavy is it?

[interval1066]

Not for mobile devices. Your understanding is flawed. God I love /. ...

Re:How heavy is it?

[edxwelch]

That's still pretty bloated for mobile phone platforms

Re:How heavy is it?

[Anonymous Coward]

Nah, Qt is more like 10-20MB with everything enabled. Hundreds of megabytes would be the full KDE.

Re:How heavy is it?

[Anonymous Coward]

There are obviously things you wouldn't have, like QtWebkit and QtOpenGL, both being thin wrappers over existing functionality.

Re:How heavy is it?

[loufoque]

I find it funny that some people would find 16GB of storage to be small.

Re:How heavy is it?

[somersault]

It is pretty small if you are storing music or photos on your phone.

Re:How heavy is it?

[loufoque]

It still isn't small.
My phone only has 1GB of data for such media files, and I can still store lots of thing in it.

Re:How heavy is it?

[somersault]

For some definition of "lots". Lots of text, sure. But not lots of pictures or music, unless you are happy with some serious compression losses. In today's world, 16GB of storage is about the minimum acceptable for a phone/tablet/netbook class of device.

Re:How heavy is it?

[loufoque]

A music album is 30MB. 1GB still allows more than 30 albums.
That's enough for listening to music on the go.

Re:How heavy is it?

[somersault]

It's enough if you want to faff about with managing your music all the time, but it's definitely not "lots". Space for "lots" of music to me would be over 50GB. My (legally acquired) music collection was something like 80GB, before I started using Spotify.

Re:How heavy is it?

[loufoque]

You should store your music collection on a real hdd, not on a smartphone...

Re:How heavy is it?

[somersault]

I do have my old collection on an HDD. Now I use Spotify. So at home I don't need to store anything. I cache my "starred" list and some albums on my phone for playing when out and about. Currently that's just over 1000 tracks.

QT is a flawed implementation of cross platform

[jbssm]

QT has some very cool stuff, some nice libraries/utilities that allow you to program the algorithmic part of some app in it and use it everywhere. That part is great.

Problem is, QT is not aimed for app developers, because no way someone that wants to release an app for profit would indulge in this almost pornographic way of cross platforming. QT just has all these images of controllers from the platforms it runs on, and them puts them on top of it's implementation to have a similar look of the platform it's running on at the moment. And well, the look is not that similar and the functionality of the platform, on most of the cases just isn't there.

The end result will always seem an hack, no matter how much work you put into it. And for all that work you take to make your app look almost rightand behaving acceptably, you would probably spend less time and get it looking/behaving perfectly if you just used the native coding tools of the platforms you want to run your app in.

Re:QT is a flawed implementation of cross platform

[Anonymous Coward]

It is "Qt". Beware of letter case. "QT" is usually used for QuickTime.

Re:QT is a flawed implementation of cross platform

[Anonymous Coward]

Not anymore. Have you actually used QuickTime in last 5 years? I haven't, so RIP QuickTime - Long live QT Quick! ;)

Re:QT is a flawed implementation of cross platform

[caseih]

Sorry but you're full of it. Hate to break it to you but that's how all UI libraries work by definition! On Windows there is no standard widget set that everyone uses, an no agreement on how a widget should behave. Every framework has their own. MFC, WinForms, whatever MS Office uses, Wordperfect, etc. They all have their own ideas of what a widget looks like and does. MS Office has traditionally shipped it's own widget set with every release. Buttons, scroll bars, dialog boxes, the works. All of these uis use the Windows Theming API to give them common bitmaps to draw, and Qt is no different. Thus a Qt app absolutely looks and acts as good as any other widget toolkit on Windows.

On Mac also, Qt uses the Cocoa native apis to draw widgets, and then tries very hard to follow Mac standards to make them act natural, and to a very large extent they succeed. True on Mac people's idea of fidelity is at a very high standard, or so I've been led to believe.

Maybe your experiences have solely been on Mac where the fidelity wasn't as good in the past. I can tell your experiences with Qt were not on Windows, though.

On linux, of course, well Qt does its own thing, unless you have it use Gtk themes, where it does a very good job of looking and acting like my other Gtk apps.

In short you are definitely wrong about Qt. If you're right about Qt, then Winforms, MFC, MS Office are all just as unacceptable as Qt, as far as look and feel goes. There is no other way to do cross-platform ui toolkits. Don't even mention wxWidgets, because wxWidgets just thunks through to yet another toolkit, though it's provided by Microsoft on Windows so you would probably argue it is the one true widget set, even though precious few applications use it these days.

Re:QT is a flawed implementation of cross platform

[nawcom]

Apple uses their Windows port of the QuickTime framework for iTunes. In OS X, the QuickTime framework is taken advantage of in too many apps to count. So yeah, people are still stuck using what you refer to generically as QuickTime. You didn't say something specific, like "QuickTime Player". QuickTime is gonna be around for a while.

Re:QT is a flawed implementation of cross platform

[Anonymous Coward]

There is no other way to do cross-platform ui toolkits

Maybe Swing, but it's less feature rich and in some cases slower. But then again it is cross platform and then there's Jamba, SWT or Myeclipse widgets...Sure Qt is faster since it hits the native layer more directly and uses their own LnF, but my SWT, Swing, and MyEclipse apps sure do look & behave exactly the same on OSX, Windows, or Linux. Having written engineering apps under Qt and PyQt, I say the development complexity is the same.

Re:QT is a flawed implementation of cross platform

[jbssm]

Sorry but you're full of it. Hate to break it to you but that's how all UI libraries work by definition!

Sorry, but you are full of it.

Good implementations of cross platform development UI libraries use the native UI toolkit of the platform. Things like SWIG or Appcelerator Titanium use the platform native UI, so when you tell me that kind of thing doesn't exist, you are either ignorant or you are willingly putting out false facts in order to justify your opinion.

Re:QT is a flawed implementation of cross platform

[drinkypoo]

On Windows there is no standard widget set that everyone uses, an no agreement on how a widget should behave. Every framework has their own. MFC, WinForms, whatever MS Office uses, Wordperfect, etc.

There are standard widgets provided by the OS, and everyone who uses them will produce apps which look the same, absent customization. There are alternatives, but that doesn't change the fact.

On Mac also, Qt uses the Cocoa native apis to draw widgets, and then tries very hard to follow Mac standards to make them act natural, and to a very large extent they succeed. True on Mac people's idea of fidelity is at a very high standard, or so I've been led to believe.

You've been led astray. Last time I looked Apple was using no less than three themes, with iTunes notably using its own. They do all behave the same as far as I can tell, but they're still not the same.

In short you are definitely wrong about Qt. If you're right about Qt, then Winforms, MFC, MS Office are all just as unacceptable as Qt, as far as look and feel goes.

That's provably true, since Microsoft is the poster child for the API-of-the-week club. How many different APIs have people been expected to use to write applications for Microsoft-based mobile phones over the last five years? How many different web APIs (for dynamic content) have they produced so far? Etc.

Re:QT is a flawed implementation of cross platform

[Anonymous Coward]

I know Qt better than ANY of the "native" coding tools. So no I couldn't get a better result in less time.

  You on the other hand seem to have used Qt 5 minutes and decided that I wasn't worth it because you could reproduce the exact same design patterns you were used to. Well guess what : it's a feature NOT a bug.

  The thing to know about Qt is : it is incredibly powerful and you're going to need time (a lot of it) to take 100% from it. Once you've mastered it you can build cross-platform apps faster and better than with anything I've seen, and it behaves PERFECTLY = exactly like planned, and not doing monkey see on visual, monkey do on Qt and it fails.

  If you're using Qt for your dev it means you're going all in on the cross-platform thing for one, and that you are going to design your whole app accordingly. Look at VLC.

Re:QT is a flawed implementation of cross platform

[Anonymous Coward]

This is an accurate criticism pre-QtQuick.

Re:QT is a flawed implementation of cross platform

[McLoud]

On Windows there is no standard widget set that everyone uses, an no agreement on how a widget should behave. Every framework has their own. MFC, WinForms, whatever MS Office uses, Wordperfect, etc.

There are standard widgets provided by the OS, and everyone who uses them will produce apps which look the same, absent customization. There are alternatives, but that doesn't change the fact.

Really? So how to I use those nice office widgets like the excel pivot or word rich text editor (since the one I can use in MFC is crap) in my own native MFC application?

Re:QT is a flawed implementation of cross platform

[akanouras]

OLE embedding? (ducks)

Re:QT is a flawed implementation of cross platform

[drinkypoo]

There are standard widgets provided by the OS, and everyone who uses them will produce apps which look the same, absent customization. There are alternatives, but that doesn't change the fact.

Really? So how to I use those nice office widgets like the excel pivot or word rich text editor (since the one I can use in MFC is crap) in my own native MFC application?

Slow down, I can see you're upset, but it's not worth using the wrong word over. The existence of custom controls beyond the standard controls used in Microsoft applications in no way contradicts my statement. You may try again, but I wouldn't if I were in your shoes.

*tears in m yeye*

[Chompjil]

What about haiku? You know, for Qupzilla

Re:*tears in m yeye*

[Anonymous Coward]

I think Qt already works on Haiku.

Tmodl up

[Anonymous Coward]

Achieve any of the balance 1s struck,