Qt Script for Application

Posté par  . Modéré par Yann Kerhervé.
Étiquettes :
0
27
avr.
2002
Serveurs d’affichage
Apres quelques rumeurs sur la mailing list de Qt, Trolltech annonce officiellement QSA : "the Qt Script for Applications", prévu pour fin 2002.
Il s'agit d'un toolkit multiplateforme basé sur Qt, permettant de réaliser des applications C++ scriptables utilisant un langage de script interprété Qt Script, basé sur JavaScript.
Le QSA toolkit sera composé de QSA library, le language Qt Script - basé sur la norme ECMAScript-, QSADevelopper - un IDE multiplateforme.

Aller plus loin

  • # interressant

    Posté par  . Évalué à 10.

    -ils ont l'air d'être parti de qt designer pour le faire.
    -les compétences en javascript étant répandus, ca va en interresser plus d'un.
    -par contre, la license n'est pas encore déterminée:
    "Pricing and licensing models are not yet finalized.".
    -espérons qu'on pourra essayer des versions de développement avant la sortie. fin2002 c'est tard.

    [OT] la pub pour teambuilder est drole.

    • [^] # Re: interressant

      Posté par  . Évalué à 10.

      Espérons que le modèle de licence sera compatible avec le logiciel libre ... En effet Trolltech produit du code de haute qualité, et il serait vraimment dommage de ne pas avoir de pont entre leur système de scripting et les logiciels libres :-/

      Leur modèle de licencing pour QT/X11 est un exemple de bon sens AMHA.

      • [^] # Re: interressant

        Posté par  (site web personnel) . Évalué à 4.

        C'est une très bonne idée de pouvoir scripter ses applis, pour les testeurs par exemple (ben oui, on refait passer la même batterie de tests sur toutes les version, quand il y en a 500, on est content d'avoir des scripts !)
        On pourrait rajouter ça dans GTK ?
        On met un inerpréteur dans la boucle principale ?
        Quelle est la différence avec le DCOP de KDE ?

  • # beuark

    Posté par  (site web personnel) . Évalué à 4.

    Ils auraient pu choisir python :-(
    -1 parce que ce que tout le monde ne porte pas python aux angesI

  • # Hop... deuxieme gui scriptable

    Posté par  . Évalué à 10.

    Au passage il existe quelque chose de similaire pour l'environement GNUstep: StepTalk/AppTalk (http://steptalk.host.sk/(...))

    StepTalk est multi langage (grace aux bundles) et permet d'appeler des DO (Distributed Object).

    On va finir par avoir des environnements puissants et souples :-)

    • [^] # Re: Hop... deuxieme gui scriptable

      Posté par  . Évalué à 10.

      Il y avait déjà dcop dans KDE qui permet de scripter les programmes (jette un oeuil à kdcop pour voir les application qui le supportent, sinon y a dcop en ligne de commande), c'est pas un language de script en lui-même, c'est mieux car ça peut être utilisé directement dans les languages de script existant.

      • [^] # Re: Hop... deuxieme gui scriptable

        Posté par  . Évalué à 10.

        Il faut justement espérer que le modèle de licencing retenu permettra l'inclusion de ce scripting au sein de KDE :-)

      • [^] # Re: Hop... deuxieme gui scriptable

        Posté par  . Évalué à 6.

        dcop tu scriptes à partir de ce qui existe dans le programme, non?
        Là tu as le langage de dispo dans l'appli, pour faire des virus de mails avec ton logiciels de mail par exemple.

        • [^] # Re: Hop... deuxieme gui scriptable

          Posté par  . Évalué à 3.

          dcop n'est pas un langage de script !
          dcop c'est un protocole basé sur xml-rpc (qui a donné soap). Soap, en fait, c'est du xml-rpc plus des trucs du w3c.

          dcop est plutôt l'équivalent de corba. On peut utiliser ce protocole avec du perl, python, java, ... (voir des exemples sur http://developper.kde.org(...) ou dans le module kdenonbeta dans le cvs de kde).
          Enfin, il serait tout à fait possible d'utiliser QT Script pour piloter des applis écrits en C++ ou autre à distance en utilisant le protocole dcop du moment que l'applis supporte dcop.

          :))))))))))))
          bobby

  • # Pourquoi encore un langage ? Et PyQt ?

    Posté par  . Évalué à 10.

    J'aime beaucoup la librairie Qt, et la possibilité de "scripter"
    une application est intéressante, mais là j'avoue ne pas bien
    comprendre...
    Pourquoi redéfinir un nouveau langage, fut-il basé sur
    JavaScript ? Par exemple, pourquoi ne pas s'appuyer sur
    PyQt (le portage de Qt en Python) pour faire cela ? Justement,
    je bosse sur l'intégration de Python dans une (grosse) application
    basée sur Qt, pour pouvoir exécuter des scripts...
    Pourquoi TrollTech ne se penche-t-elle pas davantage sur
    PyQt ? Toute l'infrastructure existe déjà !
    Pour info sur PyQt : http://www.riverbankcomputing.co.uk/pyqt/index.php(...)

    • [^] # Re: Pourquoi encore un langage ? Et PyQt ?

      Posté par  . Évalué à 0.

      « Pourquoi redéfinir un nouveau langage »

      Pour pouvoir le vendre ?

      • [^] # Re: Pourquoi encore un langage ? Et PyQt ?

        Posté par  . Évalué à 3.

        Pour pouvoir le vendre ET le diffuser en touchant une base d'utilisateurs plus large, les gens ayant déja utilisé javascript étant beaucoup plus nombreux que les utilisateurs de python (estimation au pifométre vu le nombre de sites faisant n'importe quoi en javascript).
        et aussi le coté "easy-to-learn" qu'ils mettent en premier sur le site, ce qui rejoint aussi l'optique de grande diffusion.

    • [^] # Re: Pourquoi encore un langage ? Et PyQt ?

      Posté par  . Évalué à 3.

      Un des avantages serait peu etre que le langage serait intégré par defaut dans le toolkit, ce qui est un avantage pour la distribution (ala tcl/tk). C'est un des gros pb de pyQt (et pyGtk): tu dois distribuer trois applis/bibliothèques: Qt, python et le wrapper.
      Au final ca peut poser bcp de pb, surtout quand tu vises le multiplateforme.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.