Journal Manque d'arguments pour Qt... Help !

Posté par  .
Étiquettes : aucune
0
27
sept.
2005
Bonjour mes chers amis LinuxFRiens!

Aujourd'hui, il m'est arrivé quelque chose de fort. En tant qu'étudiant de deuxième année au département informatique de mon IUT, un projet de synthèse un peu particulier a été proposé à l'ensemble de ma promotion.
Ce projet, proposé par un professeur du département de génie mécanique du même IUT, consisterait en une sorte de modélisateur d'efforts sur véhicules qui permettrait de faire du "tweaking" de voitures pour ceux qui s'y connaissent assez.

Au final 10 étudiants, dont moi-même, sont intéressés pour la mise en oeuvre de ce projet en tant que projet de synthèse. Ceci étant, une réunion dite "technique" doit avoir lieu mardi prochain en début d'après-midi pour décider des technologies (notamment au niveau de l'interface du logiciel) qui seront utilisées lors de la réalisation.

Sont donc en compétition
- .NET
- Java
- Qt

Outre le fait de l'aspect propriétaire des deux première plateformes, j'aurais besoin d'arguments en faveur de Qt. Pourquoi lui et pas un autre? Sachant que presque aucun membre de l'équipe ne connaît d'API graphiques, qu'elles soient spécifiques à n'importe laquelle des plateformes suscitées.

En plus de cela, je manque aussi cruellement d'arguments sur la question pour / contre les générateurs de codes. A savoir le fait de faire ses interfaces à l'aide d'un outil graphique et lui laisser générer du code pour que ça marche bien (TM). J'avoue que sur ce dernier point, je n'ai pas d'opinion tranchée, bien que je pense intimement que le mieux est quand même de tout faire à la main, histoire au moins d'avoir un code plus propre. De toute façon, pour ce genre de programmation, il faut connaître l'API utilisée quoi qu'il arrive, non?

