Journal GUI portable

Posté par  .
Étiquettes : aucune
0
13
juin
2005
Cher journal, toi qui sait tout,

j'ai une question pour toi*.

je cherche à faire des petits programmes graphiques de sciences physiques pour mes élèves et aussi les autres (genre équilibrage d'équations chimiques, tableau d'avancement, association de lentilles,...). D'après mes recherches sur le grand Ternet je sais qu'il n'existe pas grand chose si ce n'est le trio bien vieillissant Lum/Xem/Mek de Ghislain Picard, ou des appliquettes javascript disparates de qualités inégales et pas toujours libres. Donc il faut quelqu'un pour s'atteler à la tâche. Sachant que malheureusement la majorité de mes élèves et des établissments sont sous windows (bien qu'un de mes élèves de 4ème de cette année tourne sous Mandriva et Suse), il me faudra quelque chose de portable.

Ce que je cherche c'est donc un couple langage/GUI à la fois portable et facilement déployable sur win.

Maintenant mes préférences:
- plutôt un langage de script (par ordre de préférence: ruby, python, perl, ...)
- installation facile du langage et de la boite à outils graphique (si possible tout en un)
- pas des gigas de dépendances
- putôt un look à la gtk

Mes recherches mon conduit au couple ruby/fox. A priori c'est ce qu'il y a de plus simple pour l'installation grâce à rubyinstaller (http://rubyinstaller.rubyforge.org/wiki/wiki.pl(...) ). Il vient aussi avec Tk mais je trouve les widgets vraiment tropabôs. Que penses tu de cette solution?

Sinon, est ce que tu peux me donner des avis sur des choses tel que:
- l'install de gtk+gtkruby sur win
- .net/mono avec une GUI (et laquelle)
- pourquoi pas faire des javascript (à part que je connais pas le js mais ça peut être une bonne raison de s'y mettre)
- autre, ...

Petite précision, je n'ai pas de zin sous la main, sinon je ne t'embeterais bien évidement pas avec mes questions. J'aurais éssayer tout seul comme un grand. C'est aussi pour ça je pense qu'un langage de script serait plus simple (et pour d'autres raisons bien sur).

Voila toutes mes questions qui sont dans ma tête cher journal. Je suis ouvert à toutes tes propositions.



* Alors, je sais tu vas me dire que pour les questions c'est fait pour ton pote le forum, mais vu ma question et l'usage fait des forums (peu de réponse et questions essentiellement techniques), je pense que je trouverais plus de solutions à mon problème ici.
  • # du choix, du choix :)

    Posté par  . Évalué à 4.

    Effectivement t'as le choix, voici une petite liste à laquelle je pense :
    vu que tu cherches plutôt script, avec ruby ou python tu as accès à Qt et GTK sans soucis il me semble mais j'ai jamais fait de GUI avec du script.

    Pour le côté javascript tu pourrais regarder du côté XUL, tu peux faire des choses très bien avec, et il te suffit d'avoir un mozilla installé pour faire tourner ton appli (je sais pas où ça en est avec XULrunner).

    Sinon tu parlais de .Net/Mono, niveau GUI portable y'a pas trop le choix à part GTK il me semble. les WinForms sont en cours de portage sous mono mais je me suis pas plus renseigné que ça.

    Après perso, j'ai fait du GTK, Fox, Qt et WinForms (premier en C, les 2 autres C++ et le dernier en C#) et j'avoue que ma préférence va nettement à Qt, que je trouve vraiment bien foutu. Attention je ne parle qu'au niveau toolkit graphique, le framework .NET étant vraiment un truc super bien foutu mais les WinForms valent pas la conception possible avec Qt Designer (mais c'est mon avis).

    Voilà voilà :)
    • [^] # Re: du choix, du choix :)

      Posté par  . Évalué à 2.

      Merci pour le XUL (et merci aussi à Romain qui a eu la même idée). Je n'y avais pas pensé, mais je vais me pencher sur le sujet.
    • [^] # Re: du choix, du choix :)

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

      J'aurais également tendance a te conseiller qt plutot que gtk ou wxwidget. La qualité de Qt est bien meilleure et sa programmation plus facile (je ne connais pas fox et ne jugerai donc pas par rapport à lui)

      De plus, tu as PyQt qui, bien que je n'ai pas (encore) essayer, semble génial.

      Cependant, j'espère que tu as un peu de temps devant toi (je supose que oui puisque c'est la fin d'année scolaire) : Qt4, d'après ce que je sais, ne sors que dans un mois en GPL sous win. De plus, il faudra certainement attendre que PyQt se mette à jour.

      Par contre, rien ne t'empeche de les créer maintenant en Qt3 sous linux et de le porté en Qt4 sous windows par la suite.

      PS : PyQt est normalement multiplatforme, mais je ne peut pas te dire si l'installation sous windows est facile ou non

      PS2 : quand au "look à la gtk", sous windows ça ne change pas grand chose, c'est toujours aussi moche...
      • [^] # Re: du choix, du choix :)

        Posté par  . Évalué à 1.

        Ben qt,... comment dire,... je ne remets pas en cause sa trés grande qualité, je ne veux surtout pas troller sur le sujet bientôt dépassé de sa liberté,... c'est juste que visuellement je n'y arrive pas.

        Je sais, c'est trés trés con, mais il y des trucs comme ça, complètement absurde qui vous bloquent des horizons.

        PS: A quand un thème classique à-la Gtk/Gnome avec les icônes et tout pour Qt/KDE
        PS2: Et non! Il vaut mieux pas que je me lance dans une telle entreprise, le remède serait pire que le mal ;-)
        • [^] # Re: du choix, du choix :)

          Posté par  . Évalué à 4.


          c'est juste que visuellement je n'y arrive pas.


          J'avoue que je comprend pas , Qt adopte le look and feel de la plateforme native et tu peux en switcher dynamiquement.
          En plus tu dis toi même que tu n'as que Windows.

          Tiens regarde une appli qt sous Windows
          http://albumshaper.sourceforge.net/(...)

          Enfin on ne va pas insister si t'es allergique
          • [^] # Re: du choix, du choix :)

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

            Je rencheris sur PyQt. Tres agreable, tres rapide.

            Sinon, en partant de python, il est facile de generer des .exe avec py2exe, voire de genrerer des installeurs en utilisant NSIS ou InnoSetup.

            En une demi-heure, tu peux te faire un executable windows tout ce qu'il y a de plus classique. Le seul hic, c'est que PyQt prend pas mal de place. 3,5 Mo en compression bzip, je trouve ca beaucoup. 13 Mo en non compresse.

            La situation devrait s'ameliorer avec la sortie de Qt4, qui sera separare en plusieurs composants.

            Compte tenu de ton objectif, je recommande des toolkits de haute qualites. Pour moi, ca veut dire Gtk ou Qt. Les autres toolkits graphiques sont bases sur une programmation evenmentielle qui est plus lourde a gerer que les signaux/slots.
      • [^] # Re: du choix, du choix :)

        Posté par  . Évalué à 2.

        En effet, PyQt est très facile et agréable à programmer (pour peu que l'on adhère à la "philosophie" Qt).

        De plus, je signale qu'il existe une version compilée de Qt3 pour win32 depuis le site de l'impressionnant éditeur Eric, ainsi que d'une version précompilée de PyQt (toujours pour win32).
        Je n'ai pas été voir le détail des licences cependant...

        PS: attention, les libs win32 sont compilés avec python 2.4.

        http://www.die-offenbachs.de/detlev/eric3.html(...)
        http://www.quadgames.com/download/pythonqt/(...)

        Pour Qt, il y a aussi les bibliothèques graphiques Qwt et Qwt3D qui ont des bindings Python. Il y a aussi matplotlib qui est un bon package de "plotting" avec une syntaxe à la Matlab, mais qui dispose aussi d'une API plus "pythonique" avec des classes etc.

        De plus, l'ensemble de la bibliothèque Vtk est aisément utilisable à partir de PyQt, ce qui laisse pas mal de possibilités, mais qui reste une usine assez lourde.

        Enfin, de nombreux projets autour de python pour la chimie et la biologie existent, voici quelques liens :
        http://www.biopython.org/(...)
        http://pymol.sourceforge.net/(...)

        David
  • # wxwidgets ?

    Posté par  . Évalué à 5.

    je ne sais pas si c'est bien ce que tu demandes mais je ce que j'en ai compris:

    http://www.wxwidgets.org/(...)
    "An open source C++ GUI framework to make cross-platform programming child's play. Well, almost."
    • [^] # Re: wxwidgets ?

      Posté par  . Évalué à 2.

      Effectivement, je l'avais mis dans ma liste au début, puis je l'avais sortit car je cherchais un installateur tout en un (quand on à une idée en tête!). Mais au vu de http://wxruby.rubyforge.org/wiki/wiki.pl?WxRuby_Tutorial(...) l'install à pas l'air trop difficile, et en plus il est pas trop gros.

      Merci de l'avoir remis dans la course.
      • [^] # Re: wxwidgets ?

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

        Il y a aussi wxPython si tu preferes le Python... En plus ca a l'air pas mal utilisé (quand je recherche des docs sur wxWidgets, j'arrete pas de tomber sur des exemples en Python...)
  • # XUL a de l'avenir

    Posté par  . Évalué à 3.

    Je pense que tu devrais jeter un oeil du coté de XUL+JS (interface graphique en XML).

    plutôt un langage de script
    Javascript.

    installation facile du langage et de la boite à outils graphique
    Firefox (+ un petit lien sur le bureau ou autre)

    pas des gigas de dépendances
    idem.

    putôt un look à la gtk
    Look : natif
    • [^] # Re: XUL a de l'avenir

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

      Surtout avec les premiers binaires dispo de XulRunner, le runtime engine des technos Mozilla :

      http://wiki.mozilla.org/XUL:Xul_Runner(...)

      Une intro en francais sur XulRunner (à enrichier, c'est unwiki ;) :
      http://xulfr.org/wiki/XulRunner(...)
    • [^] # Re: XUL a de l'avenir

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

      Il peut être intéressant alors de se pencher sur SVG ... Surtout qu'il est désormais disponible (Deer Pack alpha 1) chez Mozilla (donc Windows, GNU/Linux, MacOS)
    • [^] # Re: XUL a de l'avenir

      Posté par  . Évalué à 6.

      Je bosse depuis 2 mois sur une appli interne en XUL, et j'avoue avoir une impression en demi-teinte.

      points positifs:
      - facile de créer les objets composant l'interface
      - peut être utiliser en local ou depuis un serveur web
      - facilement modularisable
      - possibilités d'évolution

      points négatifs:
      - la doc !!!!!! A mon goût très incomplète, il faut parfois chercher des heures pour comprendre comment implémenter une fonction précise, les sites xulplanet ou xulfr sont très bien mais aussi très loin de couvrir en détail toutes les facettes de la plateforme
      - problème de rafraichissement des sources RDFs (mais un moyen détourné permet de corriger ça)
      - programmer en javascript est plutôt frustrant par rapport à d'autres langages (PHP, Python...)

      Donc j'aime bien le XUL, mais faut vraiment améliorer la doc dispo sur Internet !!
      • [^] # Re: XUL a de l'avenir

        Posté par  . Évalué à 1.

        Je plussoie :)
        Je suis en train de faire un plug-in pour un site et j'aimerais utilisé une/des sources rdf et il manque vraiment de la doc là-dessus :(
        Je lutte pas mal pour réussir à faire ce que je veux ...
  • # python

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

    Sans sortir l'artillerie lourde ...

    pourquoi pas python+pygtk
    après tu pourrai même profiter de vpython (http://vpython.org/vpythonprog.htm)(...) pour faire de la physique amusante ... voire pygame(sdl) pour encore plus de fun

    je dis ça, je dis rien ... mais je sais que le python est déjà pas mal utilisé en physique, donc y aurait moyen de pouvoir faire de la récup
    • [^] # Re: python

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

      et j'oubliais, il y a, justement pour win, des packages "à-la movable python" ... qui contient tout ce qu'il faut pour faire du python : movpy :
      http://www.voidspace.org.uk/python/movpy/distributions.html(...)
      celui là contient wxpython et d'autres packages interessants

      moi j'utilise principalement celui là : sap24 : http://arctrix.com/nas/python/standalone.html(...)
      sur lequel j'ai ajouté pygtk et lxml sans aucune difficulté ...
      • [^] # Re: python

        Posté par  . Évalué à 1.

        Je ne connaissait pas ces petites choses interressantes que sont movpy et sap24. Par contre pour ce dernier, d'après le lien que tu donnes, il faut un sap24 par appli que tu distribus ou bien j'ai rien compris. Pour movpy j'ai pas vu où il fallait mettre les scripts, mais bon je pense qu'il suffit de chercher un peu.
        • [^] # Re: python

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

          et y en a d'autres ...
          mais c clair qu'il y a des différences entre movpy et sap24
          pour movpy, il faut associer les py avec l'exe movpy je crois
          pour sap24, il faut placer les scripts dans un rep spécial

          sap24 est plus orienté pour distribuer un prog et son environnement
          movpy est plus orienté environnement python portable

          les 2 sont interessants dans leur domaine respectif ...
    • [^] # Re: python

      Posté par  . Évalué à 2.

      Pour répondre à un peu tous les commentaires plus haut, je me suis récemment posé la question pour une appli... sous python/wxwidget.
      Je me suis arraché les cheveux dessus pendant pas mal de temps pour faire marchouiller une pauvre arborescence de fichiers sous linux, la même appli tournait déjà sous windows. Au final, j'ai presque du doubler le code à coups de
      if sys.platform == 'win32':
      babla
      else:
      blibli

      Après, portage sous MacOS quasi trivial.

      J'aimerai bien changer le langage, justement parce que l'arbre marche très mal sous linux et macos...

      * GTK, c'est bien, mais y'a rien de bien sous MacOS. Avoir pour un source de 4Mo, 70Mo pour un paquet, c'est un peu fort de café selon moi.
      * QT est pour le moment pas un bon choix pour moi : pas encore libre sous Windows.
      * wxwidgets oublié donc...
      * XUL : pas encore vu le défaut, à part qu'il faudrait que j'apprenne tout depuis 0. Et que je reprogramme quasiment toute l'application.
      * fox : j'avoue ne pas avoir regardé, mais sous MacOS il faut un serveur X11 sur la machine, j'ai pas envie de créer cette dépendance (D'ailleurs, cette histoire écarte déjà GTK du lot des trucs utilisables).

      Du coup, je me retrouve coincé. Et j'en viens à me demander si je ferai pas mieux de reprendre le code, bien séparer GUI/Appli, et faire un truc propre à chaque os : cocoa pour macos, qt ou gtk pour linux, et gtk pour windows
      • [^] # Re: python

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

        je comprends pour wx, moi même je me suis bien arraché les cheveux entre les problèmes de compatibiltiés ...

        pygtk : à côté ; ça marche partout de la même façon ... c'est certes peut être pas très beau sous win, mais ça marche vraiment bien.
        (qques soucis avec les threads sous win, mais rien de bien grave, la communauté pygtk est plus que présente par rapport à wx, et la pygtk faq est une mine d'or)

        faut un x11 sous mac pour pygtk ?!.?
        • [^] # Re: python

          Posté par  . Évalué à 1.

          "The extra component you need to install for PyGTK to work on Mac OS X is
          the X server. This is because there isn't a native (cocoa, aqua?) gdk
          backend written yet. As soon as there a gdk backend written it will be
          trivial to support it in PyGTK. I don't think anyone is actually working
          on one at the moment. So no, at the moment there are no plans."

          http://www.daa.com.au/pipermail/pygtk/2005-January/009428.html(...)


          Et c'est pour ça que je ne peux pas me permettre d'utiliser gtk pour mon machin. En plus d'avoir à faire un paquet gigantesque pour une application ridicule, il faudrait que l'utilisateur lambda ait à installer X11. C'est tout bête, mais je n'en veux pas.
          • [^] # Re: python

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

            ça je ne savais pas !
            C'est un peu bête effectivement ... je croyais que gtk tournait sous mac os ... je suis un peu déçu ;-(
          • [^] # Re: python

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

            j'ai trouvé ta soluce ...

            en fait, python (toujours)
            mais en utilisant un GUI basé sur pygame, ainsi ça marchera partout, il n'y aura qu'une lib : pygame ...

            il y a ce genre de module pour gérer de l'interface : http://pyui.sourceforge.net/(...)

            et ce genre pour gerer le filesystem :
            http://pyfile.sourceforge.net/(...)

            après, je pense que l'intégration de vpython doit se faire sans prob ...
            • [^] # Re: python

              Posté par  . Évalué à 1.

              J'avais déjà fouiné du coté de pyUi mais il semble que le projet avance au ralenti et hormis le rendu OpenGl ce n'est pas très stable

              http://sourceforge.net/forum/forum.php?thread_id=1273014&forum_(...)
            • [^] # Re: python

              Posté par  . Évalué à 1.


              ça je ne savais pas !
              C'est un peu bête effectivement ... je croyais que gtk tournait sous mac os ... je suis un peu déçu ;-(


              Il suffit de voir la galère que ça a été pour avoir un paquet de inkscape en "standalone" (bon, faut toujours avoir X11, donc c'est toujours pas ça) :
              http://www.inkscape.org/cgi-bin/wiki.pl?CompilingMacOsX(...)
              On arrive a des résultats exhorbitants : 70Mo à télécharger, plus de 130Mo en installé, pour l'équivalent de 5Mo de binaire sous Linux.
              Et le plus frustrant : si tu as Gimp d'installé, ben sache que tu auras deux fois tout le nécessaire gtk sur ta machine. Chaque paquet embarque tout le nécessaire de gtk pour pouvoir lancer l'appli. Après, il faut ajouter la dépendance à X11...



              il y a ce genre de module pour gérer de l'interface : http://pyui.sourceforge.net/(...)(...)

              et ce genre pour gerer le filesystem :
              http://pyfile.sourceforge.net/(...)(...)

              Je jetterai un oeil sur pyfile. Le problème c'est que les besoins sont assez "spéciaux" : les icônes des répertoires peuvent changer selon l'état du fichier dans un tar.

              Pour pyui, euh... tu veux que les utilisateurs soient morts de rire en voyant la laideur du truc ? :D En plus, c'est intégré à rien du tout. wxwidget, au moins, ça ressemble vaguement à du qt, vaguement à du gtk, etc. Ca ressemble à quelque chose quoi :-)


              Pour la proposition de Jython : pareil que X11 : ajouter une dépendance à une machine virtuelle, sous MacOS, ça ne me dérange pas trop trop, mais sous windows ou linux, un peu plus. On oublie donc.
              • [^] # Re: python

                Posté par  . Évalué à 1.

                Java =>Runtime (JRE)
                Mozilla =>Runtime (XulRunner)
                Mono =>Runtime (CLR)
                GTK, Fox =>X11

                Tes choix se réduisent donc QT ou wxWidget

                Après à toi de trouver les bons bindings avec le langage qui te convient et les lib accessoires qui te manquent
                Pour wxPython tu as encore une couche d'abstracion supplémentaire
                avec wax et pythoncard
                http://wiki.wxpython.org/index.cgi/Wax(...)
                http://wiki.wxpython.org/index.cgi/PythonCard(...)

                Après à il faut encore trouver des moyens d'empaqueter le tout sinon tu te retrouveras de nouveau avec une dépendance à un intreprète pour ton langage de script.

                Bonne quête du Graal et poste un nouveau journal avec tes choix et motivations quand tu auras décidé. Ca peut servir aux autres
              • [^] # Re: python

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

                pour python alors, il reste wxpython qui lui "devrait" fonctionner partout ...
                peut être voir avec lua, il existe wxlua aussi ... (jamais essayé)

                sinon, dans le genre minimaliste, et ça m'arrive d'avoir recours à ça ... de faire mon appli en python, et de présenter le gui dans un navigateur web, via un http server embedded dans le python ...

                en partant avec cherrypy2 pour réaliser simplement, en python, un site web (avec le server http embedded)... tu peux générer du html (voir du xul) (avec ou sans un moteur de template)... et tu assaisonnes le tout avec du javascript (du genre : http://openrico.org/home.page(...) , pour avoir des fonctionnalités puissantes : ajax, d'n'd, ...), et faire un GUI digne de ce nom

                après compiler, avec des py2exe ou cx_freeze, ça fait des package de 1mo en gros ... c multiple plateforme, à condition d'avoir un navigateur sur le client, et ça peut marcher pour plusieurs clients multi os ... ça reste scriptable ... et tu peux même faire communiquer les progs entre eux, avec les xmlrpc embedded à python

                en plus, c fun à faire, rico est sympa et simple ... et cherrypy2 : ce n'est que du bonheur ...
      • [^] # Re: python

        Posté par  . Évalué à 1.

        Et t'as essayé Jython/SWT.

        Pour Mozilla:
        le scripting python coté client n'est pas encore pour demain même si c'est en projet.
        Après tu peux developper des composants XPCOM en python mais ca devient plus complexe.On en a parlé là:
        http://linuxfr.org/comments/586007.html#586007(...)
  • # DrScheme ?

    Posté par  . Évalué à 2.

    et pourquoi pas DrScheme
    c'est complet et c'est parfais pour un environnement scolaire ... c'est fait pour ça

    http://www.drscheme.org/
    Extrait....
    DrScheme is an interactive, integrated, graphical programming environment for the Scheme, MzScheme, and MrEd programming languages.

    DrScheme runs under Windows (95 and up), Mac OS X, and Unix/X. Download DrScheme.

    DrScheme provides source highlighting for syntax and run-time errors, support for multiple language levels, an algebraic stepper, objects, modules, a GUI library, TCP/IP, and much more.
    • [^] # Re: DrScheme ?

      Posté par  . Évalué à 1.

      Si on va vers les langages moins usuels (?), il y a squeak aussi qui pourrait très bien faire l'affaire.

      En fait, ce serait même une bonne idée je pense pour ton projet. Ça tourne sur toutes les plateformes habituelles, et ça intègre plein de trucs pour faire des applis vite fait et très facilement "scriptables" (voir le programme de 'jeu' où il faut écrire un automate de conduite automatique de voiture, par ex.).

      Évidement, il faut se mettre à Smalltalk, mais c'est pas si dur.

      http://www.squeak.org(...)


      Cela dir DrScheme est très bien aussi (enfin, on m'a dit car je ne connais pas vraiment, en fait).

      David
  • # Et le JAVA ?

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

    installation facile, portabilité, GUI + langage de programmation ...

    Enfin, vu les demandes, je pense que c'est quasiment le plus facile à installer et à utiliser.

    Enfin, c'est juste mon avis en passant

    (je sais pour certain, ca pu c pas libre mais bon .... Java c'est c'est bien aussi)
    • [^] # Re: Et le JAVA ?

      Posté par  . Évalué à 1.

      Java n'est pas vraiment un language de scripting
      et swing c'est forcément simple a utiliser
      • [^] # Re: Et le JAVA ?

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

        C'est un fait, et en plus c'était la première condition à remplir ....
        D'un autre coté, ensuite, il parle de .net et de mono donc cela revient un peu à JAVA non ........

        Bon ok ----------->[] et vite en plus :D
        • [^] # Re: Et le JAVA ?

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

          Oué mais en .NET tu peux programmer en JScript, donc tu peux scripter. T'as aussi IronPython par exemple pour scripter en python, t'as Boo pour scripter en Python mais en mieux. Bref c'est envisageable.
      • [^] # Re: Et le JAVA ?

        Posté par  . Évalué à 1.

        Tu as aussi Jython/SWT

        Tu accedes à toutes les libs java avec un langage de script.
        et swt est plus simple à utiliser.
  • # Mono & winform

    Posté par  . Évalué à 3.

    Je te conseille mono et les winforms,l'install est facile, et le portage des winforms est presque terminé sous unix.
    L'utilisation et le déployement est vraiment simple et rapide
    • [^] # Re: Mono & winform

      Posté par  . Évalué à 2.

      sauf que les winforms sapudubaic. Je travaille sur la gui d'une appli en .NET depuis presque un mois et j'en peux plus. Le modèle de container est vraiment naze je trouve.
      • [^] # Re: Mono & winform

        Posté par  . Évalué à 1.

        Je plussois fortement ! Je développe aussi depuis un ou 2 mois en .NET et avec le WinForms, et c'est clair que c'est pourrave. Pas de layout potable, pas possible de grouper les éléments rien. Autant je trouve que C# est un très bon langage, le framework .NET un truc bien foutu, autant la GUI c'est vraiment pourrave :(
        Qt est meilleur et de loin, vivement Qt4 d'ailleurs :)
        (faudrait un Qt# en fait ;) )
        • [^] # Re: Mono & winform

          Posté par  . Évalué à 1.

          on est d'accord. De toute façon les winforms sont vouées à disparaître...
          • [^] # Re: Mono & winform

            Posté par  . Évalué à 0.

            ah oui et pkoi ? lancer des affirmations en l'air ne sert a rien...
            • [^] # Re: Mono & winform

              Posté par  . Évalué à 4.

              pourquoi quoi ?
              Pourquoi c'est voué à disparaître ? parceque je pense que même chez microsoft ils savent que c'est une solution bancale. Et qu'avec Avalon on aura un vrai framework pour les appli graphique.

              Pourquoi sapudubaic ? Pour faire des gui "de base" (des boutons, des panels, une ou deux textbox...) c'est suffisant et assez simple. Mais quand tu veux faire des chose un peu plus avancées, tu te retrouves comme un con à réinventé la roue. Exemple ? J'avais besoin de gérer moi même le defilement vertical d'un contrôle pour le synchroniser avec un autre. Ba j'ai chercher des heures comment supprimer les scrollbar sans trouver de solutions. J'ai été obligé de refaire le contrôle à la main. La plupart des modifications de contrôles existants passent par la redefinition de la boucle de messages, le décodage des paramètres "alamain" (tm), ... Un autre problème est le modèle de layout. En fait le probléme c'est qu'il n'y en a pas, à part le système de dock qui est assez limité. Et pour finir le générateur de code pour le designer d'interface (de VS.NET) fait un peu ce qu'il veut, et en plus il le fait mal (du code qui disparaît, des synchronisations hasardeuses...).

              Bref c'est encore pire que Swing.
              • [^] # Re: Mono & winform

                Posté par  . Évalué à 0.

                Ben voila c'etais pas difficile de donner quelques arguments et exemples...
        • [^] # Re: Mono & winform

          Posté par  . Évalué à 0.

          juste une question : tu veux grouper les éléments comment ?

          sincerement, les winforms son vraiment bien foutu, et simple.
          • [^] # Re: Mono & winform

            Posté par  . Évalué à 1.

            Plutôt que de te faire un long discours, je t'invite à tester le design de forms sous QtDesigner et de comparer avec les winforms :)

            regarde donc cette url pour apprendre rapidement comment ça marche : http://doc.trolltech.com/3.3/designer-manual-2.html(...)
            et surtout amuse toi bien avec les layout ;)

            Si après tu trouves encore que les winforms sont bien foutues, ça sera vraiment bizarre =)
  • # Py2exe

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

    Avec python tu peut generer un exe qui embarque l'interpreteur et a cote tu a les dll necessaire a son execution. Comme cela sur les platerformes Win aucun probleme de depandances.

    http://wikipython.flibuste.net/moin.py/QuestionsPratiques(...)
  • # Libre ou pas ?

    Posté par  . Évalué à 1.

    Si le côté libre n'est pas trop important pour toi, tu peux aussi essayer rebol...
    Avec son toolkit View, tu pourras des interfaces graphiques (très moches !) sous windows et Linux...
    http://www.rebol.com(...)
  • # Pike, c'est bien

    Posté par  . Évalué à 1.

    Je me suis posé la même question y'a quelques mois [1], et j'ai opté pour Pike.
    OK c'est pas très connu, mais ça a l'avantage de tourner sous linux et win, d'être très rigoureux (fort typage, modèle objet bien foutu etc.), rapide malgré la compilation à la volée, et avec le support de GTK (1 pour l'instant, 2 en développement), mais aussi de SDL, OpenGL (super pour des graphiques 3D avec roto-zoom sub-ionique à particules inversées).
    Depuis, mon projet avance bien, et je ne suis pas déçu par le langage !

    Pour l'édition, il existe jedit qui prend en charge pike (coloration syntaxique). Avec la console intégrée et l'extension gruntspund pour le CVS, c'est assez confortable...

    J'ajoute que la syntaxe de pike est proche de java/C#, qui est pour moi plus "naturelle" que python/ruby (le gouts, les couleurs, tout ça...)
    Niveau toolkit je me sens très à l'aise avec GTK (le 2 aurait été un plus, mais enfin bon), il a le gros avantage d'éviter de se casser la tête sur les histoires de redimensionnements de fenêtres.

    [1] http://linuxfr.org/~qstone/17434.html(...) Mon journal
    [2] http://pike.ida.liu.se(...) site officiel de Pike
  • # Merci journal

    Posté par  . Évalué à 3.

    Merci pour toutes vos suggestions, et je doit dire que ça fait plaisirs de voir que l'on peut parler des différentes solutions disponibles sans troller!

    Si je résume un peu tout:

    Beaucoup de python dans la course. J'avais un peu regarder ce langage à l'époque, mais il ne m'avait pas vraiment accroché (contrairement à ruby). Il existe soit des solutions à base d'environnement facilement déployable (genre movpy ou sap24) soit des créateurs d'exe. Pour la gui ça semble être plutôt du wxwidgets (pas au gout de tous), du qt (de (trés) bonnes critiques, donc à voir, surtout avec l'arrivée de qt4) ou du gtk (qui à ma préférence mais pas forcément bien intégré).

    Un peu de XUL. Il semble que la doc soit encore un peu faiblarde. La sortie du nouveau Panda rouge / Renard de feu avec le support SVG et le xulrunner qui à l'air en bonne voie en font un framework à prendre en compte. Par contre il va falloir que j'apprenne le js.

    Un peu de Mono/.net. Les winforms semblent arriver sur le manchot et les langages dispo sont nombreux, donc pourquoi pas.

    Un peu de Java. Le gros problème c'est que je ne connais pas du tout. Du peu que j'en ai vu il faut installer une jre plutôt imposante. Ou alors voir avec gcj. Bref, ce qu'il me faudrait c'est surtout c'est pistes qui me permettraient de me plonger la dedans. Mais pourquoi pas.

    Des trucs plus ésotériques (du moins pour moi): DrScheme, squeak ou pike (et surement d'autre à venir). A priori pourquoi pas. Il faut voir si ça m'accroche.

    Sinon lorque je parlais de scripting, c'est juste que n'ayant pas de win sous la main je ne me voyais pas cross-compiler tout mes progs.

    Merci à tous pour vos réponses, je vais étudier tout ça et je vous ferais part de mon choix lorsque je sortirais mes progs.

    Si quelqu'un a d'autres suggestions,...
    • [^] # Re: Merci journal

      Posté par  . Évalué à 0.

      En fait tu dois choisir entre des toolkits graphiques portables genre Qt, GTK, Fox, wxWidget, ..... qui sont compilés nativement et qui offrent des wrappers
      et des platetformes d'exécution (interprète, bytecode) qui offrent des mecanismes de partage d'objet et un support multilangage.
      Tu as ainsi:
      Mono/CLR
      J2SE/JRE
      Mozilla(XPCOM)/XulRunner

      et même OpenOffice
      UNO/URE
      http://udk.openoffice.org/servlets/NewsItemView?newsItemID=287(...)
      Tu disposes alors du binding python pyUNO.
      http://udk.openoffice.org/python/python-bridge.html(...)
      L'inconvénient c'est que pour l'instant il faut installer OOo .
      mais le runtime URE arrivera pour OO 2.0

      De même XulRunner n'est pas encore achevé ce qui t'oblige à installer FF ou Mozilla, sauf qu'avec Mozilla le langage de l'interface graphique t'es imposé: Javascript, même si tu peux te creer des composants dans différents langages via XPCOM. Le langage de description de l'interface graphique XUL (dtd XML) t'apporte une bonne séparation présentation/tratement. Le support à venir de SVG et la plateforme de déploiement (.xpi) peuvent être un plus.

      Pour Java tu peux faire exactement la même chose que IronPython pour Mono, avec Jython et acceder ainsi aux librairies graphiques Java au travers d'un langage descript (Swing, SWT, Java2D).Le lagge

      Dans tous les cas, ca necessite de connaitre le framework et son API à défaut du langage de référence.

      Si tu affectionnes Ruby tu as aussi JRuby qui permet la même chose
      http://jruby.sourceforge.net/index.shtml(...)
      L'equivalent mono ou XPCOM doit exister mais je n'ai pas creusé.

      Bon courage
    • [^] # Re: Merci journal

      Posté par  . Évalué à 3.

      si vous en souhaitez d'autre, ce n'est pas ce qui manque

      un language made in france
      avec des 'binding' WxWindows ou GTK1, 2 au choix
      plus multi-plateforme que Java (oui , oui c'est possible ;-)
      plus efficace également ( http://shootout.alioth.debian.org(...) ;-)
      interprété ou compilé nativement
      fonctionnel? impératif? objet? ou les 3

      si si ça existe

      http://caml.inria.fr/r(...)

      ni plus simple ni plus compliqué que java ou lisp
      c'est juste une autre option pas idiote non plus
      d'autant qu'il y a pas mal de chose plus ou moins 'académique' avec
      • [^] # Re: Merci journal

        Posté par  . Évalué à 1.

        d'ailleurs j'ai oublié de mentionner pour ocaml un exellent exemple pour vous
        http://home.gna.org/geocaml/(...)
        • [^] # Re: Merci journal

          Posté par  . Évalué à 1.

          Le ocaml! En voila une idée qu'elle est bonne. Ca faisait un petit moment que je voulais m'y mettre et l'occasion est toute trouvée.

          Je crois que je vais partir la dessus (sauf si quelqu'un me donne un contre argument du feu de dieu ou me donne envie de faire autre chose ;-).

Suivre le flux des commentaires

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