What is the difference between Qt for Symbian and Qt for MeeGo? I know Qt is a cross-compiling platform. Does this mean that if I use a library from Qt the exact same library works on all devices which support Qt (e.g. Symbian, MeeGo)?
For example:
QtDesktopServices can launch a web browser. Despite the name 'Desktop' is confusing for mobile devices can I launch a web browser on every device which supports Qt? If I look at MeeGo, MeeGo is used for different kind of devices e.g. In-Vehicle, TV, media phone
Is it guaranteed that every device has a web browser on it? I don't think so and that's why I'm asking. If a browser is guaranteed, which browser is it? Which features does it have? I know there is WRT, but a user here stated that WRT has discontinued. So what now?
Do I have to choose between Qt 4.7 and Qt Mobility 1.0?
What leinir said - Qt Mobility is a module that implements common features for mobile devices. Qt's API is the same on all platforms, though there are some platform-specific functions (mainly dealing with low-level stuff).
While the API (the interface) is the same, the implementation of course may be different. I suggest looking at the Qt online documentation - the pages linked under "Platform-specific Development"
According to "Platform notes - Symbian", the Symbian port is not complete and lacks some features (e.g. OpenGL support is "planned for a future release", while printing probably never will be supported). I'm pretty sure that the MeeGo/Maemo version supports OpenGL ES, as I've seen a Qt-based application using it (Stellarium on a Nokia N900).
QtMobility is an extra module for Qt, which provides a bunch of extra functionality which is more esoteric than the other 13 or so Qt modules, but functionality which is really useful when you are building applications the way you suggest.
So no, you don't choose between Qt 4.7 and QtMobility 1.0, because you have to use Qt to be able to use the extra module QtMobility :)
The browser will always be whatever is set up as the default browser on the system. So, no, there is no guarantees - for Windows, for example, you might have people using Firefox, Chrome, Internet Explorer 6 and many others. This is the nature of platform integration, i'm afraid :)
Related
I have been trying to implement a mapviewer application in Qt as a desktop applicaation to work with multi-touch. I'd been having some trouble when I came across mention of Qt Mobility. Qt Mobility seems to be an old module that was used on mobile devices but doesn't appear to be supported by Nokia anymore. Although there is a active repository.
From what I can gather from various more recent forum posts such as this is if we want to use Qt Mobility's Location features we need to wait for it to be released in newer versions of Qt.
If the Qt Mobility api is still available through the repository is it possible to use this for desktop applications or is it strictly for mobile devices? I am interested in making use of the Qt Location classes to help create a map viewer client.
The QtMobility API while deprecated is still being updated and is still available and according to a thread on the Qt Developers it should work with Qt 4.8 (it was only officially supported up until Qt 4.7). According to the documentation it can be used for desktop applications, but they are mostly tier 2 platforms.
While Qt Location won't be ready until Qt 5.2 (expected at the end of November), I wouldn't expect it to drop support for platforms that are already supported in QtMobility.
I am currently looking at using PySide for mobile app development. I've done a few tutorials for creating desktop applications using Pyside and loving it. I understand PySide/PyQt is a port or mapping for Qt, and is usualy behind a little bit with Qt as developers of PySide/PyQt have to keep up with whatever happens in Qt.
I particularly want to develop for Android, BlackBerry and iOS. I also understand that Qt recently added support for Windows 8, as well as the more recent BlackBerry 10 OS.
My question: How well versed is PySide/PyQt in its current state with cross mobile application development.
Does it achieve mobile development by means of the WebKit component, allowing the use of everyday HTML, CSS and JavaScript?
Would it be a better option to consider PyQt for mobile app development, or PySide?
I think its not realistic to think you can use PySide/PyQt and Python in order to make one application suitable for all those platforms.
First of all the platform you want to develop for should support your programming language (Python) as well as the graphical framework (Qt) in order to make it work. This is mostly achieved by third party developers. If Python runs on your mobile operating system this does not say you can start developing and vice versa.
Mobile development is often done with QML (Qt Modeling Language). This allows you to make really cool and fancy interfaces on many platforms. You can connect it to your own Python code to make a real working application.
At this moment Qt is working on support for mobile devices. Most mobile operating systems like iOS and Windows Phone are not supported yet for the combination Python/Qt and mostly the support for working projects is not really big in comparison to the preferred languages of the operating systems.
Here is a list of mobile OS's which support the combination Python/Qt
Link to projects if there is a good link for a starting points is available
Android: PySide for Android
or if you like to use "webviews" instead of PySide: SL4A
Blackberry 10: BB-py
Meego: Python/Harmattan Project
SailFish OS: Harmattan apps (Meego) run without any problem
For your other questions I have a shorter answer.
The webkit component is intended as a content viewer component. Its not a component for building full HTML 5 apps.
The question which bindings for Qt are better is often asked. What you need to be aware of is that the old version of PyQt did almost the same as PySide. The difference was mainly in the license! However PyQt supports now Qt 5 while PySide doesn't, so make your own choice. I think you can make beautiful apps with both of them.
If I write a Qt Gui application in c++, will it work on the Android OS?
You might be interested in this video: http://labs.qt.nokia.com/2011/02/28/necessitas/
So, yes, it is possible. Personally I would recommend always using the native platform where possible - chances are it's going to be more stable across all the various Android devices.
I have to develop an application which requires Bluetooth and profile change functionality for Symbian phones. After spending sometime I found that following options:
Java: but java does not allow to change profile
Symbian C++: I read basics for Symbian C++ and created some basic stuffs. Symbian extended APIs provide simple APIs for Profile and Bluetooth (I haven't tested yet). But its required lot of efforts to grab these. Specially certificate singing problem. I want to test my application on different devices and wish to give my friends whom having different cellphones. But couldn't due to signing problem.
QT: I am still confused on this. Whether this platform capable to fulfill my requirement or not. Secondly which phone supports QT or not...
Honestly, I am bit frustrated while writing this. I am looking someone, experience in these matter, to guide me in this situation.
You can combine native C++ with Qt. Though you'll lose some of the cross-platform nature of Qt by mixing native C++ with it.
See the XQProfile example on Forum Nokia Wiki for mixing Qt and native Symbian C++ for profile changing.
Qt can be installed to practically all devices from S60 3rd Edition FP1 (S60 3.1) onwards. Newer device models ship with Qt preinstalled. Forum Nokia has device specifications that you can filter based on Qt availability.
QT (+ QML) is the language of choice going forward. I believe it is currently on the following phones: N8,C7,C6,E7. i version 4.6.1 with version 4.7 which has the QML support due shortly.
However if you need to target current and older devices then your only choice is Symbian C++.
why programmers are jumping to Nokia Qt rather than symbian C++?
Is there any techinical difficulities in symbian c++?
mostly nokia mobiles run in symbian os?
Not really a question, but Symbian sucks.
Try to do some geoloc in Symbian and in Qt, you'll see the difference.
It's far easier to do it in Qt and to test it in the simulator.
That is since Symbian APIs are going to be replaced, if not superseded or deprecated by the Qt framework with Symbian^4. Even at the moment, you are better off writing Qt applications for Symbian rather then using the horrible(subjective view) Symbian APIs. In fact there isn't going to be a Symbian^4 release anymore. Quote from Nokia:
In fact, we will no longer be talking
about Symbian^3 or Symbian^4 at all –
it will be one constantly evolving and
constantly improving platform.
Bottom line, Qt has already become the standard application development framework for all Nokia platforms(Symbian/Maemo/Meego) and the Symbian OS will follow a more streamlined continuous operating system model like iOS or Android.
References:
http://conversations.nokia.com/2010/10/21/nokia-focuses-on-qt-to-extend-reach-for-developers-make-mobile-experience-richer-for-users/
http://blog.symbian.org/2009/04/30/reviewing-the-release-plan/
Symbian has a very archaic SDK. Some concepts are from the times when booleans and exceptions were not supported by an average C++ compiler. Therefore it is very cumbersome to work with, especially if you are used to more modern SDKs.
Maybe you noticed the TBool typedef, which is used instead of boolean, Descriptors were introduced because there was no standard string in C++ at the time, and as soon as you are doing something non-trivial, you will have to commit to the wonders of symbian garbage collector which is, to put it mildly, archaic and does not mix well with Qt's standard C++ exception handling.
The reason why people still code in native Symbian is either 1. they've been doing this for years 2. they're nuts/masochistic/adventurous 3. they need to use some specific functionality, that is not yet implemented/properly released in Qt APIs (e.g. if you need advanced camera functionality).