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).
Journal Java, après pratique, je trouve ça à chier, vive .net
27
sept.
2004
# KROUIK
Posté par Nap . Évalué à 10.
# interfaces graphique...
Posté par mol67 . Évalué à 2.
Ok il y'a AWT mais ca complique énormement pour faire des interfaces
# la doc...
Posté par Tonton Th (Mastodon) . Évalué à 3.
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 alt3 (site web personnel) . Évalué à 10.
[^] # Re: la doc...
Posté par ours Ours (site web personnel) . Évalué à 1.
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 Sisyphe Plâtrier . Évalué à 10.
Que viendrait fou^H^Haire du FTP dans un framework IHM ?
[^] # Re: Il manque aussi ...
Posté par Nelis (site web personnel) . Évalué à 3.
[^] # Re: Il manque aussi ...
Posté par TImaniac (site web personnel) . Évalué à 3.
# Un coup de pouce au troll
Posté par Jerome Herman . Évalué à 6.
Mais a part ça ?
Kha
[^] # Re: Un coup de pouce au troll
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
L'utilisation des LayoutManager est assez complexe.
[^] # Re: Un coup de pouce au troll
Posté par Jerome Herman . Évalué à 5.
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 Nap . Évalué à 4.
tiens mon p'tit troll, voilà à manger
# certes
Posté par gc (site web personnel) . Évalué à 5.
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 Pierre Tramonson . Évalué à 8.
[^] # Re: certes
Posté par gc (site web personnel) . Évalué à 4.
[^] # Re: certes
Posté par TImaniac (site web personnel) . Évalué à 3.
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 Vincent . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 3.
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 Vincent . Évalué à 2.
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 thaodalf . Évalué à 3.
[^] # Re: certes
Posté par TImaniac (site web personnel) . Évalué à 2.
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 Pierre Tramonson . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
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 Pinaraf . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 Pinaraf . É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é)
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 pasBill pasGates . Évalué à 2.
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 Pinaraf . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 3.
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 Pinaraf . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 3.
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 Pinaraf . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 Pinaraf . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 Pinaraf . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 Pinaraf . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: certes
Posté par Pinaraf . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
Je suis sans doute trop optimiste, comme tu es sans doute trop pessimiste ;)
[^] # Re: certes
Posté par seedeexeen . Évalué à 2.
Tu l'as vu où que les devs de mono ont accès au code source de ms .net ???
[^] # Re: certes
Posté par TImaniac (site web personnel) . Évalué à 2.
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 lorill (site web personnel) . Évalué à 4.
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 Sebastien . Évalué à 5.
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 Stéphane Klein (site web personnel) . Évalué à -1.
- 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.
[^] # Re: Exemple concret au niveau de la documentation
Posté par Nelis (site web personnel) . Évalué à 4.
http://java.sun.com/products/java-media/jai/forDevelopers/jai-apido(...)
Il m'a fallut ... 40 secondes pour les trouver alors que je ne savais même pas dans quel API les trouver ...
[^] # Re: Exemple concret au niveau de la documentation
Posté par Pierre Tramonson . Évalué à 2.
Il y a ce qu'il faut dans l'API java pour manipuler des images mais pas pour utiliser les codecs, qui ne sont pas toujours utilisables sans royalties... Du moins je présume que c'est à cause de ça que ces classes ne font pas partie de l'API Java.
Il faut donc récupérer la lib (ou une autre) ailleurs. Tu trouveras une liste de liens ici par exemple http://java.sun.com/products/java-media/jai/utilities/jaiutils.html(...)
La doc de l'API Sun est dispo là : http://java.sun.com/products/java-media/jai/forDevelopers/jai-apido(...)
[^] # Re: Exemple concret au niveau de la documentation
Posté par Nicolas Cuny (site web personnel) . Évalué à 1.
[^] # Re: Exemple concret au niveau de la documentation
Posté par Stéphane Klein (site web personnel) . Évalué à 1.
J'ai besoin de charger un .jar ? Si oui, je ne le trouve pas dans la partie download. Enfin, je ne sais pas où la trouver.
Deuxièmememnt, je copie ce jar au même endrois que mon fichier source qui utilise ces class ?
[^] # Re: Exemple concret au niveau de la documentation
Posté par thecat . Évalué à 7.
Si tu pose ce genre de question c'est que tu devrait etre moins catégorique dans tes affirmations; en particulier ton "Je suis attristé de voir un framework aussi mal fourni." est trés mal placé pour quelqu'un qui ne comprend en fait _rien_ de la plateforme Java ...
Bref quand on débute, on évite les jugements à l'emporte pièces ...
[^] # Re: Exemple concret au niveau de la documentation
Posté par Stéphane Klein (site web personnel) . Évalué à 1.
Mais je galère énormément.
[^] # Re: Exemple concret au niveau de la documentation
Posté par jcs (site web personnel) . Évalué à 6.
Pour java il y a un forum ici : https://linuxfr.org/forums/18/(...)
mais les newsgroups fr.comp.lang.java et comp.lang.java
ainsi que les forum de Sun : http://forum.java.sun.com/(...)
et pléthore de pages web.
[^] # Re: Exemple concret au niveau de la documentation
Posté par Pierre Tramonson . Évalué à 1.
Ensuite tu lis la doc d'install http://java.sun.com/products/java-media/jai/INSTALL-1_1_2.html(...) je sais pas quoi tu dire de plus je me suis jamais servi de cette API.
Il faut mettre quelques jar dans jre/lib/ext et jre/bin comme d'habitude.
Comme ces deux paths sont connus par l'install initiale de n'importe quel JRE, tu ne devrais même pas avoir à modifier un quelconque classpath.
[^] # Re: Exemple concret au niveau de la documentation
Posté par Stéphane Klein (site web personnel) . Évalué à 1.
J'aimerai donc l'intégrer dans mon jar.
une idée ?
[^] # Re: Exemple concret au niveau de la documentation
Posté par Pierre Tramonson . Évalué à 1.
Le mieux étant d'avoir déjà les jars de JAI installés sur tous les postes clients.
Bon j'ai pas fait d'applets depuis 3 ans, alors...
[^] # Re: Exemple concret au niveau de la documentation
Posté par Stéphane Klein (site web personnel) . Évalué à 1.
Il faut que mon applet fonctionne directement.
[^] # Re: Exemple concret au niveau de la documentation
Posté par Nelis (site web personnel) . Évalué à 3.
En gros c'est un fichier XML qui définit ton application (quelle classe lancer, de quelles librairies elle dépend, où les trouver). L'utilisateur clique sur le lien vers le fichier XML, JavaWebStart (qui est inclus avec les JRE depuis le 1.4) lit ce fichier, il télécharge les librairies si nécessaire, puis lance l'application. Après ça, chaque fois que l'utilisateur relance l'application, JWS vérifie qu'une nouvelle version n'est pas disponible, et si oui il propose d'upgrader.
Je trouve ça mieux que les applets pour des applications qui ne font pas parties intégralement d'un site web.
[^] # Re: Exemple concret au niveau de la documentation
Posté par David Sporn (site web personnel) . Évalué à 1.
Premiere méthode (qui à tous les coups doit contrevenir à la licence d'utilisation de l'API)
===================
un fichier jar, c'est un fichier zip.
Change l'extension, dézippe et rajoute les fichiers class dans ton projet.
===================
deuxième méthode
===================
quand tu fait ton jar pour ton applet, utilise un fichier manifest.mf contenant :
Manifest-Version: 1.0
Class-Path: foo.jar bar.jar etc...
tu remplace bien sûr "foo.jar bar.jar etc..." par la liste de jar dont tu as besoin.
Enfin, tu place tous tes jars (applet + librairie) au même endroit
[^] # Re: Exemple concret au niveau de la documentation
Posté par _alex . Évalué à 2.
{nomClasses/Méthode/etc} site:sun.com
En général ca marche très bien
# .net
Posté par tonton . Évalué à 5.
en meme temps il n'y a pas non plus classe FTP dans le framework .net
# ...
Posté par cho7 (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.