TImaniac a écrit 6420 commentaires

GNUstep s'intègre parfaitement à WindowMaker.
Vi mais comme tu me l'as gentiment fait remarqué dans un de mes commentaires précédents, pour moi l'existant desktop actuellement c'est Gnome et KDE. WindowMaker voilà quoi.
Ca sert à rien d'avoir une plateforme portable si elle ne s'intègre pas dans les environnements les plus utilisés, surtout pour une plateforme desktop.
"C'est super portable, mais on vous conseille d'utiliser WindowMaker"
youpi.

Donc, sur Apple les menus d'applications Qt seront "ergonomique" par rapport au reste des applications.
Youpi alors t'as trouvé une astuce de KDE pour ressembler à Apple et tu crois avoir contredis ma affirmation qui dit que les applications 100% portables s'intègre très mal lorsqu'elle change d'environnement.
Moi je veux rien configurer, je veux utiliser mon application de la même manière que j'utilise les autres applications de mon environnement, sans de voir m'adapter aux particularités "ergonomiques" issue de l'environnement initial de développement.

Pour obtenir une meilleure intégration, il faudra multiplier les types de fenêtres prédéfinies genre dialogue etc.
Dans la plateforme ? Oui c'est une solution, mais on perd une grosse partie des spécificités de chaque plateforme en se contentant des points communs. Ou alors on en est rendu à "imiter" certains composants absent de tel ou tel environnement.
Et puis il ne faut pas oublier qu'il n'y a pas que les fenêtre prédéfinies qui demandent de l'intégration, c'est tout l'interface qui doit être pensée en conséquence.

A l'heure actuelle, la seule solution est de faire une application ou la couche de présentation est bien différenciée du reste de l'application, et de réécrire cette couche pour chaque environnement cible. C'est la seule manière d'avoir une solution de qualité, on se contentera de la portabilité de s autres couches.

J'espère que tu comprends mieux pourquoi je trouves que cette plateforme est jolie mais a oublié le principal objectif de toute solution desktop : l'intégration. Je crois que c'est une des principales causes de ce qui lui arrive. Heuresement que MacOSX l'utilise, parcque sinon j'y verrais pas beaucoup d'intérêt...

tu ne comprends pas du tout ce que j'entend par intégration...

T'as sûrement remarqué, on peut faire tourner une application KDE sous Gnome et inversement. Tu trouves pas qu'il y a de nombreux problèmes d'incohérence d'ergonomie entre les interfaces ? Pourquoi à ton avis on trouve des applications gMachin et kMachin si une seule suffisait ?

Pourquoi KDE existe ? pourquoi Gnome existe ? S'il n'y avait aucune différence, que la seule était le window mamager, y'a longtemps que les projets auraient fusionné...

Je parle d'ergonomie, il y a des chartes graphiques à respecter dans chaque environnement, et aussi une charte d'ergonomie (nom des menu, emplacement des boutons, format d'une fenêtre de conf, accessibilité, etc.)

Je cherche pas des poux à GNUStep, je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé).

Mais vraiment n'importe quoi... depuis quand l'interface n'a pas besoin d'être portable ?
Depuis que de nombreux programmeurs croivent que Java & Co vont résoudre tous les problèmes de portabilité, se sont ensuite rendu compte que y'avait un problème d'intégration visuelle (en partie résolu avec des thèmes utilisant les toolkit natifs) et maintenant un autre problème : intégration ergonomique, et là je ne connais aucun toolkit qui peut se vanter d'être portable tout en respectant l'intégration.

Icaza le dit clairement, la portabilité c'est bien, mais pas au détriment de l'interface.
Mono propose GTK# pour utiliser GTK. Après le fait est que GTK tourne sous MacOSX et Windows, celà peut être une solution portable efficace lorsqu'on ne se soucis pas de faire un soft de qualité (on veut juste qu'il marche partout).
Après Mono marche très bien avec les WinForms sous Windows, et ils bossent d'arrache pied sur Cocoa#, sachant que Qt# est existe également. A ton avis pourquoi ils s'amusent avec tous ces toolkit ? Pour faire joli ?

