net, de mon point de vue, est une solution propriétaire née suite à un désaccord entre deux grands acteurs de l'informatique contemporaine.
Ce dont je te parle, c'est du modèle technique pour appeler des libs natives depuis la machine virtuelle implémentée dans .NET. C'est spécifié, standardisé et normalisé ISO.
Qt est portable, je ne crois pas que ce soit discutable (?)
la critique sous-jacente, c'est les API C++. Binairement, des API C++ ne sont pas portable d'un compilateur à l'autre, alors ne parlons même pas d'une plateforme à l'autre. C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.
mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.
Si les solutions que propose Nokia ne s'appliquent pas à Mono, c'est que Mono se contente d'implémenter .NET, et pas les briques non portables qu'ils proposent d'utiliser : COM ou C++/CLI.
Et c'est le même problème pour tous les langages, pas seulement Mono, en Python on peut attaquer un composant COM, donc celui de Qt, et c'est exactement le même problème : ca ne tournera que sous Windows. C'est pas pour rien que PyQt existe de la même manière qu'il y a Qyoto.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à -1.
Ce dont je te parle, c'est du modèle technique pour appeler des libs natives depuis la machine virtuelle implémentée dans .NET. C'est spécifié, standardisé et normalisé ISO.
Qt est portable, je ne crois pas que ce soit discutable (?)
la critique sous-jacente, c'est les API C++. Binairement, des API C++ ne sont pas portable d'un compilateur à l'autre, alors ne parlons même pas d'une plateforme à l'autre. C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.
mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.
Si les solutions que propose Nokia ne s'appliquent pas à Mono, c'est que Mono se contente d'implémenter .NET, et pas les briques non portables qu'ils proposent d'utiliser : COM ou C++/CLI.
Et c'est le même problème pour tous les langages, pas seulement Mono, en Python on peut attaquer un composant COM, donc celui de Qt, et c'est exactement le même problème : ca ne tournera que sous Windows. C'est pas pour rien que PyQt existe de la même manière qu'il y a Qyoto.