One would think that laying claim to the largest share of the world’s smartphone market would attract the most high-quality mobile software developers, but that doesn’t seem to be the case for Nokia.
One would think that laying claim to the largest share of the world’s smartphone market would attract the most high-quality mobile software developers, but that doesn’t seem to be the case for Nokia.
I call bs. Here are the 3 reasons:
1. Symbian (UI sucks)
2. Symbian (dev tools sucks)
3. Symbian (getting certificates sucks)
I think the article hit the nail on the head. Nokia have too many devices running too many completely different oses. They have Symbian S63 devices as well as Symbian S65 devices (mostly compatible with one another except that S65 is touch-based and so apps designed for it are designed around touch), Symbian^3 on the N8 (largely compatible with S65 but not completely), Maemo on the N900, and now all future phones supposedly will use Meego… except the mid range smartphones which will remain Symbian for some time to come. Developers don’t target manufacturers, they target platforms. We don’t talk about developers targeting HTC, we talk about them targeting Android or Windows Mobile. I think the same thing is relevant here. If I were developing a mobile app for a Nokia device, I wouldn’t know which platform to target. Symbian which is the most well-established? Do I target Meego in hopes that it will take off, and what if it doesn’t? In the end though, most don’t care who makes the device their app is running on as long as it sells well.
With the Qt SDK, You make one application, and it should compile straight across for Maemo/MeeGo, Symbian, Windows, Linux and Mac.
Granted if you have a really bloated UI, you’re not going to want to build it for a mobile platform, though you still could…
Really, Nokia has done something quite cool with the Qt SDK.
Symbian sucked to develop for before, which is why most people think that way now, but it should be fairly straight forward now.
Things are only going to get better. They pretty much have to be so they can steal back some of the thunder from iOS and Android.
While you can compile QT cross-platform, cross platform GUIs tend to look terrible and integrate poorly with the UI environment they’re placed in. Remember all those Java GUI apps? I wonder if Nokia could pull that off with QT.
I mean, there’s the touch interface. And it looks like Meego is planning on using QT built with special (but not done yet) Meego-specific touch APIs that are not QT-cross-compatible.
So yeah, you could compile something with QT and put it in a lot of different places, but the integration/usability would probably be terrible (app built for stylus/mouse on a touch screen? Yuck).
Nokia has a big problem with all these platforms.
You’ve clearly never *seen* Qt apps. They’re not Java apps – after all, you compile Qt apps for the platform. The Trolls (Qt developers) pride themselves on the native look and feel of their applications. It might not be a 100%, but you don’t see that on win and lin anyway – mac is a slightly different story but the Qt apps are close enough there.
The Qt apps I’ve seen on Maemo look like native apps, on MeeGo they ARE native apps and on Symbian you won’t notice the’re not native either.
It doesn’t look like they’ll be entirely native, as they need to get into the hooks of the touch hardware. That was the problem with the Windows Mobiles and similar phones before 2007, in that they were basically built for a mouse, and the solution was to include a stylus. Doing away with the stylus and developing new touch UI eleements (ala iPhone, WebOS, Android) made interacting much easier. QT doesn’t have those nativly yet it looks like, hence Meego adding them on top of QT.
I’ve seen plenty of QT, Java, and GTK+ applications. Java and GTK+ in particular are used a lot in networking. Generally, the GUIs are pretty terrible, but they don’t need to be perfect because they’re Cisco networking tools or the like.
Basically the main problem with write-once/compile anywhere GUI toolkits is that they’re re-inventing the wheel. The native OS has its own way to interact with the user and a very distinct look and feel. Add then QT/Java/GTK which diverges wildly from the native UI in terms of look and method of interaction, help, clipboard, toolkit, all that is different.
Bring that into the phone world, where new UI elements are being developed to make them a completely different breed of computing device (touch, task versus desktop oriented, etc.) and QT is either going to need a lot of new addons, or they’ll use the dreaded “skin” method, which is a few UI elements pasted on an app built for mouse interaction.
Ok, frankly I’m with you here 😉
I think it’s quite a challenge. Still I think the Qt ppl do reasonably well on windows/mac/linux, and I have at least SOME hope they can solve at least part of the issue on these other platforms.
Maybe QtKinetic can help here, dynamic as it is, or other solutions like having a thin custom-per-platform gui on a common core…
What does this mean?
As an example of how Qt for N900 works:
– “styles” are used to draw the controls (like QPushButton)
– the maemo style is based on QGtkStyle. It asks style information (button background color, pixel sizes etc) from the underlying gtk libs
– Everything is still drawn using the standard QPainter stuff
So basically, Qt is pretty close to being native – with the difference that gtk libs are still needed currently. Also, gtk does the file dialogs etc.
MeeGo goes a bit further than what Maemo5 did. Still, Maemo5 Qt is at the same level of functionality as the ‘native’ hildon libraries.
So what’s the “native” toolkit for Linux? Or Windows?
QT was built for mouse interaction, where as touch has the added dimension of multiple touch points. It doesn’t look like QT is native to that yet, given the Meego site lists separate dev libraries for touch.
Android, iPhone, and WebOS has all shown that dealing with smartphone requires a new UI methodology.
For devs, it’s pretty easy to write an Android, iPhone, or WebOS app. They use the platform’s SDK, and voila. They care a bit about versioning (Android 2.1 versus 2.2, iOS 4 versus 3, etc.). They certainly don’t have to worry about which QT libs are installed, which platform they’re running in and testing for (MeeGo versus Symbian3 versus Symbian 4). It’ll be interesting to see if Nokia can garner much developer interest.
Even for the multi-point touch interactions?
[/q]
Native Windows is the Windows API. For Linux, it’s either GTK or QT depending on the desktop environment (Ubuntu versus Kubuntu for instance), and if you have a GTK-based environment running a QT app or vice versa, it’s very obvious. All the great native enviornment controls go out the window.
Multitouch isn’t that big a deal. Touch is basically a mouse click, only less accurate (for which you compensate with large press areas).
Maemo5 doesn’t offer multitouch. It’s a single-touch resistive display.
I think the distinction of “native” toolkit is a bit bogus, esp. on Linux. Qt works and looks fine in Gnome, and Gtk would work in KDE if Gtk developers cared enough.
Really? I just found tech previews of it being multi-touch. And I was confused, because that means there are how many different platforms for Nokia?
Mameo5
Mameo6 (was that cancelled?)
Symbian3
Symbian4
Symbian5
MeeGo
Honestly, I don’t know if that’s all there is, or if that’s correct.
That’s a mess, an none of them are feature competitive with Android/iOS/WebOS yet. Nokia has a huge install base, but nothing compelling now or in the future. Developers are revolting, market share dropping, and it doesn’t look like Nokia has any coherent platform to fight back (other than the platform of arrogant denial).
[/q]
Ugg, and that’s another problem: GTK/QT snobbery. They both look out of place in each others desktops (themes, widgets, buttons, preferences). You’ve got inconsistent UI, megs of libraries that do the exact same thing, and snobbish developers, railing on about how this little thing is better than that little thing.
QT or GTK? I. Don’t. Care.
So Linux systems are loaded (bloated) with both libraries, because everyone tends to have one or more apps they use in both camps.
I just want something easy to work with. Most of the QT/GTK apps I do use are GTK (GIMP and Wireshark), and they work fine save for the inconsistent UI.
There is no probably about it, about the only platform I’ve seen QT decent on is KDE. QT is an ABSOLUTE DISASTER on the Mac, I really have not seen a worse toolkit for Mac applications. Absolutely nothing feels native. QT apps are so freaking bad on the Mac, that I actually prefer to run the Linux version in Parallels.
Although I’ve not had any personal experience with QT on Windows, I hear it is pretty bad as well.
I really wish people would stop this cross platform GUI toolkit nonsense: Linux,OSX and Windows are fundamentally different in how desktop apps behave, it is simply impossible to use a single toolkit to make an app feel native on all 3 platforms. Just look at really great cross platform apps, like Handbrake, or Transmission: they use GTK on Linux, Cocoa on Mac, and WinForms on Windows, thats why they look and feel correct everywhere, even though most of the core logic is cross platform.
Note, there is a reason why Skype and Mathematica use QT ONLY ON LINUX, on the Mac, they both use Cocoa, and use the standard Windows API on Windows.
Edited 2010-07-19 04:26 UTC
Whoa, what a troll.
Qt looks perfectly native on KDE, Gnome, Windows.
On mac, they have rewritten the backed to use Cocoa (I think – I don’t own / don’t care about Mac), so it should look much better than it used to.
“I hear”? I guess you have a link handy where someone is saying this?
Er.. no. The concept works just fine. What are these fundamental differences (that are *not* supported by Qt) you speak about?
More likely reason is that they developed the Linux version later than the other versions.
Edited 2010-07-19 07:03 UTC
Fine call me a troll, I guess than anyone with difference of opinion is a troll then. So excuse me for not drinking the QT kool aid.
Just tried a QT app on Windows 7, looks pretty strange. Has the typical QT toolbars, and all the QT chrome (wasted gray space). And why would anyone use something like QT when they could use WinForms???
Its also very obvious if you have ever tried to use a QT app on Mac that neither do Trolltech care about the Mac. Yes, the backend of the latest QT might be cocoa, but literally all Cocoa (or any other native backend) us used for is to create a window with a pixbuff, QT does all of its own rendering to the pixbuff, all its own event handling so forth. It just tries to mimick the native toolkit, and does a very bad job.
In Skype, the Windows and Mac version were developed first. In Mathematica, all versions existed for a long time, they just decided to re-write the Motife based Linux version with QT. But if QT is so great, write once / compile anywhere, why not drop the native version on the other platforms and use QT?
So, from someone who has dug though the QT source code, worked for a group that developed a QT application, and had been forced to use QT apps on the Mac, I can tell you what an absolute disaster QT is on the Mac.
Edited 2010-07-20 12:47 UTC
I called your post a troll, not you as a person.
Then file bugs. What application are we talking about? Perhaps the app is just misdesigned?
Cross platform code is always more valuable than platform specific code. It can mean the difference in selling your app to a company, or not.
No idea. Perhaps they value their old codebase too much? Or don’t trust the new linux code 100% yet?
When was this? Tried with newer Qt version?
Also, QT is QuickTime.
It is not that easy.
First of all, you are still forced to go down to the Symbian C++ dialect with all its nuisances for some cases.
http://developer.symbian.org/wiki/index.php/C%2B%2B_Develop…
Thanks to Open C/C++ libraries and Qt things are getting easier but still there will be a market problem.
Only Series 3 FP1 onwards are supported, but if you look at the OVI store most Symbian software is only available to Series 5 (Symbian^1) onwards.
Qt is supposed to make everything easier, but even then you do have to put a few #ifdefs to deferenciate between emulator and phone environment.
Also not all non Nokia phones have support for Qt.
So with Symbian you also have the same issues as with J2ME regarding fragmentation.
Not sure if in the long run Symbian will survive, maybe yes, depending how Nokia can handle the competition.
I can give 2 reasons:
1) Symbian, like WinMo, is a relic of the resistive stylus UI and that isn’t very appealing
2) Much software innovation, like it or not, comes from the US. Symbian/Nokia has very little marketshare in the US and won’t attract US developers.
I wrote a few things for the WiMax n810. So for developers like me how much is the N900? Close to street price sans warranty. Plus they don’t backport so I could do something close on any of my 3 similar N8x0 models.
Nokia is a lesson in how not to engage the FLOSS community – they come close, very close, but fail.
(I’d do symbian, but same idea – I’d have to buy more hardware).