Un journal avec déjà de nombreux commentaires sur le sujet :
http://linuxfr.org/~pterjan/15684.html(...)

Sinon il semblerait que les DSLAM de Free supporte également la nombre READSL qui ne vise pas à augmenter le débit mais à accroître la distance entre le client et le DSLAM (8km)

Bref, que du bon.

Ceux qui ont râlé tout l'été en attendant leur freebox, savent maintenant pourquoi : ce sont les premiers a avoir la freebox v4 compatible l'ADSL 2, ca vallait le coup d'attendre.

Quand tu développes en Objective-C, tu utilise le framework GNUstep...
Ah bon le langage est limité à la plateforme ? (???)

Je ne vois pas le rapport avec Gtk ou Qt...
Ben si, moi j'en vois 1 : si j'ai envie d'intégrer une appli écrite en Objective-C dans un environnement Gnome ou KDE. S'il n'y a aucune possibilité d'intégration de cette plateforme aux environnements existant, je comprends nettement mieux pourquoi personne n'utilise NeXTStep en dehors de l'environnement MacOSX qui a été développé pour...

C'est gentil la portabilité
C'est gentil un beau langage
C'est gentil une belle plateforme super puissante et performante qui n'a pas bougé depuis 10 ans et qui va grandement augmenter ma productivité

Mais si je ne peux même pas concevoir une application desktop qui s'intègre ailleur que dans un environnement dédié, ben je dis que c'est normal que ce soit au même stade depuis 20 ans.

Un projet comme Mono a l'avantage de ne pas promettre systématiquement la portabilité, ils préfèrent supporter plusieurs environnement (Windows, Gnome et Cocoa) et promettre la portabilité de ce qui DOIT etre portable (bref, pas l'interface)

Maintenant, question à 2 euros, que me propose GNUStep pour m'intégrer à l'existant ? Je peux facilement utiliser GTK ou Qt ? Nan parcque en l'absence d'environnement comme Gnome ou KDE pour GNUStep, je ne peux qu'envisager GNUStep sur plateforme MacOSX...
C'est pas le tout de promettre l'interopérabilité, mais si celà doit se faire au détriment de l'ergonomie parcqu'il n'y a pas d'intégration voilà quoi...

Je viens de lire l'introduction du projet GNUStep et notamment le paragraphe concernant les "avantages" de GNUStep.
Ben, à part le fait qu'il sont apparement plutôt fier du fait que le framework n'a quasiment pas bougé depuis 10 ans (ce dont je m'en fou pas ma à vrai dire, ce uqi compte pour moi, c'est ce que je peux faire maintenant et si je peux toujours faire tourner ce que j'avais fait avant), je n'ai vraiment rien vu de spécial qui fait que cette plateforme roxe largement J2EE ou .NET.
Donc bref, c quoi qui enlarge mon penis ?

sans aller jusque au ratio 1 pour 2, il est clair qu'en 96kbps le wma s'écoute plutôt bien, qasiment comme du mp3 160. Faut pas se leurer, mais si on peut mettre 3 albums au lieu de 2 sur son lecteur c'est déjà pas mal même si c'est pas le double :)

Clap clap clap, celà va vraiment faire avancer le schmilblick.

Délais d'ouverture de ligne aléatoire ? A part chez Wanadoo (me demande pas pourquoi, pourquoi c'est pareil chez tout le monde ?

Débit erratique, si tu suivais un peu, tu verrais que les reseaux de Free sont loin d'etre surchargés, le problème vient dans quasiment otus les cas de la qualité de la ligne du client, et celà Free ne peut rien y faire, et celà serait pareil chez tous les fournisseurs.

Hotline il y a effectivement des défauts, mais question incompétence et attentes, j'ai plein d'exemple chez Wanadoo ou Neuf.
La téléphonie fonctionne mal ? Pareil que plus haut, celà vient de la qualité de la ligne, à vrai dire je n'ai plus entendu personne se plaindre depuis plusieurs mois, au début il y avait effectivement des soucis techniques, comme pour la TV, mais maintenant celà fonctionne plutot pas mal du tout.

