Ce journal fait suite à mon précédent sur le sujet ( http://linuxfr.org/~lastman/19545.html )
Pour résumer : une équipe d'étudiants dont je fais partie devront coder dans le cadre de leurs études un projet qui consiste en une sorte de modélisateur d'efforts sur véhicules. Le tout avec un peu d'OpenGL et une jolie interface graphique. Contrairement aux projets qui sont demandés aux étudiants habituellement, celui-ci a pour vocation de fournir une application propre, fini et léchée, dont le but sera notamment d'être distribuée le plus largement possible.
Pour ce faire, trois technologies sont en compétition : Qt, C# et Java.
Pour le groupe d'étudiants que nous sommes, au niveau des qualifications générales, C++ et Java sont les langages les mieux maitrisés avec un avantage pour le C++, pratiqué depuis plus longtemps.
La réunion que j'avais mentionnée lors de mon précédent journal a été ajournée à la semaine qui arrive. Pendant ce labs de temps, notre groupe a été découpé en trois sous-groupes chargés de coder une démonstration avec de l'OpenGL en utilisant une des technologies précitées. Nous avons donc été trois groupes, soit un par technologie.
Ceci pour se rendre compte par la pratique ce que valaient les technos aussi bien sur le plan technique que sur la facilité d'utilisation.
Cette fois, si je fais appel à vous, c'est pour que vous me disiez sincèrement avec le peu d'éléments de contexte que je vous donne, quelle technologie vous semble la plus adaptée pour cette situation. De mon côté je penche encore et toujours du côté de Qt (avec plus d'arguments que pour la dernière fois ;-) ) mais je me suis dit que l'avis de personnes expérimentées sur le sujet n'est pas toujours des plus négligeables...
PS : L'obligation de faire du code GPL en cas d'utilisation de Qt ne semble pas être un problème pour nos chers profs.
PPS : Promis, après ce journal, j'arrête de vous embêter avec cette histoire :-)
Merci encore !
Journal .Net vs Qt vs Java
5
nov.
2005
# QT
Posté par Jean Roc Morreale . Évalué à 5.
[^] # Re: Qt
Posté par Guillaume Ceccarelli . Évalué à 2.
PS : Je crois d'ailleurs qu'il existe un binding C# aussi mais je ne sais pas s'il est finalisé et utilisable "en production" ...
[^] # Re: Qt
Posté par Philippe F (site web personnel) . Évalué à 4.
# Qt
Posté par fork_bomb . Évalué à 3.
- OpenGL s'intègre bien avec Qt (Par contre je ne connais pas Java3d)
- Les signaux/slots sont plus pratiques et plus élégants que les MachinListeners.
- L'avantage du java au niveau portabilité n'est pas évident
- Je trouve la construction d'interfaces avec Qt bien plus pratique qu'avec Swing
- De plus , les widgets de qt s'intègrent mieux à l'environnement que ceux de Swing
- C'est plus facile de faire installer une application native que du Java
- Swing est lent.
Quant au C#, je ne connais pas du tout.
[^] # Re: Qt
Posté par real_pouet . Évalué à 1.
il y avait gl4java il y a quelques annees, je ne sais aps ce que c est devenu cela dit...
- Les signaux/slots sont plus pratiques et plus élégants que les MachinListeners.
question de point de vue...
- L'avantage du java au niveau portabilité n'est pas évident
totalement d accord. le C++ est "totalement" portable.
- Je trouve la construction d'interfaces avec Qt bien plus pratique qu'avec Swing
- De plus , les widgets de qt s'intègrent mieux à l'environnement que ceux de Swing
- C'est plus facile de faire installer une application native que du Java
- Swing est lent.
a ce que je m etais laisse dire, il y avait un nouveau kit graphique developpe pour eclipse SWT qui resoudrait les problemes que tu cites.
http://developpeur.journaldunet.com/tutoriel/jav/050201-java(...)
noter le conditionnel, moi le graphique cest pas mon truc :)
--
pouet
[^] # Re: Qt
Posté par Guillaume Ceccarelli . Évalué à 2.
A ce niveau, si on se résout à ne pas sortir de l'API Qt (ou a faire du portable à côté), le code est à 100% portable.
[^] # Re: Qt
Posté par real_pouet . Évalué à 1.
[^] # Re: Qt
Posté par serge_kara . Évalué à 4.
heuuu... un pti peu quand meme...
mon sujet de stage a ete compile sur x86/windows et tourne encore sur solaris 4/HPUX10.chaiplucombien/linux/windows
sans avoir rien touche..
Et ya moultes interfaces graphique dedans.
Tu compiles le tout avec des scripts ant, et tu te retrouves avec des sources 100% portables sans te poser la moindre question.
Essayes de faire la meme chose avec du C++ et make...
- Swing est lent.
true.
Mais ya SWT qui existe qui n'est pas lent du tout.
- C'est plus facile de faire installer une application native que du Java
bopf, sous reserve que la jvm est la, installer une appli java c'est decompresser un repertoire, point. Tu peux meme pousser le vice et livrer un jar.
Pas franchement complique, plutot que de se farcir des versions de libs tout ca, a devoir compiler en static pour que ca passe partout etc...
- De plus , les widgets de qt s'intègrent mieux à l'environnement que ceux de Swing
ben si t'utilise le lnf metal, ouais, c'est normal, si tu t'utilises le lnf de l'os cible, bah ca s'integre tres bien.
- Je trouve la construction d'interfaces avec Qt bien plus pratique qu'avec Swing
il est vrai que le Qt designer est quand meme super clââââsse... +1
- Les signaux/slots sont plus pratiques et plus élégants que les MachinListeners.
mouais, ca se discute.. C'est surement une question de gout apres.
Ce qui m'enerve dans l'implementation du signaux/slots de Qt, c'est que ca se fait avec une entorse au C++ (moc et tout ca).
Bref, avec aussi peu de contexte, difficile d'obtenir autre chose que la techno preferee de l'interlocuteur comme reponse..
A ce niveau la, tirez a pile ou face...
[^] # Re: Qt
Posté par Guillaume Knispel . Évalué à 0.
heuuu... un pti peu quand meme...
mon sujet de stage a ete compile sur x86/windows et tourne encore sur solaris 4/HPUX10.chaiplucombien/linux/windows
sans avoir rien touche..
Et ya moultes interfaces graphique dedans.
Tu compiles le tout avec des scripts ant, et tu te retrouves avec des sources 100% portables sans te poser la moindre question.
Essayes de faire la meme chose avec du C++ et make...
J'ai fait la même chose avec une interface graphique en C et make qui tourne sous windows, gnu/linux (debian / fedora / suse / rhes), solaris, aix, hpux (et je cite que ce que j'ai testé), tru64. Sans aucune compilation conditionnelle, et avec 100% de mon code source inchangé.
Tout est une question de dépendance. C'est pas parce que tu n'as jamais essayé que c'est infaisable. Une fois que t'as l'habitude d'écrire du C portable tu vois même plus pourquoi la portabilité pourrait être un problème en fait :)
[^] # Re: Qt
Posté par serge_kara . Évalué à 4.
passque le mien l'etait, d'ou l'interet de la manip
et ton makefile doit pas etre tres agreable a regarder
;-)
'fin bon, c'que j'en dis, c'est comme pour les laptops, ya portable et transportable
[^] # Re: Qt
Posté par Guillaume Knispel . Évalué à 5.
On peut aller loin comme ça.
Mais il est indéniable que si la portabilité de ce qui constitue "l'executable" est un plus pour un projet, alors une VM est un plus. (Mais dans le cas général elle ne règle pas _tous_ les problèmes de portabilité)
Sinon mon makefile était parfaitement normal.
[^] # Re: Qt
Posté par serge_kara . Évalué à 1.
a peu pres autant que le binaire de la lib Qt ;-)
Sinon mon makefile était parfaitement normal.
ouais, c'est bien ce que je dis, avec moultes
if os = machin CC = cc else CC = gcc
if os = machin CPP = cc else CPP = g++
et autres CFLAGS CPPFLAGS COPTS etc avec a chaque fois une entree par os et des flags differents..
Sachant que des fois faut utiliser qmake, le reste du temps make.
Bref, ca marche, mais ca reste chiant a ecrire et c'est pas reellement ce que j'appelle du multiplateforme (un script ant te fait ta compile avec une et une seule balise pour toutes les plateformes cibles)
[^] # Re: Qt
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Qt
Posté par real_pouet . Évalué à -1.
c't abus de langage!!!
mais bon on t a compris: avec du C(C++ ou d ailleurs je pense tous les langages majeurs) et des dependances portees sur tous tes os de destinations, tu as un programme portable. alors que bon moi j'ai eu des comportement bizarres entre windows et linux avec le meme jdk (de sun)
[^] # Re: Qt
Posté par serge_kara . Évalué à 2.
C'est quoi tes comportements bizarres?
# compte rendu
Posté par real_pouet . Évalué à 4.
merci,
--
poueeeet!
[^] # Re: compte rendu
Posté par Guillaume Ceccarelli . Évalué à 1.
C'est déjà le deuxièlme sur le sujet. C'est vrai que les journaux privés ont une durée de vie limitée mais quand même :)
(sauf si bien sur on me le demande explicitement :) )
[^] # Re: compte rendu
Posté par real_pouet . Évalué à 1.
# Avis pas forcément utile
Posté par un_brice (site web personnel) . Évalué à 3.
Sinon, je sais pas s'il est important que vous implémentiez votre propre moteur 3d, donc au cas ou je me permet de rappeller l'existence de Ogre : http://www.ogre3d.org (les captures d'écran d'Ank sont magnifiques, dommage que ce soit un jeu propriétaire). Quelques unes des captures d'écrans présentent des interfaces fenêtrées, donc je suppose qu'il doit y avoir un toolkit d'interfaces utilisateurs quelque part.
[^] # Re: Avis pas forcément utile
Posté par Guillaume Ceccarelli . Évalué à 2.
D'autant plus que nous étions parti pour faire notre propre moteur 3d bien que ce ne soit pas une stricte nécessité et qu'il m'est avis que nous manquons d'expérience sur le sujet. Je vais aller voir un peu du côté de ogre afin de voir s'il serait possible de s'en servir.
Merci !
[^] # Re: Avis pas forcément utile
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# portabilité
Posté par herodiade . Évalué à 4.
À ma connaisance mono (donc C#) n'est pas encore porté sur la plupart des systèmes *BSD (et en particulier sur les architecture non i386) ; Idem pour java (surtout si tu a besoin d'un jdk1.5, qui par ex n'est pas porté sur Mac OS X, mais gcj n'est pas encore très portable non plus). Par ailleur la large audience que tu semble vouloir toucher sera certainement heureuse de n'avoir pas à installer des interpréteurs pour faire tourner l'appli, surtout les non informaticiens.
La légereté (économie de mémoire) est aussi un bon argument en faveur de qt par rapport à java/mono.
Dans tout les cas (heu, en fait pour java et qt au moins) il y a des bindings opengl à disposition et ont toutes les widgets nécéssaires pour faire des "interfaces bien léchées", donc semblent remplir les (trop peu détaillées) contraintes techniques que tu indique.
[^] # Re: portabilité
Posté par Guillaume Ceccarelli . Évalué à 1.
Je sais que les contraintes techniques que je cite sont très peu détaillées mais nous sommes tous plus ou moins dans le flou sachant que le cahier des charges définitif n'a pas encore été établi par nos mandataires.
[^] # Re: portabilité
Posté par sloft . Évalué à 1.
Nos professeurs n'ont pas dit que la portabilité était une priorité car au départ on nous a proposé de convertir le projet en visual basic .NET.
Le programme est plutôt destiné à des entreprises car trés spécifique et technique; ce genre de programme existe en propriétaire et est utilisé par exemple pour préparer les réglages d'une formule 1. C'est pour cela que je mettrait un bémol sur <<le but sera notamment d'être distribuée le plus largement possible.>>
Pour ce qui est de la simplicité de programmation, Qt et C# ont l'air de se valoir. Question IDE, j'ai pu tester pour le C#, Visual Studio .NET et Sharp Developp qui sont tous deux agréables et pratiques à utiliser. Mais pour Qt je me demande s'il existe un équivalent. Nous avons Qt Designer mais ce n'est que pour dessiner des interfaces.
Un autre point à noter, la majorité de l'équipe développera sous Windows (personne n'est parfais...) mais au moins une personne sous linux, donc même si ce n'est encore pas une condition essentielle, l'idéal serait de pouvoir développer sous ces deux environnements.
[^] # Re: portabilité
Posté par Guillaume Ceccarelli . Évalué à 4.
Déjà réalisée, oui. Mais il nous a été demandé de repartir quasiment de 0, pour faire quelque chose qui se tienne mieux que ce que le professeur de GMP à pu faire de lui même. Quoi qu'il arrive et quelle que soit la technologie employée, il faudra coder l'interface à nouveau.
Au niveau de la 3d, l'API va rester à quelque chose près la même si on développe notre propre partie moteur (ce que nous somme à priori sur le point de faire) : Il s'agit de l'API OpenGL. Il faut surtout regarder du côté de l'intégration de cette API au niveau de la technologie employée.
Tu oublies (par exemple) les universités, professeurs, étudiants, passionés, et les inévitables curieux.
Ce sont les mots du professeur qui nous mandate.
Tout IDE C++ qui se respecte. Qt n'est pas un langage, c'est juste une API.
Pour le cas de Qt et Java, tout le monde peut programmer sur ce qu'il veut! Le code restera le même. Pour ce qui est de C#, c'est pareil... Sauf qu'il est plus facile de faire du non portable (à mon avis), ce qui sera un frein pour ceux qui voudraient développer sous linux ( crois-tu vraiment que je sois le seul ? ).
En gros, quelque soit la technologie employée, les windowsiens ne seront pas embêtés. Seuls les linuxiens pourraient l'être dans le cas de fabrication de code non portable sous C# .
[^] # Re: portabilité
Posté par sloft . Évalué à 2.
C'est surtout l'OpenGl que nous ne connaissons pas du tout qui nous demandera le plus de travail.
Soit pas si idéaliste que ça, comme je l'ai déjà dis c'est trés spécifique comme application, c'est pour cela que j'ai expliqué que les principaux utilisateurs seront des entreprises qui n'ont pas accés à ce genre d'application sans devoir mettre des milliers d'euros.
En ce qui nous concernet, étudiants, je doute qu'on s'en serve trés souvent... Ca n'en reste pas pour autant interressant à développer et plutôt enrichissant.
Il disait ça à propot de la gratuité de l'application, n'oublie pas qu'au départ il a refusé de distribuer le programme avec ses sources, tu as dû d'ailleurs pas mal discuter pour essayer de lui faire changer d'avis. Pour l'ouverture du code, c'est à reconfirmer avec le prof.
Ca première motivation pour développer ce logiciel c'était qu'il n'existait pas de logiciel gratuit qui modélisaient les efforts sur véhicules. C'est donc dans l'optique de le distribuer gratuitement qu'il s'est mis à la tâche.
A parce que tu n'es pas le seul dans l'équipe? XD Attends, je réfléchis... mmm.... hum... Nan je vois pas^^
[^] # Re: portabilité
Posté par sloft . Évalué à 0.
Et concrètement dans la pratique, il existe quelles IDE valables pour du Qt/C++ ? Aussi aboutis que Sharp Develop par exemple.
[^] # Re: portabilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: portabilité
Posté par herodiade . Évalué à 2.
sous Linux & *BSD au moins, je ne dev pas sous d'autres plateformes on trouve notament kdevelop , assorti de tout le bazard pour les besoins précis (assistant pour l'aide/la doc, designer pour la gui, linguist pour l'internationalisation ...), ou XCode sous mac.
[^] # Re: portabilité
Posté par Guillaume Ceccarelli . Évalué à 2.
Certes, mais n'oublie pas que la programmation de l'interface et l'intégration du code de calcul représentera quand même une tâche très importante. Nous avons une base de travail tout au plus. Même si son appli fonctionne, je doute que l'organisation du code soit des plus orthodoxe. N'oublie pas que nous avons à faire avec quelqu'un pour qui la programmation n'est pas la première des facilités.
On ira faire un tour au département GMP et peut être aussi à l'école polytech' Orléans. Tu verra de quels genre d"étudiants et passionés je parle. ^^
Pour ce qui est des professeurs et universités, n'oublie pas que ce sont elles qui forment les personnes qui auront besoin de se servir de ce genre de logiciels par la suite. Je ne crois pas que l'utilisation au sein d'une formation poussée dans le domaine de la mécanique soit si utopiste que ça...
Et enfin pour les curieux, tu doutes autant qu'il y en ait? Regarde autour de toi... Nombre de personnes utilisent parfois des logiciels très spécifiques, au début en faisant n'importe quoi puis ensuite pour une certaine partie d'entre eux, essayer d'apprendre par le biais de ce logiciel.
N'oublie pas non plus que ce qui le préoccupais, c'était le fait de se faire taper sur les doigts si les données (qui ne lui appartiennent pas) pouvaient se retrouver dans le code. Ce qui, bien entendu, ne sera pas le cas. Ensuite, après discussion avec lui sur l'éventuelle ouverture du code (notamment du code de calcul), avec une explication des avantages que ça aurait tant pour la notoriété de l'application que pour son développement à venir, il était d'accord. Il n'y a aucune raison qu'il change d'avis aux vues des objectifs qu'il s'est fixé.
Je réitère. Gratuitement et largement
Kdevelop, anjuta, borland C++ builder, eclipse/CDT, MSVC++, vim, emacs, devcpp, notepad2 (ou même notepad tout court si ça t'amuse), ultraedit pour ceux qui me viennent à l'esprit. Si tu en veux d'autres, google est ton ami. Le C++ ça se fait avec tout et n'importe quoi : du plus simple éditeur de texte à l'environnement tout en un. Après à chacun de se sentir à l'aise avec l'outil qu'il préfère
On verra ça mardi! ^^
[^] # Re: portabilité
Posté par sloft . Évalué à -1.
C'est pas du même niveau que VC .NET ou Sharp Developp lol, qu'est-ce que tu me sors là, Notepad2... Emacs... Devcpp... Voyons, reste sérieux :p
On les utilie pour nos TP de prog, mais là ce ne sont pas des outils adaptés. On doit pouvoir modifier à la souris notre application, elle est tellement vaste qu'on s'en sortirait pas avec un simple bloc note. On se perd vite sous les lignes de code.
On en reparle mardi ;)
[^] # Re: portabilité
Posté par Yusei (Mastodon) . Évalué à 8.
Les étudiants d'maint'nant, c'est plus c'que c'était, ma bonne dame...
[^] # Re: portabilité
Posté par Guillaume Ceccarelli . Évalué à 2.
vim ruleZ :-)
PS : Afin d'éviter tout troll sur le sujet, je tiens à préciser que je n'ai rien contre emacs
[^] # Re: portabilité
Posté par sloft . Évalué à 1.
[^] # Re: portabilité
Posté par herodiade . Évalué à 2.
Parce que sinon: Qtdesigner est vraiment très bien pour faire ses interfaces à la souris. Et ensuite, effectivement, n'importe quel éditeur convient pour écrire le code C/C++ en dessous.
[^] # Re: portabilité
Posté par un_brice (site web personnel) . Évalué à 3.
Avec ces logiciels dont tu te moque (et Eclipse) ont étés codées des projets comme Firefox, (Open/ms)Office, mswindows, KDE, gcc, .net, photoshop et Linux.
D'ailleurs ton argumentation est surprenante : t'est en train d'expliquer qu'il n'existe pas de logiciels valables pour développer en C++.
Ou alors t'a juste pas compris que Qt était pas un langage mais une belle api. Ça serait déjà un peu moins effrayant. En fait ça voudrais juste dire que t'avais mal comprises les différentes alternatives.
Il manque un connecteur logique entre la première et la seconde phrase. Ou alors tu considère que la question du journal a déjà une réponse, la tienne: .net .
Soit dit en passant, je trouve ça un peu petit dommage que tu te dise "notre application ne vise pas à avoir beaucoup d'utilisateurs et personne de l'exterieur ne s'y n'interesseras" avant même d'avoir commencer à coder. On dirais que t'apprécie pas ce que tu fait... et puis c'est en se fixant des objectifs élevés qu'on progresse.
Un peu HS: à propos de Kdevelop, je me permet de rappeller l'existence de kcachegrind, qui roxe : http://kcachegrind.sourceforge.net/ et que je n'ai découvert que très récement.
(Bon courrage lastman -_^)
[^] # Re: portabilité
Posté par sloft . Évalué à 1.
Jette un oeil au post au-dessus de tiens, cela te donnera une idée du contexte. Nous sommes justes des étudiants de deuxième année, plutôt débutants en programmation, surtout graphique.
Je m'attache juste à essayer de trouver la meilleure technologie et les meilleurs outils qui nous permettrons de terminer au plus vite et dans les temps ce projet. Ce n'est pas plus compliqué que ça ;)
[^] # Re: portabilité
Posté par cedric . Évalué à 3.
C'est amusant comme reflexion, mais je trouves que des qu'on a besoin d'utiliser la souris pour faire manipuler quoi que ce soit on perd du temps par rapport a la version clavier.
Aussi bien pour le code :
- Une interface pour la regler au pixel pres rien de tel que de le dire en rentrant directement les valeurs aux claviers plutot que d'essayer de viser de maniere aproximative avec la souris. Mais ca doit etre moi qui est des problemes de vise, en meme temps mon clavier est toujours au meme endroit et j'en connais les touches par coeur, alors que cette foutue souris, elle n'arrete pas de bouger a l'ecran et sur mon bureau...
- Entrer du code, rien de tel que de le tapper au clavier avec l'autocompletion, c'est encore mieux, mais a part notepad, il le gere tous.
- Lire du code, rien de tel que d'utiliser les raccourcis claviers (plus rapide a retrouver) pour trouver ou est definie une fonction, ou elle est utilisee,...
Je penses que tu comprends ou je veux en venir, mais de toutes les interfaces que j'ai teste (et on me force en ce moment a dev sous .Net), c'est toujours Emacs que je preferes. Son efficacite a manipuler du code est sans limite sa reactivite est excellente compare au bousin comme Sharp Develop ou Eclipse.
Alors j'attends toujours de voir mieux, mais ce n'est pas la souris qui en faira un argument en faveur, car quand tu passes ta journee a code, c'est vraiment le clavier que tu connais...
PS: Ca marche aussi pour les lecteurs mail, Kontact poutre carrement avec tous ses raccourcis clavier, meme plus besoin de souris. D'ailleur les travaux d'accessibilite de KDE en ce sens sont impressionant.
[^] # Re: portabilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: portabilité
Posté par sloft . Évalué à 2.
Je ne disais pas cela pour des professionnels et des personnes expérimentée mais pour de simples étudiants débutants en programmation graphique. Soyez indulgents, s'il vous plait, ne me jetez plus de pierres :p
[^] # Re: portabilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: portabilité
Posté par InfoRital . Évalué à 4.
Tu peux très bien packager la JVM avec ton appli (pense bien à ajouter manuellement la lib de la JVM server, bien plus puissante), et éventuellement de créer de petits lanceurs sous forme de scripts ou à l'aide pas mal d'outils comme JSmooth.
Pour faire de l'OpenGL en Java tu as deux excellentes API :
-LWJGL : une API développée communautairement, de très bonne qualité.
-JOGL : l'API officielle développée par Sun et SGI.
Pour cette dernière, cela tombe bien car la JSR 231 (le nouveau JOGL) est sortie en beta il y a environ une semaine.
Maintenant tu peux parfaitement utiliser OpenGL avec tes composants Swing, et je pense que cela conviendrait parfaitement à ton application.
Pour la rapidité, sache que Java n'est pas du tout lent ! Si tu utilises la JVM server tu auras des performances proches de celles du C++, voir meilleurs sur pas mal de points.
Pour l'utilisation de la mémoire, bof hein. Moi par exemple avec Eclipse, à son lancement, avec un petit projet chargé, et une perspective bien remplie de vues, je suis à 7 ou 8 Mo.
De plus Java + JOGL ou LWJGL et tu as une application quasi parfaitement multiplateforme (je vois d'ailleurs pas pourquoi elle ne le serait pas à 100%).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.