Laurent J a écrit 2933 commentaires

Bien que les formulaires dans HTML5 soient grandement amélioré (voir une présentation ici http://ljouanneau.com/blog/2006/08/30/587-web-forms-2 ), XForms reste, et de loin, bien plus riche (et plus complexe aussi, mais bon..), offrant plus de possibilité.

XForms est beaucoup utilisé en dehors du web, ou coté serveur.

> un nouveau XHTML qui prendrait les bonnes idées de HTML 5 serait le bienvenu...


HTML5 == XHTML5

http://www.w3.org/TR/2008/WD-html5-20080122/#html-vs

En gros, pour le HTML5, tu as le choix entre la syntaxe SGML (le HTML quoi), et la syntaxe XML (donc XHTML).

Bref, c'est comme entre XHTML 1 et HTML 4.01 : ce n'est qu'une histoire de notation. Les balises, les attributs etc, sont identique dans les deux cas.

Dans FF3, il y a un garbage collector. Parce que le comptage de référence, c'est bien mais pas suffisement. Genre un objet A detient un objet B, et B detient A. Si il n'y a pas de garbage collector, jamais A et B ne seront détruits.

tu oublie une chose : Mysql est quand même vachement plus simple à installer/configurer. Et pour un hébergeur, ça compte aussi.

personnellement, j'ai installé la dernière kubuntu sur trois machines totalement différentes, et je n'ai eu à faire aucun bidouillage.

Quant au choix de krita, je ne vois pas en quoi c'est un manque de discernement : je trouve normal d'avoir des logiciels kde/qt dans un environnement kde (meilleure intégration), et je trouve que krita a de moins en moins de choses à envier à gimp (surtout pour un usage "normal").

Bon et puis on peut pas dire que apt-get install ou l'utilisation de adept soit particulièrement compliqué pour installer tes logiciels préférés (non mais).

s/juste/chuste
s/alsacien/alssacien

ils t'ont fait fuir, en tant qu'utilisateur ou en tant que contributeur ? Si c'est en tant que contributeur, qu'est ce qui t'a fait fuir ?

>N'y aurait-il pas moyen d'utiliser quelque chose du type des annotations qu'on retrouve sur JPA dans Java EE 5?

Je ne sais pas, je ne connais pas JPA :-)

Ceci dit, pour les fichiers XML, il y a des scripts en ligne de commande fourni pour les générer, et pour les DAO en particulier, à partir de la base. (Et ils ne sont pas généré à la volée car il n'est pas toujours possible de tout détecter au niveau du schema selon la base, selon la qualité du schema etc...)

>Disons que le désamour est assez réciproque

Prend pas ton cas pour une généralité :-)

Je suis sous KDE depuis des années, j'adore KDE, mais je préfère Firefox à Konqueror... Et j'aimerais bien aussi une meilleure intégration de FF dans Kde...

justement, si ils n'utilisent pas CVS ou peu, c'est peut être parce que CVS c'est franchement dépassé et franchement pénible à utiliser, non ? Et donc peut être que si vous migrez vers un outils plus moderne et plus simple d'utilisation...

ben ça se résoud, ça se résoud...

il me semble qu'il y a eu des améliorations aussi de ce coté là, mais je te confirme rien, j'ai pas regardé cet aspect.

Pour ce qui est de Firefox/QT, ben... quand il y aura des volontaires ?