Quand au SAV j'en sais rien je ne l'ai pas expérimenté.

Alors voilà c'est bien gentil de raler, mais celà m'étonnerai que tout celà te soit arrivé à toi, où alors tu n'as vraiment pas de po. Dans tous les cas celà ne sert strictement à rien de généraliser, puisqu'on rencontre les memes problèmes chez tous les FAIs.

A noter que si tu voulais un service nickel, sans retard, avec un débit de crete en permanence et tout et tout, tu le paierais 60 euros ton forfait chez Wanadoo. Et encore, tu n'aurais pas plus de certitude sur la qualité de la ligne.

l'ADSL 2+ permet de plus haut débit mais également des synchro un peu plus loin. Meme si le gain n'est pas phénoménal, celà n'est pas négligeable, et si certaines personnes peuvent grace à cette techno avoir du Haut Debit, je trouve celà vraiment important, tout aussi important que le fait de fournir les freebox en moins de 2 semaines par exemple.

Mais c'est bien gentil de dire que tout est déjà présent dans GNUStep, qu'il n'y a besoin de rien recoder, et blablabla c'est mieux que les autres solutions, mais perso des plateformes comme ça j'en connais pas mal, par exemple Java ou Mono pour ne pas les citer. Alors en quoi GNUStep enlarge plus mon penis qu'une autre solution ?
Et quel IDE permet de tirer pleinement partie de cette plateforme ? Parcque bon, question productivité, on peut y aller à coup de Visual Studio, et là aussi tu vas pouvoir anlarger ton penis en encore moins de temps...

Sérieux je veux des arguments.

"permet de programmer des applications en quelques heures au lieu de jours, semaines ou jamais"

On peut avoir des arguments ? En quoi cette plateforme, surement superbe, permet-elle de développer plus rapidement une application ? qui de plus s'intègrera dans tous les environnements sur toutes les plateformes ? Parcque bon, celà fait quand meme longtemps que ca se saurait si ce saint graal avait été atteind...

Sinon ben bon anniversaire, et contrairement à ce qui est dit plus haut, celà peut-etre très beau, cf Cocoa.

tu fais du hors-sujet, là on ne débat pas de l'intéret des brevets, c'est juste une blagounette.

Bon bah ca y est, celà fait un brevet de plus violé par Linux.

Attention à ne pas confondre la comparaison des langages avec la comparaison des plateformes.

On teste pas une plateforme comme J2EE en faisant un Hello World.

Ensuite il n'y a sûrement pas grand chose que tu ne puisse pas faire en PHP par rapport à J2EE. Donc celà ne sert pas à grand chose d'essayer de trouver un exemple.

J2EE est plus complexe que PHP, c'est un fait. Mais pourquoi ? Ils se sont amusés à compliquer J2EE pour enmerder le programmeur ? Ben non. C'est juste qu'il y a pleins de notions et de principes de fonctionnement à assimiler pour pouvoir faire de grosses applications (pas un hello world) sans avoir à tout re-concevoir, de nombreuses briques complexes mais bien utiles étant présentes en STANDARD (pooling, transactions, etc.) et surtout qui s'intègrent avec l'existant de façon élégante.

