Philippe F a écrit 2214 commentaires

> Quelle est la spécificité de Microsoft qui fait qu'il sont obligés de sortir cela langue
> par langue ?

La specificite de Microsoft sur la gestion de l'internationalisation, c'est qu'ils n'ont rien. rien.

Les developpeurs bidouillent en general un truc qui fait que tu dois recompiler ton appli pour la traduire, qu'il y aura pratiquement a coup sur un segfault si ta chaine est plus longue que l'originale ("cancel" -> "annuler", boum!).

Recemment ma boite s'est retrouvee confrontee au probleme et ils ont finalement degote un outil developpe par un mec las du vide de traduction. C'est a des annees lumieres derriere gettext() mais ca permet de modifier des chaines hardcodees d'une application sans la recompiler. Pour eux, c'etait le miracle.

Pourtant, il n'y a pas de gestion de la mise-a-jour, pas de selection automatique de la langue, pas d'ajout automatique de traduction, pas de reajustement des arguments, pas de reference aux lignes de code au moment ou tu traduis, pas d'editeur de traduction, pas de gestion des conflits de raccoucis.

Quand je leur ai presente Qt, ils ont envisage d'utiliser Qt uniquement pour convertir les chaines a traduire. Mort de rire. Finalement, le prix de la licence les a un peu calme :-) et ils sont partis avec un truc valide par un mec, qui n'a meme pas regarde gettext().

Pour une fois, on est a des annees lumnieres devant microsoft en terme d'utilisabilite.

Reste encore que la page info de gettext() est loin d'etre accueillante, et il n'y a pas de page web te presentant les avantages et ce que tu faire avec gettext(). On peche vraiment en marketing cote logiciel libre. Je suis sur qu'avec une bonne page web, ils utiliseraient gettext() a l'heure actuelle.

J'ajouterai que tout produit developpe a une finalite a etre utilise, et souvent vendu. Le boulot du developpeur n'existe donc pas en soi mais existe dans une chaine. Grossierement: besoin -> developpement -> vente -> utilisation.

Oui il y a des commerciaux pourris qui meprisent les developpeurs (marchands de viandes ou marchands de vent). Mais il y a aussi des commerciaux tres bien, et il y a aussi des developpeurs qui s'imaginent qu'il n'y a rien d'autre que le developpement qui compte et refusent de s'integrer dans la chaine: ils negligent (voire meprisent) les besoins, la vente ou l'utilisateur. C'est tout aussi con que l'attitude du commercial.

Quand la chaine fonctionne bien, le developpeur explique au commercial ce que son produit peut faire et le commercial doit cerner les besoins, les points forts et les endroits a ameliorer, et gere le client. Un bon commercial va proteger son developpeur et a un bagage technique. C'est d'ailleurs souvent la que ca peche.

Alors que eux, ils sont pour le brevet parce qu'ils connaissent le logiciel :-)

Disons que on s'est vachement ameliore. Le logiciel libre avait un gros probleme du cote des logiciels de bureau, mais on est en train de combler le retard.

Cote kernel, il ne manquait guere que un journaling file system afin d'etre desktop-ready. Pour le reste, on a maintenant une infrastructure solide qui va nous permettre d'avancer vite: Gimp, Gtk, Gnome, Php, Qt, KDE, ...

Notamment, KDE remplit d'applications le desktop avec une vitesse proprement incroyable (oui, j'adore KDE).

Le fait que ce soit un marche emergent ou il y a tout a faire veut dire que tu peux te faire un max de thune si tu t'y prend bien. Je pense a ce sujet que TheKompany se positionne tres intelligemment, notamment avec une portabilite windows/unix/mac (merci Qt)l

Donc oui, on a ete lent mais on avance de plus en plus vite.

"Le moins que l'on puisse dire, c'est que quand le géant se sent menacé, il sait réagir vite."

C'est une des tres grandes qualites de Microsoft, qui fait que la boite est encore la. Ils font peut-etre de nombreuses erreurs, mais quand leur business est menace, ils savent tres tres bien reagir.

