TImaniac a écrit 6420 commentaires

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 ;)

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

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 :)

Moi je vois celà tout autrement : là on a des clients qui expriment des besoins. Le rôle de MandrakeSoft et de les étudier et d'en tirer les conclusions commerciales nécessaire. Mais un client qui s'exprime, notamment en formulant des demandes, est loin d'être inutile : MandrakeSoft est là pour répondre à ses attentes, il paraît normal qu'il formule de nouvelles demandes, sans forcement être déçu du produit.

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 ;)

Je pense que l'originalité réside dans le fait que tu n'es pas obligé d'accepter de licence du tout dans le cas d'une utilisation personnelle sans redistribution : en gros tu fais ce que tu veux tant que tu ne redistribue pas. Je penses que c'est celà qui est original, à côté du choix de 2 autres licences.
Mais j'ai une autre question : quand est-il de la légalité ? Si je choisi de n'accepter aucune licence, ce simple texte a-t-il la moindre valeur juridique si je redistribue leur soft après ?

Franchement lis la pétition avant de dire n'importe quoi. C'est pas vriament une pétition au sens franchouillard où on gueule, mais plutôt une proposition.

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)

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

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

Si tu optes pour un format XML (tu es un puriste et tu adore séparer la sémantique de la présentation et tu utilise DocBook parcque LaTeX n'est pas assez extrémiste), il y a un standard : MathML.

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 ?

(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/(...)

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

sink c'est une "sortie", et source ben une source. Ce sont les filtres utilisés par défaut. A priori il faut mieux choisir parmis ceux proposer que de t'amuser à en préciser un toi même, surtout quand tu n'y connais rien ;) L'avantage de cette fenere c'est qu'elle te permet de clicker sur le bouton "test" pour vérifier qu'un sink (ce qui nous intéresse ici) fonctionne. Si ce n'est pas le cas, vérifies par exemple ton mixer, ou change de choix dans la "dropdownlistbox"
Si tout est bien configuré, c'est que le problème vient de rhythmbox : tu as testé avec un fichier audio .ogg ? Il est parfois possible que tu n'est pas les plugins nécessaire à la lecture des mp3, le ogg étant supporté la plupart du temps en standard (because c'est libre)

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.

C'est une tendance assez globale des GUI de masquer totalement les outils en ligne de commande qui sont derriere, meme dans les docs!
Je crois aussi que ce modèle basé sur la réutilisation et le masquage de lignees de commandes a de graves repercutions sur la réactivité d'une application : une GUI utilise un prog en ligne de commande qui n'a pas été spécialement conçu pour être utilisé ainsi. Celà me semble être une approche très unixienne, du fait de la profusion de commandes existantes. La bonne méthode serait pourtant de proposer un API en même temps que l'on propose une interface en ligne de commande, afin de faciiliter l'intégration dans d'autres applications, notamment les GUI.
Celà m'a toujors fait sourire d'apprendre comment on faisait communiquer 2 processus à coup de pipe et autres mécanismes "inter-processus", comme si il n'était pas possible de les faire communiquer directement sans passer par les entrées-sorties standards...

Pour BeOS, je pense qu'il doit y avoir une partie du à une bonne optimisation et comme tu le fais remarquer au fait que y'a quasiment rien qui tourne, chaque application étant dédié et programmer sans doute avec cette aspect de réactivité.

Quesqui ne marche pas ? L'application se lance et refuse de lire un mp3 ? (voir ma solution plus bas) Elle refuse de se lancer ?

et pourquoi pas vers Windows Update, un peu d'éducation ne fait pas de mal)
Ou carrement dans Panneau de configuration > Système > Mises à jour -> automatiques

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.

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)

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.

je dis juste que les couches sont peu integrees
Pourrais-tu expliciter ce que tu entends par intégré ? Parcque là j'ai du mal à bien cerner ce que tu entend par là... Pour moi je comprenais celà plus comme l'effet inverse de séparer en couche, bre regrouper, je me trompe ?

- souvent dans les GUI on ne donne pas le nom des commandes sous-jacente, ce qui est tres ennuyeux que l'IHM plante!
Peux-tu donner une exemple ?

parfois j'attends un certain temps, parfois je trouve que c'est trop long et je me retrouve avec deux applications ouvertes..
Oui effectivement j'ai déjà rencontré ce problèmes plusieurs fois sous Linux, notamment ce pointeur "sablier" qui ne s'affiche que pour certaines applications...
Mais celà est-il dû au fait que les applications mettent 10 plombes à charger l'interface ou plutôt du fait que l'application a de nombreuses bibliothèques et autres données à charger en mémoire en cours d'initialisation ? Parcque pour moi je ne vois pas en quoi une application "lourde" à lancée sera plus rapide sur un OS avec GUI "intégré", non franchement je vois vraiment pas le rapport.
Plus généralement je crois que tu mets en évidence des problèmes de communication entre les couches, parcque les développeurs ne s'occupe pas toujours de faire apparaître un retour visuel (ou autre) lors d'actions lentes ou inatendues (plantage) : mais c'est l'entière et unique faute du programmeur qui n'y a sans doute pas vu d'intérêt.

Franchement, celà dépend aussi de la distribution que tu as et de leur "orientation", cad Gnome ou KDE. Dans tout cas où tu semble préférer Gnome, je suppose que tu tournes sous une feroda ou une redhat ? (à moins que ce ne soit une debian, mais tu semble être un débutant alors bon) Si c'est le cas, Rhythmbox tourne out-of-the-box, à l'exception qu'il ne lit pas les mp3 mais seulement les ogg par défaut (il faut ajouter le plugin gstreamer-plugins-mp3 qui va bien, question de licence d'après redhat).
Muine pareil, suffit d'ajouter le repository de Mono dans ton yum.conf ou autre apt.conf pour obtenir tout ce qu'il faut pour qu'il tourne. Par contre il faut compiler Muine à la main, avec la version la plus récente, il n'y a à ma connaissance aucun paquet rpm ou deb à jour de ce logiciel, ce qui explique peut-être tes problèmes.

Gecko. (je te laisse googeuliser)