peau chat a écrit 577 commentaires

Pourquoi effectivement ne pas utiliser l'USB comme norme unique pour les périphériques à bas débit (souris, clavier, scanners...).

Mais tant qu'ils y sont, qu'il obligent aussi les contructeurs de périphérques USB à mettre 2 prises USB, une entrée *ET* une sortie, pour pouvoir chainer les périphériques comme c'était révu au début.

Ca nous évitera d'avoir à acheter des HUBS en pagaille, et d'avoir des kilomètres de cables emmêlés sous le bureau...

;-)

Ceci dit, tu as raison, j'ai tapé trop vite sans me relire, il manque quelques mots :

"Microsoft est obligé de parler de son concurrent (...)"

Microsoft est obligé de son concurrent, et essaye de se justifier.

Triple erreur :

- ceux qui ne connaissaient pas Apache et qui ne savait pas que le gartner group avaient fait cette recommandation sont désormais au courant.

- Les justifications prevenant de Microsoft même ne seront pas convaincantes car assimilées à un discour marketting.

- En politique, il y a une règle d'or : Quand on commence à se justifier et à expliquer ; on a perdu.

Ca depend de quoi il parle. S'il parle de KOffice 1.0 qui, il me semble, est livré par défaut avec MDK 8.0, je suis de son avis. Il est inutilisable. KWord 1.0 m'a été pratique pour taper un FAX, mais c'est tout. KOffice avait un énorme mérite : celui d'exister. Mais il aurait dû être numéroté 0.9

KOffice 1.1 est par contre superbe. KWord est réellement utilisable, KPresenter n'a pas à rougir de ses concurrents.

