Linked by Thom Holwerda on Fri 13th Jul 2012 23:39 UTC
Windows Ars Technica is running an interesting article about the Mail application on Windows 8. It's one of the first party Metro applications, and Ars' conclusion is that it's really, really not up to snuff - it can't even compare favourably to the mail application on Windows Phone. The sad thing is, however - this applies to virtually all Metro applications.
Permalink for comment 526886
To read all comments associated with this story, please click here.
RE[4]: Too many platforms
by iswrong on Sun 15th Jul 2012 09:40 UTC in reply to "RE[3]: Too many platforms"
Member since:

It's not about the power - it's about having four incompatible versions of Qt in the last 15 years.

You are now mixing ABI compatibility, API compatibility, and familiarity in the same argument. Qt 4 is very similar to previous Qt versions. I have been programming in Qt since the early Qt 3 versions, and the switch from Qt 3 to Qt 4 was simple for programmers in terms of familiarity. The leap from an older Qt version to Qt 4 will be very small compared to e.g. the Win32 API to WPF.

API compatibility between Qt3 and Qt4 is not perfect, but acceptable. For many classes that were deprecated, there are (Q3*) classes, so that the old functionality is still available.

The ABI compatibility between Qt versions is not so good, e.g. 4.8 is guaranteed to be binary compatible with 4.7, but that is all you get. Of course, you can still run older precompiled applications using older Qt libraries.

In the preceding discussion the argument was around familiarity. People say that Microsoft asks developers to learn a new API every few years or so. The transition between Qt versions was non-disruptive, evolutionary, and simple. So, I don't think that the argument that Qt released 4 major versions in the last 15 years really applies. It's not as if Qt programmer had to learn a completely new framework.

The more serious problem on Linux is fragmentation. People do not just use Qt, they use Qt, GTK+, wxWidgets, or even Tk and many permutations of other libraries. As a result, the experience is rarely consistent.

The APIs of Windows are more clouded in this respect. Some people will argue that WinRT and WPF both use XAML, and consequently are very similar. Others will argue that they are completely different APIs. For companies making a new product, it is a difficult choice, Metro could be the future, so developing an application using WPF could be deprecated soon. On the other hand, if Metro flops, having developed a WinRT application would've been a waste of time.

On the other hand, although I am not a Windows developer, I think such arguments tend to be overstated. In a serious application, UI code will only be a fraction of an application. If the underlying application is written in a .NET language, it's probably not too hard to target WPF or WinRT at will.

It has the same design, but many APIs have been deprecated - or just plain broken - in the meantime.

Right. People often forget Carbon, or how Apple pushed Cocoa on Java, to deprecate it just a few years later. Or how Objective-C garbage collection was the next great thing, to deprecate it in no-time for ARC. The gcc -> llvm-gcc -> clang switch in a short amount of time was also not pretty, with everything from small codebases or Haskell compilers breaking every few months.

Reply Parent Score: 7