Carbon : un demi echec ?

[locyrille]

Le API carbon, lorsqu'elles ont été présentées, avaient deux caractéristiques : faciliter le portage vers Mac OS X ET permettre une compatibilité ascendante. Sur ce deuxième point cela semble être un echec, et la politique logiciel d'Apple semble en être la preuve : plutôt que de nous fournir un seul logiciel carbonisé, on a droit à des versions spécifiques pour X : itunes, imovie, apple works. Pour ce dernier, cela semble être un minimum quand on voit à quel point la version 6.0.4 (pourtant carbonisée) marche mal sous OS X (j'arrive même plus à enregistrer un fichier), et même dans l'environnement classic.
En fait, tous les éditeurs semblent se diriger vers des versions spécifiques pour OS X, même lorsqu'ils utilisent Carbon.
Pensez vous que c'est par facilité, ou bien la compatibilité avec OS 9 n'a t elle été que de la poudre aux yeux de la part d'Apple ?

 

[PowerMike]

En fait, je sais pas trop ...

Je pense que si c'est bien fait, ça devrait pas poser de problème ... en fait en théorie Carbon doit marcher sur Mac OS 9 comme sur MacOS X ... Ça c'est pour les applications qui esxistaient sous Classic et qu'on veut faire marcher sous OS X aussi .. mais effectivement rien n'empêche avec Carbon de ne faire qu'une appli conçue pour MacOS X.

Puisque Carbon est dispo pour les deux OS, on peut très bien choisir de ne développer que pour OS X et de toute façon ça semble logique de vouloit programmer pour le nouveau système.

Je crois aussi que c'est parce qu'il y a pas trop le choix. Soit tu fais du Cabron avec du C++ .... pour OS X soit tu fais du Cocoa mais là faut connaître soit Java soit Obj-C et pour ceuw qui ont déjà qq lignes de codes prévues pour OS 9 c'est plus pratique.

 

[comgil]

Effectiement, Carbon n'est pas "magique".

En fait Carbon est un outil pour faciliter la transition à OSX. Si on a les moyens de faire plusieurs versions d'une même application (une classic et une carbon pour OSX uniquement), on peut le faire, et cela vaut mieux car il y a des spécificités dans OSX qui valent la peine de réécrire une partie du code. En particulier, le multitâche DANS les applications. En effet, les applications Carbon d'aujourd'hui on tendance à garder les vieux mécanismes d'OS9, c'est à dire d'attendre la fin d'événements avant de continuer un événement en cours (comme le résultat d'une commande de menu).

Si un développeur veut à tout pris avoir une application qui fonctionne sous OS9, et OSX, il peut le faire avec carbon. S'il veut faire rapidement une application qui fonctionne seulement sous OSX à partir de code existant, il peut aussi travailler en Carbon.

Faire cohexister 2 systèmes pour une seule application est difficile et prend certainement plus de temps lors de la mise au point.

Pour AppleWorks, il faut savoir quand même qu'il a été développé avec les tous premiers jets de la CarbonLib, qui a beaucoup évoluée depuis.

Mais ce n'est pas une excuse pour Apple qui aurait pu faire de Carbon un outil encore plus performant, mais ce n'est pas le cas. Cependant, aujourd'hui OSX est une réalité, et les applications peuvent se baser sur ce qu'il y dans cet OS pour travailler plus sérieusement.
Qui vivra verra !

 

[Manu]

En fait Carbon en plus de nettoyer les apis de la toolbox introduit des concepts nouveaux regroupés dans les Core Services qui sont en grande partie les apis cocoa (Foundation Kit) présentées sous une forme plus simple en C et appelée 'opaque types'. Cela permet aux applis carbon de bénéficier des fonctions puissantes de cocoa.

Carboniser une appli c'est pas seulement la passer dans une moulinette. Une appli bien carbonisée est une appli mieux organisée pour prendre en compte le comportement du système ainsi que les nouvelles possibilités offertes par l'OS.

Ce qui en revanche change CONSIDERABLEMENT c'est le packaging des applis. En effet sous OS X Apple conseille aux développeurs de créer des 'disk images' pour que les utilisateurs se passent des installer. Sous OS X les applis s'installeront par simple drag'n drop. Ainsi tu peux déposer ton appli directement du cd au dock par exemple. L'intérêt ? C'est qu'une appli peut être facilement transportable ou s'exécuter directement à partir d'un serveur. ce qui est génial dans un monde ou règne le RESEAU.

A+