Pour des raisons historiques, Gecko utilise GTK. Il y a eu dans le trunk Mozilla la possibilité de remplacer GTK par QT (c'est à dire plus de trace de gtk), mais le problème est que ceux qui avaient fait cette partie de code ne l'ont jamais vraiment maintenu. Ça compilait même plus d'ailleurs à un moment. Ils ont donc fini par virer dans le trunk (et donc FF3) le support QT et les sources qui allaient avec.

Mais bon, si des volontaires veulent s'investir à nouveau sur QT inside FF, c'est toujours possible.

Bizarrement, y a toujours eu des volontaires pour aider au support de GTK dans FF, mais jamais vraiment pour QT...

openid c'est pour s'authentifier, pas creer un compte

>Si il faut des plombes pour que un patche soit « accepté » par le reste des devs, ça va pas marcher. Et ça peut arriver si on ne donne pas d'accès en écriture car les mainteneur peuvent être occupé et penser qu'un autre répondra.

Y a pas de raisons qu'un patch soit intégrés après des plombs. Par exemple dans Mozilla, quand tu proposes un patch, et que tu demandes une revue, elle se fait dans les quelques heures ou jours, mais pas des semaines. Et ceci parce qu'il y a des responsables, des reviewers pour telle ou telle partie de code, et que la revue de code fait partie de leurs tâches (le code de mozilla est tellement gros qu'il n'y a personne qui connait suffisement bien *tout* mozilla pour pouvoir faire les reviews de n'importe quel patch).

bref, ton "ça va pas marcher" n'est pas vrai. Ça fonctionne dans de nombreux projets.


>Ça marche avec Wikipedia, ça marche avec KDE

Ouai enfin, la qualité des articles dans wikipedia est très très inégale. Et ils ne sont pas systématiquement toujours relus. Mais à la limite, on s'en fiche un peu, un mauvais article ne met pas en péril le projet. On ne peut pas en dire autant dans un projet informatique comme KDE : du mauvais code peut ajouter des trous de sécurité, des problèmes de stabilité etc... Je trouve donc ça hasardeux de comparer Wikipedia avec un projet informatique.

Autant je suis d'accord avec toi que le point 1 et 3 peuvent rendre agréable le développement, autant je ne suis absolument pas d'accord avec toi sur le point 2.

Ce n'est pas parce qu'on ne donne pas les clés à tout le monde au dépôt de source que le projet est moins communautaire. Très franchement, je préfère qu'une certaine confiance s'instaure entre les dirigeants d'un projet, et un contributeur, avant de lui donner les clés. Pourquoi ?

- parce que même si on peut annuler des modifs, c'est franchement une perte de temps que de corriger les merdes de contributeurs peu scrupuleux, codant comme des porcs, ou tout simplement débutant. Et dieu sait si le temps nous est particulièrement précieux.

- J'ai pas envie, sur mes projets que les types commit n'importe quoi, des fonctionnalités dans tout les sens, des trucs qui font dévier le projet de ses objectifs, ou encore des trucs inutiles, au risque de mettre en péril le produit même : au niveau stabilité, utilisabilité etc.. (c'est du vecu)

- Si on s'aperçoit qu'un type auquel on vient de donner l'accés, fait du mauvais boulot, c'est encore une perte de temps pour le virer (lui expliquer, tout ça...), et ce n'est jamais agréable pour les deux parties. En tout cas, c'est un risque fort de tuer l'ambiance du projet si le gars en question n'est pas content et qu'il fait des histoires parce qu'on lui a couper son accès. Éviter ce genre de problème, c'est des soucis en moins. Bref, je préfère qu'il y ait une sélection à l'entrée, plutôt que de devoir virer les gens.

- Corollaire : Ne pas donner accès en écriture à tout le monde est un gage d'une certaine qualité, en tout cas d'une qualité du niveau de ce qu'attendent les responsables du projet.

- Je ne vois pas franchement à quoi ça sert de livrer l'accés en écriture si il y a un outils de suivi (bugzilla ou autre) et qu'il est utilisé efficacement : n'importe qui peut faire un checkout, faire sa modif en locale, et proposer un patch dans un ticket. Où est le problème ?

De plus, tu penses qu'un processus de review c'est long et contre-communautaire : moi je dis que l'absence de review est synonyme de code pourri (en tout cas, pourrissement à moyen et long terme, donc de plus en plus dur à maintenir). Les reviews permettent d'une part aux nouveaux venus d'apprendre par leurs erreurs, et d'autre part de faire en sorte que le code commité soit d'un niveau de qualité minimal. Par exemple, dans Mozilla, les patchs, de qui que ce soit (qu'il soit débutant sur le projet ou un vieux de la vieille), sont revues par au moins deux personnes. Et pour un projet d'une telle complexité, c'est pas du superflu.

D'ailleurs, la revue de code est un des fondements des méthodes "agiles" de développement, et garantissent, avec les tests unitaires, d'une qualité **constante**, et en tout cas plus uniforme sur l'ensemble du projet.

Bref, je préfère donner les clés à des contributeurs qui ont montré par leurs contributions passées, qu'ils sont sérieux, qu'ils codent pas trop mal et qu'ils sont actifs.

Il est possible que les devs de KDE donnent accès en écriture à tous, mais je serais vraiment étonné si ils ne mettent pas des droits restreints sur certains répertoires...

Pour conclure, non, restreindre l'accès en écriture au dépôt de source n'est pas une condition pour que le développement soit agréable. Ça n'empêche nullement de coder, de proposer des patchs. Ce qui fait qu'il est agréable de contribuer à un projet, c'est le contact que l'on a avec les devs, c'est le fait qu'il ne soit pas fait n'importe quoi sur le projet, et donc qu'il y ait des objectifs clairs et définis, qu'il y ait un minimum de serieux (sans tombé dans une atmosphère dictatoriale), que les reviewers soient "pédagogiques" genre pas dire, "ton patch il est nul", mais expliquer pourquoi ici ou là ça ne va pas, qu'est ce qu'il est préférable de faire etc. Bref, avoir l'impression qu'on apprend quelque chose, qu'on avance tous ensemble dans la même direction.


Ah oui au fait, en utilisant des dépôts décentralisés, ton point 2 n'a pas lieu d'être... les dépôts centralisés sont has been, surtout pour les gros projets... (même si j'aime bien et j'utilise subversion :-) )

Il y a plein d'autres choses qui ont changé dans FF, des choses qui se voient : nouvelle gestion des bookmarks/historique par ex, icones, theme, et plein de petites choses dans l'interface, dans les préférences, amélioration de l'intégration dans le desktop.

Et des choses qui ne se voient pas : le moteur de rendu a eu des parties refondues pour un meilleur support de CSS, performances accrues, améliorations de la gestion de la mémoire, améliorations dans le support SVG, amélioration de l'accessibilité (ceux qui utilisent des lecteurs d'écrans par ex vont apprécier).

