tcws a écrit 199 commentaires

> C'est valable dans le cas où il possède la propriété de
> l'ensemble de ce qu'il fait

il possède par définition la propriété de ce qu'il a fait...
Sauf si il a donné son boulot à la FSF, et si quelqu'un fait ça c'est en connaissance de cause.
C'est bientôt fini les conneri^Wdésinformations dans ces commentaires ?

oui mais quand même la nuance parceque certains langages sont plus goret-proof que d'autres quand même...

mais non, les moujahidines, tu sais bien que sur linuxfr on est tous que des sales intaigristes ^^)

ben ça gratte

[+] !!!!!

        | | | | | |

        | | | | | |

        | | | | | |

        | | | | | |

        | | | | | |

       | |  | |  | |

       | |  | |  | |

      | |   | |   | |

      | |   | |   | |

     | |    | |    | |

   |  |     | |     |  |

 |   |     |   |     |   |

ha oui là d'accord [+]

-1 pour moi mais alors + au dessus quand même.

zut, -12 quelqu'un a mis la même chose ci dessous plus tôt...

un XML propriétaire ça veut rien dire AMHA... par contre une DTD qui permet (impose ?) d'intégrer des éléments propriétaires au document en binaire c'est tout à fait possible...
style
<documentxmlmicrosoft><![CDATA[ insérez ici un document .doc Word ]]></documentxmlmicrosoft>
non ? :)

on ajoute l'adresse d'un backend rss et hop --> une nouvelle boite ?
comme la boite personnelle quoi :)

[+]

> mais quand on est pas fichu de donner une alternative à
> BiteKeeper on ferme son claque merde !

cite une seule personne qui soit "fichu de donner une alternative à bitkeeper"... tu as dix secondes.

2...1...0 personne ? tout le monde ferme sa gueule alors ? <troll>et les développeurs libres ils mettent le palladium le papier alu ?</troll>

oui tiens un fork --> linus repart avec un linux non GPL basé sur les premières sources du noyau, quand il n'yavait que lui qui avait mis les mains dedans, et de l'autre coté continuation du linux GPL (alllez GNU/Linux ? :) ) dans l'état actuel :o)

(blague -1)