Ils ont loupe le debut du virage internet. Mais ils se sont vite ressaisis, et ont reussi a tuer netscape. :-(

On est pas pret de voir la fin de Microsoft, ca c'est sur. Enfin, nous aussi on sait reagir vite.

Ou tu as trouve cette syntaxe "site:" ?
Je n'ai rien vu de tel dans la recherche avance.

Il y a d'autres options cachees comme ca ?

> Bref... L'utilité d'excel sur un SE propriétaire ou aucun serveur SQL n'est disponible est certaine.
> Sur un SE libre, où l'on a le choix entre aux moins deux serveurs SQL, j'avoue moins comprendre l'intérêt d'un clone d'excel.

Je crois que tu ne saisis pas toutes les utilisations d'un tableur.

Excel permet avant tout de faire rapidement et simplement des calculs et de montrer les resultats sous forme de graphique. Alors que de mon point de vue (mais je ne suis pas expert), une base de donnee permet de faire d'abord des recoupements (les clients ayant achete XXX habitant YYY et tout ca) et ensuite de faire des operations quelconques sur ces recoupements: rapports, calculs, ...

La generation des rapports et calculs avec une base de donnee sera plus long a mettre en place mais sera plus puissante.

Par exemple ma derniere utilisation de Excel: ma boite gagne tant, elle paye 33% d'impots, je me reverse tant en dividendes imposes a x%, mon salaire est de tant, donc ca me fait tant d'impot au final et je dispose de z francs. Il y a 5 formules et une dizaine de nombres a rentrer et ca me donne un resultat. Je peux alors faire varier les parametres et voir ce que ca donne, voir faire une courbe.

Il me parait difficile de faire ca avec autant de facilite avec une base de donnee.

En revanche, si le cas devient plus complexe, par exemple que je m'interesse aux 12 clients de ma boite a qui j'ai vendu une dizaine de produits a des prix differents, et qui me payent avec un decalage, je vais probablement avoir interet a commencer une petite base de donnee de clients avec quelques parametres. Mais pour obtenir mes resultats, ca va tout de suite etre plus complique.

Donc oui, KSpread ou Gnumeric ont une tres grande utilite, meme sur un systeme d'exploitation libre.

Au passage, je me souviens d'un article ou un mec de Microsoft expliquait que tous les concurrents d'Excel n'ont pas decolles a cause d'une grosse erreur : ils ont cru que Excel etait un tableur et ils ont developpe un super tableur. En fait, une etude prouvait que 70% des gens utilisent Excel pour gerer des listes. Donc pour concurrencer Excel, il faut bien gerer les listes.

Notons que pour l'instant, je n'ai pas vu d'equivalent agreable a Ms Access pour Linux. Ne me pointez pas vers des moteurs de Base de donnee, ce n'est pas ca qui fait la force d'Access (c'est meme surement sa faiblesse). La force d'access, c'est qu'un debutant ou un programmeur moyen peut facilement se creer ses 10 tables et faire les formulaire qu'il faut pour les remplire et les afficher. Quand on reste juste dans l'optique "je veux un truc qui marche rapidement", c'est vraiment un plaisir a utiliser.

Bien sur, si on depasse la cinquantaine de tables, ou si on commence a se soucier des problemes de migrations, c'est plus du tout fun.

> Une bonne utilisation de Corba permettrait en théorie d'utiliser des objets KDE dans Gnome
> et vice-versa.

C'est ce que croient beaucoup de gens. Ce serait un rien plus facile avec Corba des deux cotes, mais ca ne resoud pas les problemes de fond pour avoir l'interoperabilite: des api et des fonctionnalites communes. A cote de ca, Corba ou pas Corba, c'est un detail. Pour l'instant, Gnome et KDE ont des trucs similaires, mais creer un pont entre les deux releve de la gagure, meme s'ils utilisaient tous les deux Corba.

En plus, KDE utilisait mico et Gnome utilisait Orbit. Je ne sais pas pourquoi mais ca posait de problemes. Le fait que l'un soit en C et l'autre en C++ avait aussi des consequences.

Et puis qui aurait developpe ce pont ? Probablement personne! Ca ne serait qu'un "cool hack" mais pas tres util. KDE a deja tous les composants dont il a besoin. Gnome n'en a pas beaucoup, mais il a presque les meme que KDE, donc il ne va pas aller chercher ceux de KDE.

