Mobile Extensions for Qt for S60 updated

[ltomuta]

An updated release of the Mobile Extensions for Qt for S60 project has been release today. You can find the source code, a demo package and of course a lot of information about the project at http://wiki.forum.nokia.com/index.php/Mobile_Extensions

What's new:

• Built on Qt for S60 Tower release
• New API features:
  
  • New API added for setting device alarms: Alarms API.
  • New API added for accessing the calendar on the device: Calendar API
  • Messaging API now supports emails
  • Settings Manager API now includes several new classes for more control.
• Simpler installation
  
  • The libraries do not need to be built since the binaries are now included
• Simpler usage:
  
  • "system include" directory containing all public headers added
  • Only LIBS += xq* is needed in .pro files
• Carbide templates removed

I hope you will enjoy this release. As usual, your feedback is welcomed.

[gaba88]

hello Lucian

this is a great news indeed.

Will try them for sure.

Regards
Gaba88

[axeljaeger]

Again arises the question what is the difference between

XQUtils* utils = new XQUtils(this);
utils->launchFile("MyPicture.jpg");

and bool QDesktopServices::openUrl ( const QUrl & url ) [static]

I see no value in duplicating Qt API in a Qt Extension. I also don't like the idea of not having Phonon but another extension sound library but I understand that making a version of phonon for the device is harder than an extension that only has some of the features.

[jvuori]

Hi, axeljaeger!

Thanks for your feedback!

If I remember correctly QDesktopServices was not yet ported in Qt/S60 when the functions in XQUtils were originally written. (Qt/S60 version was then 4.4.4-Temple.) Nowadays the funtion XQUtils::launchFile() is of course quite useless. We'll propose this to be removed unless somebody still wants it.

Regarding Phonon the reason is about the same: While Qt/S60 porting is still ongoing some projects may already need quick workarounds of some interesting features even if the official solution will be available in future.

[axeljaeger]

Ok, so I hope that the quick workarounds published as some mobile extensions get obsolete as soon as the same functionality is available in the main qt.

[TrungThanhMtad]

When you have Mobile Extensions for other platform: Windows CE, Linux MObile?

[ltomuta]

When you have Mobile Extensions for other platform: Windows CE, Linux MObile?

See http://labs.trolltech.com/page/Projects/QtMobility

[savaj]

It will be useful to others if next version of Mobile Extensions will have methods to get Network name, operator name, mcc and mnc. As i have added in following articles.

http://wiki.forum.nokia.com/index.ph...tor_name_in_Qt

http://wiki.forum.nokia.com/index.php/Get_MCC_MNC_in_Qt

[axeljaeger]

It will be usefull if the next version of the sensor framework could be used with self signed certificates.

I'm still waiting for someone to explain me the security risks in getting device orientation given the fact that WebRuntime gets it without any kind of signing.

I know that the problem might be one layer below but I seek for every channel possible to express my feeling that the whole signing stuff will be a big showstopper.

Remember that high class telephones are in the price range of netbooks. These also have sometimes also have GSM connection and thus are connected to a carrier network who concerns so much about security. They run a deskop OS where I can install and develop software as I please. I'm used to this as a long time Qt programmer so I would like to know why the development experience should be any different here.

[ltomuta]

It will be usefull if the next version of the sensor framework could be used with self signed certificates.

I'm still waiting for someone to explain me the security risks in getting device orientation given the fact that WebRuntime gets it without any kind of signing.

I know that the problem might be one layer below but I seek for every channel possible to express my feeling that the whole signing stuff will be a big showstopper.

Remember that high class telephones are in the price range of netbooks. These also have sometimes also have GSM connection and thus are connected to a carrier network who concerns so much about security. They run a deskop OS where I can install and develop software as I please. I'm used to this as a long time Qt programmer so I would like to know why the development experience should be any different here.

There's no need to communicate this on every possible channel, you have been heard already. If you still want to shout it out every now and then you can do it on the feedback forums. Too much feedback turns into spam and that gets removed

Still, the proposal is to be retained, Qt for S60 could in fact correct some of these Platform Security errors but it would require a bit more work to do so.

[axeljaeger]

There's no need to communicate this on every possible channel, you have been heard already. If you still want to shout it out every now and then you can do it on the feedback forums. Too much feedback turns into spam and that gets removed

You are right. I just wanted to be sure that no one answers: "We can't do anything about it, it's a symbian thing". I also see that the whole signing thing is rather a symbian issue and not a nokia one but given the fact that both Nokia Qt Software and Symbian are no nowadays owned by nokia, there is only one party to blame left

Still, the proposal is to be retained, Qt for S60 could in fact correct some of these Platform Security errors but it would require a bit more work to do so.

Yes, because of "Write once, compile everywhere" means that there might be phones running other OSes (Windows XP) that do not need signing running the exactly same application.

[ltomuta]

You are right. I just wanted to be sure that no one answers: "We can't do anything about it, it's a symbian thing". I also see that the whole signing thing is rather a symbian issue and not a nokia one but given the fact that both Nokia Qt Software and Symbian are no nowadays owned by nokia, there is only one party to blame left

I understand you point but no, Nokia does not own Symbian, the Symbian Foundation is an independent non-profit organisation.

Yes, because of "Write once, compile everywhere" means that there might be phones running other OSes (Windows XP) that do not need signing running the exactly same application.

That's not really mai point. Symbian is designed as a secure patform and it will remain so. Apps build for it will be asked to obey those rules even thoug, the same code may run on other platforms without such restrictions. It may however be the case that some features are controlled by the wrong set of capabilities and that can be corrected by Qt by running your API calls through a proxy server.

[axeljaeger]