Enfin bref, prend le temps de lire http://www.mozilla.com/en-US/firefox/3.0b2/releasenotes/#wha(...)

Pour tes problèmes de lenteurs : tu as manifestement un problème sur ta machine avec ton système. Les builds de Firefox subissent de manière incessantes des tests de perfs dans tout les sens, sur tout les types de machines courantes (windows, mac, linux...). Si il y avait de tels problèmes sur ces système "normaux", ça serait corrigé aussitôt.

Oui, c'est le serveur. Dans le test, il y a un lien qui doit pointé sur une page 404, or sur le serveur, il y a maintenant une page à l'url indiqué, donc plus 404, donc test faux.

https://bugzilla.mozilla.org/show_bug.cgi?id=289480#c179

Pour IE8, il passe effectivement le test acid (avec un nouveau moteur de rendu basé sur le moteur de rendu de MS Office...)
http://blogs.msdn.com/ie/archive/2007/12/19/internet-explore(...)

Ça n'est pas au même niveau. Il parle ici des allocations/désallocations bas niveau.. Le garbage collector est une couche au dessus. Et puis bon, les allocations/desallocations sur la stack ne concernent pas vraiment le garbage collector...

Exact, chuck norris est indéstructible. http://www.willitblend.com/videos.aspx?type=unsafe&video(...)

>après une longue attente et diverses RC, signe que les développeurs voulaient sortir un produit de qualité et non pas bâclé

Ouai enfin, je suis dubitatif. Parce que bon, quand je vois qu'ils ont sorti 8 RC avant la finale, je me dis qu'il y a un problème quelque part :

- soit ils ont sorti la RC1 trop tôt, c'est à dire non débuggée et alors ils auraient dû l'appeler beta (pour rappel : RC= release candidate, c'est à dire une version censée être stable, suffisament débuggée, prête donc à être utiliser en prod)
- soit leur code est toujours aussi pourri (il n'y avait qu'à voir le nombre de requête SQL inutiles executée à chaque page dans les versions précédentes)

Enfin bref, 8 RC, pour moi ça ne fait pas sérieux et n'est pas un gage de qualité, et ils ont certainement des progrès à faire au niveau de la prise en compte de la qualité dans leur processus de développement (par exemple, je n'ai pas vu de tests unitaires dans le dépôt CVS).

>L'ergonomie, c'est bien, surtout pour madame michu

Non, l'ergonomie, c'est pour tout le monde, même pour les geeks. Taper des lignes de commande ou cliquer sur 15 boutons d'affilé, ça va un moment, et ça devient chiant à la longue.

> Mais l'ergonomie, quand on à du code ouvert, bah chacun peu l'arranger à sa sauce.

