Journal .Net vs Qt vs Java

Posté par  .
Étiquettes : aucune
0
5
nov.
2005
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 !
  • # QT

    Posté par  . Évalué à 5.

    l'avantage du choix de QT4 est la disponibilité future du binding java, ce qui permettrait d'utiliser à terme vos 2 langages de prédilections.
    • [^] # Re: Qt

      Posté par  . Évalué à 2.

      Tu me fais penser que j'avais oublié de préciser que ce serait bien la V4 qui serait utilisée si Qt était choisi . Sinon merci, je ne savais pas qu'il y avait un QtJava en cours de préparation. Et en effet, ça fait un avantage pour Qt

      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  (site Web personnel) . Évalué à 4.

        Qt existe aussi avec une licence educative, qui te permet meme de ne pas mettre tes programmes en GPL.
  • # Qt

    Posté par  . Évalué à 3.

    Si c'était à moi de choisir, j'aurais, à priori, aussi pris Qt :
    - 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  . Évalué à 1.

      - OpenGL s'intègre bien avec Qt (Par contre je ne connais pas Java3d)

      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  . Évalué à 2.

        totalement d accord. le C++ est "totalement" portable.


        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  . Évalué à 1.

          oui (enfin surement), je repondais a la portabilite de java.
    • [^] # Re: Qt

      Posté par  . Évalué à 4.

      - L'avantage du java au niveau portabilité n'est pas évident
      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  . Évalué à 0.

        - L'avantage du java au niveau portabilité n'est pas évident
        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  . Évalué à 4.

          et ton binaire, il est portable?
          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  . Évalué à 5.

            Et le binaire de ta JVM elle est portable ? ;)
            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  . Évalué à 1.

              Et le binaire de ta JVM elle est portable ? ;)
              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  . Évalué à 2.

                Tu n'as pas forcément besoin d'un truc comme ça. j'ai un cas linux/solaris/windows qui a juste les librairy à linker de différentes.

                "La première sécurité est la liberté"

        • [^] # Re: Qt

          Posté par  . Évalué à -1.

          J'ai fait la même chose avec une interface graphique en C

          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  . Évalué à 2.

            ben j'aimerais bien voir ca tiens.
            C'est quoi tes comportements bizarres?
  • # compte rendu

    Posté par  . Évalué à 4.

    je ne peux pas t aider sur ces technos, mais je serais interesse de connaitre les conclusions de votre comparatif. si tu peux les poster plus tard.

    merci,

    --
    poueeeet!
    • [^] # Re: compte rendu

      Posté par  . Évalué à 1.

      Pas de soucis, je les posterai mardi soir, à l'issue de notre petite réunion. Mais je ne sais pas si je re-ferai un journal pour ça...
      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 :) )
  • # Avis pas forcément utile

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

    Ce que je vais dire sera pas forcément un critère pour toi, suivant ton avis sur la question. Mais pour moi le fait que l'implémentation libre de Qt soit celle "de référence" est un atout.

    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  . Évalué à 2.

      Ton commentaire m'est utile, bien au contraire :)

      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  . Évalué à 2.

        Cherche sur sourceforge. Ils y existent plus de moteur 3D en développement que de jeux qui les utilisent.

        "La première sécurité est la liberté"

  • # portabilité

    Posté par  . Évalué à 4.

    Un plus pour qt4 si la portabilité est un objectif important (c'est un peu comme ça que je comprend le "dont le but sera notamment d'être distribuée le plus largement possible").

    À 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  . Évalué à 1.

      Merci de ton commentaire.

      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  . Évalué à 1.

        Etant un membre de l'équipe du projet je peux préciser que l'applicaiton est déjà réalisée pour ce qui est de l'interface (en visual basic 6, avec 10 ans de travail par un professeur de GMP) . Etant donné que nous devrons programmer une partie en openGL, nous pensons que le mieux est de choisir un langage plus adapté à la programmation 3D.
        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  . Évalué à 4.

          l'applicaiton est déjà réalisée pour ce qui est de l'interface

          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.


          le mieux est de choisir un langage plus adapté à la programmation 3D

          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.


          Le programme est plutôt destiné à des entreprises car trés spécifique et technique

          Tu oublies (par exemple) les universités, professeurs, étudiants, passionés, et les inévitables curieux.


          C'est pour cela que je mettrait un bémol sur <<le but sera notamment d'être distribuée le plus largement possible.>>

          Ce sont les mots du professeur qui nous mandate.


          Mais pour Qt je me demande s'il existe un équivalent

          Tout IDE C++ qui se respecte. Qt n'est pas un langage, c'est juste une API.


          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.

          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  . Évalué à 2.

            il nous a été demandé de repartir quasiment de 0
            C'est pas l'interface la chose la plus difficile à réaliser, on a déjà l'application en VB pour nous guider sur l'aspect visuel. Pour ce qui est du code des calculs, on les a tous également et la traduction ne sera pas spécialement un soucis. Donc je pense pas qu'on peut parler de repartir de 0.
            C'est surtout l'OpenGl que nous ne connaissons pas du tout qui nous demandera le plus de travail.
            Tu oublies (par exemple) les universités, professeurs, étudiants, passionés, et les inévitables curieux.

            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.
            Ce sont les mots du professeur qui nous mandate.

            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.
            Tout IDE C++ qui se respecte. Qt n'est pas un langage, c'est juste une API.

            Explicitement et dans la pratique ça donne quoi ?
            ce qui sera un frein pour ceux qui voudraient développer sous linux ( crois-tu vraiment que je sois le seul ? ).

            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  . Évalué à 0.

              Tout IDE C++ qui se respecte. Qt n'est pas un langage, c'est juste une AP

              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  . Évalué à 3.

                Si le but est juste de tapper du code et non debugguer, j'ai encore rien vu au niveau de emacs. Même si Eclispe propose l'autocomplétion des fonctions de bibliothèques (bien pour java mais pas pour C++).

                "La première sécurité est la liberté"

              • [^] # Re: portabilité

                Posté par  . Évalué à 2.

                Et concrètement dans la pratique, il existe quelles IDE valables pour du Qt/C++ ? Aussi aboutis que Sharp Develop par exemple.

                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  . Évalué à 2.

              C'est surtout l'OpenGl que nous ne connaissons pas du tout qui nous demandera le plus de travail.

              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.

              Soit pas si idéaliste que ça

              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 qu'au départ il a refusé de distribuer le programme avec ses sources

              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é.

              C'est donc dans l'optique de le distribuer gratuitement qu'il s'est mis à la tâche

              Je réitère. Gratuitement et largement

              Explicitement et dans la pratique ça donne quoi ?

              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

              A parce que tu n'es pas le seul dans l'équipe?

              On verra ça mardi! ^^
              • [^] # Re: portabilité

                Posté par  . Évalué à -1.

                J'ai pas bien l'impression que tu vois exactement ce que je te demande. J'te ferai une démo si tu comprends pas ce que je veux dire. Par exemple, Sharp Develop est conçu pour .NET donc également pour le C#. Il est parfaitement adapté pour programmer un projet comme le notre.
                Kdevelop, anjuta, borland C++ builder, eclipse/CDT, MSVC++, vim, emacs, devcpp, notepad2
                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  . Évalué à 8.

                  On doit pouvoir modifier à la souris notre application

                  Les étudiants d'maint'nant, c'est plus c'que c'était, ma bonne dame...
                  • [^] # Re: portabilité

                    Posté par  . Évalué à 2.

                    M'inclus pas dedans STP
                    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  . Évalué à 1.

                    On a 5 mois pour développer cette application (sans compter nos cours à côté), ensuite on part dix semaines en stage et puis... il n'est pas prévu de continuer de la développer. Un petit nombre continuera peut-être à la faire évoluer mais rien n'est moins sûr car on ne sait pas encore où nos études nous meneront et si nous trouverons le temps pour ça (nous sommes tous en deuxième année de DUT informatique option génie logiciel). Nous venons juste de débuter la programmation graphique depuis un petit mois en java et ne connaissons ni l'API de Qt ni le C#. Donc dans tous les cas on aura une phase d'apprentissage qui prendra du temps. Donc si dessiner une partie de l'interface à la souris peut gagner du temps, je pense qu'il faut en profiter :)
                    • [^] # Re: portabilité

                      Posté par  . Évalué à 2.

                      Heu oui mais ce dont vous parliez c'est du besoin d'avoir le machin graphique de conception d'interface intégré à un éditeur (ce que j'ai compris par "IDE" en tt cas).

                      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  (site Web personnel) . Évalué à 3.

                  Kdevelop, anjuta, borland C++ builder, eclipse/CDT, MSVC++, vim, emacs, devcpp, notepad2
                  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
                  C'est pas que veuille m'interposer... mais je te trouve trop condescendant.
                  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.

                  Sharp Develop est conçu pour .NET donc également pour le C#. Il est parfaitement adapté pour programmer un projet comme le notre.
                  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  . Évalué à 1.

                    Je conçois tout à fait que l'on peut développer n'importe quel programme avec emacs ou Vim, depuis le début de mes études j'ai toujours programmé avec emacs que ça soit pour le C/C++, l'ASM ou le java. Mais pour ce projet, il me semble que ce type de programme n'est pas vraiment adapté.
                    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  . Évalué à 3.

                  On doit pouvoir modifier à la souris notre application,


                  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  . Évalué à 3.

                  Tu crois que linux se développe à la sourie O_O ? A-t-on avis Linus code avec quoi ? (emacs pour info...)

                  "La première sécurité est la liberté"

                  • [^] # Re: portabilité

                    Posté par  . Évalué à 2.

                    Je vois que le coup de l'édition d'une fenêtre à la souris ça hérisse les cheveux de pas mal de personnes, désolé :s
                    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  . Évalué à 2.

                      Pour le coté pure graphique, y'a Qt designer pour Qt.

                      "La première sécurité est la liberté"

    • [^] # Re: portabilité

      Posté par  . Évalué à 4.

      Le JDK 1.5 existe sous Mac OS X (c'est Apple qui en assure le développement) => http://www.apple.com/support/downloads/java2se50release1.htm(...)

      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 à ceux qui les ont postés. Nous n’en sommes pas responsables.