On ne code pas (j'ai pas dis on peut pas) les composant métiers en PHP, PHP n'est qu'une façade et est fortement limité aux applications Web.

Voilà, donc PHP peut être une alternative à J2EE lorsque l'application concernée est une application orientée web, qui n'a pas vraiment besoin de s'intégrer à un existant.
Les pro-PHP ne comprennent pas ce que J2EE peut faire en plus (bah vi ils en ont jamais eu besoin), alros que les pro-J2EE voient clairement les limitations qu'apporte PHP.

Après peut-être que PHP pourra plus tard prétendre concurrencer J2EE au niveau de l'intégration (grâce à Sun par exemple), mais en l'état actuel ces 2 plateformes ne sont comparables que sur une petit sous-ensemble d'application.

Voilà, c'est mon avis et je le partage avec moi-même.

Je ne sais pas ce qu'il va dire, mais je penses que celà est due au fait que l'itanium cassait la compatibilité avec une bonne partie de l'existant sous Windows. Après est-ce vraiment la faute à Windows, sachant surtout que c'est Intel qui a défini le jeu d'instruction qui les enmerde maintenant... Disons que Windows a populariser la plateforme de Intel, ce qui n'a pas dû leur déplaire, mais maintenant ils sont plus ou moins "embêter" par ce jeu d'instruction qui ressemble plus à un fardeau qu'autre chose :)

HTML ne sert qu'a structurer un document rien de plus, rien de moins
Houlà malheureux :)
HTML sert à présenter, pas structurer un document :)
Et puis dire que c'est fait pour l'impression, disons que celà n'a jamais été sa fonction première, les trucs media print ont été rajouté au HTML (même pas, au CSS) comme les liens hypertexte ont été ajoutés aux PDF, c'est pour celà que c'est fait pour :)

Bon allez hop je répond à tout le monde à la fois, apparement je me suis mal fait comprendre :)
J'ai pas dit qu'on pouvait pas faire de web services en PHP.
J'ai dis que c'était pas fait pour. Nuance.
Ce que j'entend par là c'est que dans la pratique on peut effectivement faire de la communication SOAP avec à peu près n'importe quoi, et donc implémenter entre autre le protocole des Web Services tranquillement en PHP, je n'en doute absolument pas.

Ce que je veux dire c'est qu'un web services non trivial se contente rarement de renvoyer une bête réponse à l'utilisateur, et fait parfois (souvent ?) appel à une solution qui n'a absolument aucune intérêt à être implémenté en PHP par rapport à Java ou autre. C'est en ça que je dis que les Web Services en PHP voilà quoi. On peut mais c'est pas fait pour, et c'est surtout beaucoup plus confortable sur d'autres plateformes.

"PHP a d'ores et déjà gagné ses galons en matières d'applications Web, PHP 5 devrait être l'occasion de voir PHP gagner l'univers des Web services et des middleware applicatifs pour le moment chasse gardée de Java."
(tiré de l'interview)
Y'a un gros conditionnel dans la phrase, et les Web Services sans middleware applicatifs comme il dit, ben voilà quoi.

J'espère m'être mieux fait comprendre, je me rend moi même compte que mon post n'était pas clair.

Non, c'est vrai que un parc hétérogène de terminaux ca doit être génial... J'imagine tout de suite la hotline de Free :
- "vous avez quelle version de firmware ?"
- "version 6.43.2 alpha 4 warlord-mega-boost-GPL"
-"..."

Tu veux parler de Web Services ? Tout dépend de la nature de la fonctionnalitée fournit. Mais franchement je ne vois pas du tout ce que viens faire PHP là dedans, PHP c'est pour faire du web dynamique, pas encore des Web Services.

Tu veux que je te trouves un site en PHP qui bug un peu, globalement lent, avec de belles erreurs ?
Nan sérieux me dis pas que tu juge la qualité d'une plateforme à l'utilisation qu'en fait un mauvais programmeur :)

Pour l'histoire des onglets, ben en fait faut comprendre ce qui est dispo dans .NET : tu as à ta disposition un ensemble de "widgets" prédéfinis, qui se programment exactement comme leurs équivalent dans les applications lourdes. Celà permet de concevoir très rapidement un site web avec des briques de bases, d'ailleur celà peut se dessiner de la même manière sous Visual Studio, la seule différence venant de l'interface, qui est du HTML.
Bien entendu, celui qui recherche la productivité seulement, peut se contenter de cette solution. Mais après libre au développeur de modifier les paramètres par défaut pour relooker entièrement son site. Tu retrouves le même concept dans le monde Java depuis peu, en moins abouti cependant.
Solution 2 : tu ne tient pas du tout compte de ces composants, et tu te refais une interface avec des composants de moins haut niveau, ou directement à base de HTML comme tu le ferais en PHP.
Il faut bien voir que ce n'est qu'un des aspects de ASP.NET, cet aspect ne permet pas d'avoir un contrôle total sur le code généré, les widgets prédéfinis générant automatiquement le code associé (heuresement, sinon je verrais pas l'intérêt)