Ce qu'il manque : filtres d'importation/exportation en HTML. Ceux qui existent permettent de récupérer les données (c'est toujours ça de pris), mais pas les mises en forme.

Avec des filtres HTML améliorés, on y gagnerait un excellent éditeur HTML WYSIWYG : KWord.

Konqueror a fait bcp de progres, il est pas parfait, mais je le trouve supérieur à Mozilla.

En ce qui concerne KParts, je pense que le monsieur ne sait pas du tout de quoi il parle...

Cela n'aurait pas de sens, une distro ce n'est pas un noyeau.

On peut faire une nouvelle release de distro en gardant le même noyeau, mais avec un upgrade de KDE, de Apache, de htdig etc.

Une Mandrake 5.1 non (aucun sens).

Si, cela avait beaucoup de sens. Cela permettait à l'utilisateur de savoir avec quelle version de RH sa MDK était compatible, et donc de choisir les RPMs en conséquence.

À l'époque où je bossais chez intergraph (1991), on avait des stations system V pur de dur, on avait l'habitude de dire que le FFS se transformait en "very very slow FS" quand le dirk était presque plein.

C'est le meme FFS dont on parle ?

Le probleme existe-t-il toujours ??

chacun crée ses propres standards et que l'inter-communication en est rendue difficile

Euh... on rappelle quand même que sous KDE tu peux utiliser les composants GTK ainsi que Active-X. De plus, rien ne t'interdit d'utiliser corba dans une appli KDE (si tu en as vraiment besoin, c'est pas bien grave de devoir faire un truc qui rame et qui nécessite des 100aines de lignes de codes supplémentaires).

Alors au niveau interopérabilité... pour l'instant Gnome à carrément un TGV de retard.

Il n'empeche que RH a finit par mettre KDE 1.x avec Qt 1.x quand leurs parts de marchés s'envolaient.

La licence de Qt à toujours été la même jusqu'à la sortie de QT 2.0

Comme quoi... la licence était peut être inacceptable, mais il faut chercher ailleurs les réelles motivations de RH !

>bientot tu vas nous expliquer que toutes les
>distro utilisant la meme libc que debian sont
>basées sur la debian ??

Apprendre à lire ? Je n'ai *rien* dit allant en ce sens, et c'est une belle anerie, évitez de me l'attribuer.

Pourtant vous avez écrit :

"D'autre part, certains choix montrent qu'ils ne s'en détachent (gcc 2.96 -- à moins que tu m'apprennes qu'ils ont choisi le meme snapshot de gcc "par hasard" ?)."

Donc, apprenez à écrire...

Toutes les distribs en ont, ce n'est pas le fait d'etre flashy qui compte, mais la facilité à y ajouter des programmes conviviaux.

Rassurez-moi, vous ne connaissez Linux que depuis 6 mois ??
A cette époque, les outils d'installs étaient tout sauf flashy, ce n'étaient que de pauvres menus en mode texte. On partitionnait ses disques pendant l'install à coup de fdisk ...
Si les outils d'install de RedHat étaient frustres, ceux de la Debian 1.3 étaient carrément à l'age de pierre. C'était le Lascaux de la convivialité. Normal, ce n'était vraiment pas un priorité de développement à ce moment là.

Si Gael Duval avait pris une Debian comme base pour bricoler tout seul sa petite distro conviviale et facile à installer, Mandrake serait né après la fallite de Microsoft.

D'autre part, certains choix montrent qu'ils ne s'en détachent (gcc 2.96

bientot tu vas nous expliquer que toutes les distro utilisant la meme libc que debian sont basées sur la debian ??

Mandrake a fait énormément de travail pour la convivialité, se baser sur RH plutot que Debian n'a eu aucun intéret au final
On reprend l'histoire : la mandrake a été créée par un mec tout seul, dans son coint, bien avant que la société soit créée. Donc, si, choisir RH avait du sens, parce qu'elle disposait déjà d'outils d'intallation.

Il n'y était pas pour de bonnes raisons, et comme dans toutes les distribs, KDE a été mis dès que ça a été acceptable.

Là encore, vous réécrivez l'histoire. RH à mis KDE lorsque c'était devenu la seule distro (avec debian) à ne pas proposer KDE et que RH perdait trop de parts de marché face à Mandrake.
La premiere RedHat à proposer KDE (la 6.2 ??), proposait la version 1.1.1 ou 1.1.2 (je sais plus) de KDE, qui utilisait exactement la même licence que KDE 1.0...

Mandrake ... mais son choix de se baser sur RH n'est certainement pas motivé par ce prétendu besoin de convivialité (d'ailleurs ils ont réécrit beaucoup) mais c'est un choix purement économique visant les parts de marché

Un peu de grammaire française et d'histoire vont aider à désamorcer ce troll ... pardon ce FUD.

D'abord, un contributeur n'étant pas de mauvaise foi aurait utilisé l'imparfait : ...baser sur RH n'était certainement pas... En effet ça fait belle lurette que la Mandrake n'a plus rien à voir avec la RH (depuis la 7.0 il me semble).

Ensuite, il faudrait aussi voir à ne pas réécrire l'histoire. Les parts de marchés n'ont rien à voir avec le choix de la RedHat comme base de Mandrake. En effet, G.Duval à créé cette distribution bien avant d'avoir monté la moindre société, et bien avant d'avoir eu le moindre contact avec J.Le Marois.

Enfin, n'en déplaise aux Débianistes, à l'époque la RedHat était la distro la plus conviviale, et la plus simple à installer. KDE n'était pas inclus dans la RedHat pour les raisons que l'on sait. L'idée étant d'avoir une distro convivale avec KDE, G.Duval a donc naturellement pris la RedHat pour y ajouter un KDE préconfiguré, avant de le mettre en téléchargement sur un site FTP ... et de partir en vacances.

je parlais des rpm KDE pour mandrake...

non, virale (Marketting Viral)

Faut pas faire les updates.

Faut d'abord effacer les anciens RPM, puis installer les nouveaux.

Va comprendre ...

Je pars lundi faire un reportage pour un mag british dans un studio spécialisé dans les effets speciaux numériques (Taxi, alien 4, ...).

Ils sont globalement sous Unix (j'en saurais plus après le reportage ;-) ), et écrivent eux-même leurs softs en utilisant la lib Qt. Donc a priori, ils peuvent basculer sous linux vite fait...

Si, elle change pas mal de chose. Enormément de bugfixes sur Konqueror, notamment pour les formulaires et le javascript.

La documentation.

Les traductions.

Y a pas de classe "Qt".

Hmmm : http://doc.trolltech.com/2.3/qt.html(...)

"The Qt class is a namespace for miscellaneous identifiers..."

"Inherited by QBrush, QCanvasItem, QCustomMenuItem..."

Si c'est hérité, c'est une "classe" non ? :-)

C'est un cas très particulier, les top-levels (typiquement, QMainWindow

Typiquement aussi les boites de dialogues. Cela permet de les désinstancier de la mémoire lorsque la boite est fermée. Dans les programmes qui gonflent en mémoire, il y a souvent des problemes de boites de dialogues non désinstanciées.

On dira ce qu'on voudra, je trouve que :

ctree.setColumnWidth(...) c'es plus simple que :

gtk_clist_set_column_width(GTK_CLIST(ctree), ...)

Pourquoi devrait-on avoir besoin de savoir que c'est dans la "classe" clist que se trouve la méthode set_column_width ? Le principal est de savoir qu'elle est disponible dans un ctree non ?

En plus je te dis pas la redondance sur la même ligne de code :

gtk_clist_set_column_width(GTK_CLIST(ctree), ...)

si on se passe des deletes, le prg enfle rapidement en memoire

Je te conseille de jeter un oeil à la documentation Qt, et consulter la classe "Qt". En particulier, regarde l'utilisation du flag "WDestructiveClose".

Non non, je ne confonds rien du tout :-)