cinquième option, si tu utilises linux ils considèrent que tu es sait bien configurer ta connection :) (c'est peut-être mal vu de leur part mais bon...)

on est d'accord sur certains points, mais pas sur le suivant: moi je dis que flash marche maintenant, est bien implémenté et que c'est une raison pour l'utiliser (en tous cas de mon point de vue qui est assez particulier je le conçoit).
Et je ne suis pas d'accord avec ça:
> SVG+ECMAScript+d'autres choses en XML,
> c'est avantageux par rapport au Flash,
je dis qu'à l'heure actuelle c'est complètement faux. Concernant le long terme --> concernant la pérennité on s'en fout.
Je ne dis pas ça pour troller, mais simplement parceque les interfaces (homme/machine) ou les applis qu'on développe aujourd'hui on ne les utilisera plus demain et on les redeveloppera.
Par contre on utilisera toujours sûrement les interfaces logicielles, lesquelles ont intérêt à être basées sur XML, standard avec lequel flash sait très bien discuter (moins bien que perl mais beaucoup mieux que PHP).

En ce sens je ne vois pas de bonnes raisons de ne pas utiliser de flash aujourd'hui (autre que politiques, et ça me fait mal au cul mais je fais avec). Par contre je vois plein de raisons de ne pas utiliser SVG+SMIL+ECMAScript (cf ci dessus) et hélàs je ne vois pas se profiler les outils qui me permettront de passer ce cap, sans parler du peu d'audience qui voudra accepter ce type de contenu. Le dernier exemple élaboré de contenu SV+Script que j'ai vu était celui de l'expo sur la bande dessinée de la BNF, je chercherai l'url, mais franchement ça m'a fait rigoler la lourdeur du truc.

Par contre ça ne m'étonnerait pas que macromedia fasse de flash un jour un outil capable d'exporter en SVG+SMIL+tout le toutim (à mon sens ce serait une chose à faire - du point de vue commercial ce n'est peut-être pas leur avis) et ainsi pour moi la transition sera transparente.
(enfin là je me touche un peu mais c'est pas grave :) )

> Sauf erreur ECMA (javascript si tu préferes) est normalisé.

je sais très bien ça pour la bonne raison que c'est ce standard qu'implémente le langage de script de flash (le soft hein).
Donc forcément j'ai plutôt intérêt à connaitre ;op
Précisément, j'apprécie beaucoup ECMAScript comme langage de script (rapide à developper, compréhensible pour les neu² comme moi). Dommage que ses implémentations ne soient pas plus répandues (hors Javascript et produits propriétaires). [ d'ailleurs je me gourres certainement sur ce dernier point et j'adorerais avoir des infos là dessus]

ben sans vouloir troller de trop... va falloir clarifier.
le swf c'est quand même un standard de fait, le SVG c'est très bien mais c'est un format vectoriel GRAPHIQUE point.
Après ECMAScript oui c'est standard MAIS ce n'est pas SVG on est d'accord ?
Enfin vous parlez de SMIL, ECMAScript et SVG, mais vous avez essayé de faire ce qu'on peut faire en flash avec un combo SVG/SMIL/script ? vous avez regardé combien de temps ça prend ? quels outils existent ? vous avez une idée de l'investissement ($) que ça peut représenter ?
Si vous n'avez pas essayé vous devriez. Ensuite vous verrez que le nombre d'outils à votre disposition sera peut être nombreux, mais pratiques et utilisable pour obtenir la productivité qu'on peut avoir avec flash je sais que non. Pour le temps vous vous rendrez compte que *dans l'état actuel des choses* ce sera de 2 à 10 fois plus de temps de développement nécessaire avec du SVG (ne serait-ce que pour faire communiquer les graphistes et les programmeurs). Enfin vous vous amuserez beaucoup j'en suis sûr avec les problèmes de compatibilité.

voilà pour "tout standard tout ça".

> Il est toujours avantageux à long
> terme de suivre le standard

je n'en doute pas. Je suis même sûr que c'est pas pour rien que MM est impliqué dans le SVG aussi.
Mais je suis aussi certain que à long terme des outils utilisables utiliseront des standards qui seront des évolutions de SVG+ECMAScript+SMIL (quoique smil...), des vrais outils puissants avec lesquels on peut faire quelque chose qui fonctionne ET qui ait de la gueule ET qui permette d'explorer des pistes intéressantes dans les interfaces ET qui facilite l' "accessibilité".
C'est pas le cas aujourd'hui, aujourd'hui le standard de fait c'est le swf. C'est dommage, j'ai personnellement pas de fierté à bosser avec Flash, mais c'est le seul outil actuel qui me permette de bosser de manière créative ET productive.

Sinon je ne demande pas mieux que d'utiliser les standards. (je souhaite qu'ils s'inspirent quand même de flash ;op )

> Le SVG couplé à un langage de script

oui je ne te le fais pas dire... pas encore très standard tout ça.

> permet de remplacer

parfois

> avantageusement

jamais vu encore des cas où c'était avantageux...

non non c'est pas un troll :) seulement faut relativiser : je gagne de quoi payer mon loyer et manger à peu près, c'est mal hein ? :)

oui c'est ce que MM appelle pompeusement le "one page"..
mais en gros c'est vrai l'intérêt c'est ça: pouvoir faire vite et bien (enfin bien c'est toujours relatif) des applis clientes qui tournent dans les browsers, en s'assurant en général pas mal de compatibilité et moins de difficulté qu'avec java (pis c'est moins lourd qu'une jvm à télécharger) (pis on peut faire plus vite des trucs vachement plus sexy qu'avec java quand on est un neu² comme moi ;) ).

> 1°) je trouve le post de la news
> particulierement illisible : on comprend pas grand-chose.

shame on me... j'étais un poil pressé, pas pour le poster le premier mais pour que quelqu'un le poste tout court :/

désolé c'est vrai c'est rédigé comme un goret.

ho j'ai failli rater le troll:

> en attendant SVG bien sûr...

oui SVG c'est un format graphique ça (très bien d'ailleurs au demeurant)...
quel rapport avec le format swf qui est un bytecode ? :)

Non le format swf6 n'est hélàs pas encore ouvert :(

> SAI PA LIBRE

on s'en fout, et puis c'est bien je gagne des sous avec.

> Sa prend plein de ressource

oui ça suxe quand même :/ mais c'est bien je gagne des sous avec.

ou alors y'a pas de p effectivement et je me plante mais comme dit l'autre où est passé le -1 :)

le problème si je me rappelle bien c'est que le copyright est (c) Sygma là où il devrait être (c) les developpeurs d'XVid.
A priori y'a vraiment un problème quoi.