Journal Java, après pratique, je trouve ça à chier, vive .net

Posté par  (site web personnel) .
Étiquettes : aucune
0
27
sept.
2004
Mon chère journal, cela fait maintenant 2 semaine que je fais du Java swing.

Je suis attristé de voir un framework aussi mal fourni.

SWING est catastrophique à programmer en comparaison à GTK ou QT.

Le framework ne contient même pas de class pour gérer du FTP, il faut passer par une librairie externe (jakarta dans mon cas).

La documentation de sun est vraiment laborieuse.

C'était donc mon coup de gueule.

Vivement que l'on puisse créer dans Applet .net en GTK#. Là, ça sera un vrai plaisir de programmer.

C'est mon opinion, il n'engage que moi, mais je suis très énervé après ce framework (pas le langage en lui même).

  • # KROUIK

    Posté par  . Évalué à 10.

    vous faîtes comme vous voulez, mais moi, je désactive mon trollomètre

  • # interfaces graphique...

    Posté par  . Évalué à 2.

    Faire des interfaces " pleines " d'objets rend le chargement du fichier bien long en plus...
    Ok il y'a AWT mais ca complique énormement pour faire des interfaces

  • # la doc...

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

    La documentation de sun est vraiment laborieuse.

    Là, je suis d'accord avec Stéphane. Je ne savais pas trop comment qualifier cette doc, mais le terme laborieuse est parfait...

    • [^] # Re: la doc...

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

      La MSDN n'est pas forcément mieux...

      • [^] # Re: la doc...

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

        bah le wysiwyg sur vs .net est vraiment bon.
        après je t'accorde que tout le monde n'a pas accès à cet outil mais bon au passage c'est à mon avis le meilleur IDE, et visiblement la prochaine version (VS 2005) sera une killer app (la bêta est dispo) et je dis ca alors que j'adore Eclipse.

  • # Il manque aussi ...

    Posté par  . Évalué à 10.

    une classe pour gérer la bouilloire pour ma camomille.
    Que viendrait fou^H^Haire du FTP dans un framework IHM ?

  • # Un coup de pouce au troll

    Posté par  . Évalué à 6.

    Je veux pas paraitre méchant, ca fait des années que je fait du swing et du GTK ert je n'arrive pas a voir en quoi GTK est infiniment supérieur a Swing. Perso la seule différence notable que j'ai vu pour l'instant est qu'il y en a un qui est presque, quoique pas tout à fait, tout sauf de l'objet et que l'autre est pur objet.

    Mais a part ça ?

    Kha

    • [^] # Re: Un coup de pouce au troll

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

      Déjà au niveau de layout. GTK est beaucoup plus simple à mon avis.

      L'utilisation des LayoutManager est assez complexe.

      • [^] # Re: Un coup de pouce au troll

        Posté par  . Évalué à 5.

        L'utilisation des LayoutManager est assez complexe.

        C'est vrai si on veut une mise en page au pixel près, sinon il existe une floppée de gestionnaires de layout simplissimes, tous encastrables les uns dans les autres. Personellement je n'ai jamais chercher a me départir de la mise en page par défaut d'un boxedLayout ou d'un gridbag, la série des layoutspanes est extrèmement facile d'utilisation.

        Par contre, juste pour contre balancer j'aimerais que l'on parle du passage de message d'une fenêtre à l'autre en GTK+.... Juste pour rire.

        • [^] # Re: Un coup de pouce au troll

          Posté par  . Évalué à 4.

          à quoi ça sert de passer un message d'une fenêtre à une autre ? dans mon souvenir c'est mal de mélanger l'interface graphique et le modèle sous-jacent.


          tiens mon p'tit troll, voilà à manger

  • # certes

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

    Je suis attristé de voir un framework aussi mal fourni.

    C'est a dire ?

    SWING est catastrophique à programmer en comparaison à GTK ou QT.

    C'est a dire ?

    Le framework ne contient même pas de class pour gérer du FTP, il faut passer par une librairie externe (jakarta dans mon cas).

    ("classe", "bibliothèque"). Ca te paraitrait normal qu'une GUI fasse du FTP ? Tu connais pas la notion de séparation des tâches ? Utilise une bilbiothèque pour faire du FTP, je vois pas le problème.

    La documentation de sun est vraiment laborieuse.

    Ca depend à quoi tu la compares. Je ne connais pas la documentation de .Net mais par rapport aux autres doc dispos sous linux (par exemple les man pour le C, perldoc pour perl) je la trouve tout a fait satisfaisante[1].


    [1] sauf quand la doc sur les servlets omet une précision radicalement importante qu'il faut aller pêcher dans les specs des servlets à force de rien comprendre au comportement du bouzin (en l'occurrence, demander le changement de l'encoding de reception des parametres http apres qu'un parametre ait ete lu n'a aucun effet)

    • [^] # Re: certes

      Posté par  . Évalué à 8.

      La MSDN est ignoblement inutilisable à côté de la JavaDoc.

      • [^] # Re: certes

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

        En fait effectivement, j'ai été contraint (sous la torture) à faire un script ASP (en VB) pour nos clients neuneus (un truc pour nous uploader des trucs en XML) et j'ai trouvé que la doc en ligne était immonde par rapport à celle dispo pour PHP. J'utilisais pas de produit microsoft (le serveur ASP SunONE pour Linux) donc peut-etre que pour leurs clients payants ils donnent de la bonne doc sur cdrom ?

      • [^] # Re: certes

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

        J'adore ces arguments que tout le monde pertinente, comme si c'était une vérité absolue et évidente...
        Franchement pour avoir utiliser la doc du framework .NET (puisque c'est celà qu'on compare), à la doc de Sun, voilà quoi, y'a pour moi pas photo :
        - les 2 proposent de naviguer dans les classes de manières hiérarchiques et propose des tutoriaux et autres exemple
        Mais question contenu, il n'y a pas photos, la MSDN est bourré d'exemple, de tutoriaux, de conseils, le tout sur un même site : c'est celà qui rebutte le plus souvent, les gens y trouvent peut-être trop d'info. Mais faut-il s'en plaindre ou plutôt essayer de se faire une liste de favoris ?
        Et puis franchement l'effort de traduction fait par Microsoft rend vraiment plus agréable la tâche du débutant, qui risque de passer à côté de beaucoup de notions et apprendre bêtement le nom des méthodes sans en comprendre la signification.
        Franchement dire que ça s'est ignoble :
        http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/(...)
        à côté de ça :
        http://java.sun.com/reference/index.html(...)
        c'est se foutre de la gueule du peuple. On ne trouve peut-être pas les infos au même endroit, mais les 2 ont leurs avantages et inconvénients à l'utilisation...

        • [^] # Re: certes

          Posté par  . Évalué à 3.

          Il me semble que sur cette page la : http://java.sun.com/j2se/1.5.0/docs/api/index.html(...) les informations soient plus directements accessible que sur cette page la : http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/(...)

          Mais bon après comme tu dit les goûts et les couleurs ...

          Quand à l'anglais ... c'est pas nouveau que pour programmer faut mieux comprendre l'anglais.

          • [^] # Re: certes

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

            Faudrait comparer ce qui est comparable.
            Tu veux comparer la vue globale des APIs, alors tu compares celà :
            http://java.sun.com/j2se/1.5.0/docs/api/index.html(...)
            et celà :
            http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/(...)

            Tu veux comparer la classe String avec la classe String :
            http://java.sun.com/j2se/1.5.0/docs/api/index.html(...)
            avec
            http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/(...)

            Alors je veux bien comparer les goûts et les couleurs, mais je ne veux pas comparer la couleur d'une maison avec celle d'une étagère si tu vois ce que je veux dire.

            Quand à l'anglais ... c'est pas nouveau que pour programmer faut mieux comprendre l'anglais.
            Bah oué mais justement, quand tu es débutant tu es bien content d'apprendre les notions de base et les termes techniques, et franchement, avoir le nom anglais d'une méthode (parcque ils ont pas traduit les noms de méthode non plus) et sa documentation en français, celà aide énormement à progresser, on comprend le sens de mot comme "Handle" par exemple. Pour obtenir plus d'infos on peut bien entendu aller sur internet, auquel cas la doc risque d'être en anglais, mais une base dans sa langue native celà ne fait vraiment pas de mal.
            Je ne parlerai même pas du cas des tutoriaux où il est encore plus difficile de cerner les explications quand on n'en comprend pas toujours le sens. Alors moi je dis OUI la traduction est utile, et oui évidemment l'anglais est important. Mais l'un n'empêche pas l'autre.

            • [^] # Re: certes

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

              Excusez moi, pour la classe String en Java, il faut bien entendu aller à cette url :
              http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html(...)
              (j'avais pas fait gaffe que l'url n'avait pas changé, à cause de ces jolies frames)

              • [^] # Re: certes

                Posté par  . Évalué à 2.

                "(j'avais pas fait gaffe que l'url n'avait pas changé, à cause de ces jolies frames)"

                C'est justement ce que je voulais montrer (même erreur que toi, sauf que dans ton lien les frames disparraissent du coup) :)

                Tout en étant dans l'aide de la classe String, tu as rapidement accès à toutes les autres classes graces à ces "jolies frames".

                Voilà c'est tout, après c'est sur sa ne rend pas la doc de java 100* mieux que celle de msdn ...

        • [^] # Re: certes

          Posté par  . Évalué à 3.

          MSDN a un probleme je trouve c'est celui de melanger la doc pour different langage dans un meme endroit. et lorsque tu fait une recherche sur un point précis, les MFC par exemple, tu tombes sur des résultats relatifs a différentes versions de windows sans avoir moyen de faire le tri.

          • [^] # Re: certes

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

            Il est vrai que le fait d'avoir 36000 API pour différents langages peut être pénible, il faut ajouter le mot clé idéal pour obtenir que les références aux parties qui nous intéresse (par exemple .NET pour obtenir ce qui est relatif au framework .NET), peut-être auraient-ils pu partitionner leur outil de recherche par framework, celà aurait sans doute été une bonne idée, surtout que les contenus proprement dis ne sont pas du tout mélangés.
            Celà dis ce problème ne se pose que pour la version OnLine. La version Offline propose de nombreuses facilitées de recherche avec des possibilités de filtrage avancées, le tout pouvant bien entendu être intégré assez joliement avec Visual Studio.NET.

        • [^] # Re: certes

          Posté par  . Évalué à 3.

          Il est vrai que la MSDN fournit pas mal d'exemples et aide beaucoup les débutants (traduction, liens vers des classes associées).

          Cependant je lui trouve plusieurs défauts :
          - quand on affiche une classe, on a la doc de tous les langages, et c'est pas super lisible (écrit trop petit par ex)
          - ces exemples de code sont très mal indentés dans Firefox
          - la navigation dans l'arborescence d'une API est mal foutue (interfaces/classes abstraites/packages tout ça ne saute pas immédiatement aux yeux)
          - on n'a jamais de page résumant toutes les méthodes, arguments, classes mères et classes filles d'une classe
          - les URLs directes sont difficilement lisibles et utilisables par le commun des mortels
          - je ne sais pas la taille que ça fait mais ça m'a l'air d'être tout un bordel là dedans (ça tient sur un CD ?)
          - la navigation est lente (entre autres synchro avec la TOC)

          A côté de ça, la JavaDoc pêche de ces côtés-là :
          - manque de tutoriaux simplement accessibles depuis la javadoc (les tutoriaux sont à l'extérieur de la javadoc, bien qu'ils soient librement téléchargeables)
          - manque de traductions
          - pas d'explications pour débutants

          Mais avec qq années de Java derrière moi et qq mois de C#, je préfère bien évidemment la JavaDoc. Mon avis aurait peut être été différent si j'avais fait 3 ans de VB :)

          • [^] # Re: certes

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

            Mmmh, la plupart des problèmes que tu cites sont exactes : la MSDN est limité à Internet Explorer, ce qui explique que tu ne puisse affichre le filtre par langage, que la police soit trop petite ou que l'indentation soit mal faite.

            la navigation dans l'arborescence d'une API est mal foutue
            Question de point de vue, perso j'aime bien voir les méthodes héritées directement comme toutes les autres méthodes, quand je consulte la doc d'une classe, c'est pour voir ce que je peux faire avec, pas ce qui lui est spécifique, c'est plutôt pénible de ce point de vue là dans la javadoc à mon goût.

            on n'a jamais de page résumant toutes les méthodes, arguments, classes mères et classes filles d'une classe
            En même temps je vois pas trop l'intérêt d'avoir tout celà sur la même page... Dans le cas de la javaDoc celà fait une page énorme et faut scroller à outrance je trouve.

            je ne sais pas la taille que ça fait mais ça m'a l'air d'être tout un bordel là dedans
            3 CD entiers. Je te laisse imaginer le boulot de traduction, sachant qu'il n'y a qu'une langue sur 3 CD ;)

            la navigation est lente
            C'est vrai qu'il y a une légère latence.

            Bref bref, la MSDN a évidemment quelques défauts, la plupart étant liés à la version Web, mais il ne faut pas oublier que la majorité des développeurs a la version Offline qui n'a quasiment plus aucun des problèmes de naviguation/compatibilité/filtrage cités.
            Sinon pour moi JavaDoc et la MSDN on la même vision d'une documentation et on peut naviguer à peu près de la même manière dans l'arboresence des classes. C'est pour celà que je trouvais la critique facile, d'autant plus que les 2 centre de documentation ne sont pas du otut à la même échelle, leurs contenus absolument pas dans les même proportions, les API, langages et articles étant en nombre beaucoup plus conséquent sur la MSDN.

        • [^] # Re: certes

          Posté par  . Évalué à 2.

          c'est se foutre de la gueule du peuple. On ne trouve peut-être pas les infos au même endroit, mais les 2 ont leurs avantages et inconvénients à l'utilisation...
          Je ne connais ni Java, ni .Net.
          Enfin si, des bribes.
          Je connais java.lang.system c'est pour écrire sur la console et en .Net c'est system.console. Boarf le nom ne change rien je préfère std::cout m'enfin bon...
          Regardons cette MSDN :
          Ho une arborescence, je regarde : c'est lourd ce rechargement systématique qui change tout, sans retour arrière rapide (cf ce que fais la Javadoc)
          Bon, je veux programmer => un clic sur Programmation avec le bitoniau
          Gasp ! Je m'enfuis sur le champ recherche devant l'horreur !
          Je cherche system.console : Pouah une pub "sécurisez votre PC" (nonnon pas une pub pour linux ou BSD !) avec les propriétés et méthodes : la classe arrive 9ème (pratique)
          Bon j'ai des infos que je comprends pas l'intérêt ("Ce type est sécurisé pour les opérations multithread." => tout ne l'est pas ???) Passons sur la LOURDEUR des exemples de code.

          Maintenant, la Javadoc : je veux les API. Sur le J2SE 1.5.0. Ho la doc du JDK ! Je clique sur "Java 2 Platform API Specification"
          Dans le cadre en bas à gauche, je vois toutes les classes : cool je cherche system, et hop j'ai ce que je veux. Il ne manque qu'un exemple, m'enfin c'est compréhensible leur doc...

          Bref, je dirai que la MSDN peut être bien mais il faut utiliser IE uniquement sûrement (pour avoir de jolis nactiveX qui utilisent DirectX (ils aiment le p0rn chez billou))
          La javadoc, c'est nickel, mais ça manque d'exemple et d'un moteur de recherche (bien qu'on puisse s'en passer, merci les frames)

          • [^] # Re: certes

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

            Voilà : tu viens de démontrer que la MSDN est lourde en version web, bien. J'ai dis qu'elle avait des avantages et des inconvénients. En version Offline, c'est bizzare, tu peux survivre facilement avec la MSDN, tu vas y trouver la naviguation et les fonctionnalités offerte par le naviguateur spécial très agréable, réactif et tout et tout. Comme quoi elle a aussi des avantages. Après si on compare le contenu et la qualité (traduction, etc.), y'a pas photo. Bref c'est vraiment se foutre de la gueule du peuple que de dire que la MSDN est pourrie.
            Ou à croire qu'un secteur où Microsoft partage ses connaissances fait chier les adeptes du LL. C'est vrai quoi, on parle de code OpenSource, mais perso des fois je préfère du bon closedSource avec une bonne doc (comme celles que l'ont trouve dans la mine d'or MSDN) où je vais comprendre le fonctionnement interne d'architectures, algorithmes, etc (je ne parle pas de la doc qui résume les méthodes d'une classe) : c'est une autre façon d'ouvrir ses connaissances. Evidemment les extrémistes diront que ce n'est pas sous FDL...

            • [^] # Re: certes

              Posté par  . Évalué à -2.

              En version Offline
              apt-get install msdn ?
              urpmi msdn ?
              voilà, problème cerné ! c'est un prog pour win, sûrement payant. (remarque, ça nécessite win ou au minimum IE => ça coûte le prix d'une licence win c'est pas donné)

              traduction
              Je peux pas blairer la traduction de ce genre de docs. Point barre. C'est inutile, souvent la trad est obsolète, et moins fournie que la VO. De plus, l'anglais étant nécessaire pour programmer (ou presque)...

              • [^] # Re: certes

                Posté par  . Évalué à 2.

                apt-get install msdn ?
                urpmi msdn ?
                voilà, problème cerné ! c'est un prog pour win, sûrement payant. (remarque, ça nécessite win ou au minimum IE => ça coûte le prix d'une licence win c'est pas donné)

                Tu te fous de qui ?
                Tu veux utiliser MSDN pour programmer des softs Unix ?

                Je peux pas blairer la traduction de ce genre de docs. Point barre. C'est inutile, souvent la trad est obsolète, et moins fournie que la VO. De plus, l'anglais étant nécessaire pour programmer (ou presque)...

                L'avantage avec MSDN, c'est que t'as le choix, si tu preferes l'anglais tu prends ca, sinon tu prends le francais. Tu vas pas te plaindre qu'on te donne le choix quand meme ?

                • [^] # Re: certes

                  Posté par  . Évalué à 2.

                  Tu veux utiliser MSDN pour programmer des softs Unix ?
                  Bravo pBpG, tu viens d'expliquer à l'auteur du journal la différence entre .Net et Java.
                  Java est multi plateforme, donc avec des restrictions supplémentaires normalement... .Net c'est pour win. D'après ms c'est portable. J'attend la version linux pour voir... (Non, Mono n'est pas un port de .Net)

                  • [^] # Re: certes

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

                    (Non, Mono n'est pas un port de .Net)
                    Mono c'est une implémentation libre de standards ISO et ECMA, mais aussi un port des API .NET, avec en plus de nouveaux API qui mappent des API natif Gnome, Mozilla ou encore Cocoa (et j'en passe). Tu préfères dis comme ça ? Ca change quoi ?
                    tiens si tu préfères :
                    http://www.go-mono.com/docs/(...)

                    • [^] # Re: certes

                      Posté par  . Évalué à 2.

                      TODO : me relire deux fois avant de cliquer sur envoyer.
                      Non, mono n'est pas un port de .Net au sens où tu n'auras pas windows.forms avant un bout de temps (enfin, c'est pessimiste, mais je pense franchement qu'implémenter cette API windows est effroyablement complexe)
                      Mono c'est en quelque sorte un clone (ou clown si vous préférez) de .Net. Et comme dans chaque clonage il y a des pertes. La MSDN ne référence pas GTK#, ni Gecko#. Par contre, elle est prolixe concernant windows.forms.
                      Bien sûr, je me suis focalisé sur windows.forms parce que c'est celui qui m'a le plus emmerdé quand j'ai regardé les deps de mono 1.0 et je sais que c'est ce qui gêne le plus.
                      Je crains que Mono ne soit toujours à la traîne de ms. Je ne renie pas les API propres à Mono et leur qualité (Gtk# est vraiment sympa à mon goût) mais la compatibilité avec le .Net de ms sera difficile.

                      • [^] # Re: certes

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

                        AH oui donc pour toi quand on porte 80% des API ce n'est pas un port. Il te faut 100% c'est ça ? Marrant comme définition. Moi j'aurai dis un port partiel pour te faire plaisir, mais celà reste un port.
                        Pour les windows.forms, ben tu as beau être pessimiste mais c'est sur le roadmap de la prochaine version prévue avant la fin de l'année (même s'ils ont du retard, celà n'amènera pas à dans 10 ans), voilà en gros où ils en sont :
                        http://primates.ximian.com/~jackson/blog/archive/2004/Sep-20.html(...)

                        Alors OUI, .NET est portable et à été conçu pour. Après une partie des API est plus difficile à implémenter sur d'autres plateformes, parcque le modèle diffère pas mal d'autres environnement, mais c'est quand même possible.

                        La MSDN ne référence pas GTK#, ni Gecko#
                        Sans déconner, pas plus que la JavaDoc de Sun ne comporte la doc des projets Apache et autre...
                        Et puis bon Mono fournit un joli setup qui installe GTK#, toutes ses dépendances et la doc s'intègre à la MSDN et par le même fait à Visual Studio...

                        Je crains que Mono ne soit toujours à la traîne de ms.
                        Mono sera toujours à la traîne pour ce qui concerne les API de Microsoft, c'est évident (on copie pas ou même on ne porte pas un API avant qu'il soit dispo), mais il peut être en avance sur d'autres points, fournir de nouveaux API, etc.

                        Ma question qui tue : que celà apporte t-il à ton argumentation ?

                        • [^] # Re: certes

                          Posté par  . Évalué à 1.

                          AH oui donc pour toi quand on porte 80% des API ce n'est pas un port.
                          Heu
                          (Tiens, tu sais où on le retrouve leur super arborescence des classes sur le site de mono ? Le changement m'a fait perdre le lien...)
                          Les API de .Net vont évoluer au fur et à mesure (enfin, je l'espère). L'implémentation des prochaines nouveautés de LongHorn sera une horreur pour Ximian et ses amis. Je souhaite qu'ils réussissent.
                          voilà en gros où ils en sont :
                          Pour toi un screenshot montre la progression d'un projet ??
                          D'après les réactions des devs de Wine lors de la décision de ne pas utiliser WineLib, les remarques me faisaient comprendre que l'interface n'est pas tout : il y a aussi ce qui est derrière les widgets qui est effroyablement complexe.
                          .NET est portable et à été conçu pour.
                          Tout est portable si tu vois .Net portable.
                          .Net c'est pas que le C# non ? Pour moi c'est aussi les classes windows.***, microsoft.***...

                          Et puis bon Mono fournit un joli setup qui installe GTK#, toutes ses dépendances et la doc s'intègre à la MSDN et par le même fait à Visual Studio...
                          Ça je savais pas... Merci de l'info.

                          fournir de nouveaux API,
                          Oui mais j'ai peur qu'elles soient finalement inutilisées par rapport aux API de microsoft.

                          Ma question qui tue : que celà apporte t-il à ton argumentation ?
                          Ma réponse qui tue : c'était quoi déjà ?

                          • [^] # Re: certes

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

                            .Net c'est pas que le C# non ? Pour moi c'est aussi les classes windows.***, microsoft.***...
                            Sans déconner, et c'est aussi ASP.NET, porté à 100%, c'est System.XML, porté à 100%, c'est System, porté à 100%, etc. Les classes Microsoft.* sont clairement des classes non detinées à être portable, c'est pas pour rien que Microsoft les a mis à dedans, mais y'a quasiment rien dedans d'intéressant... Le seul truc pas encore au point c'est comme tu le dis les Windows.Forms.

                            Pour toi un screenshot montre la progression d'un projet ??
                            Je vais t'apprendre un truc : il y a même du texte à côté des images, les images osnt là our illustrer les widgets qui ont été portés.

                            il y a aussi ce qui est derrière les widgets qui est effroyablement complexe.
                            A la différence près que les API vues en version "propre" à travers le framework .NET sont beaucoup moins complexe que vu linérairement comme dans les API de Windows que tentent de porter Wine. Mais là, je crois que le plus simple est de dire Wait&See.

                            Oui mais j'ai peur qu'elles soient finalement inutilisées par rapport aux API de microsoft.
                            Ah bon pourquoi ?
                            Il suffit que quelques grosses applications les utilisent pour qu'elles soient adoptées... Je vais par exemple prendre comme exemple les API RelaxNG, ou encore les API LDAP qui sont développés et utilisés par Novell, quand à GTK# ou Gecko#, je crois qu'il y a suffisament d'exemples pour montrer qu'elles sont parfaitement utiles... au même titre que les autres bindings dans les autres langages.

                            • [^] # Re: certes

                              Posté par  . Évalué à 1.

                              Je vais t'apprendre un truc : il y a même du texte à côté des images, les images osnt là our illustrer les widgets qui ont été portés.
                              J'ai pas vu un truc avec :
                              "Classe Button : x% implémenté
                              Classe ListBox : x% implémenté"
                              Ni de "current limitation" ou "x properties isn't here"

                              Mais là, je crois que le plus simple est de dire Wait&See.
                              Je préfère "Attendre et Voir" :)

                              Ah bon pourquoi ?
                              Bof, un pressentiment.
                              Parce que ce qu'il manque à linux c'est un visual basic. VB engendre plein d'applis. Et les devs en VB qui codent ces petites applis sont des programmeurs du dimanche généralement, qui se foutent qu'il y ai Gtk# ou Qt#. (Quelqu'un peut il dire ce qu'il en pense si il l'a essayé ?)
                              au même titre que les autres bindings dans les autres langages.
                              Que veux tu dire ?

                              • [^] # Re: certes

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

                                J'ai pas vu un truc avec :
                                Vi c'est vrai, désolé pour ce lien pas vraiment pertinent, mais bon je t'aurais dis d'aller voir dans le CVS voilà quoi...

                                Parce que ce qu'il manque à linux c'est un visual basic
                                Si tu parles du langage, le compilateur VB.NET de mono est bien avancé.
                                Mais de façon plus générale, franchement, les codeurs du dimanche comme tu dis, voilà quoi, c'est pas eux qui engendre le plus d'application bien conçu et tout et tout... Et puis le VB est aussi très utilisé dans le milieu professionnel (surtout le VB.NET)... ce que je veux dire c'est que ce n'est pas vraiment le VB qu'ils veulent (les développeurs du dimanche), c'est surtout un environnement pour développer facilement une application avec un GUI Designer pour clicktouiller partout. Après que ce soit GTK# ou Qt# derrière, effectivement le programmeur du dimanche s'en fou, mais le programmeur du dimanche aime bien pouvoir faire des effets de ouf et reproduire une interface comme dans les autres appli qu'ils utilise : bref dans le même environnement. Mais je ne vois toujours pas en quoi celà diminue l'intérêt de Mono ?

                                Que veux tu dire ?
                                Bah que les bindings dans d'autres langages permettent de rendre accessible un framework dans un nouveau langage, par exemple pyGTK permet de faire des applications GTK en python, etc. C'est quand même utile non ? (surtout quand leur fabrication est automatisée)

                                • [^] # Re: certes

                                  Posté par  . Évalué à 1.

                                  Si tu parles du langage, le compilateur VB.NET de mono est bien avancé.
                                  Ha, bonne nouvelle... Ils le prévoient complet pour mono 1.1, non ?
                                  Malheureusement je prensais beaucoup à l'EDI qui lui est très simple. À vrai dire, Gambas est aussi simple, mais bon, faut voir à l'usage réellement.
                                  le VB est aussi très utilisé dans le milieu professionnel
                                  On m'aurait menti ? :)
                                  Sans dec, quand j'étais sous win, je lisais partout des : "VB c'est nul, vive Delphi ou C++Builder"
                                  Mais je ne vois toujours pas en quoi celà diminue l'intérêt de Mono ?
                                  Simplement que gtk# et qt# seront sous utilisés, et que l'implémentation incomplète de windows.form avec tout le bordel qu'on peut faire dessus (transparence par exemple ?) engendrera des incompatibilités (ou des fonctionnalités manquantes) vis-à-vis des applis .Net issues du monde windows...

                                  • [^] # Re: certes

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

                                    Simplement que gtk# et qt# seront sous utilisés
                                    Je ne vois toujours pas pourquoi.
                                    Je dois avoir du mal, mais pour moi GTK# ou qt# a autant d'utilité que GTK tout seul ou qt tout seul : ils permettent d'utiliser des API spécifiques. Les efforts apportés à GTK# sont dus au fait que Icaza et son équipe veulent faire de Mono une plateforme pour développer sous Linux (et surtout Gnome), et il faut de nombreux API à proposer pour attirer les développeurs, notamment ceux du monde Unix, qui se retrouveront en terrain connu, s'en apprendre un nouveau toolkit. Je ne penses vraiment pas que l'objectif de Mono est de répondre aux attentes des programmeurs du dimanche qui sont sous Windows, ceux là, voilà quoi...

                                    Ils le prévoient complet pour mono 1.1, non ?
                                    Release target: Q4/2004. (1.2, 1.1 c'est devel)

                                    Sans dec, quand j'étais sous win, je lisais partout des : "VB c'est nul, vive Delphi ou C++Builder"
                                    Oué mais depuis Le créateur de Delphi est passé de l'autre côté, et le VB.NET n'a plus grand chose à voir avec l'ancien VB... il est vraiment objet, permet de faire tout pleins de chose, c'est surtout une question de syntaxe, et de goûts et de couleurs... C'est pourquoi il est toujours utilisé, au même titre que le C#, même dans les projets professionnels.

                                    transparence par exemple ?
                                    T'es sûr que c'est directement accessible à travers .NET celà ? De toute façon c'est pas infaisable, y'a Composite (ok ok voilà quoi), mais c'est très (tropà peu utilisé pour qu'on en tienne compte ;)

                                    • [^] # Re: certes

                                      Posté par  . Évalué à 1.

                                      Je ne vois toujours pas pourquoi.
                                      Attention, j'étais dans l'optique Mono=port de .Net
                                      C'est sûr qu'en tant qu'outil pour le dev linux, Gtk# sera utilisé...
                                      Le créateur de Delphi est passé de l'autre côté
                                      Borland ? Qu'ont-ils fait ? (je ne suis plus l'actu de ce côté depuis delphi 7)

                                      (Merci pour tes réponses patientes...)

                                      • [^] # Re: certes

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

                                        Attention, j'étais dans l'optique Mono=port de .Net
                                        Oué effectivement, en fait j'ai pas très bien compris où tu voulais en venir :)

                                        Borland ? Qu'ont-ils fait ? (je ne suis plus l'actu de ce côté depuis delphi 7)
                                        Ben, je voulais juste dire que Borland a perdu sa pièce maîtresse : Anders Hejlsberg qui est passé chez Microsoft pour développer le C# après avoir développé le fond de commerce de Borland : Turbo Pascal et surtout Delphi. Maintenant chez Borland ils surfent sur la vague .NET et propose un studio complet autour de delphi (mais aussi C#) qui a pour cible le framework .NET. Bref les produits Borland sont exactement au même niveau que Visual Studio et VB.NET, et les produits sont comparables (peut être pas dans leur étendues et possibilités, mais en tout cas dans leurs objectifs), Borland fournissant une alternative tout en intégrant la solution de son concurrent. Bref, Delphi ou VB.NET, dans une entreprise c'est même combat, et VB n'est plus vu comme un langage de noobs boutonneux sous Windows : ça c'est plutôt une vue typiquement linuxienne :)

                                        • [^] # Re: certes

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

                                          (m'enfin apparement tu étais rendu au delphi 7, toujours d'actualité, donc je ne t'apprend rien)

                                        • [^] # Re: certes

                                          Posté par  . Évalué à 1.

                                          Oué effectivement, en fait j'ai pas très bien compris où tu voulais en venir :)
                                          Moi non plus maintenant :)
                                          En fait, le pb pour mono, c'est qu'en tant que port du .Net de microsoft il est et sera toujours en retard (malgré son avance pour certaines features de c# 2.0 comme les generics). Par contre, pour les développeurs linux, y'a toujours la peur d'un coup de poignard dans le dos de la part de microsoft

                                          • [^] # Re: certes

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

                                            Vi effectivement, mais bon voilà, je ovis plus l'implémentation des WinForms et autres trucs Windows comme étant un "+" permettant de porter plus facilement des applications, je ne vois pas celà comme une base technologique sur laquelle on peut s'appuyer... C'est pour celà que le retard ne me gène pas spécialement... Pour ce qui est de l'épée de damocles au dessus de Mono par Microsoft, je crois vraiment que ce n'est pas dans leurs objectifs et encore moins dans leur intérêt d'embêter Mono... Microsoft a volontairement tout fait pour que Mono apparaîsse, pas seulement pour dire que "voilà, c'est portable comme Java", mais aussi parcqu'ils savent qu'ils peuvent utiliser cette plateforme pour attirer des clients, voir même faciliter leurs propres développements... C'est à mon avis dans l'intérêt des 2 parties : Microsoft popularise sa plateforme (et n'a donc aucun intérêt à lui mettre un coup de poignard) et Linux se retrouve avec une plateforme alternative à Java, qui a l'avantage d'avoir une base de programmeur potentiels énorme (ben oui les developpeurs Windows, pas ceux qui bossent le dimanche hein ;)) et une documentation très fournit avec toutes les publications uqi vont bien. Perso je sais que Mono a facilité ma migration sous nux, j'ai retrouvé mes habitudes, et maintenant je n'ai même plus de partition Windows :) De toute façon comme le dis Icaza, même si Microsoft évite la compatibilité dans l'avenir, Mono volera de ses propres ailes, tant pis s'il n'y a plus la compatibilité de certains API avec Windows, il y aura toujours une plateforme techniquement performante et répondant à de nombreuses attentes des developpeurs.
                                            Je suis sans doute trop optimiste, comme tu es sans doute trop pessimiste ;)

                        • [^] # Re: certes

                          Posté par  . Évalué à 2.

                          Arretes tes conneries, mono n'est pas un "port" de .net !
                          Tu l'as vu où que les devs de mono ont accès au code source de ms .net ???

                          • [^] # Re: certes

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

                            euh, ils ont accès au code de rotor, donc à toute la base technique, et ils ont également accès indirectement au code de la plupart des classes, la décompilation dans un langage de haut niveau étant aisée et compréhensible.
                            Je parlais pas de port au sens on reprend le même code qu'on adapte, mais au sens on fait une implentation compatible qui permet d'utiliser les mêmes applications sur différentes plateformes. Enfin c'est dans ce sens qu'était notre discussion, il n'y a d'ailleur pas eu de confusion de ce point de vue là.

  • # mouaif

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

    c'est marrant, j'ai déja programmé avec QT et GTK, et euh... QT c'est franchement pas mal, gtk bof, et Swing j'adore.

    Le mécanisme de listeners, la séparation controlleur / renderer / model pour les widgets evolué est franchement bien pensée, ...

    bref, il en faut pour tout le monde, mais j'échangerais pas mon baril de swing contre 2 barils X

    • [^] # Re: mouaif

      Posté par  . Évalué à 5.

      bref, il en faut pour tout le monde, mais j'échangerais pas mon baril de swing contre 2 barils X

      En voila encore un qui tape sur le dos d'X.
      Alors comme ca, des qu'il y a un truc 'graphique' qui va pas, boum c'est
      pan dans la gueule d'X.

      Ca m'enerve ca ! ;)

  • # Exemple concret au niveau de la documentation

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

    Où trouver la documentation de :
    - ImageEncoder
    - ImageCodec

    Quand je recherche ces deux class dans
    http://onesearch.sun.com/search/developers/index.jsp?charset=UTF-8&(...)

    il ne me trouve aucune class.

    De plus, j'aimerai savoir comment trouver l'import à effectuer pour ces deux class.

    Merci d'avance sur l'explication du système de documentation de java.

  • # .net

    Posté par  . Évalué à 5.

    Le framework ne contient même pas de class pour gérer du FTP, il faut passer par une librairie externe (jakarta dans mon cas).


    en meme temps il n'y a pas non plus classe FTP dans le framework .net

  • # ...

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

    ...

Suivre le flux des commentaires

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