Je veux dire par "mécanisme d'héritage" que si le codeur n'a pas besoin de se cogner les delete à la man, c'est parce qu'il y a un ancêtre à son objet qui, dans son destructeur, contient déjà le code qui le fait.

Je voulais surtout signaler que dans le cas de Qt, la libération mémoire se fait par un tout bête "delete object", alors que dans un GC, on doit implémenter des trucs du genre :

getReference(Object)
{
memList[Object].references++;
return memList[Object].pointer;
}

releaseReference(Object)
{
memList[Object].references--;
if (!memList[Object].reference)
{
delete memList[Object].pointer;
removeObjectFromMemList(Object);
}
}

... et tout ça en priant pour qu'à aucun moment le codeur n'ai dupliqué une référence, par exemple en oubliant de surcharger un opérateur d'affectation ...

Bref, en raccourci pour faire simple, dans un cas on gère des pointeurs, dans l'autre des handles.

Il y a une différence fondamentale en un GC et le mécanisme de Qt.

Un GC, est une entité unique qui gère les allocations mémoires, et les suppressions de références dur les objets afin de les desinstancier quand ils ne sont plus references.

Dans Qt, c'est tout betement un mécanisme d'héritage. Le destructeur d'un objet Qt contient déjà le code consistant à désallouer les objets qui ont été instanciés dans l'objet qui est détruit. C'est du code tout bête avec du delete qui est transmis par héritage. Chaque objet désalloue la mémoire qui dépend de lui. Ce n'est pas un mécanisme centralisé comme un GC.

Justement, n'est ce pas mauvais signe quand on a besoin de savoir à quel niveau d'héritage on se trouve ?

>c'est fait automatiquement par QApplication

comment ça se passe tout ça ?

C'est surtout faux, ou très mal exprimé. Ce n'est pas QApplication qui gère cela mais QObject.

En fait, quand tu instancies un QObject (qui est la classe ancêtre de toutes les autres classes Qt, ou presque), tu fournis en premier paramètre un QObject * parent=0.

Dans le constructeur de QObject, si le *parent est renseigné, alors le parent va être informé qu'il a un "fils" et il va l'ajouter dans une liste.

Lorsqu'un objet d'une classe dérivée de QObject est désinstanciée avec un delete, le destructeur va parcourir la liste de tous les objets fils afin de faire un delete sur chacun d'entre eux.

2 remarques :

* Pourquoi critiquer ce fonctionnement ? Lorsqu'on supprime un père, il faut bien supprimer les fils non ? Alors pourquoi se plaindre du fait que le codeur n'ai pas besoin de pisser systématiquement ces lignes de codes ?

* Si tu t'amuses à instancier tes object sans fournir de *parent , tu auras la joie de devoir tout désinstancier à la main et d'écrire des lignes de codes inutiles...

C'est bien ce que je dis alors :)

Tout va pour le mieux alors :-)

Mais pensenz quand même à faire signer un contrat de cession de droits pour la publication sur le magazine et le site web, même aux "contrinuteurs" qui ne demandent pas de rémunération.

On est jamais trop prudent... autant être clean d'un point de vue légal. Et ça laisse plus de latitude pour éventuellement poursuivre les contrefacteurs :-)