Pour rappel, QSA, développé par Trolltech, est une bibliothèque et un langage permettant de rendre scriptable les applications C++ développées avec Qt.
C'est-à-dire que les développeurs vont pouvoir faire en sorte de façon simple que les utilisateurs de leurs applications puissent étendre celles-ci en utilisant et/ou en écrivant des scripts QtScript.
Le langage QtScript est basé sur le standard ECMAScript, d'où découlent entre autres le JScript de Microsoft et le JavaScript de Netscape. Le langage peut faire appel à toutes les classes Qt, et peut utiliser les instances de celles-ci du programme mère selon le bon vouloir du programmeur.
QSA fournit donc la bibliothèque, l'interpréteur QtScript et deux éditeurs QtScript directement intégrables dans les applications par le biais de deux classes.
QSA est sous la double license Qt/GPL, à noter que la version GPL est comme pour la bibliothèque Qt, disponible sous environnement X11 et MacOS (évaluation seulement disponible sous Windows).
Aller plus loin
- Trolltech (1 clic)
- L'annonce (2 clics)
- Pour télécharger QSA (2 clics)
# Re: QSA 1.0 est disponible
Posté par Sixel . Évalué à 5.
d'où découlent entre autres
s/language/langage/g
intégrables
Mes 0.02 euros
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: QSA 1.0 est disponible
Posté par Nÿco (site web personnel) . Évalué à -1.
[^] # Re: QSA 1.0 est disponible
Posté par Sixel . Évalué à -3.
(Mais à quand une section spéciale Capello dans les commentaires???)
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Fautes d'orthographe
Posté par Uvoguine . Évalué à 10.
mes 0,02...
[^] # Re: Fautes d'orthographe
Posté par Sixel . Évalué à 5.
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Fautes d'orthographe
Posté par grafit . Évalué à 4.
C'est bien vrai!
pour voter/commenter/completer: https://linuxfr.org/forums/3/479.html(...)
[^] # Re: Fautes d'orthographe
Posté par Sixel . Évalué à 9.
Déjà que vu le nombre de commentaires, on peut se douter qu'ils ne sont que très peu lus par les utilisateurs du site.
Je sais ce qu'on va me dire, envoie un mail à fab, ou bien propose un patch...
Par contre, si vous pouviez éviter de trop me moinsser, ca serait cool, je viens de perdre mon droit de vote avec les posts au dessus...
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Fautes d'orthographe
Posté par Nÿco (site web personnel) . Évalué à 1.
Personne n'utilise les forums car les "modéros" (éditeurs) ne les utilisent pas ?
C'est ça ? ;-)
[^] # Re: Fautes d'orthographe
Posté par benja . Évalué à 2.
C'est clair qu'on ne sait pas étaler sa science au grand public mais au moins l'info passe vite aux modérateurs tout en restant discrete pour les autres usagers du cite qui ont cure de l'orthographe et des correcteurs.
Je propose d'ajouter un notice contentant cette adresse mail sur la page du postage de commentaire (du style:"Pour signaler une faute d'orthographe... blablabla moderation@linuxfr.org" )
[^] # Re: QSA 1.0 est disponible
Posté par Julien . Évalué à 0.
Ca en devient un peu lassant de voir des posts de correction bien que je n'ai rien contre le tien.
[^] # Re: QSA 1.0 est disponible
Posté par Sixel . Évalué à 3.
Mais tant qu'il n'y aura pas d'autre moyen plus efficace pour signaler aux modéros ces coquilles, je préfère voir des posts en trop plutôt que de m'écorcher les yeux sur une news.
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
# Re: QSA 1.0 est disponible
Posté par flyer . Évalué à 10.
# Re: QSA 1.0 est disponible
Posté par Cyprien (site web personnel) . Évalué à 9.
[^] # Re: QSA 1.0 est disponible
Posté par blackshack . Évalué à 10.
intégré au tableur.
Sinon il y aussi un jeu, en fait c'st une base de jeu, et tu peux choisir dans une liste des jeux -2 fournit: bouncer, un casse-briques, et shooter, un invaders-. Ces deux jeux sont en fait des scripts sur lequel sont écris le moteur -rudimentaire- les sprits ...., en fait l'application fourni l'interface utilisateur -espace d'affichage, gestion du clavier....- et les scripts, les jeux. Je me suis même amusé à écrire un petit truc, trés simplistes, gérant un déplacement d'un personnage, c facile. il y a quelques trucs à savoir, entre autre que l'application appelle un fonction next du script qui doit donc être présente, et qui correspond au traitements dans le temps ainsi qu'une fonction init, qui initialise les paramêtres du jeu. Par contre l'espace d'affichage étant enfait un qwidget tout simple et pas un qcanvas, il y a pas accès aux fonction d'animation de sprite et autre du qcanvas. En fait les 'animation' correspondent aux réaffichage de pixmap à dans endroit de la fenêtre -QCanvas posséde de réel fonctions d'animation de sprite par exemple-.
par contre j'ai pas réelement lu la doc de QSA, donc je peux as te dire toute la richesse du language. Mais la mise en place n'a pas l'air compliqué -bien sûr il existe toujours des cas où cela pourra être plus critique à intégré de facon simple-, et l'utilisation aussi.
[^] # Re: QSA 1.0 est disponible
Posté par Thomas Petazzoni (site web personnel) . Évalué à -1.
# Re: QSA 1.0 est disponible
Posté par Frédéric Desmoulins (site web personnel) . Évalué à 1.
Ca ne serait pas plutot: le JavaScript de Netscape, d'ou découlent entre autre le JScript de MS et le standart ECMAScript ?
[^] # [correction]
Posté par jmfayard . Évalué à 4.
"... le standard ECMAScript, qui découle entre autres du JScript de Microsoft et du JavaScript de Netscape."
# Re: QSA 1.0 est disponible
Posté par Fabimaru (site web personnel) . Évalué à 2.
Cette solution est quand même plus universelle (enfin, tant qu'on reste dans le monde Windows), cela permet un pont entre des applis (et des objets) écrits dans différents langages. Bref, je trouve que ça manque un peu aux systèmes libres.
C'est quand même mieux d'avoir un système unique que de devoir faire face à:
- qsa
- kparts
- Corba (gnome)
Je ne sais pas par contre si cela demande beaucoup d'investissement (re-design) de rendre une application accessible par COM.
[^] # Re: QSA 1.0 est disponible
Posté par blackshack . Évalué à 2.
[^] # Re: QSA 1.0 est disponible
Posté par Raphael Junqueira . Évalué à 8.
QSA n'etant qu'un acces scripte a Qt, alors que kparts et ORBit (le corba de gnome) sont des "equivalents" a DCOM
Et bien que COM te semble simple, je peut t'assurer que c clairement pas le cas des que tu veut l'utiliser reeleement. Et pour l'implementation d'un composant COM tu rigole bien aussi.
Essaye donc kparts (et meme ORBit) et je peux t'assurer que tu toucheras plus a COM :)
[^] # Re: QSA 1.0 est disponible
Posté par Christophe Fergeau . Évalué à 4.
Petit précision, ce qui correspond à COM du côté GNOME c'est bonobo (qui est utilise CORBA), c'est plus sympathique que ORBit, mais c'est quand même un peu lourdingue
[^] # Re: QSA 1.0 est disponible
Posté par Raphael Junqueira . Évalué à 1.
Vi excuse moi pour ce "raccourci", pour moi c naturel car je voit mal qqu'un faire de l'ORBit pur ;)
Enfin bonobo a toujours ce defaut de montrer trop les couches CORBA, donc trop lourd a manipuler.
[^] # Re: QSA 1.0 est disponible
Posté par Schwarzy . Évalué à 2.
Par contre, il reste toujours le problème d'un manque de documentation correctes pour bien des interfaces. Peut-être qu'on a pas donné assez de pognon à MS. Ou alors j'ai pris l'habitude d'avoir la documentation gratuitement avec Linux ... (oui oui c'est un troll :) )
[^] # Re: QSA 1.0 est disponible
Posté par Raphael Junqueira . Évalué à 1.
Faut regarder le code de wine, c souvent bien plus clair ;)
# AppleScript
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
[^] # Re: AppleScript
Posté par Olivier Jeannet . Évalué à 4.
Pour moi, un des premiers langages de script permettant de commander des applications, c'est Rexx (sur IBM) et surtout ARexx sur Amiga, qui permettait de commander pas mal de softs, par exemple traitement d'image ou éditeur.
Ce langage était disponible avec la version 1.3 du système, et a été complètement intégré au système 2.0 . Ca date de 1990 à vue de nez. Rexx était disponible sous OS/2 en 1992, et permettait de commander Excel et DB/2. L'équivalent de ARexx sur Linux pourrait être Perl, par exemple pour Gimp avec le module Perl::Gimp.
[^] # Re: AppleScript
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
# scripting
Posté par Nÿco (site web personnel) . Évalué à 2.
Est-ce qu'on ne peut pas standardiser les langages de scripting des applications sous Nux ? KOffice, GNOME Office, OpenOffice.org, tout le monde a à y gagner, à avoir des scripts portables d'applis en applis.
Je vois mal Apple et MS tenter de standardiser quoique ce soit, puisque pour eux, c'est un argument de vente : "les autres n'ont pas"...
Freedesktop s'en chargerait-il ?
La standardisation des bureaux est en marche (copier-coller, drag'n'drop, XRnR, etc...), pareil pour les formats de fichiers bureautique (OASIS bosse sur le XML zippé de OpenOffice.org), alors on attend quoi pour le scripting ?
De plus on pourrait se mettre d'accord pour se bastonner contre les virus bureautiques avant que ça arrive... hum...
[^] # Re: scripting
Posté par Fabimaru (site web personnel) . Évalué à 4.
C'est pour ça que je parlais de COM. Si on pouvait avoir une interface de communication unique... D'une part on a kpars et bonobo pour les applications KDE et Gnome. Et pour les autres, on a (il peut y avoir des erreurs mais l'idée est là):
- des interfaces spécifiques non accessible de l'extérieur (The Gimp, GnuCash, Emacs...)
- rien (OpenOffice.org...)
D'une part ça éviterait d'avoir une lib par langage (imaginez que des devs de Gimp doivent faire des libs pour Python, Perl, Scheme, Pyke, Ruby...), ce qui doit représenter un travail énorme.
D'autre part, si on veut que son appli soit scriptable dans n'importe quel langage, il faut que l'appli aie accès à une interface commune à tous les interpréteurs. Cette interface doit permettre de:
- lister tous les interpréteurs dispos
- pour chaque interpréteurs, de lister les scripts étendant l'application pour ce langage
Ce qui donne (par exemple):
COM <-> Python <-> interpréteurs <-> application <-> COM
[^] # Re: scripting
Posté par Nÿco (site web personnel) . Évalué à 2.
(à la fin, pense à mettre des 1/ 2/ 3/ et un titre, et tu l'envoies à freedesktop ! ;-)
[^] # Re: scripting
Posté par Raphael Junqueira . Évalué à 1.
- des interfaces spécifiques non accessible de l'extérieur (The Gimp, GnuCash, Emacs...)
- rien (OpenOffice.org...)
Normal les applis que tu cite ne sont pas integres a un desktop (nii kde, ni gnome, ni gnustep, ...) donc ne profitent pas des possibilites de ceux-cis.
Maitenant a part pour The Gimp, les autres ont des equivalents bien mieux integres.
D'autre part, si on veut que son appli soit scriptable dans n'importe quel langage, il faut que l'appli aie accès à une interface commune à tous les interpréteurs. Cette interface doit permettre de:
- lister tous les interpréteurs dispos
- pour chaque interpréteurs, de lister les scripts étendant l'application pour ce langage
Ce qui donne (par exemple):
COM <-> Python <-> interpréteurs <-> application <-> COM
Ben justement le moteur kparts/scripts de kde fait justement ce que tu dis la. Le but est de pouvoir facilement ajouter un langage de scripts qui utilisera les interfaces kparts (de memoire c surtout kdevelop qui l'utilise)
[^] # Re: scripting
Posté par wismerhill . Évalué à 1.
Le système dcop de KDE va beaucoup dans ce sens-là.
Dcop est déjà disponible en C++ et la commande dcop permet de l'utiliser dans des shell script. À partir de là il est possible de faire des binding dcop pour d'autres langages (ils existent peut-être déjà, j'ai pas regardé).
Ensuite les programmes fournissent une interface dcop (essaye kdcop pôur voir ce qui est disponible) et on peut les scripter dans tous les langages où on peut utiliser dcop.
[^] # Re: scripting
Posté par HappyPeng . Évalué à 1.
(utilisé dans GNUcash, GNU LilyPond, Siag Office, TeXmacs, ...)
http://www.gnu.org/software/guile/guile.html(...)
[^] # Re: scripting
Posté par Philippe F (site web personnel) . Évalué à 3.
En ce cas precis, c'est une recommendation de RMS. Je trouve ca abuser de dire que c'est Gnu, a moins de penser que toute la FSF leche les bottes de RMS. En bon chercheur du MIT, RMS est tres familier avec les langages fonctionnels, pense qu'ils sont tres adaptes a plein de chose et souhaite leur diffusion.
D'un certain point de vue, je le comprends: c'est vrai que les langages fonctionnels ont bcp d'interet et permettent de faire plein de chose plus facilement et avec moins de bugs. Le probleme, c'est qu'ils sont plus durs a aborder car ils demandent un autre mode de pensee, et souvent une syntaxe qui n'a rien a voir avec des langages plus courants (C, C++, Java, Python, Perl, ...)
Alors que le but d'un langage de script est de pouvoir etendre facilement l'application, on se retrouve avec Guile avec un truc qui est plus complique a aborder que l'application elle-meme. Le programmeur bourrin aura plus vite fait de patcher en C que d'apprendre Guile pour faire plaisir a RMS. D'ou ma remarque intiale, on peut se torcher avec cette recommendation.
Si on veut rendre une application scriptable, il faut que le langage de script soit tres facile a aborder car le but est que des non experts puissent scripter (sinon, ils patcheraient directement). Un bon choix est donc un langage simple facile a apprendre. Un excellent choix est un langage que les gens connaissent deja par un autre contexte. D'ou le choix de VB dans le monde Microsoft. Javascript est aussi un bon choix puisque des millions de developpeurs web savent faire du Javascript (mais pas moi). D'apres un pote, avec mozilla, tu peux te coder une appli complete en javascript. Maintenant, tu pourras aussi scripter les applis Qt. Python me parait un bon choix aussi, car il est simple a apprendre, souple et facile a etendre. Mais embarquer python, c'est quand meme un peu lourd. Dans la categorie des poids leger, j'ai entendu bcp de bien de lua (http://www.lua.org/(...)).
[^] # Re: scripting
Posté par ckyl . Évalué à 4.
Les languages fonctionnels developpent un mode de pensé très intéressant qui serait bénfique à beaucoup de personnes. Je pense qu'il ne faut pas jeter trop vite Lisp/Scheme à la poubelle...
Je pense que commencer la programmation par un language fonctionnel est une très bonne chose bien qu'un peu repoussante au départ. Scheme par exemple permet de coder dans un nombre de style assez impressionant. Tu peux faire de l'Objet si tu le souhaite, du fonctionnel pur ou de l'imperatif.
Si ca interesse que monde je peux montrer de petits exercices de style en Scheme avec tout un tas de facons de coder. Et ca eviterais une certaines "etroitesse" d'esprit a non voir la programmation que par C/C++/Java, qui sont très bien d'ailleur.
[^] # Re: scripting
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Ecrit un article, ça peut intéresser pas mal de gens
[^] # Re: scripting
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: scripting
Posté par LeMagicien Garcimore . Évalué à 1.
Ex :
Dans la boîte où je bosse (en stage), les commerciaux utilisent VBA pour scripter word, access et excel (désolé). On a déjà du mal pour leur expliquer les concepts de la POO, alors le fonctionnel...
[^] # Re: scripting
Posté par Mickaël Rémond (site web personnel) . Évalué à 1.
Mickaël
[^] # Langages fonctionnels
Posté par Mickaël Rémond (site web personnel) . Évalué à 1.
http://www.erlang-projects.org/(...)
ou
http://www.erlang-fr.org/(...)
Mickaël
[^] # Re: scripting
Posté par Raphael Junqueira . Évalué à 1.
Justement pas mal d'applis commencent a pouvoir etre scriptables et en regardant le langage majoritaire semble etre le python. Le plus drole c que meme des grosses applis bien commerciales l'utilise aussi (maya, ...). Ca peut faire un standard de fait. Maintenant l'interet du libre c aussi de laisser le choix alors je suis plutot partisan du principe de moteurs de scripts integres aux desktop sur lequels viennent se plugger des langages de scripts.
Je vois mal Apple et MS tenter de standardiser quoique ce soit, puisque pour eux, c'est un argument de vente : "les autres n'ont pas"...
Tu aurais tord de penser cela, Apple commence a mettre de l'applescript partout dans leurs applis et MS eux ils foutent du VBA un peu partout aussi (on peut meme scripter IE et l'explorateur avec)
# Re: QSA 1.0 est disponible
Posté par cyril bosselut (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.