Sur dot.kde.org

toolkit graphique = troll ?

• [^]Re: toolkit graphique = troll ?

  Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 01/09/2006 à 12:48. (lien). Évalué à 2.

  Oui, je sais, je connais ce projet. Mais c'est pas parce que on peut faire des trucs jolis que c'est facile de le faire.
  Mais, j'ai été vaguement trollesque sur ce coup-là, mais bon il y a une belle part de vérité quand même, SWING ça saoûle pour faire le moindre petit truc. Tiens d'ailleurs, au passage pour ceux qui ne connaîtraient pas :
  http://madbean.com/anim/totallygridbag/

  • [^]Re: toolkit graphique = troll ?

    Posté par Pierre Tramo (page perso, ) le 01/09/2006 à 13:33. (lien). Évalué à 5.

    SWING ça saoûle pour faire le moindre petit truc.
    
    Effectivement, Swing est plus adapté pour faire des gros trucs que des petits (encore que, avec les éditeurs d'interface qu'on trouve dans les principaux IDE, Swing n'est plus aussi difficile à prendre en main...), mais ton argumentation me parait un peu légère pour affirmer que c'est "une plaie".
    
    J'ai personnalement eu à utiliser Swing sur des projets assez complexes et volumineux et je suis loin de faire un tel constat. Je trouve l'API plutôt bien pensée, carrée, et relativement simple à utiliser une fois qu'on a réussi à rentrer dedans (ce qui est à la portée de tout ingénieur qui se respecte).
    
    En revanche, je n'ai jamais utilisé Qt, donc j'aimerais savoir en quoi c'est mieux exactement, histoire de dépasser le niveau 0 du troll velu de l'énoncé de la dépêche...

    • [^]Re: toolkit graphique = troll ?

      Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 01/09/2006 à 13:56. (lien). Évalué à 2.

      M. Tramo,
      Bien sûr que SWING a sa logique qui a quelquechose d'élégant avec son beau modèle MVC. Mais il reste que le positionnement des éléments et leur dimensionnement ne sont pas évidents. Je n'ai peut-être pas autant d'expérience que vous dans ce domaine, mais il me semble que ces quelques points ralentissent la productivité et sont sources de bugs graphiques.
      
      En quoi Qt est mieux ? Le rendu. Pour avoir réalisé quelques applications en QT, j'ai été impressionné de la facilité de concevoir une interface graphique qui a une apparence correcte.
      Un autre point intéressant est les composants qui sont proposés par Qt. Les composants SWING ont souvent été accusés d'un manque de fonctionnalités (comme les JTable), même si ça a tendance à s'améliorer avec le temps. Un autre exemple est celui du sélecteur de date qui a longtemps fait défaut, et s'est vu comblé par des solutions tierces plus ou moins bien distribuée.
      
      Bien sûr tout cela reste suggestif :-) Et puis c'est vendredy aussi :-D

      • [^]Re: toolkit graphique = troll ?

        Posté par Pierre Tramo (page perso, ) le 01/09/2006 à 14:27. (lien). Évalué à 3.

        Mais il reste que le positionnement des éléments et leur dimensionnement ne sont pas évidents.
        
        On ne fait plus du Swing aujourd'hui de la même façon qu'en 1995 : http://weblogs.java.net/blog/claudio/archive/nb-layouts.html
        
        Les composants SWING ont souvent été accusés d'un manque de fonctionnalités
        
        Sur ce point je suis d'accord, un peu plus de widgets de haut niveau utilisables "out of the box" ne feraient pas de mal à Swing (mais la plupart des besoins du genre que j'ai eu concernait des widgets assez orientés métier, et je doute que d'autres frameworks aient pu m'aider plus sur ces cas précis).

        • [^]Re: toolkit graphique = troll ?

          Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 01/09/2006 à 14:38. (lien). Évalué à 3.

          Ok Ok, sauf que moi, je fais principalement des interfaces dynamiques qui se construisent en fonction du contexte, et là le netbeans il va pas me servir à grand chose ... Mais c'est vrai que ma vision est un peu déformée par ma pratique. Quoique ...

        • [^]Re: toolkit graphique = troll ?

          Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 01/09/2006 à 14:48. (lien). Évalué à 1.

          Mouaif, m'enfin la démo reste marrante quand même. Là on se croirait en 1995 ! Tout ce tableau de bord de paramètres dignes d'un A380 juste pour positionner quelques éléments ... bonjour la migraine !
          Pour avoir utiliser QtDesigner, je le trouve tout de même beaucoup plus naturel.

          • [^]Re: toolkit graphique = troll ?

            Posté par Pierre Tramo (page perso, ) le 01/09/2006 à 15:08. (lien). Évalué à 2.

            De quoi parles-tu exactement ? De la configuration dans le cadre du GridBagLayout ?
            Il est bien précisé qu'elle n'est présente que pour ceux qui veulent absolument s'en servir et que le mode par défaut permet d'obtenir le même résultat très rapidement, de façon très intuitive et suffit à répondre à la plupart des besoins (au même titre que les autres éditeurs d'interface).
            Ce n'est pas cette mauvaise foi flagrante qui va me convaincre de passer à QtDesigner..

    • [^]Re: toolkit graphique = troll ?

      Posté par Rhadamante () le 01/09/2006 à 14:11. (lien). Évalué à 10.

      Effectivement, Swing est plus adapté pour faire des gros trucs que des petits
      
      QT ne permet en effet que de faire des petits projets ... comme KDE par exemple ;-)
      
      
      J'ai personnalement eu à utiliser Swing sur des projets assez complexes et volumineux et je suis loin de faire un tel constat. Je trouve l'API plutôt bien pensée, carrée, et relativement simple à utiliser une fois qu'on a réussi à rentrer dedans (ce qui est à la portée de tout ingénieur qui se respecte).
      
      Je trouve ta phrase que je mets en gras très intéressante, car elle raisonne étrangement avec une puissante métaphore que j'ai entendu Matthias Ettric, fondateur du projet KDE et travaillant aujourd'hui chez Trolltech, utiliser pour illustrer le très difficile art du design d'API (Application Programmers Interface)
      
      

      Designing APIs is very complexand cannot be captured in a 45 minute talk. API is an Application Programmer Interface, not a program, and must be used by the programmers who are human. API is to the programmer what a GUI is to the end user : you can't just add things all over the place (or you end up with KControl). APIs should be both minimal and complete (which can conflict), have clear and simple semantics, be intuitive and easy to remember, guide the user to readable code in the same way as a good user interface guides you to what to do.

      
      
      N'hésitez pas à lire tout le compte-rendu, ce ne sera pas du temps de perdu :
      http://conference2004.kde.org/transcripts/matthias.ettrich-d(...)
      http://doc.trolltech.com/qq/qq13-apis.html
      
      La métaphore est celle-ci : l'API est au programmeur ce que la GUI est l'utilisateur et doit être élaborée avec le même soin.
      
      Je suis très tentée de filer la métaphore : ta phrase que j'ai soulignée sous-entend que SWING a sa logique propre, carrée, logique et qu'il s'agit pour le programmeur de la découvrir et de s'adapter à elle. C'est le paradigme qui était utilisé traditionellement pour concevoir les interfaces graphiques : m'enfin, comprenez comment marche la machine, quoi , et adaptez vous y. Il est logique lui ! Et si vraiment l'utilisateur n'y arrive pas, c'est qu'il est con, qu'il ne se respecte pas
      
      Et puis est arrivée la révolution du macintosh qui a posé comme principe de renverser cette manière de penser. C'est à la machine de s'adapter à l'utilisateur et à tendre à fonctioner comme lui. Observez et comprenez d'abord comment fonctionnent les bipèdes et proposez ensuite une interface qui respecte les users expectations.
      
      N'est-ce pas une raison qui expliquerait que des programmeurs trouvent les interfaces à la Qt intuitives et qualifie les interfaces à la Swing de plaie conceptuelles malgré ses qualités théoriques que tu défends ? Oui, ils sont bizarres et imparfaits ces bipèdes, qu'ils soient utilisateurs ou simple programmeurs, résignons nous y et voyons comment on peut les aider malgré cela.

      • [^]Re: toolkit graphique = troll ?

        Posté par Loic Dreux () le 01/09/2006 à 14:56. (lien). Évalué à 4.

        Pourquoi Swing est-il une plaie ? J'utilise cette API depuis maintenant 5 ans, et c'est vrai que le GridBagLayout est une horreur mais personne ne vous oblige à l'utiliser. Il existe aujourd'hui des layout très simple à mettre en place et on peut faire de superbe chose avec Swing en quelques lignes. Je vous conseille de faire un tour sur le site de JGoodies : http://www.jgoodies.com

      • [^]Re: toolkit graphique = troll ?

        Posté par Pierre Tramo (page perso, ) le 01/09/2006 à 14:57. (lien). Évalué à 5.

        l'API est au programmeur ce que la GUI est l'utilisateur et doit être élaborée avec le même soin.
        
        Il y a quand même des différences de taille entre un programmeur et un utilisateur qui font qu'on peut avoir des attentes différentes envers eux : le programmeur est bien souvent payé pour le faire et doit justifier son salaire par ses compétences, de plus il est supposé avoir suivi une formation solide et en avoir conservé des acquis (autant en connaissances brutes qu'en méthodes ou en faculté d'adaptation, ...). On peut supposer qu'il aura le courage de se documenter un minimum avant d'utiliser un outil, et de réfléchir un peu plutôt que d'écrire du code au kilomètre. Sinon, qu'il reste avec son VB6...
        Quand on conçoit une GUI, on se doit de considérer que l'utilisateur est assez neuneu, je suis confronté tous les jours à cette contrainte. Mais considérer le programmeur comme un neuneu n'est pas lui rendre service : c'est en résolvant des problèmes qu'on progresse, et j'ai personnellement beaucoup appris en intégrant les principes de certaines bibliothèques qui me semblaient complexes au premier abord.
        
        ta phrase que j'ai soulignée sous-entend que SWING a sa logique propre
        
        Absolument pas, la logique de Swing est inspirée d'un bon nombre de patrons de conception (MVC, cité plus haut, pour le principal, mais aussi beaucoup d'autres : Observateur, ...). Swing utilise un paquet de notions qu'il est nécessaire de maîtriser, et celles-ci n'ont pas été inventées pour l'occasion, mais sont tirées de l'état de l'art.
        
        malgré ses qualités théoriques que tu défends ?
        
        Ça n'a rien de théorique, c'est de par mon expérience que je me permets de contredire certains mythes qui ont la vie dure.
        
        Bien évidemment, Swing a ses défaut (personne n'osera défendre le code verbeux qu'on doit parfois se taper quand on ne passe pas par un éditeur d'interface ou une surcouche spécialisée), et Qt a certainement beaucoup de qualités tellement on en dit du bien. Je ne demande qu'à les connaître, mais pour ça, il faudrait sortir un peu des sentiers trollesques et des leçons de rhétorique...

        • [^]Re: toolkit graphique = troll ?

          Posté par tanguy_k (page perso, ) le 01/09/2006 à 17:33. (lien). Évalué à 10.

          - L'API Qt est beaucoup plus intuitive, simple et haut niveau avec une belle documentation
          Les delegates (ou signaux) par rapport a des interfaces Listener c'est carrement moins rebarbatif/verbeux a utiliser.
          
          - Qt Designer genere du XML
          Qt Designer est une petite merveille a utiliser.
          Le code genere se trouve dans un fichier separee et pour s'interfacer avec c'est propre et clean. La derniere fois que j'ai utilise des generateurs SWING ca collait tout dans le meme fichier (ca a peut etre change depuis)
          
          - Qt s'integre 10x mieux au desktop que SWING sous Linux et Windows
          
          - Une interface Qt c'est rapide !
          
          - Qt evolue beaucoup plus vite que SWING et est plus complet
          il suffit de voir les ameliorations de la version 4.2: integration DBUS, icones SVG, nouveaux widgets, utilisation de CSS pour personnaliser l'interface...
          
          De tout ce que j'ai utilise (MFC, win32, GTK+, SWING, SWT, wxWidget) j'ai trouve que Qt est le plus sympa a tout niveau: rendu, rapidite, integration, simplicite, puissance, maintenabilite du code, documentation ect...
          
          SWING n'est pas mauvais, mais a mon avis est moins bon que Qt ce qui ne signifie pas qu'on peut pas faire des trucs sympas avec SWING.
          
          Ceci est juste mon avis :)

          • [^]Re: toolkit graphique = troll ?

            Posté par ndesmoul () le 05/09/2006 à 17:09. (lien). Évalué à 2.

            Pour l'intuitivité de QT, aucune idée, j'ai jamais essayé.
            
            
            - Qt Designer genere du XML
            Qt Designer est une petite merveille a utiliser.
            Le code genere se trouve dans un fichier separee et pour s'interfacer avec c'est propre et clean. La derniere fois que j'ai utilise des generateurs SWING ca collait tout dans le meme fichier (ca a peut etre change depuis)
            
            Le designer de la dernière version de NetBean génère également du XML. Pour l'avoir essayé un peu il est plutôt pas mal. A voir pour un vrai projet mais je conseille tout de même à ceux développant une GUI java d'y jetter un coup d'oeil. Ca pourrait les intéresser.
            
            
            - Qt s'integre 10x mieux au desktop que SWING sous Linux et Windows
            
            Ca s'est clair. Encore que ce qui me dérange le plus c'est que les polices de caractères ne sont pas lissées avec Swing. Ca devrait bientôt être le cas ceci dit.
            
            
            - Une interface Qt c'est rapide !
            
            
            Pour avoir essayé des versions récentes de Swing, je trouve que c'est plutôt réactif. J'ai même trouvé NetBean (Swing) plus réactif que Eclipse (SWT). Le tout sous Linux. En même temps c'est sans doute SWT qui est un peu buggé...
            Je me demandai d'ailleurs si j'allais pas essayé SWT pour voir mais QT me semble beaucoup plus intéressant.
            
            L'autre avantage c'est qu'on va pouvoir développer plus facilement des applications Java pour KDE. Bah, oui moi j'aime pas le C++.
            Avec Java qui devrait être libéré par SUN, ça pourrait devenir intéressant.

        • [^]Re: toolkit graphique = troll ?

          Posté par golum () le 02/09/2006 à 12:54. (lien). Évalué à 2.

          "mais pour ça, il faudrait sortir un peu des sentiers trollesques et des leçons de rhétorique..."
          
          Marketainge QT
          

          
          Compared to other toolkits and frameworks, Qt Jambi’s paint system is easier and more intuitive
          to use. For example, consider a component with some graphical contents and a print
          button. Using Swing, the programmer must implement the Printable and ActionListener
          interfaces and the following two functions to pop up a print dialog enabling the user to print
          the contents:
          public int print(Graphics g, PageFormat pf, int pi)
          throws PrinterException {
          if (pi >= 1)
          return Printable.NO_SUCH_PAGE;
          // perform drawing
          return Printable.PAGE_EXISTS;
          }
          public void actionPerformed(ActionEvent e) {
          if (e.getSource() instanceof JButton) {
          PrinterJob printJob = PrinterJob.getPrinterJob();
          printJob.setPrintable(this);
          if (printJob.printDialog()) {
          try {
          printJob.print();
          } catch (Exception ex) {
          ex.printStackTrace();
          }
          }
          }
          }
          Using Qt Jambi, all the programmer has to do is to connect the print button’s clicked()
          signal to a custom print() slot:
          void print() {
          QPrinter printer = new QPrinter();
          QPainter painter = new QPainter();
          QPrintDialog printDialog = new QPrintDialog(printer, this);
          if (printDialog.exec()) {
          painter.begin(printer);
          // perform drawing
          painter.end();
          }
          }
          In addition, Qt Jambi’s text handling is based on native font support, providing access to
          platform features like ClearType anti-aliasing on Windows and Mac OS X, and sub-pixel
          anti-aliasing on X11ä. QPainter can even be used to generate PDF documents, without
          requiring a third-party component.
          Qt Jambi’s rendering pipeline co-exists with Java2Dä rendering, meaning that it is possible
          to use Java2D for advanced imaging and Qt Jambi’s graphic system for painting widgets.
          

  • [^]Re: toolkit graphique = troll ?

    Posté par ndesmoul () le 01/09/2006 à 17:48. (lien). Évalué à 1.

    J'adore cette animation. Merci beaucoup pour ce moment de franche rigolade. Mais c'est tellement vrai!! (oui j'ai utilisé des gridlayouts et cette animation fait presque office de documentaire...)

  • [^]Re: toolkit graphique = troll ?

    Posté par Calvin0c7 () le 01/09/2006 à 19:33. (lien). Évalué à 5.

    Alors là !!
    Trop fort.
    Je suis un utilisateur de swing et c'est sur que si on est habitué à faire du VB (je prends l'extrême hein, je t'insulte pas) ça fait drôle. Je trouve l'API TRES bien faite et puissante, la manière de gérer les event est élégante (même si un peu déroutante au début) et la portabilité n'est PAS une légende (en tout cas dans la majorité des cas).
    
    Par contre l'exemple de cette animation est, à mes yeux, symptomatique de la principale difficulté de swing : les layouts.
    Alors je le dis pour ceux qui vont, veulent, sont obliger de s'y mettre : les layouts c'est l'enfer, la géhenne, c'est mystérieux, c'est vivant, ça se rebelle, ça fait ce que ça veut (et ça veut rarement la même chose que toi).

    • [^]Re: toolkit graphique = troll ?

      Posté par Philippe Fremy (page perso, ) le 05/09/2006 à 10:07. (lien). Évalué à 6.

      Je ne connais pas swing, mais dire dans la meme phrase que les layouts sous swings sont pourris mais que swing c'est bien me parait un peu tire par les cheveux.
      
      Une application graphique, c'est avant tout un ensemble de briques graphiques a organiser. Et de nos jours, on a les parametres suivants qui sont variables :
      - les traductions peuvent allonger ou racourcir les dialogues en permanence
      - les gens ont des resolutions d'affichage hautement variable : entre le commercial avec son portable 12 pouces et le geek avec son 3500 x 4600, il faut s'adapter.
      
      Donc les layouts sont quand meme un element important de la conception graphique de nos jours.
      
      Pour l'instant, je trouve le discours des defenseurs de swing plutot desagreable. En gros, soit le programmeur est assez intelligent pour comprendre comment swing marche, soit il ferait mieux de retourner a son visual basic. Ca me fait penser aux defenseurs des MFCs qui disent que les MFCs sont simples et faciles a utiliser, mais qu'il faut 5 ans pour apprendre a bien s'en servir.
      
      Trolltech a propose une approche de la programmation graphique qui est facile. Ce n'est pas une tare d'etre facile a utiliser, et ce n'est pas parce que Microsoft a fait rimer facilite et simplicite avec truc crade et inutilisable en gros deploiement que c'est une loi immuable.
      
      Qt possede a mon sens l'avantage d'etre agreable a utiliser par des experts et par des debutants. Les debutants sont contents d'arriver rapidement a des resultats et les experts ne se sentent pas contraints par le framework mais peuvent au contraire laisser libre cours a leur creativite.
      
      Pour revenir a l'histoire des layout, sous Qt, on peut par exemple laisser un expert en ergonomie travailler sur l'interface avec Qt Designer pendant que le programmeur travaille sur la logique, et cela sans se perturber l'un l'autre. La gestion des layouts est donc accessible a des non-techos.
      
      Dans toutes les applications graphiques sur lesquelles j'ai travaille avec Qt, ce qui m'a le plus plu, c'est que comme la partie graphique est simple a mettre en place, on peut vraiment se concentrer sur la logique de l'application.

      --
      phil.freehackers.org

      • [^]Re: toolkit graphique = troll ?

        Posté par ndesmoul () le 05/09/2006 à 16:53. (lien). Évalué à 1.

        Swing est effectivement une API relativement bien conçue (enfin les goûts et les couleurs, hein), mais les layouts par défaut, c'est à dire livrés avec le JDK sont soit trop limités, soit trop complexes à utiliser (GridBagLayout, Grrr). Mais rien ne t'empêche de développer ton propre layout ou plus simplement d'en récupérer un adapté à tes besoins. Il y en a pas mal de disponibles bien mieux foutus.
        
        J'aimerai également attiré l'attention sur l'éditeur graphique de la dernière version de NetBean. J'ai un peu joué avec et il m'a paru très facile d'utilisation et permettant un placement facile des composants (et sans soucis pour bien aligner les composants). Le code Java généré a l'air propre mais de toute façon l'éditeur ne te permet pas d'y toucher: l'interface créé est sauvegardé dans un format basé sur du XML à partir duquel est généré le code.
        
        Je suis pas allé très loin avec mais à mon avis ça mérite un coup d'oeil.
        
        Ceci dit je trouve que pouvoir utilisé QT avec Java est une excellente nouvelle. Je préfère cette solution à SWT et QT tourne sur énormément de plateformes différentes donc la portabilité ne semble pas être un problème.
        
        Mais bon j'attend d'avoir essayé.
        
        PS: pour les adeptes du GridBagLayout, je sais qu'il y a une logique d'utilisation derrière (si si) et qu'on finit par arriver à un résultat correct mais c'est quand même prise de tête.

        • [^]Re: toolkit graphique = troll ?

          Posté par Philippe Fremy (page perso, ) le 06/09/2006 à 08:01. (lien). Évalué à 3.

          > Les layouts par défaut sont soit trop limités, soit trop complexes à utiliser (GridBa gLayout, Grrr). Mais rien ne t'empêche de développer ton propre layout
          
          Rien ne m'empeche non plus de developper un toolkit graphique complet pour remplacer Qt, Gtk, Swing en une seule fois. Sauf que je prefere me concentrer sur la logique de mon application et que je trouve que ce travail revient plutot au developpeur du toolkit graphique.
          
          Le fait que les layouts soient mal geres veut dire que le programmeur va passer beaucoup de temps a resoudre un probleme qui n'a rien a voir avec l'application qu'il developpe alors qu'il pourrait etre en train de corriger des bugs ou ajouter des fonctionnalites.

          --
          phil.freehackers.org

  • [^]Re: toolkit graphique = troll ?

    Posté par reno () le 04/09/2006 à 09:36. (lien). Évalué à 1.

    Sympa le gribbag, mais codé 'à la main' une interface graphique, quelque soit le toolkit c'est ch***, pas un défaut de Swing en soit dont j'aime plutot la conception ...
    mais beaucoup moins l'implémentation: quand j'avais essayé de l'utiliser c'était buggé jusqu'a la moelle (i18n, impression, etc) et très lent: ça n'a pas du beaucoup changer pour cette partie: les outils d'admin Solaris9 donc fait par Sun (!!!) sont 'escargotesques'.

• [^]Re: toolkit graphique = troll ?

  Posté par d-jo (page perso, ) le 02/09/2006 à 12:45. (lien). Évalué à 2.

  J'ai comme l'impression que des que l'on parle de toolkits graphiques, les trolls sont livrés de série et pas en options...
  
  Personnellement, j'aime bien les trolls, je trouve ça drole : "un projet bien conçu (un peu comme qmail)", "des raccourcis conviviaux à la façon d'emacs", "ubuntu contribue fortement à la popularité de debian" ...
  
  J'ai l'impression que là il s'agit surtout d'affirmer des certitudes : "j'aime pas swing, donc c'est pourris". Ce n'est pas surprenant, venant d'un utilisateur de kubuntu, mais c'est vraiment curieux que les modos aient laissé passer ça.

  • [^]Re: toolkit graphique = troll ?

    Posté par baud123 (Jabber id, page perso, ) le 03/09/2006 à 15:58. (lien). Évalué à 4.

    mais c'est vraiment curieux que les modos aient laissé passer ça.
    
    quand dans le texte de la dépêche, il y a
    Si vous êtes utilisateurs de logiciels libres (et pas trolleur pour un sou)
    
    Ne crois-tu pas que certains modos sont trolleurs eux-aussi et le laissent sciemment passer ? De temps en temps, cela ne fait pas de mal et peut permettre des choses au passage.

    • [^]Re: toolkit graphique = troll ?

      Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 04/09/2006 à 16:07. (lien). Évalué à 2.

      Ben oui !
      Si j'avais fait une dépêche sans troll, sans aucune critique, il n'y aurait eu aucun commentaire, à part une ou deux tentatives de lâcher de troll par des frustrés. Tandis que là, on a plein d'éléments ! Merci donc à ceux qui ont fait l'effort de répondre, et tant pis si je vous ai froissé ;-)

      • [^]Re: toolkit graphique = troll ?

        Posté par stephwww () le 04/09/2006 à 16:42. (lien). Évalué à 1.

        Combattre le troll par le troll ;)