Là par contre, le chacun, tu veux bien entendu parler des geeks :-p. M'enfin un geek est rarement ergonome, ça se saurait sinon :-p . L'ergonomie est un métier, et demande encore à l'heure actuelle beaucoup de recherche (surtout que c'est un domaine dépendant de beaucoup d'autres, comme les sciences cognitives)

>Bah pour noël je serais bien plus heureux de pouvoir modifier ce logiciel pourrie que d'avoir un iphone.

Tant mieux pour toi si tu as du temps à perdre.

>Au niveau ergonomie il est peut être bien, j'en sais rien puisque je ne l'ai pas utilisé, bah dans ce cas il suffira de reprendre les bonnes idées pour les porter ailleurs.

Pour arriver à faire au moins aussi bien qu'Apple, et surtout faire encore plus original (pour pas être étiqueté de simple pompeur), tu va avoir du boulot. énormément de boulot. Et surtout, le soft, ça fait pas tout, parce que si tu n'as pas un écran type iphone (capable de détecter plusieurs pointage en même temps), tu ne pourra jamais égaler l'iphone. Bref, le matos compte beaucoup, le succés de l'iphone tient tout autant du software que du hardware. (une interface ne se limite pas au graphisme, au logiciel : il y a aussi l'interface "physique").

Au début, j'étais septique comme toi, sur le pourquoi de cette folie sur l'iphone. Depuis que j'ai pu faire mumuse avec un iphone (mais j'en ai pas acheté), j'ai complètement changé d'avis, et franchement, ils ont vraiment fait un boulot extraordinaire en matière d'interface utilisateur, en matière d'experience utilisateur. L'iphone a donné un sacré coup de vieux aux autres OS de téléphones (et du coup, windows mobile ne parait plus être une merde, mais une mega super merde).

Enfin bref, ok il lui manque quelques trucs (3G etc), ok c'est pas libre, mais ça reste pour moi une révolution en terme de mobile. Ah la limite, je suis sûr que si Apple n'avait pas autant fait de pub et de marketing, ça n'aurait rien changé au succés de l'iphone.

Que tu le veuille ou non, *c'est* un produit génial.

PS : je ne suis pas un groupie de S. Jobs, ni un fan d'Apple, ni d'ailleurs propriétaire d'un produit Apple.

PS2: il ne faut pas prendre à la légère le phénomène iphone : il risque bien de changer la done sur l'avenir du web, en ce sens où il ouvre grand la porte pour l'accès au web, et que les concurrents, vont, à ne pas en douter le suivre (avec des écrans large, des browsers dernières génération &cie). Ceux qui ont pu suivre la conférence sur le web mobile du W3C à ParisWeb2007 ont pu avoir un résumé de ce que sera le web de demain ;-)

Apparemment faut être un fan inconditionnel détestant le web pour utiliser amigaos :-)

En effet, je trouve que le navigateur iBrowser a une interface très peu sexy^W^W^W à chier ( http://www.acube-systems.com/splash/os4_classic_7.jpg ou encore http://www.ibrowse-dev.net/documentation/images/gui_screen.p(...) ), mais surtout, il n'a même pas le support CSS ! (http://www.ibrowse-dev.net/faq.php#Q4). C'est sport pour surfer ;-)

Plus sérieusement, il n'y a pas d'autres navigateurs disponibles sur amiga, possédant un moteur de rendu plus moderne ? Éventuellement basé sur webkit/khtml, gecko ou autre ?

Ah non.. Pas besoin en fait... Ca peut pas être moi... Je ne suis pas admin système, et il y a longtemps que j'ai éradiqué son windows de sa machine...

Mais alors, qui ça peut être ?

>Ah, y en a beaucoup qui ont une copine?

Parait même qu'il y en a qui sont mariés.. Si si. Enfin moi en tout cas.

Mmm... Mince... Deux secondes, faut que je passe un coup de fil à ma femme...

Ta vision est certainement ce qui se passera. Mais peut être pourrait-on être plus optimiste : si j'ai bien compris, KDE 4 apporte pas mal de nouveautés en terme de fonctionnalités et de bibliothèques, qui sont normalement fait pour faciliter la vie des développeurs. Donc en théorie, une appli KDE4 est plus rapide à développer que pour KDE3 (en ce qui concerne l'interface et l'intégration dans le desktop j'entend). Donc il est possible que le portage des applis vers KDE4 aille assez vite, et qu'on se retrouve donc avec pas mal d'applis finalisées pour la 4.1.

Enfin bon, on verra si la réalité confirme ma théorie :-)