Godzil (./40) :
Heu... OpenGL, libxml2, libxslt, libZ, libm, libtcl, libssl, libexpat, libcrypto, libcups, libpam, libbz2, OpenAL, libicu, GLUT et plein d'autre que je passe... C'est proprio ça ? et bien sur monoplateforme ?

J'ai dit "en grande partie", pas entièrement. Je sais qu'il y a ces libs, mais elles:
1. ne sont pas suffisantes, par exemple le seul widget toolkit là dedans est Tcl/Tk qui laisse pas mal à désirer,
2. ne sont pas toujours compatibles avec les applications existantes, par exemple certaines de ces libs sont repackagées dans des frameworks, et Tcl/Tk est une version non-X11 qui n'est pas forcément compatible avec les applications écrites pour la version X11, c'est une des raisons pour lesquelles Fink et MacPorts remplacent certaines de ces libs,
3. ne sont souvent pas à jour (une autre raison de les remplacer), en général les mises à jour ne sont disponibles qu'avec les mises à jour de OS X, qui sont payantes.

Le plus grand problème dans OS X est qu'ils ont réinventé la roue pour leur interface graphique au lieu d'utiliser X11, ça crée des tonnes de problèmes. Leur excuse était que X11 "ne permet pas" leurs histoires d'effets de transparence etc., mais KWin 4.x et Compiz prouvent le contraire. Et X11 permet des choses que Aqua ne permet pas, par exemple la transparence réseau (ssh -X).

kim (./28) :
* les packageurs de gimp n'ont je crois jamais compris que créer un framework, ou simplement, faire un pkg qui installe un bout en sys, et le reste sur l'app, leur permettait de proposer des package standalone en meme temps que des packages d'upgrade...

Et l'utilisation de package permet aussi une desinstallation propre !

C'est clair, mais c'est pour ça qu'il faut un système de packages avec une résolution de dépendances!

Kevin Kofler (./31) :
Qt respecte le look&feel de la plateforme

Heu, réponse TRES courte : NON

Montre-moi des captures de Qt 4 / Mac (pas Qt/X11) et explique-moi où le look&feel n'est pas correct. (Et tant que tu y es, explique-le aussi à la division Qt Software de Nokia, comme ça ils le corrigeront. )

Kevin Kofler (./31) :
qui du coup va mal aller avec le KDE 3 utilisant X11

-> Voilà pourquoi il nous faut le portage KDE 4 (KTIGCC 2).
Mais il me faudra des personnes motivées pour tester le tout avec Qt/Mac et KDE/Mac!

Kevin Kofler (./31) :
Et l'argument de la place n'est pas aussi important sur un ordinateur

Heu, c'est pas toi qui 20 posts avant gueulais sur les applications qui font "plusieurs Go" ?

La solution n'est pas de ne pas utiliser les libs, mais de les partager entre toutes les applications qui les utilisent, avec la résolution et installation automatique des dépendances.

Ha oui ? Linux le fait ? Il me semblait que c'était une application, genre apt, yum, emerge...

Bizzare si c'est Linux (le kernel hein) qui fait ça, pourquoi c'est pas standardisé ?

J'ai dit "GNU/Linux", c'est-à-dire le système entier!

Et le problème est que OS X ne propose même pas une solution propriétaire pour la résolution des dépendances, il n'en propose aucune. (Et je lis des absurdités comme "c'est au packageur de le faire", c'est n'importe quoi, c'est une fonctionnalité essentielle pour faire de bons paquetages et ça ne marche correctement que si c'est géré centralement - si chaque packageur réinvente la roue, c'est mal parti pour partager les libs entre les paquetages faits par différentes personnes. De plus c'est une perte de temps de devoir faire ça à la main quand l'OS pourrait le faire.)

Franchement, arrête de dire des conneries plus grosse que l'Himalaya...

Lis ce que j'ai écrit avant de critiquer! GNU/Linux != Linux.

Kevin Kofler (./31) :
C'est un mythe

Du tout, il y a pas mal d'exemples du contraire...

Lesquels? Firefox? Ça utilise une lib d'abstraction (XUL) qui simule les widgets natifs, justement tu n'en veux pas de ces libs.

Demande à Romain de raconter son expérience avec le multi-frontends. Ce n'est pas maintenable à long terme, il est beaucoup plus efficace d'utiliser une solution multiplateforme comme Qt ou GTK+.