Journal Programmation multiOS

Posté par  .
Étiquettes : aucune
0
15
sept.
2006
Une interrogation que j'ai à chaque fois que j'ai besoin de programmer un outil graphique multi-OS : quel langage, quel toolkit utiliser, sachant que l'idéal est de n'avoir rien à installer sur le poste client ?

En plus, comme je suis un peu chiant, je préfère les langages interprétés!

Et vous, quand vous programmez, vous utilisez quoi pour être multi-plaforme ?

  • # Java ?

    Posté par  . Évalué à 6.

    Même si je n'apprécie pas trop ce langage, le plus adapté à ton besoins n'est-il pas java ?
    Mais bon il faut installer la machine virtuelle
    Mais qu'entendu par ne rien avoir à installer.
    Si tu programmes en qt en gtk, il faudra bien installer les bibliothèques.
    Tu pourrais aussi faire du python, tk (je crois) est intégré, mais il faut installer l'interpretteur python.
    Voilà en fait, je vois pas trop parce que forcément, il va faloir installer quelque chose (interpreteur, bibliothèque, machine virtuelle...)

    • [^] # Re: Java ?

      Posté par  . Évalué à 2.

      java marche tres bien en multi plateforme, mais je deplore toujours les performances deplorables de la jvm sous linux...

      Testez eclipse linux puis eclipse windows pour vous en rendre compte.

      Vraiment dommage.

      Niveau gui, SWT tourne tres bien sous windows, c'est relativement leger (packageable avec l'appli, clairement).

      SInon, effectivement, le denominateur commun a toutes les plateformes, c'est un ensemble vide, donc faudar toujours installer un truc en plus. Ou utiliser une techno largement repandue (genre Java, par exemple. Et merde, on retombe dans le travers precedent. :( )

      bref, le multiplateforme, c'est pas evident.

      • [^] # Re: Java ?

        Posté par  . Évalué à 3.

        A noter qu'avec Qt Jambi tu n'est plus obligé de choisire entre SWT et Swing
        http://www.trolltech.com/developer/downloads/qt/qtjambi-tech(...)

        • [^] # Re: Java ?

          Posté par  . Évalué à 1.

          Fun!!!
          Ca m'interesse pas mal, je trouve swt encore trop jeune et je suis pas fan du modele choisi (impossible de deriver els widgets de base, ca a tendance a vraiment saouler ca).
          a tester quand j'aurais 5 minutes

          • [^] # Re: Java ?

            Posté par  . Évalué à 2.

            Si tu es vraiment interessé , il y a eu une dépêche y'a pas longtemps sur le sujet
            http://linuxfr.org/2006/09/01/21276.html

          • [^] # Re: Java ?

            Posté par  . Évalué à 2.

            Si tu trouves SWT trop jeune, je doute que tu te satisfasse de Jambi qui, pour le coup, est vraiment jeunot.

            • [^] # Re: Java ?

              Posté par  . Évalué à 0.

              a voir, mais :
              Qt a deja quelques annees, jambi c'est bindings pour Qt, donc sensiblement la meme api si je ne m'abuse? Donc en gros, la maturite de jambi est celle de qt, modulo pas grand chose, non?

              Pour swt, par exemple, il a fallu attendre la version 3 (version actuelle) pour avoir des trucs aussi keuss qu'un spinner (comme un ascenseur, mais avec juste les fleches qui modifie une valeur numerique). C'est dans ce sens que je trouve SWT jeune.

              Pas mal d'evenements tres utiles etaient absent aussi en SWT2 et ne sont apparus en partie qu'a la version 3.

              Le dragndrop est aussi catastrophique (mais la pour le coup, ils y sont pas grand chose, SWT etant natif et java etant java, faut se fader la moulinette java/natif a la main, ca parait difficile de faie autrement)

              • [^] # Re: Java ?

                Posté par  . Évalué à 1.

                J'espère que tu plaisantes là.

                L'api a été remaniée pour la version 3 et la version 4.
                T'es pas sous KDE toi pour oser dire un truc pareil :)
                SWT, il manque plein de widgets tout simplement parce que au départ c'etait uniquemen la lib d'Eclipse et donc ceratins widgets n'etaent pas forcément necessaires (un peu comme à l'époque de GTK avec Gimp)
                Pourquoi Swt progresserait entre chaque version et et Qt stagnerait.
                Abandonnes un peu tes préjugés et essayes.

                • [^] # Re: Java ?

                  Posté par  . Évalué à 2.

                  heuuu pardon?

                  va falloir me relire mon canard...

                  L'api a été remaniée pour la version 3 et la version 4.
                  ouais, enfin ca reste une api assez vieille, donc mure...

                  SWT, il manque plein de widgets tout simplement parce que au départ c'etait uniquemen la lib d'Eclipse et donc ceratins widgets n'etaent pas forcément necessaires (un peu comme à l'époque de GTK avec Gimp)
                  oui, enfin ca change rien au probleme...

                  Pourquoi Swt progresserait entre chaque version et et Qt stagnerait.
                  heuuu, j'ai dit ca moi? marrant ca, parce que je le lit pas en tout cas.

                  Abandonnes un peu tes préjugés et essayes.
                  hihi.
                  deja fait (les deux ;-) ).

                  • [^] # Re: Java ?

                    Posté par  . Évalué à 2.

                    dsl mon poulet :) j'avais lu ton post sans relire celui d'avant.

                    Sorti du contexte j'ai eu l'impression que tu critiquais l'inertie plus que tu ne défendais sa maturité.


                    hihi.
                    deja fait (les deux ;-) ).

                    Et alors t'en penses quoi ?
                    Tu nous feras bien un petit journal sur le sujet à l'occasion.

                    • [^] # Re: Java ?

                      Posté par  . Évalué à 1.

                      baaah, Qt c'est fun, c'est bien pense, signal/slot c'est groovy, mais
                      1) c'est du c++, et le c++ c'est pas fun (desole pour le troll).
                      2) le code est pas standard.

                      donc ca me freine enormement.

                      d'ou mon interet de voir des bindings java.

                      Maintenant, c'est tout de suite moins interessant en java, vu que l'api de base est deja dans le langage et que donc ca se limite vachement plus vite a la GUI.

                      • [^] # Re: Java ?

                        Posté par  . Évalué à 2.

                        Y'a PyQT, hein. C'est fun comme du Python, donc (en ce qui me concerne) largement plus fun que du Java. Et c'est l'API de QT. Et c'est aussi multiplateforme que QT. Et c'est fourni sous les mêmes conditions de licences. Que demande le peuple? ;)

      • [^] # Re: Java ?

        Posté par  . Évalué à 1.

        Je me permet juste de préciser un point au niveau des différences de performances de la jvm sous linux et windows

        Elles sont effectivement moins bonnes au niveau toolkit graphique sous linux que sous windows.
        Par contre, hors toolkit graphique c'est plutôt idem.

        Donc la différence peut ne pas avoir d'importance suivant le type de programme développé ( En gros s'il y a une gui très complexe ou non, voir pas d'interface utilisateur du tout ).

        • [^] # Re: Java ?

          Posté par  . Évalué à 0.

          mmmmmh
          non pas que je remette en cause ton discours.

          mais bon.

          j'ai fait des benchs de servlets, donc absolument pas de gui du tout.

          windows/tomcat, windows/was, linux/tomcat et linux/was

          en gros :
          windows : tomcat was sensiblement meme perfs.

          linux : was 1.5 fois plus rapide que tomcat
          linux windows : linux was sensiblement meme perfs que windows tomcat/was. linux tomcat atomise par les autres.

          perso j'en tire que la jvm est pas bonne.

    • [^] # Re: Java ?

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

      Je suis plutôt Pythonneur, mais en effet Java a été créé (vendu, packagé, markeuté) dès le début pour être une couche sensée complètement masquer l'OS hôte.

      Mais... faut installer Java (et la bonne version) - et faut bien packager ton soft pour que l'utilisateur n'ait pas à intervenir (classpath bien sûr, mais éventuellement sécurité, signatures & Co).

      Sinon, suivant le besoin: un bon gros calcul côté serveur... et un butineur ouebe en face - là, y'a rien à installer sur le poste client, tu peux même faire du "Ouebe 2" avec Javascript et Xmlhttp.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: Java ?

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

      La grande partie des distributions intègre l'interpreteur python ( après bien sur pas tous le monde, mais très souvent la personne qui ne l'a pas, sait très bien comment l'installer ), donc du côté de linux, pour l'interpreteur c'est plutôt bon.
      Et pour Windows, il y a par exemple py2exe qui te permet de créer un .exe 'stand-alone' qui ne nécessitera donc pas l'interpreteur.

      Par contre je ne sais pas trop pour les autres OS...

    • [^] # Re: Java ?

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

      Mais bon il faut installer la machine virtuelle
      C'est bien là le problème. Même si la machine virtuelle de SUN existe pour les plate-formes les plus répandues, elle n'existe pas pour toutes les plates-formes... Qu'en est-il des systèmes Linux PPC, AmigaOS 4, Zeta, .etc ? Tout dépends où l'on place le curseur « multiplate-forme ». Un logiciel libre et multiplate-forme écrit en Java ne devrait être-il pas être testé et validé par son ou ses développeurs avec GNU Classpath ?

      • [^] # Re: Java ?

        Posté par  . Évalué à 1.

        Alors concernant java pour les plateformes linux autres que x86 tu as la machine virtuel de blackdown qui tourne sous x86, AMD64, SPARC and PPC
        ( cf http://www.blackdown.org/java-linux/java2-status/j2se1.5-sta(...) )

        Sinon tu peux utiliser gcj ( http://gcc.gnu.org/java/faq.html ), tu supporteras alors quasiment toute les plateformes de gcc (+ ou - cf http://gcc.gnu.org/install/specific.html où sur certaines architectures gcj ne compile pas ).

        Bon après, pour que cela tourne, il faut connaitre le plus petit dénominateur commun entre les différentes jvm et ne pas coder en utilisant les spécificités d'une plateforme.
        Le côté, je compile et j'utilise de partout et un peu usurpé il est vrai. Néanmoins le nombre de plateformes accessibles est assez élevé avec ce type de solution (je compile une fois et je distribue un bytecode utilisable sans me soucier de la cible).

  • # python+PyQt4

    Posté par  . Évalué à 7.

    python+PyQt4 est un couple à mon avis très intéressant pour de l'interprété.

    Certes, il y a quelques efforts à faire pour faire du python multi-plateforme (éviter les modules monoplateforme, faire attention aux séparateurs des chemins) mais c'est très acceptable.

    et QDesigner permet de concevoir facilement ces interfaces.

    • [^] # Re: python+PyQt4

      Posté par  . Évalué à 4.

      De même que Qt4 seul fonctionne très bien en multi-plateforme.
      Certes, faut faire du C++ à la sauce Qt4 et après, il suffit de zipper les quelques .dll avec pour Windows (sous Linux, je ne sais pas si Qt4 est maintenant distribué par la plupart des distributions).
      C'est vrai que j'oublie le gros inconvénient : il faut recompiler sur chaque plateforme...

    • [^] # Re: python+PyQt4

      Posté par  . Évalué à 3.

      Vu que la question ressemble à sondage, je poste ici, car j'utilise également Python+PyQt

      J'ai commencé sous linux. Pour des projets avec des potes qui ont windows, ça fonctionne aussi. Et maintenant je l'utilise sous MacOSX.
      Qt est à mon avis un très bon toolkit graphique, très bien fait, bien documenté, etc.
      Et puis la souplesse de python (et d'autres langages de script) est vraiment agréable.

      Bon j'aime bien python, donc je peux toujours me rappatrier sur les bindings GTK+ ou wxWidgets.

      Pour faire des applis simplistes, tkInter me convient très bien.

      Si je devais faire du multiplateforme graphique en C++, je me tournerai également vers Qt

  • # Smalltalk ...

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

    Au boulot, je programme en Java, et j'écris des fois des scripts Ruby. A la maison, je me penche plutôt sur Ruby et je recommence peu à peu à faire du Smalltalk avec Squeak.
    Smalltalk répond à tes besoins : portable, performant (vis à vis de Java), et surtout productif. La seule chose à installer chez le client est la VM, mais tu peux le faire avec ton programme.
    Par contre, si tu veux faire du développement Web, alors regarde du côté de Seaside, c'est un framework Smalltalk orienté composant, assez en avance, et très efficace.

  • # Peut-être XUL ?

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

    XUL est peut-être pas mal pour ce que tu veux faire. Il est multi-plateforme. Il faut développer en Javascript, mais bon, on s'y fait.

    Mickaël

  • # XUL

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Utilise XUL. C'est multi-plateforme, interfaces rapides à conçevoir, mise à jour autos, applis légères (sans compter xulrunner/firefox). Et tu peux utiliser la version de XulRunner embarquant python, pour faire des composants en python. (ou alors tu peux utiliser JS ou C++ pour tes composants).

    http://xulfr.org


    Sinon, tu cherches un truc qui n'a pas besoin de s'installer sur le poste client. Mais là tu en demande trop. Je dirais même, tu rêve. Que ce soit python, java, XUL ou autre, il faut toujours installer quelque chose sur le poste client : une JVM, un interpreteur, ou pour XUL, ce sera firefox ou xulrunner par exemple, en plus de l'application elle même.

    Ou alors faut que tu t'orientes vers du HTML pure, une appli web pure (avec des toolkits comme dojo, yahoo ...). Ou si tu sais que les postes en question possèdent tous un firefox, faire du XUL "distant". (appli web dont l'interface est en xul et non en html).

    • [^] # Re: XUL

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

      Il y a peut-être un truc qui m'échappe avec XUL, mais en utilisant XULRunner, il n'y a rien a installer, ou bien ? Tu peux fournir ton application sur un CD-ROM, par exemple, et il suffira de double-cliquer sur l'icône qui va bien pour la lancer, et ce, sans rien installer au préalable. Me trompe-je ?

      Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

  • # trop vague

    Posté par  . Évalué à 5.

    Si pour toi l'idéal est de ne rien installer sur le poste client, alors utilise un framework web, tel que Ruby on Rails ou Django pour python.

    Si tu veux dire que tu souhaites développer une interface native en installant le moins de chose possible, alors il existe ruby/GTK+, ruby/Qt, python/GTK+, PythonQt, ...

    Ensuite le côté multi-plateforme, est-ce Window, Linux ou Windows, Linux Mac ? si c'est le trio alors tu peux éliminer les solutions en GTK+ qui n'est pas natif sur Mac pour l'instant. Reste les solutions en Qt et WXWidgets.

    Dans tous les cas il faut bien être concient que développer un logiciel multiplateforme revient à sacrifier un grand nombre de fonctionnalités offerte par le desktop. Personnellement je préfère de loin que mon logiciel soit bien intégré à mon desktop et supporte toutes ses fonctionnalités ainsi que celles de l'OS sous-jacent. Le multi-plateforme c'est être moyen partout et correctement intégré nul part.

  • # Illusion d'optique...

    Posté par  . Évalué à 9.

    En l'espace d'un instant, en lisant ton journal, j'ai cru lire MultiDeskOS...

    J'ai eu peur lol !

    • [^] # Re: Illusion d'optique...

      Posté par  . Évalué à 6.

      je crois que MultiDeskOS peut répondre parfaitement à la question posée dans ce journal : portable, performant, rien à installer (grâce à la technologie BackToTheFutureOS(tm), où les toolkits pas encore existant, y compris QT5, sont déjà pris en compte), interprété.

      (moi aussi j'ai eu cette illusion d'optique...)

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # juste comme ça...

    Posté par  . Évalué à 2.

    Moi j'ai une question de parfait inculte : est-ce qu'avec la récente libération du code de Java, on va pouvoir espérer des applis plus rapides sous linux ? Je pense à des projets comme looking glass qui, bien qu'alléchants, pêchent par des performance à faire passer un Win$ ME pour une bête de course...

    A part ça moi le code j'y connais rien mis à part un peu de basic dans ma jeunesse et changer la couleur de mon texte en html donc j'assume le caractère débile de ma question.

    • [^] # Re: juste comme ça...

      Posté par  . Évalué à 3.

      A ma connaissance, Java n'est pas encore libéré. Il y a juste des rumeurs (annonces) persistantes que la machine virtuelle de Sun sera prochainement libérée.

      Après s'il y a des développeurs meilleurs que ceux de Sun [certains doivent croire que Sun fait exprès de ralentir Java sous Linux], il est peut-être possible d'améliorer les choses sous Linux (mais la libération de StarOffice n'a pas fait de miracles de ce point de vue pour OpenOffice).

      • [^] # Re: juste comme ça...

        Posté par  . Évalué à 1.

        Il y a juste des rumeurs (annonces) persistantes que la machine virtuelle de Sun sera prochainement libérée.

        Ha oui, effectivement, il est prevu que la machine virtuelle de Sun soit très prochainement libérée, le problème c'est que ca fait de nombreuses années que c'est comme ca. Mais ptet qu'un jour, à l'occasion de la sortie de Duke Nukem Forever, ils se décideront ...

    • [^] # Re: juste comme ça...

      Posté par  . Évalué à 2.

      TrollTech a sorti une version beta du binding de QT en Java (Jambi). Gnuclasspath + QT Jambi + une VM libre ça pourrait faire l'affaire, non?

    • [^] # Re: juste comme ça...

      Posté par  . Évalué à 4.

      Pour les performances de Looking Glass, ce n'est pas lié à Java mais plutôt à :
      1- Nous et nos erreurs de programmation (je suis un contributeur du projet, je précise)... Exemple : on provoque de beaux memleak qui nous font garder en mémoire beaucoup de textures (c'est corrigé/en cours de correction dans le CVS là)
      2- Java3D, mais ça s'améliore

      Les différences de performances que l'on peut obtenir en corrigeant notre code montrent clairement que c'est pas la faute à Java...

  • # c++ + wxwidgets

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

    c++ (le meilleur langage, élégant robuste et puissant) et wxwidgets (le meilleur tookit graphique), compilé en statique. Avec ça t'as un programme qui ne rame pas contrairement au même en python ou java, qui est auto-suffisant ( par de dépendance sur d'autres libs) et qui s'integre bien

    • [^] # Re: c++ + wxwidgets

      Posté par  . Évalué à 5.

      c++ (le meilleur langage, élégant robuste et puissant)

      ça c'est de l'objectivité! Car tout le monde aujourd'hui s'accorde pour pointer du doigt les incohérences du langage. Je programme principalement en c/c++ dans mon boulot, et je suis loin d'arriver à la conclusion que le c++ soit élégant ou robuste. Après 10 ans de programmation intensive dans ce langage, j'en apprend encore tous les jours, donc d'accord sur le fait qu'il soit puissant (trop?)...
      Quant à dire si c'est le meilleur, ça dépend, comme toujours de ton besoin...dans le cas du monsieur ici présent, je ne pense pas...

      wxwidgets (le meilleur tookit graphique)

      Là je ne peux qu'être d'accord, vu le nombre de fois ou il m'a sauvé la mise ce toolkit... comme quoi l'objectivité, tout ça... :D

      • [^] # Re: c++ + wxwidgets

        Posté par  . Évalué à 4.

        Ben pour un monsieur qui ne veut rien avoir à déployer sur le poste client si ce n'est l'exécutable, et être multi-plateforme C et C++ représentent une des rares alternatives, mais avec un surcoût non négligeable.

        Sinon, tu peux tenter le FreePascal.

        • [^] # freepascal

          Posté par  . Évalué à 2.

          +1 pour freepascal, avec lazarus qui commence à être un très bon outil pour faire du multiplateforme.

    • [^] # Re: c++ + wxwidgets

      Posté par  . Évalué à 1.

      Le monsieur veut de l'interprété; pourquoi pas wxLua alors?

      • [^] # Re: c++ + wxwidgets

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

        wxlua ca ne marche même pas avec la distrib officielle de Lua :(
        Sinon, je confirme que Lua est un très bon langage, simple (très simple) rapide, léger ... toute les qualités. Le seul problème c'est qu'on a pas de batteries included comme en python, mais avec wxlua ca doit etre différent.

        Le manuel du langage + l'API C tient sur une seulle page HTML de 226KB
        http://lua.org
        http://wxlua.sf.net

    • [^] # Re: c++ + wxwidgets

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

      [blockquote]wxwidgets (le meilleur tookit graphique)[/blockquote]

      Ne goûte jamais à Qt(4), tu pourrais bien changer d'avis.

    • [^] # Re: c++ + wxwidgets

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

      +1

      C++ est le plus multi-plate-forme des languages modernes (sinon il y a C, mais il lui manque l'objet...), certes il n'est pas dès plus cohérant mais au moins il est normé, tout ca...

      et WxWidget est aussi multi-plate-forme est surtout multi-compilo (essayez QT sous un compilo pas trop habituel, qu'on rigole...)

      Le tout pour des executable qu'on n'a pas a installer etc... Juste un fichier sans dépendances.

      Oui, c'est le couple que j'utilise et j'en suis content :)
      Par contre c'est compilé (faut choisir entre compilé ou installer quelque chose, un language interprété doit être interprété, donc l'interpréteur, qui lui est compilé, doit être installé...)

      • [^] # Re: c++ + wxwidgets

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

        et WxWidget est aussi multi-plate-forme est surtout multi-compilo (essayez QT sous un compilo pas trop habituel, qu'on rigole...)


        Ouais enfin, je persiste à penser qu'ils ne boxent pas vraiment dans la même catégorie, surtout depuis Qt4.
        Et j'ai pratiqué les deux.
        Rien que la doc de Qt, ça fout sur le cul.
        Tu prends Designer, pareil. Et ce qu'ils ont fait pour Designer4 avec leur système de multi héritage Widget/Ui est tout bonnement extra.
        Encore un peu d'effort et on retrouvera la simplicité de Delphi, sans ses défauts.

  • # Précisions

    Posté par  . Évalué à 2.

    J'étudie le fait de coder un éditeur d'article SPIP qui pourrait être utilisé sur le poste client (linux/win/mac) même lorsque ce dernier est déconnecté. Un peu comme thingamablog.

    Le problème est que ma formation de développeur est lointaine, donc j'ai oublié tous les langages compilés, je n'utilises en majorité que PHP et des langages de script.

    Par contre, les réponses que vous donnez ne doivent pas être orientés à mon projet, mais devrait pouvoir aider d'autres personnes que moi. Si vous avez des retours d'expériences, n'hésitez pas à donner des liens vers vos projets, vers des tutoriels...

    • [^] # Re: Précisions

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

      pourquoi pas un binding gtk pour php ?
      Je n'aime pas trop php bien que je conaisse bien ce langage, mais ça se fait
      http://gtk.php.net/

      • [^] # Re: Précisions

        Posté par  . Évalué à 2.

        Chaque année, j'y repense à php-gtk, mais je n'accroche pas. Peut-être parce que j'ai l'impression que le projet est mort, ou que personne ne l'utilises, ou que ça n'a pas d'avenir par rapport aux autres projets... je ne sais pas. J'accroche pas.

  • # Python+GTK

    Posté par  . Évalué à 1.

    Perso, j'utilise python avec GTK. L'avantage, lorsqu'il s'agit de distribuer le programme pour windows, c'est qu'il existe des utilitaires qui permettent de "packager" tout ce qui est nécessaire, l'interpréteur python, les DLLs GTK, ... Donc il n'y a plus besoin d'installer 25 bibliothèques, ni un environnement python complet. Et pour linux, c'est du "just work" puisque toutes les dépendances sont en général déjà là.

    Sous OSX, je ne sais pas, j'ai jamais essayé, mais si quelqu'un a une solution je suis preneur :)

    • [^] # Re: Python+GTK

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

      GTK sous OSX c'est l'horreur ! lourd, lent et pas du tout integré.

    • [^] # Re: Python+GTK

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

      Package tout ca... Certes, la bande passante doit etre gratuite sur ton serveur, mais perso j'aime les logiciels plus léger.
      Et bravo aussi pour "ne rien installer", ca isntalle plein de chose ta solution non?

      • [^] # Re: Python+GTK

        Posté par  . Évalué à 1.

        J'ose tenter une réponse: si c'est comme les solutions du même type existant pour Ruby, non cela installe rien. Cela crée une archive (zip en générale), qui s'auto extrait de façon dynamique (et temporaire, mais possiblité de le l'extraire dans un rep de facon définitive) et qui execute dans la foulé le script principal de l'archive par l'interpréteur embarqué dans l'archive elle-même.
        Donc cela n'installe rien sur le dd a part un +/- grosse archive auto-exécutable...
        Pour Ruby (peut-être aussi pour Python je ne saurais le dire mais je pense), tu as un type d'archive auto-executable un peu intermédiaire où tont programme et des modules/libs peuvent être rajouté, mais qui n'embarque par l'interpréteur, et les libs standards/systèmes. Moins gros donc en définitive (plus portable aussi car lorsque tu embarque l'interpréteur ou des modules/libs compilés tu es dépendant du système cible), mais qui implique une installation plus ou moins minimale du langage choisi....

        • [^] # Re: Python+GTK

          Posté par  . Évalué à 1.

          En gros, c'est ça.

          Le truc s'appelle py2exe, au fait, si jamais ça intéresse quelqu'un.

          L'avantage est de ne pas avoir à installer gtk+, python & co. Tout est empaqueté. Evidemment, on passe de 250Ko à un petit Mo à télécharger. Mais comparé à demander à un béotien d'installer un environnement python + les bibliothèques GTK + pygtk + machin.. c'est un moindre mal, il me semble.
          Et seuls les modules vraiment utilisés sont inclus, il n'y a donc pas beaucoup de gaspillage.

  • # Et Rebol ?

    Posté par  . Évalué à 0.

    Peut être mieux que java (parceque un peu plus jeune, même s'il a plusieurs années, esssaye donc de voir du côté de Rebol, c'est étonnant.
    http://rebolzone.free.fr/rbview.php
    et bien sur
    http://www.rebol.com

  • # Mono et Php-Gtk

    Posté par  . Évalué à 1.

    Personnellement, je n'ai jamais été séduit par les langages tels que le C++ ou Java pour des raisons fort différentes. C++ pour des raisons de complexité et de rugosité évidentes. Le langage est difficilement portable. Recompil obligatoire à chaque changement de plates-formes.

    Concernant Java, la conosmmation mémoire et la vitesse d'exécution m'ont toujours rebuté.

    Mono, avec MonoDevelop, est un excellent outil Rad qui saura répondre à vos besoins. Je suis avec curiosité également l'évolution de Php-Gtk.

    • [^] # Re: Mono et Php-Gtk

      Posté par  . Évalué à 3.

      C'est pas bientôt fini les trolls sur la vitesse de Java ? Sortez des chiffres au moins !

Suivre le flux des commentaires

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