Philippe F a écrit 2204 commentaires

L'article explique tous les travers des cadres mais ne donne aucune indication sur leur remplacement possible.

<<
Parmi ces alternatives, notons les inclusions de fichiers rendues possibles
par le recours aux langages de programmation et une prise de conscience de l'importance du respect de la sémantique Web.
>>

Donc en gros, pour eviter les cadres, il faut programmer. Ce qui rejoint l'idee du monsieur plus haut, si on est tres modeste web designer, il n'y a pas d'autre alternative que les cadres pour fournir une navigation simple.

Si c'est le cas, merci d'ecrire a l'auteur de l'article d'openweb parce que ca manque grave! Et ca m'interesse aussi parce que generer des index en python sur toutes mes pages, c'est lassant.

Il serait interessant d'integrer egalement dans la reflexion les syntaxes de convertisseurs txt-> html/docbook/cocumentation.

Je n'ai plus les liens sous la main, mais il y a au moins doxygen, perldoc, http://txt2docbook.sourceforge.net/doc.html#N110,(...) un tres bien pour la doc de python que j'ai perdu, et deux ou trois pas mal qu'on trouve sous freshmeat.

Je confirme: ma copine utilise MSN pour discuter avec ses parente en Chine. Ils se trouvent d'abord sur MSN et ensuite passent en mode video. Je ne sais pas si par derriere, il lance un bete netmeeting, mais niveau facilite d'utilisation (et verouillage de l'utilisateur), c'est impressionnant.

A quand gnomemeeting integre dans un client im gnome ? Ca, ca assurerait! C'est pour faire ce genre de killer-app que Gnome et KDE depassent la notion d'application pour atteindre celle de composant graphique.

C'est quoi l'interet de faire a la fois une version Gtk et une verison Qt ? De doubler le temps de developpement ? De doubler le nombre de bug ? De couper les resources en 2 ?

Encore un projet de looser, a ranger avec les editeurs de textes a la con, les bibliotheques pour developper des jeux, et autres projets presents en 300 000 exemplaires sur freshmeat.

Tu peux preciser ? Je saisis pas bien comment tu veux faire.

J'ai l'impression que tu as mal compris le truc. Il s'agit de lancer sur la meme machine un serveur et trois clients, et de pouvoir les tuer facilement ensuite. Je vois pas trop ou ssh interviendrait ici (surtout que c'est des applis graphiques que je lance).

Sinon, il parait qu'on peut faire la meme chose avec gnome-terminal, a coup de ligne de commande. C'est un truc du genre (j'ai pas la doc sous la main, donc a vous d'adapter):

gnome-terminal --command='./camino --server --$players' --tab --command='./camino --player phil' --tab --command='./camino --player bob'

Moi, ce qui me manque (alors que je l'ai sous Visual), c'est la possiblite de remplacer un mot de cette facon. En gros, je suis sur un mot et je veux le remplacer par autre chose. J'ai la flemme de taper tout mon mot dans le s/

Sinon, il y a plein de trucs sympa en effet sur les tips de www.vim.org. Celui qui m'a troue le cul: list-methods.vim qui vous fait carrement un ide potable a partir d'un vim quelconque.

Si ils ont un mega-chaine automatisee de mon cul qui installe windows et fait 3000 000 tests, elle doit pouvoir terminer son travail par un petit formatage du disque dur.

Et puis l'argument comme quoi windows est fonctionnel est pas tout a fait juste au vue de mon experience: je viens d'acheter un portable avec XP. Si je n'active pas windows sous 30 jours, il m'arrivera des malheurs (j'aurai pas du l'activer et voir ce qui se passe).

Donc concretement, pour utiliser mon ordinateur, je dois faire une procedure d'activation. Il serait donc tout a fait possible au quidam qui a achete son ordinateur mais qui ne veut pas payer windows de l'empecher de s'activer. Ainsi, au bout d'un mois, paf, plus de windows. Ca ferait comme une version demo. Microsoft serait meme content puisque ceux qui veulent pas windows l'auraient quand meme en essaie, des fois qu'ils soient tentes au dernier moment de changer.

Conclusion: des solutions techniques existent, si on se donne la peine de les chercher. Les arguments comme quoi ca coute plus cher au constructeur ne sont pas valides. S'il n'est pas capable d'assumer la loi, il n'a pas a faire de business.

Va pour windows, mais quid des PC avec Encarta, Office + le jeu machin chose + acrobat + gna gna gna ?

La, il n'y a rien a contester, c'est logiciels sont des extra qui ne rendent pas l'ordinateur plus fonctionnel.

ProFTPD, c'est pas la passoire que certaines distrib ont vire tellement ils en avait marre des trous de securite ?

il y a tout ce qu'il faut dans cups et kprinter. Je peux meme faire des choses dont je n'avais pas idees auparavant, qui sont payantes sous windows.

C'est tres simple, RedHat externalise ses resources de developpements vers la communaute pour se concentrer sur le fric. :-)

Mine de rien, c'est une bonne strategie. Ils esperent aussi probablement regagner des places en tant que distro grand utilisateur. Enfin, a pense qu'ils en ont perdu.

Qui fait tourner une RedHat pour le plaisir ici ? Perso, j'en vois pas l'interet:
- tes fan de compilation et de custojmisation: gentoo ou slackware
- t'es fan de je-fais-rien-et-ca-marche-tout-seul meme pour ma grand-mrere: Mandrake
- t'es fan de c-est-libres-a-mort-et-on-fait-pas-de-concession: debian.

Concretement, hors environemment professionnel, je ne vois pas de raisons d'utiliser une RedHat

KDE aussi essaye de delayer certains services tout en rendant quand meme l'interface le plus disponible possible.

Je sais qu'au moment de KDE 2, ils s'etaient tues les meninges pour trouver quoi enlever et comment faire pour le lancer plus vite sans rien retirer.

Vous allez vous marrer:

j'ai des problemes de refroidissement sur mon bi-pro, il a tendance a freezer a cause de la montee en temperature quand je compile un paquet (vive les gentoo).

Donc, je cherche des trucs pour diminuer les vitesses de compilation :-)
Apres etre passe en -j1 sur un bi-pro, pour que un processeurs se repose quand l'autre travaille, j'envisage un hdparm optimise pour etre plus lent!

