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 Flink . Évalué à 4.
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 HSimpson . Évalué à 2.
[^] # Re: du choix, du choix :)
Posté par HoloAddict (site web personnel) . Évalué à 2.
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 HSimpson . Évalué à 1.
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 golum . Évalué à 4.
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 Philippe F (site web personnel) . Évalué à 4.
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 David Douard . Évalué à 2.
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 plagiats . Évalué à 5.
http://www.wxwidgets.org/(...)
"An open source C++ GUI framework to make cross-platform programming child's play. Well, almost."
[^] # Re: wxwidgets ?
Posté par HSimpson . Évalué à 2.
Merci de l'avoir remis dans la course.
[^] # Re: wxwidgets ?
Posté par Maxime (site web personnel) . Évalué à 1.
# XUL a de l'avenir
Posté par spongurex . Évalué à 3.
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 Olivier Grisel (site web personnel) . Évalué à 2.
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 Mildred (site web personnel) . Évalué à 3.
[^] # Re: XUL a de l'avenir
Posté par Tulan . Évalué à 6.
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 Gmooron . Évalué à 1.
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 manatlan (site web personnel) . Évalué à 3.
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 manatlan (site web personnel) . Évalué à 2.
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 HSimpson . Évalué à 1.
[^] # Re: python
Posté par manatlan (site web personnel) . Évalué à 2.
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 iznogoud . Évalué à 2.
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 manatlan (site web personnel) . Évalué à 3.
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 iznogoud . Évalué à 1.
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 manatlan (site web personnel) . Évalué à 2.
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 manatlan (site web personnel) . Évalué à 2.
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 golum . Évalué à 1.
http://sourceforge.net/forum/forum.php?thread_id=1273014&forum_(...)
[^] # Re: python
Posté par iznogoud . É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 golum . Évalué à 1.
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 manatlan (site web personnel) . Évalué à 4.
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 golum . Évalué à 1.
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 ygo . Évalué à 2.
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 David Douard . Évalué à 1.
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 beleys (site web personnel) . Évalué à 1.
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 ygo . Évalué à 1.
et swing c'est forcément simple a utiliser
[^] # Re: Et le JAVA ?
Posté par beleys (site web personnel) . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Et le JAVA ?
Posté par golum . Évalué à 1.
Tu accedes à toutes les libs java avec un langage de script.
et swt est plus simple à utiliser.
# Mono & winform
Posté par ookama . Évalué à 3.
L'utilisation et le déployement est vraiment simple et rapide
[^] # Re: Mono & winform
Posté par LeMagicien Garcimore . Évalué à 2.
[^] # Re: Mono & winform
Posté par Flink . Évalué à 1.
Qt est meilleur et de loin, vivement Qt4 d'ailleurs :)
(faudrait un Qt# en fait ;) )
[^] # Re: Mono & winform
Posté par LeMagicien Garcimore . Évalué à 1.
[^] # Re: Mono & winform
Posté par ookama . Évalué à 0.
[^] # Re: Mono & winform
Posté par LeMagicien Garcimore . Évalué à 4.
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 ookama . Évalué à 0.
[^] # Re: Mono & winform
Posté par ookama . Évalué à 0.
sincerement, les winforms son vraiment bien foutu, et simple.
[^] # Re: Mono & winform
Posté par Flink . Évalué à 1.
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 Julien Duponchelle (site web personnel) . Évalué à 1.
http://wikipython.flibuste.net/moin.py/QuestionsPratiques(...)
# Libre ou pas ?
Posté par CycyX . Évalué à 1.
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 qstone . Évalué à 1.
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 HSimpson . Évalué à 3.
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 golum . Évalué à 0.
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 ygo . Évalué à 3.
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 ygo . Évalué à 1.
http://home.gna.org/geocaml/(...)
[^] # Re: Merci journal
Posté par HSimpson . Évalué à 1.
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.