Donc choisir Corba, ca aurait ete alourdir le desktop que pour des situation hypothetiques (composnants distribues, pont vers Bonobo) qui en pratique ne sont pas utilisees.

Bon, et en prime, je te donne une info: il est tout a fait possible d'avoir un composant Gnome sous KDE et vice versa. Il faut connaitre un peu Bonobo et connaitre un peu KDE (KPart et XPart) mais techniquement, il n'y a pas de problemes. Simplement, personne n'a envie de le faire pour l'instant.

Cet article n'est pas fini et doit etre publie bien plus tard. Grmmmblll, ca m'apprendra a laisser des trucs qui doivent pas etre publies en lecture.

Bon, le prochain article sera certainement une comparaison relativement detaillee de Corba et KParts.

> "we were afraid that if we GPLed Qt, someone with more development muscle would create a
> hostile fork of Qt and, in a sense, take over our only product"
>
> Doit-on comprendre qu'ils avaient peur que quelqu'un fasse mieux qu'eux et s'approprie le
> produit?

Ils avaient peur que quelqu'un s'approprie le produit oui. Je peux meme te citer un nom: RedHat.
Mais RedHat est parti pour Gtk. Harmony n'a jamais decolle. A partir de Qt2, ils n'ont pas arrete de progresser et il est devenu clair que personne ne maitriserait Qt mieux qu'eux. Donc ils sont passes a la GPL.

En revanche, je ne pense pas qu'ils aient jamais eu peur que quelqu'un fasse un meilleur Qt que le leur. Ils sont trop forts. Quand Eirik dit qu'il prend uniquement les meilleurs, il dit vrai.

Rappelons que meme sans etre GPL, Qt respectait deja les trois libertes du logiciel que garantit par la GPL. Donc la GPL, ca n'a ete que politique. Ce n'est pas l'interview (qui date d'un mois alors que Qt est en GPL depuis plus d'un an) qui y a change qqch.

pour des contributions a moi, c'est pas mal :-)))

Tu peux aussi utiliser un fichier pour gerer ton swap. Je crois que la page de man interessante est swapon. Et si je me souviens bien, ils disent que les performances sont pratiquement identiques a celle d'une partition swap.

J'y etais l'an dernier et j'en ai garde un super souvenir. Ca permet d'une part d'entendre parler de plein de projets, d'autre part, de discuter directement avec des auteurs de projets que vous aimez bien et de decouvrir des tas d'autres gens.

J'ai appris qqs trucs sur Hurd, j'ai decouvert Mosix, j'ai vu RasterMan (100% comme je l'imaginais) et decouvert Evas.

Tout a fait.