When using the XQDeviceOrientation and holding the device at a nearly 45° angle, I get a lot of rotation noise. I would expect such noise when using some raw sensor API such as XQAccelerationSensor but not when using such a high level API. The problem with the high level API is that you have no chance to implement hysteris on your own so I would end up in either wait one second after the last orientation changed event comes in or don't use XQDeviceOrientation at all and implement my own one one on top of XQAccelerationSensor. I can provide a test programm if neccessary.

So please add some hysteresis to XQDeviceOrientation.

Edit: Further digging into XQDeviceOrientation shows that someone tried to use qt-like shared d-pointers but was not informed that macros like Q_DECLARE_PUBLIC, Q_DECLARE_PRIVATE or Q_D exists. So the programmer did all the stuff by hand.

Edit2: I dont think it is a good idea to emit rotationChanged whenever rotation changes. There was a paper from Trolltech that you could emit around 1000 signals / second on a pentium something. Depending on the jitter and background noise of the sensor, the CPU load on the phone will go very high. Better not offer such a signal and always let the user poll not too often or limit the number of signals emitted per second.

[jvuori]

So please add some hysteresis to XQDeviceOrientation.

Thanks for the feedback! Your request will be handled presently.

From design point of view this could be done as a hysteresis pre-filter just before the events reach the actual orientation calculation. Unfortunately current XQDeviceOrientation API doesn't support accessing the filter stack afterwards so the design must be changed a bit to allow the end users write whatever pre-filters they want.

Edit: Further digging into XQDeviceOrientation shows that someone tried to use qt-like shared d-pointers but was not informed that macros like Q_DECLARE_PUBLIC, Q_DECLARE_PRIVATE or Q_D exists. So the programmer did all the stuff by hand.

These macros are meant to be used for Qt internal use only. They are not even mentioned in the documentation. I know these macros are widely used in many 3rd party apps but they really shouldn't.

Edit2: I dont think it is a good idea to emit rotationChanged whenever rotation changes. There was a paper from Trolltech that you could emit around 1000 signals / second on a pentium something. Depending on the jitter and background noise of the sensor, the CPU load on the phone will go very high. Better not offer such a signal and always let the user poll not too often or limit the number of signals emitted per second.

This is the actual reason why XQAccelerationSensor doesn't emit signals but utilises the filter stack pattern. And since the XQDeviceOrientation supports setting the resolution of the angle it really doesn't emit that much signals unless the resolution is set very fine. The signals are there for convenience reasons. But what comes in my mind is that if the filter stack is exposed via XQDeviceOrientation the rotation events could be received by implementing application's own filter but using it more like as Observer pattern. This would give an alternative way if the signals load CPU too much.

Summa summarum: I think it would be best to improve the design a bit so that the filter stack could be utilised better by the end user. Many of these concerns could be mitigated by rather small modifications.

[axeljaeger]

Thanks for the feedback! Your request will be handled presently.

Thank you. Nice to see that the feedback here is read. It will keep me motivated giving more feedback.

From design point of view this could be done as a hysteresis pre-filter just before the events reach the actual orientation calculation. Unfortunately current XQDeviceOrientation API doesn't support accessing the filter stack afterwards so the design must be changed a bit to allow the end users write whatever pre-filters they want.

My original point is that the user should not have to write the own filter but I think the only right way to implement this API (deviceOrientationChanged) is to already filter and not bother the developer with filtering.

These macros are meant to be used for Qt internal use only. They are not even mentioned in the documentation. I know these macros are widely used in many 3rd party apps but they really shouldn't.

OK, it depends on personal taste wether someone would use these macros in non qt library code. Because the mobile extensions are by nokia I think, I make the same assumptions about coding style and quality as I do with Qt code. Thats only the reason why I might be more harsh here than usual. I only saw that the implementor tried to use some d-pointer-like design pattern but it was somehow different to the pattern Qt Software usually uses. For example, there is no need to have accessors in private class because it is private anyway, implementation of private class is usually not in seperate cpp-file and so on. This is all up to the implementor but from my experience, the way it is done in Qt is just a good way and it makes sense to adopt.
The macros are documented here: http://techbase.kde.org/Policies/Lib...ointer_Example

This is the actual reason why XQAccelerationSensor doesn't emit signals but utilises the filter stack pattern. And since the XQDeviceOrientation supports setting the resolution of the angle it really doesn't emit that much signals unless the resolution is set very fine.

So the resolution changes how often the signal is emitted because the filter is applied before the decision is made wether to emit the signal or not? I guessed it could be this way but it was not clear from the documentation.

This would give an alternative way if the signals load CPU too much.

Generally signals are not so expensive. Even with the observer patterns, I have my doubts that generating more than 20 events per second makes sense if you are not developing an application that wants to do a fourier transformation on the accelerometer.[/QUOTE]

I have another question and know that you are maybe not able or allow to anser but see my reason why I ask.
Question: Is there any timeframe when I can expect the mobile extesion ported to desktop?

Reason: I currently develop an application that uses XQDeviceOrientation. Because I don't like Carbide, the emulator and windows at at all, I try my best to keep my sources compile against a desktop Qt. This was possble till yesterday when I introduced the XQDeviceOrientation in my project. First I made a lot of #ifdefs, then I recognised that this approach makes no sense and started to port it myself. Not by utilizing the accelerometer from my notebook but by opening a dialog with buttons, one for each value of XQDeviceOrientation:isplayOrientation. So I have a device orientation emulator on my desktop then. I plan to have it ready this evening and will post it here when ready. Don't expect to much: It will be a toolbar with 7 buttons that will trigger the same API as on the device.

That is the reason why I had such a closer look at the source yesterday.