Erf, j'ai pas l'impression de faire un discours marketing... Je t'ai proposé un exemple d'application multimédia, mais je peux t'en trouver 50000 exemples que tu ne peux pas faire avec PHP en l'état actuel.
Il ne suffit pas comme tu dis de faire un wrapper vers une libc, parcque tu oublies que PHP se veut portable, et là c'est beaucoup plus délicat : il faut vraiment que tu prennes tes doigts et que tu codes, ca se fait pas en 5 minutes une plateforme de la taille de J2EE ou .NET

Effectivement, ils auraient du rajouter dans la news "concurrents *dans le domaine Web*"
Voilà voilà, mais celà n'a justement pas été précisé, et c'est ce que je regrette : certains vont croire que .NET ou J2EE ne permettent que de faire des appli web (dans le cas de .NET j'en ai même vu qui croyait que c'était uniquement pour faire des Web Services...), d'autres qui vont croire que PHP va être la solution miracle pour concurrencer les 2 autres plateformes, avec la simplicité en plus. Alors que cet atout, la simplicité, n'est valable que parcque PHP est limité à un domaine bien particulier...

Tout l'intérêt de J2EE est de définir des standards/normes pour garantir une certaine interopérabilité. Qu'une solution existe en PHP n'en fait pas un standard et ne garantie en rien son support et son acceptation de la part de tous les développeurs.

Il faut bien voir que les brevets de Kodak visent avant tout le langage Java et le fonctionnement de la VM qui va derrière. Je ne suis pas si sûr que le problème s'applique à Mono. L'équivalent dans le monde .NET c'est plus ou moins le CLR (=JVM) et au niveau du langage, plus ou moins C#. Hors ces parties sont entièrement normalisées à l'ECMA et à l'ISO. Hors cette première stipule clairement que tous brevets courant sur ces parties normalisées ne doivent être discriminatoire ou une licence payante. Tu dis toi même que MS a pris soint de vérifier tout celà avant de pondre sa plateforme.
Enfin de toute façon ce ne sont que des spéculations, je ne connais pas exactement la nature des brevets, etc. Par contre ce qui est sûr c'est une qu'une plateforme comme Mono doit sûrement violer de nombreux autres brevets, sans forcement s'en rendre compte, comme la plupart des solutions logicielles. Que faut-il en conclure ? Que les brevets logiciels vont à l'encontre de l'innovation, sont un frein économique et une atteinte à la liberté d'expression. Bref ca pu.

Il ne dit pas la même chose que toi
Moi je confirme ce qu'il dit et justement j'étend au domaine qu'il ne connait pas pour mieux répondre au sujet posé par cette dépêche :) C'est bien parcqu'il y a un fossé que j'ai voulu précisé...

Je ne conteste pas encore, je demande simplement "pourquoi ?" et "où sont tes arguments ?"
Mes arguments sont essentiellement basés sur ce que permet la plateforme en elle-même :
il suffit de regarder l'ensemble des APIs disponibles : PHP est principalement orienté web alors que les 2 autres plateformes peuvent à peu près servir à tout. Hors dans les grosses applications il faut parfois intégrer son application web à d'autres solutions métiers, et, surtout dans le cas de J2EE, l'existant est parfois énorme : l'intégration est naturelle, le site web devenant une des interfaces de la solution globale.
C'est aussi pour celà que je dis qu'ils ne jouent pas dans la même cour : leur domaines d'applications ne sont pas du tout les mêmes, on peut très bien envisager de faire une application multimédia en .NET alors qu'en PHP voilà quoi... PHP est limité au Web et tout ce qui tourne autour plus ou moins directement.