Il y a un "release schedule" (http://developer.kde.org/development-versions/kde-2.2.1-release-pla(...)) pour chaque release de KDE, qui specifie notamment quand la release doit etre officiellement announcee. Ceci afin:
- de permettre des tests dans la derniere semaine (on a vu des bugs decouverts et corriges le jeudi)
- donner du temps aux packageurs
- permettre aux miroirs de se mettre a jour
- ne pas mettre le ftp de KDE sur les genoux
- eviter d'avoir des gens qui se plaignent qu'il n'y a pas tous les package.

Donc ce serait bien que les moderateurs tiennent compte de ceci avant d'approuver une news (ce que font les moderateurs de slashdot).

.
.
.

Mea Culpa, il semble que d'une part le "release schedule" pour KDE 2.2.1 n'ait pas ete mis a jour, d'autre part, que la nouvelle date de release annoncee sur dot.kde.org soit du 17 septembre, ce qui rend la news valide.

Mais ca me semble louche que ca ne soit pas annonce sur dot.kde.org.

> - bricolage macroique, bof, pas tellement, en tout cas l'utilisateur de la librairie (i.e. le développeur) ne le vois pratiquement pas ;

bricolage macrotique ? Les seuls macros que le developpeur utilise dans Qt, c'est:
"slots" -> rien
"signal" -> "protected"
Q_OBJECT -> <on n'a pas besoin de le savoir>

Ca ressemble pas a un bricolage. Et tres vite, on a l'impression que les mot-cles "slots" et "signal" font partie du langage C++.

Ces mot-cles ne sont d'ailleurs utilises que dans le .h et pas dynamiquement. C'est leger et surtout extremement pratique d'avoir tout de declare dans le .h

Cet argument me parait donc encore plus contestable que les autres.

<troll-zone>
Alors que quand je touche a du code Gtk, je tremble a chaque fois que je vois une macro de cast, en imaginant tout ce qu'elle doit faire derriere. Sans compter les "return_if_fail" et autres bidouilles.

Les gens qui disent preferer Gtk parce que "Qt, c'est pas du C++!" me font doucement rigoler. Si un jour je veux absoluement faire du C, une chose est sure, je ne me tournerai pas vers Gtk car ca ne ressemble plus a du C. Ce ressemble plutot un clone hybride de C++.

Le top de VC++, c'est quand tu debuges et que tu tombes sur une ligne ou tu vois ton bug, qui sera executee dans trois instructions.

Tu corriges ton bug et tu appuies sur F10 (next). Et la, le miracle se produit devant tes yeux:

VC++ recompile automatiquement le fichier que tu viens de modifier, l'integre dans le nouvel executable, le charge en memoire, se transpose au meme endroit, de sorte que tu peux continuer a debugger tranquillement, comme si tu le code sans bug n'avait pas toujours ete la. C'est comme si tu travaillais avec un langage interprete.

Trop fort!!! Ca m'a scie. Dans 10 ans, peut-etre que gcc fera ca. Peut-etre.

Evidemment, ca ne doit pas pouvoir marcher dans tous les cas, mais pour l'instant, j'ai pas eu de problemes.

Je ne m'en suis toujours pas remis tellement c'est pratique.

> trouve au contraire que l'utilisation des GTK_WIDGET et autres macros rendent le code beaucoup plus lisibles

La je ne vois pas pourquoi ? Parce que c'est en majuscule ? En C++, tu peux aussi nommer tes classes en majuscule a ca deviendra aussi lisible!

> En GTK on sait à chaque fois exactement à quel niveau de l'héritage on se situe, et de quelle manière on utilise l'objet en question.

Je ne saisis pas comment le fait d'utiliser une macro te permet de savoir a quel niveau d'heritage tu es.

Et puis en C++, tu fais ca avec un simple cast, pas de soucis, le compilateur travaille pour toi. Pas besoin de "return_if_fail" et autres ajouts pas du tout leger de gtk.

En dehors du moc, qui est un peu surprenant au debut, je n'ai trouve aucun defaut a Qt depuis 2 ans que je l'utilise intensement.

Il me semble d'ailleurs que l'utilisation d'espaces de noms plus intensifs est prevu pour Qt3.

Et le modele memoire de Qt est vraiment tres pratique (a cote de celui de Gtk). C'est presque aussi agreable de coder en c++ avec Qt qu'en python. Alors en PyQt, je vous dis pas!!

Et berlios en Allemagne:
www.berlios.de
C'est proche de chez nous donc ca rame pas comme sourceforge

> GNU/Linux, parce que KDE, il pourrait très bien
> marcher avec un autre noyau !

Voire avec un autres OS, donc exit GNU. Pour info, KDE fonctionne tres bien sans un seul programme Gnu, cf la page de toutes les plate-formes et compilos suppportes (page que je ne retrouve plus, mea culpa).

<troll>
Perso, j'utilise KDE/Linux :-))
</troll>

Donc on dira jamais j'utilise Gnu/KDE !!!

> 100% des newbies Windozeurs découvrant Linux vont cliquer sur "Windoze" !

Oui, ils vont faire ca au debut. Mais il ne faut pas sous-estimer l'utilisateur. Beaucoup sont curieux. Une fois que l'utilisateur sera familier avec son environnement, qu'il n'aura plus peur des popup et qu'il arrivera a placer ses fenetres correctement, il va regarder ce qu'il peut faire pour amerliorer le look'n feel. Et la, il va gouter la configurabilite de KDE.

C'est ce qui ressort de l'installation de KDE dans la ville de Largo (cf dot.kde.org). Les utilisateurs apprecient de pouvoir bidouiller leur bureau. Mais il ne faut pas les forcer tout de suite.

Donc finalement, KDE a choisi la bonne demarche, comme toujours :-))