La portabilité n'est pas un objectif majeur mais serait un plus.
A titre indicatif, pour un rendu 3d inclus dans l'application, il y a des chances que OpenGL soit utilisé. Ceci dit, si vous avez aussi des arguments en faveur de cette solution plutôt qu'une autre (ou l'inverse), je suis tout autant intéressé!


Merci de votre aide!

  • # sinon

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

    Perso lors d'un projet universitaire on a fait un tout autre choix : appliquer un modèle appris en cours, le modèle PAC (Présentation/Abstraction/Contrôle), qui permet de ne rendre dépendant d'un toolkit graphique qu'une seule couche de l'application : au final on a produit 2 interfaces, une en GTK, l'autre en WinForms/.NET, chacune étant parfaitement intégrée. Les couches de contrôle et les services métiers sont communs.

    Au final tout le monde était content, on avait une interface pour Windows, et une pour Linux.

    Le projet en question :
    http://projet.ifsic.univ-rennes1.fr/projects/synthlab5/(...)
    Dans le rapport il y a des screenshots de l'application sous Linux et Windows et les explications qui vont bien :
    http://projet.ifsic.univ-rennes1.fr/docman/view.php/32/240/doc.pdf(...)

    Au final le programme fait un switch au démarrage sur l'OS cible pour lancer un toolkit par défaut.
    On peut aussi forcer gtk sous Windows :
    mono synthlab.exe -gtk
    ou pour l'interface .NET/WinForms :
    synthlab.exe

    • [^] # Re: sinon

      Posté par  . Évalué à 1.

      Merci pour ta réponse.
      Ce concept m'à l'air tout à fait intéressant. Ceci dit, vu le temps qui va nous être imparti, une et une seule interface pourra être codée dans le cadre du projet de synthèse.
      Bien, sur, ça ne nous empêchera pas d'utiliser ton modèle si l'application est maintenue par la suite! ;)

      • [^] # Re: sinon

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

        Ben nous on avait utilisé ce modèle en développant uniquement l'interface WinForms/.NET dans un premier temps. J'ai codé la version GTK sous Linux en une soirée, tout le gros du code étant réutilisable, notamment la couche Contrôle.

        • [^] # Re: sinon

          Posté par  . Évalué à 1.

          En gros, vous avez placé la priorité sur l'interface dependant de logiciels propriétaire et torché la version 100 % libre à l'arrache, au feeling.

          Franchement, un amateur de libre aura toutes les raisons de favoriser Qt.

          D'autant que ce n'est pas très clair dans ce que tu dis, mais dans l'exemple que tu donnes plus haut, on dirait qu'il est question d'utiliser Mono. Or Mono, c'est loin d'être considéré comme très fiable, pour le moment, si je ne m'abuse.
          Donc en gros, on a une interface qui dépend de Mono torchée en une soirée à coté d'une interface bien préparée qui fonctionne sur WinForms/.Net ?

          Je me répête, franchement, un amateur de libre aura toutes les raisons de favoriser Qt.

          • [^] # Re: sinon

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

            En gros, vous avez placé la priorité sur l'interface dependant de logiciels propriétaire et torché la version 100 % libre à l'arrache, au feeling.
            Pas du tout.
            Nous avons fait un soft qui s'intègre dans l'environnement qui était à notre disposition pour développer/utiliser notre application.
            Qt utilise des bibliothèques de Windows de la même manière lorsqu'elle tourne sous Windows. En tant que fervant défenseur des logiciels libre j'avais comme objectif de montrer l'intérêt de l'approche, et j'ai pensé depuis le début à concevoir l'application de manière à coder l'interface en GTK, ce qui s'est révélé être une formalité, validant les choix de conception.
            C'est pas du tout du "feeling" et fait à l'arrache comme tu dis. C'est encore la meilleure méthode que j'ai trouvé pour proposer une intégration suffisante dans des environnements très différents comme Windows et Gnome.

            Or Mono, c'est loin d'être considéré comme très fiable, pour le moment, si je ne m'abuse.
            C'est tellement pas fiable que c'est supporté commercialement :
            http://www.mono-project.com/Kickstart(...)
            Et ca commence à être utilisé par un certain nombre d'entreprises :
            http://www.mono-project.com/Software#Commercial_Applications(...)

            Et puis le fait est que pour notre application cheznouscamarche (TM).

            Donc en gros, on a une interface qui dépend de Mono torchée en une soirée à coté d'une interface bien préparée qui fonctionne sur WinForms/.Net ?
            Il n'y a aucune dépendance envers Mono, la seule dépendance est envers WinForms ou GTK#, ce dernier tourne sous Windows sans Mono si ca t'amuse. Voir aucune dépendance, il est facile d'utiliser la partie métier sans aucune interface graphique.

            Je me répête, franchement, un amateur de libre aura toutes les raisons de favoriser Qt.
            Un amateur de libre a la première liberté d'utiliser la technologie qu'il souhaite, et je le repèterai jamais autant, ajouter une dépendance envers une bibliothèque graphique est un mauvais choix de conception. Qt n'est que partiellement intégré à Windows et ne présente donc pas une solution idéal pour ses utilisateurs. Il est donc vital de pouvoir facilement utiliser un autre toolkit si les besoins des utilisateurs s'en fait sentir.

            Pour moi enfermer une application en utilisant Qt à tous les niveaux (des threads à l'IHM), c'est "fermer" un logiciel à un certain nombre d'utilisateur et de développeurs.

          • [^] # Re: sinon

            Posté par  . Évalué à 6.

            Outre le fait de l'aspect propriétaire des deux première plateformes, ...


            Franchement, un amateur de libre aura toutes les raisons de favoriser Qt.


            http://sourceforge.net/softwaremap/trove_list.php?form_cat=160(...)

            Java (16123 projects)
            ...
            C++ (16309 projects)

            Combien de projet Qt dans la catégorie C++ ?

            Arrêtez un peu avec vos trolls sur Java/Mono "sapussépalibre".
            Là, on essaie de se concentrer sur les mérites techniques (portabilité, réutilisabilité, ....)

            • [^] # Re: sinon

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

              C'est très laid ce que tu fait car les applis KDE sont généralement sur l'infrastructure éponyme et pas sur SF.
              De toutes manières, quoi qu'en disent ces chiffrent je sais quelle proportion des différents langages se trouve sur mon système, et qu'il y a incomparablement plus de C++ que de Java (et pas de pointnet) .

              • [^] # Re: sinon

                Posté par  . Évalué à 1.

                De même, tu ne retrouves pas tous les projets Java sur SF(Apache, ...)
                Le but était simplement de montrer que Java est bien représenté dans les projets libres et qu'il n'y a donc pas trop de souci à se faire, pas de lancer un nouveau troll.
                Qt a longtemps été critiqué sur ce point avant le revirement de Trolltech.

                Et ce genre de pb est AMHA un faux pb. A un moment donné on a toujours affaire à du proprio que ce soit au niveau de du soft du runtime, de l'OS, du hardware (driver, microcode, ... ).
                Le jour où on trouvera des fondeurs de F-CPU et des périph libres on pourra dire que la chaîne est libre de bout en bout.
                En attendant, il s'agit de problèmes qu'il faut gérer au cas par cas lorsqu'il y a de véritables dangers.

                De même que tu trouves des LL sous Windows.
                et qu'on ne parle pas de libérer Windows, il y a des projets libres en Java et des implémentation libres.
                Pour java le projet Harmony (JVM Java) peut changer la donne.
                Même si le projet est ambiteux, on est en droit d'esperer que Sun va libérer sa JVM sous la pression communautaire et c'est un peu la raison du projet et de la participation d'IBM .

                Bref! Chacun a sa conception de la liberté.

                • [^] # Re: sinon

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

                  De même, tu ne retrouves pas tous les projets Java sur SF(Apache, ...)
                  Non, c'est pas pareil. Aucun logiciel Qt que j'utilise n'est sur SF. Cette plateforme n'est pas utilisée par KDE.
                  D'ailleurs, "compter les projets" ça veut rien dire. Un projet au sens de sourceforge ça peut aussi bien être KDE que tar.

                  Le reste est un peu HS, mais je résiste pas à un beau troll.

                  Qt a longtemps été critiqué sur ce point avant le revirement de Trolltech.
                  Qt a toujours été Libre sous X11, c'est juste qu'il était pas compatible GPL.

                  A un moment donné on a toujours affaire à du proprio que ce soit au niveau de du soft du runtime, de l'OS, du hardware (driver, microcode, ... ).
                  Ça c'est du hardware. Y'a une différence fondamentale en ce qu'un logiciel est une information (liberté d'expression et partage de la connaissance) et un CPU: un matériel qui existe en dehors des idées qui le représentent.

                  Bref! Chacun a sa conception de la liberté.
                  C'est vrai. Beaucoup de gens ont des avis qui leurs sont propres sur un certain nombre de sujets.
                  Mais je ne vois pas le rapport.

    • [^] # Re: sinon

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

      > appliquer un modèle appris en cours, le modèle PAC

      As-tu de la documentation sur PAC et les modeles du genre ?
      Ca m'interesse enormement !
      Merci

      • [^] # Re: sinon

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

        GOOOOoooog... ok un premier lien :
        http://membres.lycos.fr/interaction/Architecture/Pac/pac1.html(...)

        C'est un modèle, il faut penser à l'adapter à ses besoins, à ses outils, etc.
        Perso je n'aime pas trop le principe consistant à toujours passer par la couche de contrôle, notamment lors de communications entre 2 présentations ou 2 abstractions, pour la simple et bonne raison que les abstractions constituent souvent le modèle métier, et fonctionne donc de manière autonomne, et que les objets de présentation on besoin de communiquer pour "s'emboiter" comme l'impose tous les toolkit graphiques.

        Tu peux consulter le rapport de notre projet pour avoir un aperçu de mon "mod" de PAC, notamment adapté à la plateforme .NET et à l'indépendance vis-à-vis du toolkit graphique.

    • [^] # Re: sinon

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

      Dans le rapport il y a des screenshots de l'application sous Linux et Windows et les explications qui vont bien :
      http://projet.ifsic.univ-rennes1.fr/docman/view.php/32/240/doc.pdf((...)

      Sniff, je voulais regarder comment l'application était architecturée, mais les diagrammes UML dans le PDF sont de très mauvaise qualité. En tout cas, avec evince ou xpdf, ils sont illisibles.

      • [^] # Re: sinon

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

        oué c'est pas top top dans le rapport, ca passe à peu prêt sous Acrobat reader seulement :-/
        Je viens de metttre la version HTML en ligne, beaucoup plus friendly :
        http://pascalfresnay.free.fr/projet/synthlab/(...)

        • [^] # Re: sinon

          Posté par  . Évalué à 1.

          Un peu (beaucoup) hors sujet :

          Il semble que tu ai utilisé LaTeX pour ton rapport. Quelles classes/styles as tu utilisé pour obtenir cette mise en page du PDF ?

          Je trouve ton rapport vraiment bien présenté (la numérotation, les titres en "sans serif", etc...)

          Je suis en train de découvrir LaTeX. Pour le moment, j'utilise la classe "report" mais c'est pas top (exemple : la création d'un chapitre qui ajoute "Chapitre x")

          Pourrais tu me donner l'entête (ou si possible la totalité) de ton fichier .tex pour que je jete un oeil ?

          Merci.

          • [^] # Re: sinon

            Posté par  . Évalué à 2.

            Désolé, j'ai tapé trop vite. Je viens de voir dans les sources HTML que c'est du DocBook.

            Pour ma peine, je vais tourner 7 fois mon clavier dans la bouche... Ça va faire mal...

  • # Précisions

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

    Je te renvois à ce journal qui peut t'apporter quelques éléments :
    https://linuxfr.org/~jberthon/19498.html(...)

  • # Attentions à la véracités de tes arguments

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

    Je ne te donnerais pas d'arguments pour Qt, mais juste comme cela en passant, tu sites 2 arguments pour Qt qui peuvent se retourner rapidement contre toi.

    Pour l'aspect propriétaire : Oui java n'est pas libre, mais contrairement à ce que tu dis, JAVA n'est pas complétement fermé pour autant. Ils y a maintenant un consortium d'utilisateur de Java mis en place pour son évolution. Sun est à la tête de cet entité oui, mais tout les programmeurs Java peuvent demandé des ajouts de fonctionnalités (qui ne seront pas forcément refusé ...).
    De plus, pour toute application propriétaire (ou a but commercial) Qt n'est plus libre mais soumis à licence.

    Ensuite, en ce qui concerne la portabilité, et bien je ne pense pas que le couple C++/Qt soit beaucoup plus portable que Java.
    De même qu'il existe maintenant le projet mono qui permet de faire des applications se basant sur c# sous Linux comme sous Windows.

    Donc comme tu peux le voir, sur les deux arguments que tu cites, il est rapidement possible de te contredire En faisant peut être des raccouris, en omettant des fonctionnalités manquantes, mais bon, dans tous les cas, si tu te retrouves avec quelqu'un comme moi en face de toi, (avec une tendance légère à la déformation des faits) tu as intérets à avoir des arguments bétons .... Ne pratiquant pas Qt, j'aurais du mal à t'en donné mais je pencherais plus à la performance du C++, à l'intégration de l'Open/GL par le bias de Glut, par la disposition du documentation abondante et enfin par la mise en valeur des principales applications utilisant Qt.

    Bon courage

    • [^] # Re: Attentions à la véracités de tes arguments

      Posté par  . Évalué à 2.

      Merci :)

      En fait, si je poste ce journal, c'est surtout pour ressortir avec des arguments béton (ou un changement d'avis éventuel si je me fais trop taper sur les doigts).
      Ce que tu dis n'est pas faux et pour les arguments que tu cites en fin de commentaire, je tacherai d'en faire bon usage.

      Au niveau de la portabilité, en utilisant Qt comme il se doit, on peut se retrouver avec du 0 lignes de code à modifier lors d'un changement de plateforme m'a-t-on dit. A condition bien sur de ne pas utiliser des fonctions spécifiques au système utilisé en parallèle. Mais pour un projet comme celui-ci, il n'y aurait aucune raison que ce soit le cas.

    • [^] # Arroseur arrosable !

      Posté par  . Évalué à 3.

      « De plus, pour toute application propriétaire (ou a but commercial) Qt n'est plus libre mais soumis à licence. »

      Ca ne veut rien dire. C'est comme si tu disais qu'un logiciel GPL n'est pas libre pour un logiciel propriétaire : évidemment !

      Et lorsque tu dis « (ou a but commercial ) » tu te plantes de manière assez facheuse ! Depuis quand la GPL interdit des activités commerciales ! Tout les logiciels libres sont commercialisable, tous sont donc potentiellement commerciaux, à but commercial.


      « Ensuite, en ce qui concerne la portabilité, et bien je ne pense pas que le couple C++/Qt soit beaucoup plus portable que Java.
      De même qu'il existe maintenant le projet mono qui permet de faire des applications se basant sur c# sous Linux comme sous Windows. »

      Il a dit plus haut que la portabilité n'était pas une priorité. Quand a Mono, il faudra d'abord qu'on trouve rien qu'une seule application élaborée et fiable, utilisée fréquemment qui fonctionne avec Mono pour qu'on puisse présenter cela comme une option.
      Moi jusqu'ici, je n'ai vu que des "Hello World!" améliorés. Je n'ai pas creuser la question mais ça semble un peu prématuré.


      « Donc comme tu peux le voir, sur les deux arguments que tu cites, il est rapidement possible de te contredire »

      en racontant des trucs qui ne veulent pas dire grand chose, toutefois.

      • [^] # Re: Arroseur arrosable !

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

        Quand a Mono, il faudra d'abord qu'on trouve rien qu'une seule application élaborée et fiable, utilisée fréquemment qui fonctionne avec Mono pour qu'on puisse présenter cela comme une option.
        iFolder ? http://www.ifolder.com/(...) (ok ok c'est Novell)
        GMovil ? http://www.aspl.es/gmovil/us/index.html(...) (Ok ok on l'utilise pas tous les jours, mais c'est quand même un test grandeur nature)
        Virtuoso ? http://virtuoso.openlinksw.com/(...) (idem, c'est pas tous les jours, mais c'est une application "professsionnelle")

      • [^] # Re: Arroseur arrosable !

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

        Et bien pour la license de QT, j'avoue ne pas avoir tout compris :

        Entry number: 116 - How will the dual licensing of Qt/Windows affect me?
        Answer:

        If you are a commercial developer or company developing proprietary software, we expect no direct effect. You will however, benefit over time from a gradually expanding pool of skilled Qt developers. (Texte issue de la FAQ de Qt)


        Je suis d'accord que l'on peut commercialiser un logiciel sous GPL or j'ai l'impression que eux, ils font une différence entre GPL non commercial et GPL tout court.

        Ensuite, je n'ai pas dis que mes arguments à moi était bétons, mais ils n'y a pas besoin d'avoir des arguments forts pour mettre un doute à la mise en place de technologie non connue ....

        • [^] # Re: Arroseur arrosable !

          Posté par  . Évalué à 4.

          nan, rien a voir avec le commercial ou pas.

          tu release sous gpl, t'utilise Qt GPL (donc gratuit), tu release pas sous GPL t'utilise Qt proprio (donc pas gratuit, sous reserve que ca soit compatible avec ta licence).

  • # :)

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

    le mieux est quand même de tout faire à la main, histoire au moins d'avoir un code plus propre.

    Ouai enfin parle pas trop vite quand même. Parfois, avoir un truc qui te crache du code de façon systématique pour certaine portion, ça simplifie la vie, mais tu évites d'écrire des boulette en le faisant à la main....

    Pour Qt, y'a Qt Designer qui est très rapide à prendre en main et vraiment bien fait (il m'a fallu qqs heures pour faire une interface graphique, sans rien connaitre de Qt).

    (et y'a pas GTK dans la liste ? :))

    • [^] # Re: :)

      Posté par  . Évalué à 2.

      C'est sur qu'il faut faire gaffe à ce qu'on tape aussi ;). Les deux ont des avantages, c'est pour ça que je n'ai pas d'avis tranché sur la question.

      Et pour GTK, il ne figure pas dans la liste mais il pourrais. Ceci dit il est fait mention régulièrement de la documentation pas toujours exhaustive / simple à trouver. Ceci dit, n'ayant pas utilisé moi-même GTK, j'éviterai de me présenter sur un terrain glissant. En même temps, ça serait bête de se retrouver avec une doc incomplète sachant que tout le monde débarque sans connaissance aucune de l'API

    • [^] # Re: :)

      Posté par  . Évalué à 5.

      D'ailleurs, pour Qt designer, une très bonne chose est que tu ne touches jamais au code généré (c'est fait pour), au contraire des générateurs de code à la Visual C++ ...

      Si tu l'utilises, tu es censé dériver des classes générées pour implémenter ce qui manque. Ainsi tu peux très facilement revenir à l'outil de génération, sans risques d'interférences dans aucun sens ! Et puis t'as pas à te farcir du code généré, ce qui n'est pas toujours très pratique ...

      Bref: le meilleur des deux mondes :)

  • # Langage

    Posté par  . Évalué à 6.

    Avec une telle alternative le premier argument qui me vient a l'esprit (pas forcément en faveur de QT) est : quel est le langage le mieux maitrisé par participants au projet ? Si c'est C++, il me semble que QT a un bon avantage.

    Si vous maitrisez tous Java par contre...

    • [^] # Re: Langage

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

      On peut aussi apprendre un nouveau langage dans certains cas, ce qui apportera un + sur le CV, mais que dans certains cas :
      - C# connu ? Apprendre Java.
      - Java connu ? Apprendre C#.
      - C++ connu ? Moins évident d'apprendre Java ou C#
      - Java ou C# ? Quasiment impossible de passer à C++ sans perdre de vue les autres objectifs du projet.

      Point 2 et 4 testés sur des projets de quelques mois dans le cadre universitaire (pas à temps plein)

      • [^] # Re: Langage

        Posté par  . Évalué à 2.

        Le langage le plus maitrisé pour le moment est C++. En même temps l'apprentissage de java est en cours.
        Deux visions des choses peuvent donc s'offrir au niveau du choix du langage

        - C++ parce qu'on connait mieux
        - Java parce qu'on doit apprendre

        Et là, je ne sais pas quel choix serait fait.

      • [^] # Re: Langage

        Posté par  . Évalué à 1.

        - C# connu ? Apprendre Java.
        - Java connu ? Apprendre C#.

        Franchement, argumente parce que là je vois pas l'intérêt ! Si tu veux apprendre un langage tu as tout intérêt à choisir un langage différent de ce que tu connais, et si tu ne connais pas le C++, ça me semble une bonne chose de l'apprendre. Certe le langage a des défauts (mais quel langage n'en a pas ?) et il est réputé difficile. Pourtant c'est un langage qui a l'avantage d'offrir plusieurs niveaux de programmation et tu n'es pas obligé de te frotter aux difficultés dès le début !

        Et puis le plus gros pb du C++ c'est que très peu de gens savent vraiment l'utiliser ! Y a qu'à voir le nombre de bibliothèques "haut niveaux" qui proposent encore de travailler directement sur des pointeurs ...

        • [^] # Re: Langage

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

          Franchement, argumente parce que là je vois pas l'intérêt !
          Ben si je l'ai dis : ajouter une ligne à ton CV.

          si tu ne connais pas le C++, ça me semble une bonne chose de l'apprendre
          Tout à fait d'accord, mais un projet court aux objectifs éducatifs nombreux n'est pour moi pas le bon contexte, faut de temps, à moins d'y consacré la totalité du projet, ce qui n'a absolument aucun intérêt pédagogique.
          Pour ce qui est des difficultés, que tu le veuilles ou non tu vas les rencontrer, à commencer par la gestion de la mémoire, la notion de pointeur, de référence, l'utilisation de Qt apportant également son lot de difficultés pour le débutant en C++.

          Et puis le plus gros pb du C++ c'est que très peu de gens savent vraiment l'utiliser !
          Justement, son apprentissage ne s'improvise pas dans le cadre d'un projet àlavavite, mais s'étudie lors d'un cours et s'approfondit lors de TP encadré.

          Comme l'a constaté un prof de fac en parlant des projets de fin d'année : "ca fait 10 ans qu'on faisait les TP en C++, il n'y avait quasiment aucun projet de fini, ca fait 2 ans qu'on les fait en Java et ils arrivent quasiment tous à terme."

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Manque d'arguments pour Qt... Help !

      Posté par  . Évalué à 1.

      J'ai des arguments, ceci dit j'aimerais bien les étoffer un peu :) . Perso, Java et .net me filent une petite chair de poule quant même...

      • [^] # Re: Manque d'arguments pour Qt... Help !

        Posté par  . Évalué à 1.

        Moi ce qui me désolé, c'est qu'avec Java, vous risquez de pondre un truc qui dépend de la JVM de Sun (parce que classpath/gcj ne fait pas tout, comme le montre le problème d'openoffice 2), et avec .Net, vous risquez de pondre un truc qui dépend... de Windows (parce que Mono, ça n'a pas l'air être au niveau de classpath/gcj).

        • [^] # Re: Manque d'arguments pour Qt... Help !

          Posté par  . Évalué à 2.

          Tu peux étayer sur le parce que Mono, ça n'a pas l'air être au niveau de classpath/gcj ?

          Parce que comme montré plus haut dans la discussion, des applis qui utilisent Mono y'en a de plus en plus, et le développement avance à grand pas. A tel point que certaines parties de C# 2.0 sont déjà implémentées dans Mono (v. 1.1.x ), alors que c'est pas encore chez Microsoft (à part en beta).

        • [^] # Re: Manque d'arguments pour Qt... Help !

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

          et avec .Net, vous risquez de pondre un truc qui dépend... de Windows
          Suffit de d'installer Mono sous Windows et de développer avec l'IDE SharpDevelop, qui propose l'intégration avec Mono.

          En C++ je peux te pondre du code qui sera dépendant que de Windows ou que de Linux de la même façon :) (voir encore plus simplement)

        • [^] # Re: Manque d'arguments pour Qt... Help !

          Posté par  (Mastodon) . Évalué à 3.

          parce que Mono, ça n'a pas l'air être au niveau de classpath/gcj


          Ça m'intrigue, cet acharnement (au sein de ce journal, ailleurs je ne sais pas) à descendre Mono alors que ton seul argument semble être "j'ai jamais rien vu de fini codé en Mono, mais je n'ai pas cherché".

          Pour ma part je ne me suis pas penché sur la question, mais je suis déjà tombé sur quelques softs intéressants (Beagle, F-Spot, Monodevelop...) codés en C# avec Mono, et qui ont l'air de bien tourner. Comme soft compilé avec GCJ, je n'ai à ce jour rencontré qu'iRate (bon concept mais logiciel pas terrible). C'est tellement subjectif comme observation que je ne me risquerai pas à supposer que Mono est "plus avancé" que GCJ, mais je suis curieux de savoir pourquoi tu penses le contraire.

          • [^] # Re: Manque d'arguments pour Qt... Help !

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

            Y'a Eclipse qui tourne bien avec GCJ et qui est un bon exemple de bonne grosse appli stressante pour la VM :)
            Sinon ca sert à rien de faire la guguerre CLassPath/Mono, le 2ème proposant une passerelle entre les 2 : on peut utiliser les ClassPath depuis Mono, et utiliser les libs Mono depuis Java. Le plus rigolo c'est qu'on peut compiler du code en natif sans passer par gcj mais en utilisant IKVM puis mono qui fait la compilation en natif depuis un baille (les technos .NET étant conçu pour cette opération).

  • # euh

    Posté par  . Évalué à 0.

    JAVA et .NET c'est mal voyeeeeeezzzzz!
    Sinon un bon un bon bouquin gratuit pour apprendre peut faire toute la différence. Ce bouquin est d'ailleurs disponible a cette adresse : C++ GUI Programming with Qt 3

    • [^] # Re: euh

      Posté par  . Évalué à 3.

      OUPS! Raté! Voilà l'url : http://www.phptr.com/content/images/0131240722/downloads/blanchette(...)

    • [^] # Re: euh

      Posté par  . Évalué à 2.

      En même temps, je pense pas que le manque de doc vis-à-vis de Java et .Net soit un argument qui tienne beaucoup la route... De la doc, même gratuite, on en trouve. Du moins je pense...

      • [^] # Re: euh

        Posté par  . Évalué à 2.

        Pour moi c'est un argument comme un autre, bien que je te l'accorde il soit faiblard. Un argument plus personnel est que je trouve beaucoup plus agréable et plus simple QT utilisé avec Python (que je suis en train d'apprendre) ou C++ que Java et Awt ou Swing

        • [^] # Re: euh

          Posté par  . Évalué à 2.

          Et Jython /SWT ca compte pour des prunes.

          Et perso, pour optimiser ou recoder le comportement d'une classe à cause d'un défaut de conception, quand python est à la ramasse, je préfère me mettre au Java qu'au C++, mais c'est un autre trolldébat

      • [^] # Re: euh

        Posté par  . Évalué à 2.

        Je reconnais que l'argument est faiblard. Des arguments j'en ai pas des masses, j'ai juste mon opinion personnelle. Je trouve QT allié à Python vraiment très agréable dans la construction d'une interface graphique.

        • [^] # Re: euh

          Posté par  . Évalué à 2.

          et merde! saloperie de IE de la fac

  • # gtk gtk

    Posté par  . Évalué à 1.

    et gtk, et gtkmm alors?
    glade permet de faire des fichiers xml decrivant les fenetres, et il existe enormement de binding: c, c++, ruby, perl, c#

    • [^] # Re: gtk gtk

      Posté par  . Évalué à 5.

      Sauf que gtk en temr de looh and feel et de comportement natif sous Windows y'a encore un peu de chemin à faire.

      Pour le coup, je dirais que c'est un vrai argument pour Qt ou Mono, même si Java/SWT est assez bluffant.

      Et sinon as tu pensé à wxWidgets ?
      Perso, je n'apprecie guère pour pas mal de raison mais ses partisans ne manqueront pas d'argumenter.

  • # Qt ou Java ou .NET ?

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

    Personnellement je ne me poserai pas la question comme ca.
    Je me poserai plus des questions sur le projet lui-meme pour trouver l'outil adapte a la realisation de celui-ci

    Le projet demande t'il une interface graphique complexe ?
    Le projet demande t'il une couche metier complexe ?
    Le projet doit-il etre multiplatformes (les contraintes du projet) ?
    Le projet demande t'il beaucoup d'acces aux 'perifs' de la machine (audio, port USB ect...)
    Le projet est-il principalement a but educatif ?
    ect...

    C++ est apparu en 1983, Java dans les annees 90 et depuis peu C#
    Il est evident que l'on developpe plus vite avec un language comme C# que C++. D'apres ma propre experience, on developpe au moins 2 fois plus vite en Java qu'en C++ pour un meilleur resultat du point de vue qualitatif.

    Qt est une tres tres bonne librairie graphique et on peut esperer developper une interface graphique bien plus vite avec qu'en Swing (Java) (en C# je sais pas) grace a Qt Designer notamment pour un meilleur resultat visuel. Pour OpenGL il n'y a aucun soucis pour l'integration avec Qt. Qt Designer est tres performant, je l'utilise systematiquement pour generer des fichiers .ui (XML) et charger ceux-ci au lancement de l'application (comme avec Glade pour GTK+) sans meme demander a Qt Designer de generer du C++. Donc dire que le mieux est de tout faire a la main est totalement faux: c'est une perte de temps evidente.

    Si tu n'as pas de contrainte sur les outils utilises pour le projet, ni sur le projet lui-meme en dehors des fonctionnalitees, moi je le developperai en C# tout simplement pour apprendre un language qui est cense etre l'un des plus modernes actuellement. Je laisserai soigneusement le debat du language entre les integristes.

    • [^] # Re: Qt ou Java ou .NET ?

      Posté par  . Évalué à 2.

      Le problème qui va se poser à mon niveau pour le C# est que le temps imparti risque de nous faire regretter ce choix au final (en dehors de tout autre contexte tel que la création de l'interface) sachant que personne ne connait ce langage. Et là, il ne faudrait plus seulement apprendre une API mais carrément apprendre un nouveau langage... Ce qui ne représente, à mon avis, pas le même temps d'apprentissage.

      Pour les questions
      - Oui, le projet demande une interface graphique qui pourra s'avérer complexe
      - Qu'entend-tu par couche métier ?
      - Le multiplateforme n'est pas une obligation, mais un +, voir le contenu du journal
      - Le projet risque de maltraiter le CPU et peut-être le GPU mais sinon il n'est pas prévu de faire une utilisation massive des périphs en tant que tel.
      - Le projet est à but éducatif mais pas seulement : il doit aussi pouvoir être utilisé par des professionels en quête de ses services (à terme)

      • [^] # Re: Qt ou Java ou .NET ?

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

        Le problème qui va se poser à mon niveau pour le C# est que le temps imparti risque de nous faire regretter ce choix au final
        Effectivement, c'est toujours mieux quand il y en a au moins 1 de compétent... Cela dit à 1 ou 2 mots clés prêt tu peux coder comme en Java, avec exactement la même syntaxe sans exploiter toutes les possibilités... Pour avoir eu l'occasion d'apprendre le C# à 2 reprises au reste de l'équipe lors de projets universitaire, ca c'est toujours très bien passé, et rapidement.
        Le plus simple c'est d'essayer : sous Windows, installe SharpDevelop, et essai de dessiner une interface.

        Qu'entend-tu par couche métier ?
        Couche de l'application qui contient le coeur de l'application, tu y trouves les objets qui représente le domaine, typiquement dans une application de commerce en ligne tu y trouveras les classes Client, Produit, Vente, Reduction, etc.
        Cette couche est parfaitement indépendante de l'interface graphique, mais elle fait tout le boulot.

        • [^] # Re: Qt ou Java ou .NET ?

          Posté par  . Évalué à 2.

          Pour C# je vais essayer de voir ça de plus près...

          Et sinon pour la couche métier, alors oui. Elle pourrait être compliquée à terme

      • [^] # Re: Qt ou Java ou .NET ?

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

        > apprendre un nouveau langage

        Si tu connais C++ ou Java je pense que tu n'auras aucun probleme a assimiler C# rapidement. Je lis (et comprends) tous les jours du code source ecrit en C# (que je n'ai pas ecrit donc) alors que j'en ai jamais fait. C'est franchement pas complique, au contraire. Quelques fois il faut se lancer, c'est comme cela que l'on progresse et que l'on apprend de nouvelles choses.

        > couche métier ?

        En gros c'est l'ensemble des composants moins les composants graphiques (e.g les algorithmes, la gestion des fichiers, la base de donnees ect...)

        > Le projet est à but éducatif mais pas seulement : il doit aussi pouvoir
        > être utilisé par des professionels en quête de ses services (à terme)

        Et ca pause un probleme si les utilisateurs doivent installer une JVM ou le framework .NET ? Si l'interface n'a pas le look and feel du natif (Java Swing) ?

        • [^] # Re: Qt ou Java ou .NET ?

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

          e.g les algorithmes, la gestion des fichiers, la base de donnees ect...)
          Ah non :)
          La gestion des fichiers, la base de données, ca c'est dans la couche de persistance, pas dans la couche métier malheureux :)

          • [^] # Re: Qt ou Java ou .NET ?

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

            > La gestion des fichiers, la base de données, ca c'est dans la couche
            > de persistance, pas dans la couche métier malheureux

            J'ai un object triangle, si je veux le serializer, j'appelle la methode serialize() de l'objet qui me retourne une string (XML), ensuite suivant mon data layer la string est envoyee vers un fichier ou autre (SOAP, database...). Donc oui tout ca est dans ma couche metier.

            Tu ferais comment toi ?

            • [^] # Re: Qt ou Java ou .NET ?

              Posté par  . Évalué à 3.

              la couche metier ne touche pas a ca, elle n'a meme pas a appeler la methode serialize, elle appelle uniquement des methodes metiers sur des objets metiers.

              ensuite ces objets metiers sont transmis (enventuellement convertis en objet generiques) a ta couche persistance qui elle s'occupera de l'enregistrer dans un fichier, une DB ou ce que tu veux.

            • [^] # Re: Qt ou Java ou .NET ?

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

              Ben pas comme ca :)
              Y'a pleins de solutions.
              Dans tous les cas t'as une classe métier, appelons la : Metier.
              Il faut qu'elle soit parfaitement indépendante de toutes bibliothèques techniques, qu'elle soit graphique ou accès au FS.
              Ensuite tu peux :
              - faire une classe MetierSerialisable qui hérite de Metier et qui se trouve dans la couche de persistance : problème, il faut passer par une FabriqueAbstraite pour garantir que ce sont bien tes objets de persistance qui sont construits, bref ca t'oblige à modifier ta couche métier.

              - injecter la méthode Serialize à l'aide d'un outil de tissage d'aspect (programmation par aspect).

              - utiliser une classe séparée (genre XMLSerializer) qui sérialise tous tes types métiers et qui parcours ta structure.

              - utiliser une classe séparée qui sérialise automatiquement par Reflection.

              - utiliser une lib de mapping qui fera tout le boulot pour toi. Elles utilisent généralement une des techniques au dessus.

              L'idée est dans tous les cas de pouvoir modifier/changer de moyen de persistance sans jamais toucher au modèle métier.

              • [^] # Re: Qt ou Java ou .NET ?

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

                En C++ c'est chaud pour la programmation aspect, la reflexion...

                • [^] # Re: Qt ou Java ou .NET ?

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

                  C'est sûr :)
                  Mais bon rien ne t'empêche d'utiliser les autres méthodes. Perso quand je dois le faire à la main, je me fais bêtement 2 classes "MachinReader" et "MachinWriter" qui sont capable de serialiser/deserialiser tout le graphe d'objet métier. Ensuite j'en ai autant que j'ai de support visés, et je touche jamais au modèle métier.

  • # Toolkit c++ modélisation

    Posté par  . Évalué à 4.

    Si tu utilises c++, il y a un toolkit assez bien fait (bien qu'un peu complexe) pour faire de la modélisation mécanique : OpenCascade ( http://opencascade.org ). La license est open-source et le toolkit est utilisée dans pas mal de produits commerciaux. Quelques logiciels libres dont l'interface a été faite avec Qt l'utilisent aussi.
    Pour le rendu, OpenGL est utilisé, ce qui permet l'ulisation sur pas mal de plateforme (dont Linux et Windows).

  • # question

    Posté par  . Évalué à 2.

    si tu manques d'argument pour Qt (si j'ai bien compris, le seul que t'as pour l'instant c'est "c'est bien c'est libre"), pourquoi vouloir absolument utiliser Qt?

    c'est un projet universitaire, pas un projet dans la vraie vie, le but du jeu c'est d'appendre une techno, pas de propager votre maigre savoir (bah vi!! si votre savoir etait pas maigre, vous seriez en train de bosser et pas en train d'etudier).

    • [^] # Re: question

      Posté par  . Évalué à 2.

      Sisi, le but c'est de propager le logiciel à terme. C'est un projet universitaire mais à but d'obtenir une véritable application à maintenir et faire évoluer dans le futur. Apprendre une techno, c'est aussi le but, mais tant qu'à faire, autant le faire bien et que ce soit au service de ce qu'on développe.

  • # Mon avis

    Posté par  . Évalué à -2.

    QT c'est multi-plateforme et JAVA c'est lourd. Je crois que tout est dit.

    Exemple: Si je ne me trompe pas Matlab est fait en Java. Dans mon travail j'evite toujours de lancer Matlab car ca met des plombes à se lancer ce truc et ca me bouffe plein de ressources alors que je n'ai même pas lancé de calculs !!! Rien qu'à cause de cette interface graphique en Java.

Suivre le flux des commentaires

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