Some of the S60 app “engines” are being re-written with Qt and others not as I understand it. I’ve tried a bit of hybrid Qt/Symbian C++ programming already myself and it seems to work pretty well. The Qt event loop has been ported in a way that includes active object processing.

Symbian’s non-standard version of C++ was working around issues with the compilers and standards at the time it was written. At least Qt is only non-standard in areas where they add genuine enhancements. Also, you can build Qt with exception support, although it admittedly doesn’t do much for you. Besides, it’s not like there’s a decent application framework out there that uses standard C or C++. It must be admitted that there is work to be done on OOM in Qt for embedded systems. I’m interested to see what they can come up with there.

You never HAVE to tell users to download another SIS file, you can embed it and even silently install it – the issue is how large a download can you reasonably expect people to put up with (and possibly pay for)?

Actually my larger concern would be how dependent the shiny new GUI will be on hardware accelerated graphics. Will the older devices not have the performance to run the apps anyway?

From what I can see, Nokia have jumped so far into the Qt experiment that it’s do or die now. I expect the technical challenges are not impossible and they have the resources to pull it off.

Ok I know that’s tongue in cheek. But a lot of that code is due to listening to many 100s of different events from Etel, centrep, P&S etc.
There is a huge amount of investment in active objects which litter the Apps – certainly the idea that you can strip out the symbian-esque avkon and stick Qt on top of the ‘engine’ is a bit foolhardy.

In some ways it’s quite ironic that Symbian has always been lambasted for using an out of date, proprietor interpretation of C++ and now they are moving to Qt which has a similar heritage.
- You write in a strange dialect of C++ )need to pre-processes sources with moc_
- The framework doesn’t support exceptions (you have to isolate them to your code)
- The OOM behaviour is dubious at best

Qt is better than Avkon, but it’s not linage of ‘embedded’ systems and has its own issues when it comes to creating robust applications.

>>although that’s not very practical for commercial app distribution since I assume it will be pretty big

If Symbian/Nokia want to re-stimulate app development on the platform, this would be a a valid tradeoff. As soon as I have to tell users to download another SIS…..i’m out of here.

With Symbian the hardware and interfaces are changing more significantly, so the value of keeping the old UI is much less clear. When the new UI appears, apps with old UIs will be extremely undesirable in comparison. All the core OS APIs underneath should still be there, so the application engine should still work, but it needs a new UI. This either requires extension of Avkon, or replacement, or both. I think that Avkon is hard enough to work with compared to Qt that updating the UI for the new look and feel would be more work than recoding it using Qt. Once you have Qt, they’ve been pretty good at maintaining compatibility long term (porting module provided for big break in Qt 3 -> Qt 4) and need to remain so since they also target desktops.

Mobile really is different from the desktop because we can’t just keep backward compatibility by endlessly bloating the firmware and resource use like Microsoft. Personally I think a break from the past would be a really good thing!

A few other points from comments in this thread:
The proposal really is to remove Avkon currently, and re-write the apps in the stated timeframe. The best thing you can do with a “1876 line C++ constructor” is throw it away and start again.

As I understand it, Nokia do plan to stop using and marketing the S60 brand, it’ll all just be Symbian (and just Qt for most app developers, but not with the current UI paradigm, look out for more of the declarative UI stuff built on Kinetic that the trolls were talking about in Monaco at the Nokia Developer Summit).

I’m really not sure how practical/useful a compatibility bridge of some kind is. The UI paradigms are really very different. Possibly the existing Avkon widgets could be kept for a transition period, but I very much doubt complete BC could be maintained with such a radical overhaul.

Qt for S60 (as it’s currently called) should be mature in September this year and become part of Qt 4.6. I’d expect Nokia to ship it in the firmware of Symbian^3 devices and it’ll be available to download to Symbian^1 and Symbian^2 devices (although that’s not very practical for commercial app distribution since I assume it will be pretty big).

A final point – this is currently a proposal to the Symbian Foundation’s feature and roadmap council. If you want to provide input to the discussion, sign up to the website beta (or wait for it to go public) and post a thread on the council’s discussion board in the forums.

Surely this is the point! People don’t regard smart phones as an application platform in the same way they regard, say MS Windows or Mac OS/X precisely because smart phones are not promoted (or even thought of) in that way by the very sellers and makers of these devices.

What is the point of talking about the Symbian Ecosystem, as we have been for a decade now, if we don’t take one of the core requirements of an ecosystem (a relatively stable environment) seriously?

I have absolutely no love for Avkon, so I’m not speaking out of a desire to keep it around for its own sake. However, it is a major part of the current platform, and abandoning it in a hurry is akin to attempting to move a chunk of tropical rainforest into the middle of Greenland — some plants will survive the change it their environment, but the rich diversity will vanish. (Using the ecosystem metaphor.)

Nokia are going to be reliant on avkon for many years. Migrating all the internal applications and retesting each is a huge task( Bear in mind that one of the applications has a 1876 line C++ constructor).
Also think of the task of re-localisation using Qt’s localisation method.

The more interesting question is who’s designing the Orbit widgets? Given that the core applications will be using these widgets – they will have a profound impact on the usability and feel of ^ devices.
Or to put it Lee’s language – who is the Michelangelo behind the UI renaissance?