> il est relativement rare de trouver qqn de 20-25 ans ayant competence technique associees a
> d'autres competences plus administratives et/ou relationnelles.

Competences qui s'acquierent justement en general avec l'experience. Entre un mec de 25 ans et un mec de 40 ans, s'il y a une chose dont on peut etre sur, c'est que l'un a plus d'experience que l'autre. Experience en quoi et competences precises demandent ensuite a etre approfondi, evidemment.

Si tu as 25 ans et que tu as bosse 3 ans dans ta vie, toujours dans le meme job, dans une petite boite et que t'as fait un projet logiciel libre dans ta vie, c'est redhibitoire.

Si t'as 25 ans, que t'as cree une boite qui a marche, que tu as eu plusieurs boulots, que tu as deja manage une equipe ou fait du commercial, que tu as deja bosse dans une grosse administration, que t'as deja gere 5 projets logiciel libre dont un avec succes ou il y avait une equipe, ca passera a mon avis tres bien.

Bien sur, tout ca n'est que mon avis subjectif et personnel. Mais si je devais choisir un candidat, ce qui ferait la difference, ce n'est pas l'age mais l'experience. Donc faut pas seulement etre expert Gnu/Linux/Fsf/Kde/Freebsd/Gpl/python/perl pour etre expert. Faut avoir vecu.

Gecko dans Konqueror, c'etait surtout une "preuve de concept". Comme KDE s'est fait tres critique a l'abandon de Corba, quelques developpeurs ont voulu montrer qu'il etait possible, malgre l'abandon de Corba, de faire des choses tres puissantes avec l'architecture de composants de KDE, notamment d'utiliser des programmes qui ne dependent pas de KDE.

La technologie utilisee pour encastrer Gecko eu lieu de KHtml s'appelle XPart. Elle ne depend que de DCOP et de X (et de Qt de facon sous-jacente). DCOP etant completement independant de KDE, cela veut dire que cette technologie peut permettre d'encastrer n'importe quel programme dans n'importe quel autre a condition d'avoir sous la main les bibliotheque Qt, DCOP et X (cas relativement courant sur un systeme).

Notamment, il est possible de faire un pont entre les composants KDE et Bonobo par l'intermediaire de XPart. Si quelqu'un a le courage de s'y mettre...

Qt a toujours ete Open Source avec une licence qui permettait une libre utilisation, des modifs et la redistribution de modifs sour forme de patch avec l'original.

Dire que Qt n'etait pas libre, je trouve ca un peu rapide. Qt n'etait pas GPL. Mais qui decide de ce qui est libre ? RMS ? Les trois libertes fondamentales du logiciel decrites par RMS etaient notamment respectees.

En ce qui me concerne, un logiciel peut etre libre sans etre necessairement sous GPL.

> À nouveau le troc de la commodité contre la
> liberté. C'est la grande différence avec le projet Gnome.
A mon sens, la grande difference entre KDE et Gnome, c'est que KDE ne troc pas la qualite et la facilite de developpement pour quoi que ce soit, contrairement a Gnome.

On peut d'ailleurs dire la meme chose de Linux par rapport a Hurd. Hurd ne troc pas la liberte, mais on a un truc 30% moins rapide que Linux, qui a peu de chance de decoller. Mais oui, le "message passing", c'est mieux. Mais en attendant, Linux est la, et Hurd a plus de 5 ans de retard par rapport a sa date initiale de release.

KDE, tout comme Linux, a un role d'evangelisation du logiciel libre bien plus efficace que Hurd ou Gnome, alors que ceux-ci sont "plus" dans l'esprit du libre. Mais moins bien. Alors que KDE et Linux, ils sont la et ca marche.

Ben les mecs de KDE te diront que c'est de la faute de gcc et ceux de GCC que c'est c'est celle de KDE qui est mal ecrit. :-)

La press-release precise que KDE ne compile pas avec gcc 3. gcc 3 a encore trop de bug et casse la compatilbilite binaire. Il faudra attendre KDE 3.0 (janvier 2002) pour utiliser gcc 3.0

Il y a un fichier COMPILING dans kdelibs qui explique ca:

http://kdewebcvs.nebsllc.com/cgi-bin/cvsweb.cgi/kdelibs/COMPILING?r(...)