héritage multiple?

• [^]Re: héritage multiple?

  Posté par lasher () le 01/09/2006 à 13:26. (lien). Évalué à 4.

  Ils ont fait comme on fait d'habitude quand on a besoin d'héritage multiple en Java :
  
  - dans les cas simple, l'utilisation des interfaces est suffisant ;
  - dans les cas plus complexes, il y a plusieurs techniques. L'une d'entre elles est de dériver la classe depuis l'une de celles dont on voudrait hériter, et de créer des objets privés des autres classes, en reproduisant l'interface publique de chaque objet (oui, c'est fastidieux), par exemple.

  • [^]Re: héritage multiple?

    Posté par Sylvain Sauvage () le 01/09/2006 à 17:35. (lien). Évalué à 2.

    La technique que tu cites (délagation) correspond à l'héritage privé en C++. Quand on veut profiter d'un typage multiple pour une classe, il faut à la fois des interfaces et de la délation, pour profiter du polymorphisme. P.ex. : en C++
    
    class A;
    class B;
    class C : A, B;
    
    devient, en Java :
    
    interface A {}
    class A_I implements A {}
    
    interface B {}
    class B_I implements B {}
    
    interface C extends A, B {}
    class C_I extends A_I {
    private B_I b_i;
    /* refaire toutes les fonctions f de B : */
    f() { b_i.f(); }
    }
    
    (Il faut choisir entre hériter de A_I, de B_I, ou d'aucun.)
    (On fait aussi de C une interface pour pouvoir multi-hériter de C ensuite...)
    
    Donc, c'est très lourd à écrire, mais c'est automatisable, mais c'est plus vraiment du Java...

    • [^]Re: héritage multiple?

      Posté par Thomas Douillard () le 01/09/2006 à 19:31. (lien). Évalué à 5.

      il faut à la fois des interfaces et de la délation

      
      
      Chef, chef, mon voisin de bureau il est tout le temps en pause café ! Et en plus, il délègue tout son boulot sur moi.

• [^]Re: héritage multiple?

  Posté par golum () le 02/09/2006 à 12:49. (lien). Évalué à 2.

  extrait de
  http://www.trolltech.com/developer/downloads/qt/resolveuid/2(...)
  
  

  
  3.5. Multiple Inheritance
  A few classes in Qt have more than one base class. In Java, multiple inheritance is possible
  only with interfaces. To work around this limitation, Qt Jambi uses interfaces that wrap
  the classes used in multiple inheritance contexts.
  Consider the following C++ class definition:
  class QWidget : public QObject, public QPaintDevice
  {
  ...
  };
  The QWidget class inherits both QObject and QPaintDevice. In Qt Jambi, the class is defined
  as follows:
  public class QWidget extends QObject implements QPaintDeviceInterface
  {
  ...
  }
  In this example, QPaintDeviceInterface is an interface that declares the same methods as
  QPaintDevice without implementing them. Any member variable and method implementation
  found in the original QPaintDevice class is put in QWidget instead. As a result, the Qt
  Jambi version of QWidget has exactly the same API and functionality as the C++ version.
  

SWING n'est pas une plaie pour moi

• [^]Re: SWING n'est pas une plaie pour moi

  Posté par Iyo () le 05/09/2006 à 08:34. (lien). Évalué à 2.

  +1. En lisant tous ces message, je me sens seul. Comme lorsque je suis sorti de Syriana et que j'avais dis que j'avais pas trouvé ce film trop compliqué. Les GridBagLayouts sont un peu lourd a mettre en place (1 ligne de code/element) mais ne sont pas si compliquer a comprendre que ca quand même !! Merde je suis pas un génie !! Ah biensur, si tu veux t'amuser a poser ton button au pixel pres toi-meme a un endroit fixe t'es mal barré (et un peu con aussi). Bonjours les interfaces fixe en taille qui bouge pas lorsque tu agrandi la fenetre !!
  
  Bon, la-dessus, je vais me penchez sur le projet parce que c'est vrai que QT j'aime bien aussi. Par contre, pas de version Solaris donc je ne peux pas l'exploiter en prod...
  

Quelques petites précisions ...

• [^]Re: Quelques petites précisions ...

  Posté par ndesmoul () le 05/09/2006 à 16:56. (lien). Évalué à 1.

  Et quelles sont en bref ces fonctionnalités non graphiques de QT?

  • [^]Re: Quelques petites précisions ...

    Posté par tanguy_k (page perso, ) le 05/09/2006 à 17:09. (lien). Évalué à 4.

    http://doc.trolltech.com/4.2/modules.html
    
    QtCore Core non-GUI classes used by other modules
    QtGui Graphical user interface components
    QtNetwork Classes for network programming
    QtOpenGL OpenGL support classes
    QtSql Classes for database integration using SQL
    QtSvg Classes for displaying the contents of SVG files
    QtXml Classes for handling XML
    QtTest Tool classes for unit testing
    
    
    SQL, SVG, XML, reseau (FTP, HTTP, detection reseau), OpenGL, thread, mutex, slot/signaux, file, timer, DBus... Bref tout un framework a la Java ou a la C#
    
    Tout n'est pas disponible dans Qt Jambi cf
    http://doc.trolltech.com/qtjambi-1.0/qtjambi-classes.html