Je me demandais si quelqu'un sait de bons tutoriels ou d'articles décrivant des méthodes de création d'une interface graphique HTML pour une application utilisant QTwebKit pour une application Windows Desktop.
Je suis principalement préoccupé par la communication des messages, des événements et des informations entre les permettant de dire une DLL (écrite en C ++ par exemple) et l'interface graphique (qtwebkit).
Besoin de bonnes références fiables ...
4 Réponses :
Ce ne sera pas facile: les navigateurs Web sont des forteresses en raison de problèmes de sécurité. Il est donc difficile de passer de JS dans une page Web à quelque chose en dehors du navigateur.
aussi, qtwebkit n'est pas une API très ouverte. Le plus gros obstacle de votre cas est qu'il ne vous offre pas d'accès au DOM, vous ne pouvez donc remplacer que tout le HTML.
Par conséquent, vous devez corriger et écrire beaucoup de code pour implémenter les API et les fonctions manquantes.
Puisque Qt 4.6 a été publié, il y a Qwebellement ( Voir les documents pour des exemples), vous pouvez donc au moins accéder au DOM et le modifier. Cela fera beaucoup de choses plus simples. Je suggère de décider qui contrôle le navigateur: Votre application sera-t-elle JavaScript qui appelle à l'extérieur ou est l'application vraiment en C ++ et que vous utilisez le navigateur en tant que rendu d'interface utilisateur intelligent?
Un moyen beaucoup plus simple pourrait être de faire votre idée de travail serait de démarrer un serveur Web interne lorsque votre application démarre, puis ouvrez une vue QtwebKit pointant sur l'URL du serveur local. Ensuite, vous pouvez utiliser tous les outils de développement Web standard. Eclipse utilise cette technique pour son système d'aide interne.
Le WebElement et Qwebelements ne permettent pas d'accéder aux éléments DOM de manipulation ??
Je ne savais pas que Qt 4.6 a déjà été libéré. Vous avez raison, voir ce lien: doc.trolltech .COM / 4.6 / QT4-6-INTROTRO.HTML # DOM-Access-API
J'ai amélioré ma réponse.
C'est ce dernier cas "App vraiment en C ++ et vous utilisez le navigateur comme rendu de l'interface utilisateur intelligent"
Aaron, le script de mappage appelle à C ++ et à la manutention des événements est à mon avis compliqué en le routant via une couche supplémentaire (c'est-à-dire le serveur Web). En outre, la mise en œuvre d'éléments dessinés personnalisés (vidéo, ...) devient assez piraté.
Cela pourrait aider:
http://labs.trolltech.com/blogs/2009/04/07/qwebelement-sees-the-light-do-i-hear-a-booyakasha/
http://labs.trolltech.com/ Blogs / 2009/04/17 / JQuery-and-Qwebelement /
Je cherchais juste dans le premier lien tout à l'heure et c'est peut-être la solution ... Je pense que je vais devoir étudier les classes d'abord avant de continuer à voir s'il s'agit de la solution ultime. Toujours pas sûr du bit de communication de la DLL à la page ...
Pour l'utilisation de base, le Exemples de Trolltech devrait vous aider à démarrer .
Le côté plus de l'approche QT est que l'expulsion d'objets au script est relativement facile, voir par ex. ici . JavaScript dans les différentes webkits embarqués peut alors facilement communiquer avec C ++ (et bien sûr avec le script dans d'autres fenêtres si vous fournissez une prise en charge du côté C ++ pour cela). Le bas du côté est que l'API ne semble pas être assez stable et semble manquer de supporter pour ajouter des auditeurs d'événements de JavaScript à des objets C ++ (ou au moins je n'ai pas vu comment il était censé être fait).
Placer des éléments dessinés personnalisés dans la page est à nouveau simplifié, vous incorporez des plug-ins dans la page (par exemple via via la balise sur une chose importante à garder à l'esprit: les appels à la webkit intégré (par exemple pour évaluer JavaScript) doivent toujours se produire sur le fil principal.
Merci pour un commentaire perspicace. Pouvez-vous fournir plus d'informations sur les raisons pour lesquelles "appels vers la webkit intégré (par exemple pour évaluer JavaScript) devrait toujours se produire sur le thread principal"?
Dans tout navigateur actuel, je connais le moteur de script réside dans le fil principal et n'est pas le fil-coffre-fort. Le développeur du plugin doit s'assurer que les appels dans le navigateur sont délivrés à partir du thread de droite, à moins que certaines fonctions de l'API s'en occupent déjà de cela - si vous n'avez pas de comportement indéfini et que vous vous bloquez probablement.
Je suis copier / coller des bits de différentes sections, mais c'est comme ça que j'insère un objet disponible pour JavaScript, puis j'utilise JavaScript pour parler à l'application principale. Semble bien fonctionner ... ceci fait un objet myAPI dans JavaScript et je peux appeler toutes les machines à sous disponibles à partir du myAPI classe.