GUI hybride en Perl ?

Programmation
#1

Salut,

Je cherche à créer un GUI assez simple en Perl, mais qui doit pouvoir afficher du HTML (client hybride).
J’ai vraiment pas envie de faire ça dans un navigateur, il faudrait faire du Comet (HTTP push) et certaines fonctionnalités client seraient chiantes à réaliser (libnotify notamment).
Je n’ai pas non plus envie de faire du C++ “juste” pour ça, le truc est assez simple et ça compliquerait la distribution inutilement. Le Python est hors de question (le jour où ils auront une API stable on en reparlera :013).
Le but reste que ça soit facilement distribuable au moins sur Debian, avec un maximum de paquets des dépôts.

J’aurais tendance à me diriger vers une intégration de Webkit.
J’ai fait quelques recherches : il y a des libs Gtk2::Webkit ou perlqt4 mais ça m’a l’air à moitié merdique ; l’un n’est plus mis à jour depuis 2009, l’autre est censé faire partie de kdebindings depuis 2010 mais je ne trouve rien de probant dans les dépôts Debian.
Une autre solution serait éventuellement d’utiliser SMOKE pour faire la liaison avec Qt, mais ça m’a l’air assez compliqué.

Du coup je me tourne vers vous, savoir si vous avez déjà fait ce genre de choses en Perl ou si vous avez d’autres suggestions pertinentes.

#2

salut
euh je comprend pas ta question final, un GUI , donc une interface , mai pour faire quoi ? debian /gnu linux only ou aussi du windows ?
la lib qt est quand même assez complète tu devrai y trouver ce qu’il te faut ?
Sinon java ?

#3

Le but du programme n’a pas grand intérêt pour la discussion, et je n’ai pas envie d’en parler tant que ça n’est qu’un projet.

Tout ce qu’il y a à savoir c’est que j’ai besoin d’un GUI hybride client local + affichage de HTML distant, pour une utilisation sur Linux. Effectivement Qt est pas mal. Je pourrais le faire directement en C++ mais :

  • ça serait trop lourd à mettre en œuvre pour les besoins du truc (code assez simple, du C++ ça démultiplierait la taille du code inutilement)
  • ça serait pas très pratique à distribuer (utilisateurs obligés de compiler le bazar)
    Quant à Java… :078

Donc je préférerais dans la mesure du possible utiliser un langage de “script”, il faut simplement qu’il permette d’utiliser un moteur de rendu HTML genre Webkit (peu importe que ça soit via Qt ou via GTK).
Évidemment si je trouve pas ce que je veux je finirai probablement par me rabattre sur du C++/Qt, c’est juste que je voudrais quelque chose de plus pratique.

#4

Je ne suis pas codeur Perl, mais en cherchant dans cpan.org :

search.cpan.org/~nine/WWW-WebKit … /WebKit.pm

c’est ce genre de bibliothèque que tu recherches?

#5

Salut,

J’ai déjà fait un programme dans le même esprit. Une fenêtre avec widgets (boutons, entrytext, combobox, checkbox…) j’attaquais des urls avec passage de variables (scripts cgi avec du rrd derrière entre autres).
J’ai fait ça en perl et ça reste maintenable. Côté portabilité c’est du perl donc pas trop de soucis pour déployer ça sur des machines hétérogènes.
Par contre le rendu est fait à la petite main donc pas de moteur de rendu html.

Côté lien passé par agentsteel, ça a l’ai intéressant mais j’ai l’impression que ça nécessite gtk3.

[code]init

Initializes Webkit and GTK3. Must be called before any of the other methods.[/code]

Aujourd’hui je pense que j’étudierais quand même l’option qt.

#6

[quote=“agentsteel”]http://search.cpan.org/~nine/WWW-WebKit-0.03/lib/WWW/WebKit.pm

c’est ce genre de bibliothèque que tu recherches?[/quote]
Salut,
Oui c’est un peu le genre de lib en effet, mais l’API de celle-là est plus que succincte : y’a aucun moyen pour le programme Perl d’injecter du HTML ou (au pire) d’exécuter un script dans la vue Webkit.

