... S'il devait en tomber 2 à l'eau qui feriez-vous rester sur le bateau ?
En fait, je fais une étude rapide sur la possibilité de remplacement d'une IHM faite en Motif et un autre logiciel propriétaire (Sphinx).
Je me suis fait ma propre opinion sur les 3 technologies, mais histoire de ne pas introduire un biais dans mon raisonnement, je souhaitais avoir vos opinions libres sur le sujet.
Ce que je cherche de votre part, c'est juste un retour d'expérience si vous avez été confrontés à au moins 2 des technologies sus mentionnées. Avez-vous une préférence ? Pouvez-vous argumenter en 2-3 trois points votre préférence ?
Pour ceux d'entre vous qui ne serait familier que d'une seule de ces technologies, pourriez-vous me donner un feedback sur celle-ci : difficulté d'implémentation, difficulté d'en comprendre la philosophie, etc. ou l'inverse aussi :-)
Voilà, je vous remercie pour votre aide.
PS: je transmettrais ma propre opinion une fois avoir accumulé vos réponses.
Journal Eclipse, Qt et GTK+ sont dans un bateau ...
22
sept.
2005
# Aaaah que c'est bon d'être LIBRE de choisir!
Posté par sylware . Évalué à 2.
GTK = C ou C++
QT = Essentiellement Trolltech.
GTK = Un peu tout le monde.
QT = GPL et autre chose.
GTK = GPL
Je préfère Gnome, donc mon choix personnel est GTK.
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par Yusei (Mastodon) . Évalué à 10.
ou Perl, ou Python, ou Ruby, ou Java, ou Eiffel, ou Objective Caml, ou C#, ou sûrement plein d'autres que je n'ai pas encore essayés :)
Autant GTK+ est assez lourd à utiliser en C, autant dans un langage de plus haut niveau comme Ruby, c'est très agréable.
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par sylware . Évalué à 4.
Dsl. :)
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par efyx (site web personnel) . Évalué à 5.
Php Gtk : http://gtk.php.net/(...)
Ada : https://libre2.adacore.com/GtkAda/(...)
Bon la liste est longue....
Moi j'ai une petite préférence pour GTK qui a un look plus minimaliste et moins flashy que QT,
Cependant ce que tu fait en QT avec 4 lignes il t'en faut 6 (voir plus) pour le faire en GTK (je parle en programmation C la...)
Voila...
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par Erwan . Évalué à 3.
Ben non, tu compares du C (Gtk) avec du C++ (Qt).
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par Prosper . Évalué à 10.
QT = GPL et autre chose.
GTK = GPL
non , GTK est LGPL
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par sylware . Évalué à -10.
J'ai loupé une marche?
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par Guillaume Knispel . Évalué à 10.
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par sylware . Évalué à 2.
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par CrEv (site web personnel) . Évalué à 9.
Sinon quand tu parles d'Eclipse, tu fais référence à quoi ?
Le trio à départager ça serait pas plutôt swing (ou java), qt et gtk ?
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par TImaniac (site web personnel) . Évalué à 4.
[^] # A propos d'Eclipse
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 1.
Au fait l'environement courant de l'application est SUN Solaris 8-10, mais pour le futur Linux est plus que envisagé!
Cheers,
Jean-Christophe
[^] # Re: A propos d'Eclipse
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A propos d'Eclipse
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 2.
Mais en fait, ma vision est également à plus long terme. On cherche à voir ce que pourrait apporter Eclipse et sa plateforme pour notre application. Donc si on doit bouger à terme pour Eclipse, pourquoi pas le faire maintenant pour les IHMs...
La pour me suivre, je vais faire un tour par l'archi de l'appli:
l'appli est divisée en 2 un client et un serveur qui causent en CORBA entre eux. Le seveur n'a rien de graphique mais contient l'intelligence du système, par contre le client ne fait qu'afficher les données du serveur.
Donc si à terme on baserait tout sur Eclipse, on pourrait aujourd'hui faire le client sur cette base, car c'est lui qui m'intéresse aujourd'hui. Et à terme migrer tout le reste de l'appli.
Mais évidement, il est moins coûteux sur le court terme de passer à un Qt ou GTK-- (car c'est du C++). Le moins coûteux serait Qt car c'est bien documenté pour la migration vers Motif, et la version 4 offre quelques facilités à ce niveau.
Jean-Christophe
[^] # Re: A propos d'Eclipse
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: A propos d'Eclipse
Posté par golum . Évalué à 4.
Si toutefois tu pars sur cette solution tu devras dans un premier temps réécrire la couche graphique du client et en plus utiliser un ORB et regenér ta partie cliente
Par la suite, tu peux si tu le souhaites récrire le serveur en JAVA (sous Eclipse en tant qu'IDE) conservere CORBA ou communiquer directement via RMI.
De même tu peux évoluer vers une architecture clients riches avec RCP
http://www.eclipse.org/rcp/(...)
ce qui t'apporteras des facilités en terme de déploiement.
[^] # Re: A propos d'Eclipse
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 1.
Pour la partie ORB, on ne devrait pas avoir trop de problème car on a un autre projet qui fonctionne sur ce principe (serveur C++, com CORBA et client Java). Par contre, je ne sais pas quel ORB ils ont choisis :-( (Probablement JacORB.) On pourra se débrouiller pour récupérer du code ou des compétences.
Enfin le but de ces études c'est de montrer les avantages, inconvénients et coûts estimés des différentes solutions, dans proposer une, et de voir finalement votre management ne pas bouger :-( ou de faire des choix étranges! Donc je ne suis pas sûr à la fin que je mentionnerai la solution SWT+JNI, ils seraient capable de la choisir ;-)
[^] # Re: A propos d'Eclipse
Posté par golum . Évalué à 2.
Tu ne recodes que la couche présention et appelle ta logique applicative au travers de JNI dans un premier temps
Si tu arrives à fiare passer plusieurs itérations pour le projets c'est pas mal.
Notes que j'avais vu passer une fois que JNI n'était pas l'unique (ni la meilleure) solution pour appeler du natif ou qu'il y avait des surcouches qui facilitaient le travail (je ne me souviens plus)
un coup de Google
http://weblog.janek.org/Archive/2005/07/28/AlternativestoJavaNative(...)
Mais c'est vrai qu'on s'éloigne un peu du sujet sur les tk graphiques
Sinon pour rich cleintss semble que dans ma boite on s'oriente vers une solution RCP face aux alternatives Xul, OpenLazlo et autres Flex.
Il faut dire qu'ici la culture est plus Java/clients légers.
[^] # Re: A propos d'Eclipse
Posté par ndesmoul . Évalué à 1.
Swig permet de faire le lien entre du code C/C++ et d'autres langages comme Java, Perl, Python, Ruby, C#, OCAML, ...
A essayer.
# Mon expérience
Posté par Ben . Évalué à 10.
Les techno évaluées et utilisées (selon besoins des clients) : QT / wxWidget / Gtk
Au final, QT largement vainqueur pour :
- qualité du framework et notamment la documentation
- portabilité (dev sous Mac, Win et désormais deux portage en cours sous Linux sans soucis et cela pour toutes les appli sur lesquelles j'ai bossé)
- réactivité de trolltech par rapport aux bug signalés mais également pour le suivi
- bonne compatibilité entre les version des framework, même lors de changements majeurs (de plus trolltech fourni des outils d'aide à la migration du style qt2 -> qt3 et également qt3 -> qt4)
Deuxième place : wxWidget
- j'ai commencé avec il y a plus de 6 ans donc personnellement j'aime bien :-)
- assez robuste mais peu d'exemples et parfois le framework est assez bas niveau (widget manquant par exemple ou bien la gestion de l'impression ou il faut faire pas mal de boulot soit même, contrairement à Qt)
- quelques soucis de portabilité lors de développements Windows et Macintosh
Troisième place Gtk :
- Prise en main assez difficile
- Doc assez pauvre mais apparement cela s'améliore
- Personnellement, je trouve qu'il n'y a pas une assez grande constance entre les différentes fonctionnalités (en terme de paramètres, de nommage de fonctions et de structures, de types de retour, etc) c'est déroutant au début mais on s'y fait vite.
- Personnellment, je trouve Gtk un peu moins "pro" et moins bien fini que Qt et wxWidget
- J'ai essuyé de très nombreux bug dans les versions 2.4 et 2.6 avec des corrections proposées parfois "sauvages" :-)
Au besoin, contacte-moi par mail
[^] # Re: Mon expérience
Posté par Yusei (Mastodon) . Évalué à 4.
Les "layout managers" deviennent des "containers", les "event listeners" deviennent des "signals", et voilà, on peut directement se lancer en gardant l'API sous le coude.
Par contre, c'est vrai que la documentation manque parfois, surtout sur les widgets les moins utilisés ou les plus récents/complexes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon expérience
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Le mécanisme de SIGNAL/SLOT par exemple est terriblement efficace, à tel point que je l'utilise même pour mes propres structures de données lorsque j'ai besoin d'implémenter un mécanisme évènementiel.
La documentation est exemplaire.
Le travail est propre.
Bref, c'est que du bonheur.
Néammoins, si je voulais être totalement honnête, je dirais que si TrollTech ré-écrivait QT en C#, ça ne serait pas plus mal. En fait, au fil du temps, on se rend compte que les macros QT servent à pallier les manques du langage (qui commence à vieillir, avouons-le).
[^] # Re: Mon expérience
Posté par Goth . Évalué à 2.
[^] # Re: Mon expérience
Posté par TImaniac (site web personnel) . Évalué à 4.
[^] # Re: Mon expérience
Posté par Goth . Évalué à 1.
[^] # Re: Mon expérience
Posté par Sebastien Binet . Évalué à 4.
Il me semble d'ailleurs avoir vu quelque part (a confirmer) que ca allait etre integre dans C0x...
[1] http://www.boost.org/doc/html/signals.html(...)
[^] # Re: Mon expérience
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
On peut probablement discuter de la pertinence d'avoir intégré un système delegate/event dans le langage mais force est de constater que je prend réellement plaisir à l'utiliser lorsque je fais du C# et je pense pour ma part que c'est une évolution remarquable.
[^] # Re: Mon expérience
Posté par salvaire . Évalué à 2.
Et GnuStep?
# Eclipse?
Posté par serge_kara . Évalué à 8.
Bon c'est sur que si tu fais autre chose que du java, ca va pas te servir a grand chose, si ce n'est occuper de la RAM :)
Les wizards sont pratiques (avec les classiques : generateur de classes, auto implementation d'interfaces, en tetes automatiques etc.), la completion est typee, organisation auto des imports, navigation dans le code, sauts aux classes mere/filles, surdefinition de methodes, la compilation a la volee qui change la vie, il te propose des corrections aux erreurs de codes, il te propose meme des optimisations, detection du code mort, evidemment un refactoring surpuissant, le debugger est top of the pop (pas a pas, modification a la volee du code execute, infos detaillees sur tous les objets du bloc entre autres etc.), integration de ant, la vue CVS est plutot bien branlee, avec un diff auto etc. et je dois surement oublier pas mal de features.
A ca tu ajoutes une chiee de divers plugin proprio ou libre, de qualite inegale (d'excellent a plutot a chier) dont certains sont indispensables.
Clairement, utilise la version 3.1 voire 3.0, les 2.x sont trop vieilles.
Bref, je peux pas imaginer un developpement java sans eclipse.
Et pourtant, ya 1.5 an, j'etais un inconditionnel d'emacs/ligne de commande/make (et quand je dis inconditionnel, c'est inconditionnel, ie je l'ai meme tente sous windows).
Un peu gourmand en ram par contre (quoique ca tourne tres bien sur mon p4 2Ghz/512Mo au taff), des fois il "garbage collector", en gros il freeze pendant 30 secondes, le temps de faire passer le gc, rien de mechant ca me le fait tout au plus 2 fois par jour.
Pour le c/c++ par contre..
c'est plutot bof.
La bonne nouvelle c'est que autant la version Windows est top of the pop, autant la version linux...
bah je trouve qu'elle "lag" trop, surement du a la jvm qui est a chier.
bon, ca c'est un probleme qui est plus lie a java en soi qu'a eclipse.
Jamais essaye la version compilee avec gcj, ca resoud peut etre ce probleme?
Apres, SWT.
Pas encore assez mur a mon gout.
Des choix d'implementation a s'arracher les cheveux. Par exemple, la classe Button est declaree finale. Du coup pas moyen de se faire un bouton au comportement customise en profitant de l'heritage etc. Et c'est comme ca pour enormement de widgets de base.
Pas de spinner avant la version 3.1. Et ca m'a sacrement fait chier ca, j'ai du implementer un spinner a partir d'un slider, super.
Une javadoc proprement pourrie, mais pas mal de tuto a droite a gauche et des newsgroups actifs, donc ca se balance.
Necessite de liberer les objets graphique (car natifs...). En pratique, la plupart des objets de la lib se liberent tout seul quand ils se ferment, donc c'est pas si genant que ca.
Des composants de tres haut niveau pour gerer les vues sur les tables/arbres etc. extremement pratiques et plutot simple a mettre en oeuvre.
Les layouts dispos par defaut sont biens penses (contrairement a cette chose qu'est swing).
Au final, la prise en main est pas triviale, mais ca passe bien.
Quelques gros manques tout de meme, par exemple SWT ne gere pas la transparence a la png, c'est tout ou rien.
Le DND "évolué" (ie ; dnd d'objets java) est tres chiant a mettre en oeuvre, car on doit passer par une moulinette java -> natif puis natif ->java. Le DND de texte se passe nickel par contre.
Mais conceptuellement, c'est exactement ce qu'il faut a java : de l'ihm moins lourde a coder que Swing, integree a l'os (car natif reposant sur les libs de l'os) et reactive.
la lib est dispo pour beaucoup d'environnement (je l'ai fait tourner sur un HP-UX 10 et un sunos 4, c'est vous dire si ca tourne sur des trucs bizarres).
Portabilite egale a celle de java (j'ai compile sous windows et deploye sur des stations sun sans AUCUN probleme)
Il ya SWT Designer pour creer ses propres gui de facons graphique dans Eclipse, malheureusement proprio et payant comme plugin.
Je ne le connais pas, donc je peux pas dire ce qu'il vaut.
Je pense que d'ici la version 5 on aura quelque chose de vraiment mur, et un argument de poids face a cette saloperie de SWING.
[^] # Re: Eclipse?
Posté par serge_kara . Évalué à 2.
c'est toi qui choise en fonction de ce que tu veux ou a a disposition.
.
[^] # Re: Eclipse?
Posté par Franck . Évalué à 3.
Bon c'est sur que si tu fais autre chose que du java, ca va pas te servir a grand chose, si ce n'est occuper de la RAM :)
C'est un peu sévère... perso, je me suis mis à Python récemment avec pydev, le plugin eclipse qui va bien ( http://pydev.sourceforge.net(...) )
Et que du bonheur... stabilitité, refactoring correct (pas parfait mais ça progresse) efficacité grace aux visualiseurs de classes d'Eclipse, auto-complétion très aboutie (dans les limites du langage bien sur, il peut difficilement deviner ce que contient un tuple par exemple)
Un plugin que je vous encourage à essayer.
Par ailleurs, si ça peut servir à quelqu'un, je suis sous Fedora qui a la particularité de faire tourner Eclipse avec le binaire java libre. Et bien... force est de constater quelques lacunes encore. Par exemple, impossible de faire marcher la nouvelle version de pydev sans le java de Sun. Par ailleurs, j'ai constaté que faire tourner eclipse avec le vrai java accélérait sensiblement le bouzin (en plus de l'option -Xmx512M)
[^] # Re: Eclipse?
Posté par serge_kara . Évalué à 2.
Disons que Eclipse est tout bonnement excellent pour le java.
Apres, ben ca depend de la qualite du plugin et du langage dans lequel on developpe.
C'est sur que le C/C++ ne permet pas trop les features offertes pour java, mais qui sont quand meme permises par des languages plus haut niveau style python etc.
# XUL !
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
En pratique, ca dépend un peu du type d'IHM que l'on veut faire... Personnellement, je suis plus que tenté de faire toutes mes IHM en script.
[^] # Tous est dans la phrase
Posté par salvaire . Évalué à 5.
Un jour j'aimerai avoir un navigateur web parfaitement fonctionnelle ... Mais pour l'instant j'en ai jamais vu. Alors les technos du web, je suis frileux.
[^] # Re: XUL !
Posté par woopla . Évalué à 2.
Enfin, du moins en microélectronique. C'est du TCL/TK pour la plupart, ca te permet de modifier l'apparence de l'appli pour l'adapter à ton environnement de travail assez facilement (menus spéciaux qui appellent des scripts, nouveaux widgets, etc...) Je crois que ca se mettrait à râler sérieusement si les applis n'était plus modifiables :)
Je suis pas sûr de l'intérêt pour les applis grand public, autant faire l'IHM avec les outils adaptés au langage utilisé pour écrire l'appli, ca facilite la vie du développeur, AMHA. De toute facon l'utilisateur lambda ne va pas s'amuser à aller modifier son appli.
[^] # Re: XUL !
Posté par serge_kara . Évalué à 4.
Et si tu veux faire des IHM un tant soit peu evoluee (ie : pas juste un layout d'objets de base, mais des interactions haut niveau entre les composants), ben c'est pas franchement top of the pop...
Bon, je sais c'est un coup a prendre tout ca, mais quand meme la phase de compilation permet quand meme de detecter un tres grand nombre d'erreurs de facon automatique..
[^] # Langages statiques/dynamiques et bugs
Posté par bobert . Évalué à 4.
ce qui me gene le plus avec les languages de scripts, c'est que c'est pas compile...
[...]
Bon, je sais c'est un coup a prendre tout ca, mais quand meme la phase de compilation permet quand meme de detecter un tres grand nombre d'erreurs de facon automatique..
Il y a des prémisses à ton raisonnement qui sont discutables...
1) Le premier est que dans ton esprit tu limites l'usage des langages dynamiques [1] aux seuls scripts alors qu'ils sont de facto des langages permettant de réaliser des applications des pieds à la tête
2) Le second est qu'un code écrit dans un langage statique contient autant ou moins de bugs qu'un code écrit dans un langage dynamique.
- D'une part, mon impression est que, les langages dynamiques étant plus expressifs que les langages statiques, ils permettent de décrire le même besoin avec moins de code, de façon plus lisible ; j'y vois plutôt (toutes choses égales par ailleurs) un gage de plus grande fiabilité.
- D'autre part, certains bugs (dans quelle proportion ? non négligeable je dirais) détectés à la compilation découlent directement du fait que le langage... requiert une compilation ! Exemple typique: dans un langage statique tu écris souvent qu'une classe C hérite d'une classe S ou implémente une interface I. Si tu as mal écrit l'identifiant de S ou I, ou que celui-ci a changé au cours du développement, tu auras une erreur à la compilation. Or, aussi gênant que ça puisse paraître quand on n'y est pas habitué, l'implémentation la plus naturelle dans un langage dynamique de cet exemple ne nécessite *pas* d'écrire S ou I... on adopte plutôt l'approche de "duck typing" (pas le temps d'expliciter mais d'un coup de google ca se trouve) --> avec un langage dynamique, de telles erreurs *n'existent pas*
3) Dernier point: l'idée, ou l'espoir, que corriger des bugs à la compilation fasse gagner du temps
=> De toutes manières, on ne peut pas se contenter de débugger lors de l'écriture du code, les tests unitaires + la phase de "recettage", de tests fonctionnels, sont indispensables. Ceci considéré, chasser 2 ou 3 bugs supplémentaires lors de la compilation ne change pas grand-chose
[1] J'y vais à la louche dans ce commentaire et ne considère que des langages "dynamiques" (python, ruby,...) contre des langages "statiques" (c++, c#, java,...).
[^] # Re: Langages statiques/dynamiques et bugs
Posté par serge_kara . Évalué à 2.
j'entends bien, je saisi tout a fait la difference, et je sais pertinemment que de grosses applis sont ecrites avec ces langages dit "de script".
avec un langage dynamique, de telles erreurs *n'existent pas*
Disons plutot qu'elles peuvent ne pas exister.
Et quand aux erreurs de typages, elles peuvent toujours exister (t'as beau avoir un langage dynamique si t'affecte des types incompatibles, tu vas avoir un probleme).
Itou pour les declarations implicites de variables.
Et celles la elles peuvent etre particulierement chiantes a detecter en runtime.
Quand tu code un plugin ou equivalent, effectivement t'es bien oblige de pouvoir etendre une classe qui n'existe pas dans ton environnement de dev.
Quoique t'es quand meme oblige d'avoir un minimum de spec dessus, au minimum l'interface de la classe etendue, donc en quoi est ce utile ? (c'est une vraie question, je connais assez peu ces langages..)
Cela dit, ya pas mal de cas ou tu ne veux pas deriver une classe inexistante et ou tu aimerais bien pouvoir le verifier en compilant ton code pour t'en assurer, plutot que de rechercher la faute de frappe malencontreuse pendant des heures.
Disons que la compilation permet de blinder un peu plus l'appli de facon automatique.
En fait, j'ai mal formule l'histoire de compilation, sans forcement compiler au sens strict, le fait de pouvoir valider le typage serait un plus notoire je pense.
Sinon pour reagir a ton [1], contrairement a ce que tu dit, Java est dynamique, tu peux charger une classe en runtime, appeler des methodes dynamiquement dessus etc., je m'en sert d'ailleurs enormement au taff en ce moment.
Evidmment, pas possible de compiler une classe derivant une autre sans la classe mere, vu qu'il faut generer du byte code.
[^] # Re: Langages statiques/dynamiques et bugs
Posté par woopla . Évalué à 3.
Génial, c'est tout flexible et tout. Seulement m'arrive d'avoir des bugs dans les templates de sortie. Des trucs tout con (genre un point virgule oublié à la fin d'une ligne). Comme les templates sont compilés lors de leur utilisation (on peut considérer ca comme des plugins), c'est au bout de 15 minutes qu'il me sort que j'ai une erreur de syntaxe. Et j'ai donc le droit de corriger mon erreur et de tout recommencer.
Avec un langage précompilé, cette erreur se serait vue lors de la compilation (relativement rapide, je dirais même pas une minute si c'était en C), et j'aurais pas attendu pendant 15 minutes pour rien.
Bon, c'est assez spécifique (temps de compilation théorique court par rapport au temps d'exécution de l'appli), mais quand même.
Ceci dit, ca me permet de mouler 2 fois plus sur linuxfr :)
[^] # Re: Langages statiques/dynamiques et bugs
Posté par serge_kara . Évalué à 3.
des erreurs triviales de syntaxe/typages ne peuvent se voir qu'en runtime et ca c'est pas terrible je trouve...
[^] # La compilation ne fait pas notre boulot...
Posté par bobert . Évalué à 3.
1) un compilateur ne pourra jamais trouver tous les bugs
2) ça relève d'une approche que j'appellerai ici, par provocation, "roulette russe" : on exécute son application compilée. En cas de bug, on corrige, et dans le cas contraire, confiant, on embraye sur une nouvelle fonctionnalité à implémenter. Or à cette étape, le code écrit est loin d'être fiable. Une approche beaucoup plus saine consiste à écrire les tests unitaires, en d'autres termes le comportement auquel l'application doit obéir, avant d'écrire l'application elle-même.
Je dirais que l'étape de compilation lors de l'utilisation de code "statique", a tendance à nous bercer d'illusions sur la fiabilité du code écrit et à masquer les dangers de l'approche "roulette russe".
Si on choisit d'adopter l'approche plus saine "les tests précèdent le code", alors il me semble que les langages "statiques" n'ont pas d'avantage par rapport aux langages "dynamiques", sur ce point précis.
Inversement, je me verrais mal désormais écrire du code fiable avec un langage, qu'il soit "dynamique" ou "statique", sans adopter cette approche.
[^] # Re: XUL !
Posté par thecat . Évalué à 3.
* Pas d'IDE, d'éditeur spécialisé ou de plug-in/mode suffisament poussé: les rares projets sont soit mort (depuis plusieurs années pour certains), soit en phase de conception! Le plus abouti est écrit en Java, c'est dire la confiance qu'ils ont eu dans la techno XUL.
* Pas de documentation: Mème si il y a un effort la dessus, la grosse majoritée de la doc que l'on trouve est dépassée. Les trés nombreux tutoriaux que l'on trouve sur le net sont en fait tous les mèmes et largement incomplet dés que l'on creuse un peu plus leurs exemples.
* Pas de stabilitée! Tout a changé (et va changé?) en moins de deux ans. C'est un miracle si une applications écrite il y a a peine un ans s'installera et tournera sans problème sur ton mozilla (ou firefox!). Bon ok la techno est jeunes, mais ne l'est-t-ell pas un peu trop? Si je développe un truc, dans six mois il faudra que je le porte vers le nouveau lézard?
* Complexitée de la plateforme elle mème: Que fait elle ? tout ... mais bon tout n'est pas encore implémenté.
Des technos a comprendre: XPCOM, RDF, chrome ... Pour un exemple "jouet" tou va biens, tu peut t'en sortir avec tes connaissance actuelles (JS+XUL) mais dés que tu complique tu te les prend toutes d'un coup en pleine face. De plus créer ton composant XPCOM n'est pas difficile mais il faut étres (trés) méticuleux -> difficulté de tester ou de comprendre "en douceur".
Instancier et utiliser un composant XPCom c'est plusieurs lignes de plus de 80 caractères! (ok tout est logique et simple quand on a compris mais bon c'est lourding et nuit a la lisibilitée)
Certaines technos me font pensées au "théoriquemetn parfait" mais "inutilisable/imanipulable" (par exemple les "templates" ne sont utilisables que sur des données de types RDF ... que tout le monde connait, qui est simple et concis, et qui est trés utilisé pour nos données actuelles n'est-ce-pas?)
* Enfin XUL est ... plutot mal foutu a mon sens: Dans un "listbox" (la vue "liste") tu ne peut afficher que objets d'un types prédéterminés, tu ne peut pas mettre un composant autres qu'un label et un icone.
Pareil pour les arbres.
Ce que vous verrez comme un point de détail est en fait important car la hiréarchie des composant (l'arbre d'héritage quoi) est mal faite car elle nous oblige a dire "amen" au avis des concepteur de XUL (citation: "avoir la possibilitée d'afficher dans un arbre, autre chose qu'un label, un icone ou une barre de progression est _inutile_"). On est trés loin de la souplesse de SWING ou QT alors que l'on est "dynamique" (donc on devrait avoir des possibilitée plus importantes).
* Enfin il faut pas se leurrer, ca rame un poil. Pour une interface simple c'est ok mais le tout est quand mème un peu mou.
Et pourtant! je révais d'une interface graphique "interprété", souple, jolie/elegante, basée sur de standard (XML) et "portable" (un super remplacant a TCL/TK quoi).
Le top du top: avoir juste la technos XUL seule (et lègèrement amèliorée) et pouvoir l'utiliser avec n'importe quel langage (Eiffel, lisp, java Python ..).
[^] # Re: XUL !
Posté par Yusei (Mastodon) . Évalué à 2.
Dans une certaine mesure, GTK+Glade+(Python|Ruby) fait ce que tu veux: tu as une description de ton interface en XML, c'est interprété, souple, et ça marche sur toutes les plateformes où GTK est porté.
[^] # Re: XUL !
Posté par golum . Évalué à 2.
Mais tu l'as
http://luxor-xul.sourceforge.net/(...)
[^] # Re: XUL !
Posté par Erwan . Évalué à 3.
Inversement si tu fais du GTK en Ruby (ou en Python) c'est tres simple de brancher du code C pour coder certaines parties critiques.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.