Cocotron : porter son application Cocoa sur Windows
Cela fait un certain temps déjà que nous voulions vous parler de Cocotron, mais, jusqu'à présent, l'occasion ne s'est jamais présentée. Initialement, la grande force de la Yellow Box (l'ancêtre de Cocoa), c'était sa portabilité. Elle permettait aux développeurs de faire fonctionner des logiciels aussi bien sous Windows, Sun Solaris, HP/Unix ainsi que sous Rhapsody (qui était le nom donné à Apple à son système en cours de développement et qui prit par la suite le nom de Mac OS X) sans devoir tout réécrire chaque fois.
En renommant son système Mac OS X, Apple changea également de stratégie. Il n'était plus question d'offrir aux développeurs la possibilité de compiler leurs projets sur n'importe quelle plate-forme. La firme de Steve Jobs devait à l'époque se recentrer sur le Macintosh.
De temps à autre, la rumeur voulant qu'Apple sorte à nouveau un runtime permettant d'exécuter des logiciels écrits en Cocoa sous Windows refait surface (lire par exemple : Le retour de la Yellow Box ?). En attendant, les développeurs Cocoa, lorsqu'ils désirent porter leurs applications sous Windows, sont souvent coincés et doivent revoir leur code de fond en comble.
Cocotron : une alternative à la Yellow Box ?
The Cocotron veut en quelque sorte reprendre le flambeau. Ce projet open source, initié fin 2006, a pour vocation de permettre aux développeurs depuis XCode de compiler leurs projets sur différents systèmes et notamment sur Windows, le tout en Objective-C.
Il prend en charge notamment AppKit, CoreGraphics et CoreFoundation. Malheureusement, toutes les API de Cocoa ne sont pas supportées par Cocotron. On pense notamment à CoreData.
Mais les responsables de ce projet sont très fiers des progrès accomplis et espèrent pouvoir offrir un support plus complet à l'avenir. En ce moment, ils travaillent activement sur Quartz 2D et à la prise en charge d'AppKit sous Linux.
FileMagnet Uploader : un exemple concret
FileMagnet Uploader est un logiciel pour Mac qui permet de transférer ses fichiers sur iPhone, et de les consulter grâce à une application vendue 3,99 € sur l'App Store.
Son éditeur explique sur son blog qu'il a porté ce logiciel sous Windows sans avoir à lancer Visual Studio. Pas véritablement emballés à l'idée d'avoir deux codes sources à entretenir dans des langages différents, les développeurs ont essayé Cocotron sans trop y croire, et ont fini par opter pour cette solution qui leur a permis de sortir la version Windows deux mois après la version Mac.
En renommant son système Mac OS X, Apple changea également de stratégie. Il n'était plus question d'offrir aux développeurs la possibilité de compiler leurs projets sur n'importe quelle plate-forme. La firme de Steve Jobs devait à l'époque se recentrer sur le Macintosh.
De temps à autre, la rumeur voulant qu'Apple sorte à nouveau un runtime permettant d'exécuter des logiciels écrits en Cocoa sous Windows refait surface (lire par exemple : Le retour de la Yellow Box ?). En attendant, les développeurs Cocoa, lorsqu'ils désirent porter leurs applications sous Windows, sont souvent coincés et doivent revoir leur code de fond en comble.
Cocotron : une alternative à la Yellow Box ?
The Cocotron veut en quelque sorte reprendre le flambeau. Ce projet open source, initié fin 2006, a pour vocation de permettre aux développeurs depuis XCode de compiler leurs projets sur différents systèmes et notamment sur Windows, le tout en Objective-C.
Il prend en charge notamment AppKit, CoreGraphics et CoreFoundation. Malheureusement, toutes les API de Cocoa ne sont pas supportées par Cocotron. On pense notamment à CoreData.
Mais les responsables de ce projet sont très fiers des progrès accomplis et espèrent pouvoir offrir un support plus complet à l'avenir. En ce moment, ils travaillent activement sur Quartz 2D et à la prise en charge d'AppKit sous Linux.
FileMagnet Uploader : un exemple concret
FileMagnet Uploader est un logiciel pour Mac qui permet de transférer ses fichiers sur iPhone, et de les consulter grâce à une application vendue 3,99 € sur l'App Store.
Son éditeur explique sur son blog qu'il a porté ce logiciel sous Windows sans avoir à lancer Visual Studio. Pas véritablement emballés à l'idée d'avoir deux codes sources à entretenir dans des langages différents, les développeurs ont essayé Cocotron sans trop y croire, et ont fini par opter pour cette solution qui leur a permis de sortir la version Windows deux mois après la version Mac.
C'est le mono version Cocoa quoi...?
A mon avis, il doit rester des composants multiplateforme jalousement gardés par Apple, et qu'elle utilise dans le cadre des portages Quicktime, iTunes, Safari et Apple Software Update. Mais bon, c'est juste un avis...
Bravo... ainsi de plus en plus de développeur pourront passer sous mac, optimiser pour celui-ci tout en gardant un clientèle autre sans trop de travail.... L'inverse d'actuellement où on programme et optimise win pour ensuite adapter plus ou moins mac...
"Bravo... ainsi de plus en plus de développeur pourront passer sous mac"
Pas tout fait.
De nombreux softs spécifiques mac, qui en faisait la renommée et l'attrait, vont pouvoir se retrouver chez windows...
un exemple ? Osirix, le logiciel de traitement d'imagerie médicale, qui a lui seul justifiait l'achat de macs (imac et macpro) en milieu médical. Maintenant sur windows. Une raison de moins d'acheter du mac.
@DrFatalis
Sans doute certains mais en se mettant dans la peau de développeurs... plus le marché est grand plus c'est intéressant... à l'usager de choisir son os...
Actuellement on a des portages plus ou moins réussi d'appli win et linux... j'aimerais mieux avoir des créations mac, plus ou moins adapté à win et linux que l'inverse.
L'ère du système fermé est révolu... un programme doit pouvoir marcher sur tout et l'usager faire son choix... si c'était ainsi... je n'aurais plus besoin de winmerde car, le marché mac étant relativement petit, certaines applis professionnelles ne sont pas sur mac.... Je rêve mais j'aimerais bien que cette toolbox existe et q'Esri développe dessus pour ensuite compiler pc... arcmap sous mac.... fini win et ses problèmes.
surtout, cocotron ou pas, Cocoa ne peut pas faire de windows un meilleur windows. C'est le travail sur xcode, interface builder, os X et le mac en général qui rend séduisant aussi cocoa.
Bref, tant qu'Apple travaille, je ne vois vraiment pas où serait le problème.
Les développeurs hésitants à se lancer dans les technologies apple et le développement sur mac seront rassurés en se disant qu'au pire, ils peuvent tenter le multiplateforme en sortant une recompilation pour windows.
-
dans la pratique, cocotron est encore très loin de permettre qu'omniplan, par exemple, tourne sur windows.
-
Même si cocotron était un tort fait au mac, il y en aurait pour des années avant que cocotron soit réellement utilisable pour de grands projets. Il faut porter (écrire de toute pièce, vu qu'ils n'ont aucun code de la part d'Apple, ils écrivent un "cocoa" imitant cocoa) l'ensemble des cadres de développements que propose apple : core data, core animation, tout Foundation, webkit/webcore, quicktimekit, et j'en passe.
Bref, tout ce qu'un développeur s'attend à trouver sur un mac os x standard. et faudrait il aussi fournier les frameworks non-apple populaire, tel que growl, sparkle etc ? ou s'assurer que cocotron permette leur bon fonctionnement
Gros travail. Projet très intéressant.
-
gnustep est un projet plus ancien que cocotron, consistant à porter "openstep" (le prédécesseur de cocoa) à Linux/BSD. Il y a eu des programmes qui compilait sur os X et linux grâce au travail de gnustep.
(et gnustep pouvait être installé sur windows)
Personne n'a vu un mac en mourir. Parce que la seule api ne fait pas tout.
-
Un exemple : l'une des grandes forces de mac os x est Quartz. Vous pourriez apporter l'api de cocoa à windows, vous n'aurez pas quartz pour autant.
[quote]L'ère du système fermé est révolu... un programme doit pouvoir marcher sur tout et l'usager faire son choix...[/quote]
C'est un des avantages des applications web, surtout celles s'appuyant sur des standards ouverts. Fonctionner partout, indépendamment de l'OS et même, dans l'idéal, du navigateur utilisé. (mais perso je ne crois pas au "tout au web" et à la disparition des applications "lourdes", à installer sur son OS. Mais il faut avouer qu'il y a là un potentiel énorme).
Dommage que Cocoa n'est pas open source sous licence [url=http://www.opensource.org/licenses/apsl-2.0.php]APSL 2.0[/url] ou [url=http://www.opensource.org/licenses/apache2.0.php]Apache[/url] !
J'avais acheté FileMagnet. Je l'ai laissé tomber pour [url=http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=289943355&mt=8]AirSharing[/url] qui permet de récupérer et envoyer les fichiers SANS application tierce. Ça marche sur Linux, Windows et Mac.
@Dr Fatalis : ayant discuté à plusieurs reprises avec un des fondateurs d'Osirix lors de congrès scientifiques. Il n'est pas envisagé de développer sous Windows Osirix.
Chaque fois qu'il présente Osirix, il fait de la pub pour Apple et ses machines. Donc pas de soucis pour Osirix. Même si dans le domaine médical, il y a de plus en plus de mac. Il y a très peu de PACS à travers le monde qui utilisent essentiellement Osirix. Son développement sous Windows permettrait peut-être un plus grand panel de cas d'utilisation.
Est-ce qu'il y a encore ces merd... de .nibs avec Cocotron ?
Parce que c'est la raison qui me fait préférer GNUstep, et de loin : transparence.
ericb2, je comprends pas très bien le sens de ton post. Quel rapport entre les nibs (xibs désormais) et la "transparence" ? De quelle transparence parles-tu ? Pourquoi détester les nibs (alors même qu'on peut s'en passer si vraiment on le veut, même si je trouve cela maso) ?
egw : qu'y a-t-il dans un .nib ? Tout n'est pas accessible, et donc dans un projet libre, ça le fait pas trop.
Alors je me demandais comment c'était géré sous Windows (don't les APIs semblent se rapprocher progressivement de Mac OS ), avec Cocotron.
« qu'y a-t-il dans un .nib ? Tout n'est pas accessible, et donc dans un projet libre, ça le fait pas trop. »
C'est accessible. Juste pas accessible avec un simple éditeur de texte, nuance. ;-)
Mais si c'est la seule chose qui te dérange dans les fichiers NIB, alors le format XIB doit te plaire, vu que là l'éditeur de texte le plus basique te permet de tout « voir ».
Bref, comme egw, je ne trouve pas que ce soit une raison suffisante pour détester ces fichiers (râler un peu, oui, mais les détester au point de ne pas vouloir les utiliser, ça me paraît exagéré). Enfin, bon, encore une fois, avec le format XIB ce problème est réglé.
Mettre du Coca sur la fenêtre ? C'est ça le titre ? Bah pourquoi ?
Plus sérieusement et plus gravement, c'est à se demander si le père Jobs n'est pas en train de saborder sa compagnie avant de prendre la retraite...
Moi cette appli ne m'emballe pas, ce qui m'aurait plu aurait été l'inverse, permettre au dev windows de pouvoir passer leur code en cocoa et donc favoriser l'arrivée de nouvelles applis sur mac plutot que d'en proposer encore plus sur windows...
enfin ce que j'en dis.....
Si seulement on pouvait porter l'explorateur windows sous mac, on aurait enfin un finder digne de ce nom, au lieu de se taper la bouse signée Apple (95 faisait déjà mieux..)
oldjohn, mauvaises habitudes ?
Je ne comprends pas vraiment la démarche de cocotron, je comprends le but mais la démarche me semble décalée dans les temps actuels.
Je m'explique, créer une API devant supporter "core data, core animation, tout Foundation, webkit/webcore, quicktimekit" (comme les citait oomu) me parait une tâche faramineuse, tâche qui ne sera certainement jamais terminée. Non pas que je ne le souhaite pas mais je ne le crois pas.
Une autre démarche plus en adéquation avec les désirs des entreprises actuellement aurait été de se baser sur le MDA en créant des règles de transformations pour passer sur un autre environnement.
Bien entendu le travail est aussi énorme, les avantages sont la modularité du projet, le choix des technos cibles, la facilité de retouche de la transformation... Certes il reste toujours du code à taper après la transformation, celle-ci n'étant jamais possible à 100% mais j'imagine qu'avec cocotron le code initial doit être souvent retouché pour coller aux specs reconnues.
Nulle critique haineuse de ma part dans ce commentaire. Je cherche juste à comprendre le pourquoi de cette démarche amenant à une API plutôt qu'à une approche MDA.
ericb2, un fichier NIB binaire c'est qu'un ensemble de classes "sérialisés" (pour prendre le terme à la Java), autrement dit, résultant d'un NSKeyedArchiver. Il n'y a rien de chaché là. L'opération inverse (Unarchiver) te donne le résultat initial. D'ailleurs, tout fichier binaire résultant d'un NSKeyedArchiver peut être reformé en XML pour plus de clarté, comme avec les plists (un coup de plutil -convert xml1 et puis voilà). D'ailleurs le format XIB c'est précisémment ça (stocker en plist et pas en binaire - pour en autre mieux passer dans les systèmes de gestion de versions). Enfin, dans un projet libre, on suppose qu'on a accès au code source et au fichier de projet Xcode, donc je ne comprends pas trop l'argument sur ce point non plus (un peu comme dire qu'un binaire exécutable c'est bof pour du libre, autant programmer qu'en langage interprété).
Enfin, j'enfonce sûrement des portes ouvertes et je n'apprends sûrement rien à toi (je n'ai pas programmé d'OpenOffice moi :), mais je ne vois absolument pas le problème entre les NIB (qui maintenant sont des XIB) et le libre (bien au contraire je trouve ça sympa de pouvoir trifouiller les NIB d'un programme compilé et non open source - j'aurais donc tendance à penser que c'est les concepteurs de logiciels propriétaires qui ne doivent pas aimer les NIB).
@egw
Merci pour les explications, surtout pour le plutil -convert xml1
En ce qui concerne ce qu'est un .nib, ça fait un petit moment que j'ai compris ce que c'est, mais il y a plein de subtilités, et j'ai dû relire plusieurs fois le document de Pierre Chatelier pour comprendre qu'il fallait remplacer tous les awakeFromNib par des void, et utiliser super init pour faire mon propre init ;-) ( i.e. les IBOutlets and co ).
Le problème que je vois : un .nib c'est très mal vu dans un projet libre, et commiter un binaire, donne toujours lieu à des commentaires (et c'est normal).
Sauf erreur de ma part, .xib c'est pas pour Tiger (et nous avons Tiger comme baseline pour pas mal de temps encore ).
Enfin, dès que j'ai un moment j'essaye, parce que si on peut commiter des .xib (i.e. du .xml), ça change *vraiment* beaucoup de choses pour nous. Encore merci pour toutes ces explications.
ericb2: cool content d'avoir aidé :) (je prends ça comme un compliment de ta part).
OK donc le problème, c'est que les NIB c'est du binaire.
Toujours est-il que je trouve assez génial moi le principe des nibs mais je reconnais que committer des fichiers binaires c'est un peu foireux. Je pense que c'est la principale critique qui a mené à changer les NIB en XIB, qui ne sont que des fichiers XML (donc "committables", "diffables", etc.). Maintenant j'avoue que j'ignorais que les XIB étaient réservés à Leopard. Mais je pense que Xcode 3 vaut le coup pour passer à Leopard (bien entendu les applications créées peuvent rester compatibles avec Tiger).
@ ericb2 : Sauf erreur de ma part, on peut tout à fait utiliser des XIB pour faire du développement à destination de Tiger.
Le développement lui-même doit alors se faire sous Leopard (vu qu'il faut Interface Builder 3 pour manipuler les fichiers XIB), mais on peut viser Tiger comme plateforme de déploiement : le XIB n'est qu'un format de travail et à la compilation, les XIB sont transformés en NIB pour être inclus dans l'application finale. Il doit donc suffire de ne pas utiliser dedans quoi que ce soit d'incompatible avec Tiger (aidé en cela par l'outil de vérification de compatibilité intégré à Interface Builder).
@Hindifarai : Je me suis toujours demandé ce que pouvait vouloir dire exactement "State of the Union". J'avais même imaginé que les binaires des deux plateformes allaient être compatibles dans une prochaine version. Une sorte de Rosetta universelle, mais c'est mon imagination qui me trahit =:p
@egw : pour l'instant, on est coincés, car Tiger est notre baseline, et on ne sait pas compiler depuis Leopard vers Tiger ( quelques pb residuels à résoudre).
Donc ce sera forcément plus tard