En fait je m’aperçois que j’ai mal décrit mes besoins. Pour faire court :

  • récupération de pages distantes en Perl
  • traitement du HTML en Perl pour en extraire les infos intéressantes
  • injection du résultat du traitement dans le moteur de rendu

C’est justement tout l’intérêt d’utiliser un GUI hybride : d’une part on a une UI complètement en HTML donc très simple à coder (une fois que le moteur de rendu est intégré, bien sûr, et ça c’est une autre paire de manches :mrgreen:), et d’autre part on a toute la souplesse d’une application desktop. En plus ça permet d’incorporer facilement du contenu Web en provenance de sources tierces.

J’ai déjà fait des essais dans ce sens avec Qt, mais j’ai beau apprécier le C++ faut quand même reconnaître que c’est pas toujours le langage le mieux adapté selon ce qu’on veut faire.

Sinon j’ai commencé à fouiner dans Perl-XS et ça a l’air intéressant. Inconvénient : ça serait très long pour faire un wrapper autour de QtWebkit, à moins de trouver un moyen d’automatiser tout ça. Si je me trompe pas c’est précisément le but de SMOKE, mais trouver de la doc précise là-dessus c’est pas évident. :confused:

#7

En effet sur le papier c’est très pertinent. L’intégration du moteur de rendu me semble par contre plus aléatoire et extrêmement chronophage. Mais je peux me tromper car je ne suis pas compétent en la matière. Mais maintenant que tu m’as accroché avec ce sujet je crois que je vais creuser.

Évidemment mais par contre les outils ont l’air puissants.

#8

Ironiquement, avec Qt l’intégration du moteur de rendu se fait extrêmement simplement en quelques lignes (voir le widget QWebView).
C’est généralement tout le reste de l’application qui est chronophage car ça reste du C++. :wink:

#9

Je n’ai peut-être pas suffisamment précisé mais c’était le sens de mon intervention.
Quoique avec Qt tu dois pouvoir trouver des templates te permettant de gagner du temps.

#10

Salut,

En Python, Gtk, WebKit et JS, j’avais aperçu ça de sympa : forum.kubuntu-fr.org/viewtopic. … 1#p9719071
Mais j’ai cru comprendre que Python n’était plus un choix acceptable pour toi :slightly_smiling:

#11

[quote=“Keldath”]En Python, Gtk, WebKit et JS, j’avais aperçu ça de sympa : forum.kubuntu-fr.org/viewtopic. … 1#p9719071
Mais j’ai cru comprendre que Python n’était plus un choix acceptable pour toi :slightly_smiling:[/quote]
Oui je sais que ça existe en Python. Et non, je ne touche plus à ce langage, j’ai mieux à faire que d’adapter sans arrêt mon code aux changements d’API du langage.
C’est dommage d’ailleurs, car Python est plutôt agréable mis à part ce “détail”.

#12

Je pense que ça peut être compliqué, j’ai l’impression que la plupart du temps les bindings de webkits sont orientés web (et on ne peut pas vraiment leur en vouloir). Je viens t’apporter 2 idées, originales :
[ul]
[li]XUL, avec xulrunner. XUL c’est la techno de Mozilla pour faire leur appli c’est proche de HTML pour le coté description d’interface mais là tu va pouvoir manipuler « vraiment » les interfaces (avoir des callback sur les cliques etc). L’avantage c’est que c’est portable et tu peut demander à ton serveur d’envoyer directement du XUL sans te poser de question. Du point de vu interopérabilité, si tu veux une double stack HTML/XUL tu doit pouvoir demander au serveur d’envoyer un format ou l’autre en fonction du type MIME demandé. Les inconvénients c’est que c’est pas très répendus et que ça reste sur du HTTP (mode déconnecté, client/serveur, etc). Note qu’il est important de packagé xulrunner avec ton application si tu le laisse en dépendance externe ça va te poser des problèmes lors des mises à jour de FF sur les postes utilisateurs ;[/li]
[li]si tu n’a pas peur de javascript, tu peut écrire ton application en javascript et la faire exécuter dans ton navigateur. Avec HTML5 tu as un tas de techno pour faire ça (par exemple developer.mozilla.org/en-US/doc … ng_Started) pour la parties push depuis le serveur depuis comet on a inventé websocket. Ça demande du travail au niveau serveur, mais ça a l’avantage d’être normalisé et bien supporté (la RFC 6455 est supportée par les navigateurs classique : Firefox, Chrome, Safari, Opera, IE depuis la version 10, pour le coté serveur mis à part node.js je ne sais pas pas trop comment ça se passe). Par contre il faut aimer javascript (mais tu es bien obligé de passer par lui si tu veux avoir des interfaces un minimum dynamiques).[/li][/ul]

