Mon expérience est que le développement de bureau est plus productif que le développement Symbian, en raison des cycles plus rapides mise en œuvre-test. Cela fait six mois que j'ai fait Qt sur Symbian mais à l'époque, l'émulateur était très lent à travailler et le débogage sur l'appareil via Carbide et TRK était plutôt sujet aux erreurs. Bien que les API soient les mêmes, il peut arriver que vous ayez besoin de faire du développement natif si ce que vous voulez faire n'a pas encore été couvert par Qt - comme nous l'avons fait pour la mobilité pré-QT. Dans ce cas, il peut être judicieux d'implémenter une couche PAL afin de pouvoir effectuer facilement le basculement une fois que Qt le prend en charge ou si vous souhaitez cibler d'autres plates-formes telles que MeeGo. Étant donné que Symbian fonctionne sur une variété d'appareils, il se peut qu'il ne soit pas possible de prendre en charge ce que vous voulez. Par exemple, nous avons rencontré des problèmes lors de l'exécution d'OpenGL sur certains périphériques. En termes de conception de l'interface utilisateur, nous avons trouvé que le style Symbian dans Qt n'était pas très attrayant et ne ressemblait pas à S60, vous devrez donc faire quelques efforts pour personnaliser votre interface utilisateur. Si cela n'a pas encore changé, nous espérons qu'il changera avec les prochaines versions de Symbian et de Qt. Fredrik mentionne l'utilisation de l'IDE Carbide.
en quoi demandez-vous de l'aide? depuis Qt est une plate-forme multi, la conception de l'interface utilisateur et API sont presque les mêmes – Naruto