Peut-etre qu'on aura enfin un packaging propre pour KDE. Mais non, je m'egare, il s'agit de RedHat, il ne faut pas rever.

Ca va etre encore pire a mon avis, puisque justement, sa machine pedale en memoire. Le probleme, c'est que ZoneAlarm (firewall) + msn + machin + bidule + utilitaire pour le clavier en chnois + outlook + mozilla + windows XP + word , ca fait trop pour la petite machine qui est pourtant loin d'etre un escargot.

D'ailleurs, la lenteur n'est pas seulement au moment ou elle le lance, c'est aussi au niveau de l'affichage, quand elle switch d'application. Faut dire que je lui ai colle mozilla, qui est a mon avis une tres mauvaise idee car il a tendance a ouvrir facilement beaucoup de fenetres. Je vais retenter avec FireBird.

Notons que chez moi, j'ai note que firebird est aussi tres lent au niveau de l'affichage des pages (pas du rendu, de l'affichage).

Pour le coup de la barre de recherche, c'est que je voudrai que par defaut, ce soit google. Or par default, il me fait une recherche dans la page.

Pour ce qui est de XML, XUL et tout ca, certe c'est bien mais c'etait possible de produire un bon browser sans developper _tout_ au prealable. Normalement, on devrait etre capable de faire evoluer le framework et les clients en meme temps.

Ca m'etonnerait que ca passe avec une conversation telephonique a trois enregistree sur un balladeur mp3 et convertie en ogg.

Donc, toujours pas de volontaires ? snif. A part Pascal evidemement.

khtml est relativement independant de KDE, preuve en est qu'il a ete porte sous Atheos, BeOs ou pour MacOs (Safari).

Je ne retrouve plus le lien mais quelqu'un etait en train d'isoler la partie de khtml qui depend de qt/kde dans une bibliotheque, de facon a pouvoir le porter encore plus facilement. Pour info, c'est ce qu'a fait apple avec safari.

Sinon, tu peux jouer avec un gtksocketplug et qxembed pour embedder un widget kde dans une appli gtk. J'ai deja fait l'inverse (gvim dans un widget kde, cf le projet kvim) et ca marche pas trop mal.

J'ai lu le source, car c'est toujours la qu'on trouve l'information vraiment a jour:
http://cvs.gnome.org/lxr/source/gnome-terminal/src/terminal.c(...)

Ce qu'il en ressort, c'est qu'il faut faire:
gnome-terminal --window --execute "ssh blah" --tab --execute "ssh bleh" --tab --execute "ssh bloh"

Le grosse difference par rapport a KDE, c'est que on peut controler un terminal au moment ou on le lance, mais il n'est pas possible de controler un terminal une fois qu'il est lance.

Pour etre honnete, dans cet exemple precis, je ne vois pas bien de situation ou on pourrait vouloir modifier un terminal existant en lui rajoutant des sessions ssh.

Cependant, cet exemple illustre bien mon point sur le technos KDE et Gnome:

- gnome-terminal n'utilise pas de technos particuliere et on est restreint a passer des arguments en ligne de commande. Il faut ecrire pas mal de code pour parser la ligne de commande.

- konsole utilise la techno dcop et expose ainsi un certain nombre de methodes. Tout ce qu'il a fallu rajouter au code pour permettre ca, c'est la definition d'une "interface" :

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/konsole/konsole/ko(...)

Les methodes qui sont listees ici sont les methodes utilisees de facon interne par konsole pour gerer ses sessions et fenetres.

C'est en rendant l'utilisation de ses technos avancees aussi simple que KDE prend a mon avis un leadership technologique.

> Y'a eu beaucoup de changements lors du passage Glib/GTK -> Glib2/GTK2.
> Maintenant les API sont beaucoup plus régulières et une trés grande part du wrapping peut se faire automatiquement.

Je ne suis pas sur que les binding aient déjà switché vers le nouveau système.

Aller, puisqu'on dit que je suis trop trolleur avec Gnome, je vais vous parler des défauts de KDE:
- il y a un binding python maintenu en dehors de KDE
- en théorie, il y a un binding java qui est généré automatiquement mais il n'est pas utilisé et ne marche jamais
- un binding ruby a été généré en one-shot mais il n'est pas maintenu (à ma connaissance)
- il y a le super système développé par David pour les binding perl, pour automatiser la génération des bindings mais je ne pense pas qu'il soit utilisé
- il y a un binding c-sharp mais là encore, je ne sais pas où il en est et je ne crois pas qu'il utilise le truc de David

Bref, c'est le bordel et la situation est loin d'être fantastique. Le seul truc bien, c'est que les binding Qt et KDE sont en général nickel.


> > While producing a wrapper for C++ is initially harder, once you > > have done it, you can automate most of the task.

> je vois pas pourquoi ça serait plus facile qu'en C.

Parce que le C++ donne un certain nombre d'informations dans sa syntaxe:
- quels sont le membres publics ou privés
- quels sont les constructeurs ou les desctruteurs
- y a-t-il un rapport d'héritage avec une autre classe
- certains fonctions doivent pouvoir être surchargées

C'est typiquement ce genre de problème qui est difficile à gérer.

> C'est l'avantage de bonobo. Si un composant plate, l'appli reste
> utilisable (avec une fonctionnalitée en moins).

En général, l'appli n'est pas très utilisable sans son composant. Mais pense au cas inverse, où l'appli plante mais le composant continue à tourner en arrière plan comme un malade.

Ce genre de truc est une horreur à debugger. KDE en a souffert et ca les a motivé a passer a kpart. Gnome en a souffert aussi (décolé, j'ai plus les liens mais on trouve qqs references dans les gnome foundation meeting)

Mon impression, c'est que il y a une très petite minorité de developpeurs cons ou problématiques (Neil et Mosfet par exemple) et une très grande majorité de développeurs intelligents, réfléchis, qui discutent argumentent et comme tu le dis, calme le jeu. Par exemple, j'ai un immense respect pour Waldo Bastian qui fait toujours des interventions justes.

> Par contre il y a un "troupeau" de supportaire inconditionnel qui ne veux pas prendre 3 mm de recul.

Il faut dire que Red Hat a un passé très très chargé avec KDE:
- FUD sur les premières licences de Qt
- refus de distribuer les premiers KDE
- pas de packaging des release KDE en dehors des release RedHat
- des bugs qui rendent KDE inutilisable en autre chose qu'anglais
- des modifications qui font que l'utilisateur qui suit la documentation n'arrive pas à faire fonctionner son matériel (KDE)
- un commercial qui propose un stand à KDE à une expo linux et ensuite nous envoie chier comme des malpropres.
- renommage en série de pleins de composants du Kontrol Center, ce qui les rendait potentiellement incompatible avec une appli exterieure voulant les utiliser
- suppression du 'About KDE' qui, s'il est légal, n'est certainement pas très apprécié.
- développement d'un <<faux KDE>>, c'est à dire un panel avec les icones KDE mais où aucun des programmes lancé n'est KDE.

Et plein d'autres petites broutilles. Donc à chaque fois qu'on parle de RedHat, tout le monde sur KDE se méfie. Si on pouvait éviter de packager KDE pour RedHat, je pense qu'on le ferai. Malheureusement, ils ont tout le marché d'amérique du nord. Une chose est claire en tout cas, les utilisateurs de KDE sous RedHat utilisent en général une sous-version.

Pour ce qui est des mecs de Gnome, j'ai pas beaucoup aimé l'attitude de pas mal d'entre eux au moment des flameware et autres soucis des release de Gnome. Mais je ne pourrai pas vous donner de noms.

Pour la saisie du chinois, c'est vraiment compliqué. De ce que j'ai compris, il faut quatre touches pour former un caractère. Chaque touche doit donc représenter une composante.

Je vais soulever le problème de la saisie des langues asiatiques, on verra bien si il y a des réponses.