C’est vraiment deux options qui me semblent important de prendre en compte, même si elles sont très (très ? (très ? (très ? (très ? …)))) loin d’être parfaites. Personnellement je ces deux dernières solutions me semblent intéressantes ne serais-ce que par leur originalité.

#13

En fait hier je regardais SWIG qui est un générateur automatique de bindings C/C++ vers toute une flopée de langages : Perl, Python, PHP, Ruby, OCaml, Lisp, C#, Java, …
swig.org/

Du coup y’a sûrement moyen de faire quelque chose avec ça, reste à voir quoi précisément.

Pour XUL ou carrément un truc 100% navigateur, ça me chiffonne un peu : trop web pas assez desktop à mon goût. Mais ça reste des possibilités (même si dans mon cas ça m’obligerait à avoir un serveur web sur le client, ça reste une appli desktop avant tout). C’est vrai que j’avais pas pensé du tout à XUL.

#14

Je suis pas un grand fan de SWIG je trouve ça lourd (au moins d’un point de vu build) et on bosse sur beaucoup de code généré par un outil externe (pas le compilateur).

Il y a encore une option que j’ai oublié :
[ul]
[li]tu prend du QML : doc.qt.digia.com/4.7-snapshot/qmlwebkit.html[/li]
[li]du javascript : doc.qt.digia.com/4.7-snapshot/qd … cript.html[/li][/ul]

Et tu doit pouvoir finir à faire tout en un mélange de QML, C++ et Javascript.

Mais si tu cherche vraiment à faire du perl parle en à la liste des mongueurs de perl, il y a des gars de très bons niveau dessus et je crois me souvenir qu’il y a une solution plus spécifique que SWIG pour générer des binding perl (ce qui permettrait d’avoir un meilleur style perl), mais je me demande si ça ne marchait pas que pour le C.

#15

En fait le côté intéressant de SWIG, je trouve, c’est que ça génère tout un tas de bindings différents avec assez peu d’adaptations nécessaires (juste les typemaps si j’ai bien compris).
Quitte à devoir préparer QtWebkit pour qu’il soit exploitable en Perl (ce qui impliquera sûrement un wrapper C++ autour de Qt pour lisser les spécificités genre signal/slot etc), autant faire en sorte que ça soit utilisable par un maximum de langages.

Pour être honnête, quand j’ai ouvert ce fil je pensais que ce type de solution était déjà très répandu, mais vu que ce n’est pas le cas… pourquoi ne pas en profiter pour “gratter là où ça gratte” par moi-même ? :wink:
En y réfléchissant bien, c’est quand même LE truc que beaucoup de langages un peu “délaissés” (genre Lisp :mrgreen:) attendent : un GUI portable et simple à utiliser. C’est pour ça que je trouve SWIG si intéressant.

Cela dit je retiens tes suggestions, pertinentes comme d’hab. C’est juste que je suis parti en vrille du coup, faudrait pas me laisser chercher des trucs sur internet j’ai une capacité d’attention pitoyable… (OoOoh un truc qui brille !) :laughing: