| french | english |
 |
|
| Créer un compte | |
| 03-04-08 / 23:30 : Adobe, 64 bits et CS4 : réécriture en Cocoa (cjed) |
| Adobe a annoncé que la version 64 bits pour mac de CS4 (en cours de développement) sortirait après la version Windows, du fait de l'abandon par Apple du support de Carbon 64 bits dans XCode. Le logiciel devra donc être complètement réécrit, en Cocoa (seul à supporter le 64 bits à présent), chose que les développeurs avaient refusé en 1996 lors de la présentation de la Yellow Box de Rhapsody (APIs NextStep pour MacOSX Server et Windows, renommées et enrichies en Cocoa à la sortie de MacOSX 10.0 client début 2001), ce qui avait conduit à MacOSX client et au framework Carbon, (correspond aux APIs MacOS9 mises à niveau - une partie des instructions de la ToolBox supprimées, les autres modifiées pour être réentrantes). Cependant Adobe a disposé d'une dizaine d'années pour s'y préparer, et Apple a clairement indiqué depuis 3 ans que le futur était aux développements Cocoa. D'ailleurs Lightrooom (beta 2 actuellement) d'Adobe est écrit en Cocoa... et supporte donc déjà le 64 bits (mais il s'agit d'un nouveau logiciel). Il faut également considérer qu'une mise à niveau du code Carbon de CS3 en code Carbon compatible 64 bits aurait déjà necessité une réécriture très importante. Globalement les éditeurs multi-plateforme intègrent rarement les technologies propres aux sytèmes cibles, et se contentent de développer des couches d'abstraction basées sur des appels d'APIs procédurales, chose impossible avec un framework complètement orienté objet comme Cocoa (et une gestion des événements avec système de messagerie - purement objet donc -, la ResponderChain de Cocoa). D'un certain côté donc le retard des MFC Windows en termes d'architecture et concepts (simples APIs procédurales, avec très peu de concepts objets) freine l'avancée des applications mac (au départ cependant - début des années 90 - Photoshop et Illustrator n'existaient que sur mac.... certes en utilisant les APIs procédurales du Système 7). Une solution alternative (hors gestion de l'interface graphique - qui nécessite de passer par Interface Builder et la responder chain -, et donc par l'AppKit) serait d'utiliser les APIs CoreFoundation de Cocoa, versions procédurales des fonctionnalités des objets du framework Cocoa (Foundation Kit). C'est d'ailleurs peut être tout simplement ce qu'Adobe va faire, car une réécriture en utilisant tous les paradigmes objets de Cocoa nécessiterait plusieurs années (même si le développement Cocoa est bien plus rapide que le développement procédural). Cela est à modérer par le fait qu'un logiciel de retouche d'image utilise - hormis l'interface - des fonctions (filtres, etc.) qui sont typiquement du code C, qui n'a pas à être porté (appelable depuis Objective-C, de même que le C++). Cependant si Adobe se décide à remplacer ces appels par des APIs des frameworks récents de Cocoa (ImageKit, etc.), la réécriture sera plus importante (mais on peut douter qu'ils fassent cet effort, d'autant plus que la synchronisation avec la version Windows serait rendue encore plus difficile). Quelques liens intéressants (infos qui ne sont plus forcément toutes valides) : Discussion au sujet du Carbon White Paper d'Apple (annonçait en 1998 les orientations au sujet de Carbon/MacOSX : instructions ToolBox abandonnées, etc.) Cocoa or Carbon ? (mai 2000, juste avant la Public Beta de MacOSX) Carbon vs Cocoa (forum AppleInsider de 2002) it is possible for a Carbon app to be better threaded than a Cocoa app. Much of Cocoa's AppKit is not reentrant (meaning that it's not safe to make calls to the same method within multiple threads at once), and as a result there is an awkward arrangement built into the application frameworks where only one thread draws into the view (the window, essentially), and this thread also contains the main event loop. This is why Cocoa windows stop rendering when you hold the mouse down on the scrollbar thumb (but only that window stops updating, not the whole app or the whole system). It's quite possible to make a Carbon app that doesn't exhibit that behavior.) Cocoa vs Carbon (2002) Synthèse sur Carbon (en 2000). Les choses sont en fait assez compliquées : pour la sortie de MacOSX (et encore plusieurs années après), comme évoqué Apple a du porter ses efforts principalement sur Carbon, et on trouvait même des APIs nouvelles utilisables uniquement depuis Carbon (wrappées progressivement par des objets Cocoa - du fait qu'Objective-C peut appeler du C et C++ -, donc pas natives Cocoa - ie pas dans les APIs procédurales CoreFoundation). Le Finder de MacOSX a été développé à partir de morceaux de code du Finder du Système 8/9 (lorsque les APIs utilisées étaient disponibles sous Carbon), en fait le code réutilisé utilisait le framework PowerPlant de Metrowerks, encore un autre jeu d'APIs à considérer (migrer et valider pour Carbon). Depuis quelques années le Finder est réécrit progressivement en Cocoa, notamment dans Leopard (nouveau Finder). Parallèlement les nouvelles APIs sont intégrées dans des objets Cocoa uniquement, et Carbon évolue beaucoup moins. Enfin Apple semble avoir trouvé une voie intéressante pour promouvoir Cocoa, puisque Safari et iTunes pour Windows (et probablement d'autres applications Apple à venir) utilisent les APIs CoreFoundation, portées sous Windows (récupérées de la YellowBox). Et puis heureusement, grâce à Google (GWT), on n'aura bientôt plus que de superbes applications utilisant un superbe langage objet et réentrant, javascript !!!! :):):). Bien que la programmation soit effectuée en java avec GWT, le moteur de transformation en javascript reste propriétaire à Google, le javascript est limité en possibilités et sera toujours plus lent (car interprété, au sein d'un navigateur internet). L'ajout de fonctions d'écriture sur disque (Gears) à la suite Google Docs pose par ailleurs des questions sur la sécurité de ces applications (voir aussi ce site inquiétant sur Google). |
| Commentaires |
| Poster un commentaire |