C'était l'IDE de référence sous Mac OS Classic.
Maintenant plus d'actualité, pour ce que j'en ai lu. Apparement stopé par Apple.
Non, vraiment, il ne s'agit pas d'une réponse partisane. J'ai développé plusieurs années pour les vieux systèmes 7.5. Carbon, n'en est qu'une légère amélioration. Puisque tu as la doc, regarde comment on fait pour répondre à un clic sur un article de menu:
- obtenir les coordonnées du clic
- déterminer dans quelle fenêtre s'est produit le clic
- si c'est dans la barre de menu (qui est une fenêtre), transformer les coordonnées globales en coordonnées locales
- déterminer quel est l'article de menu à cet endroit.
Effectivement, ce n'est pas propre. Même l'API Windows 3.1 était plus évoluée.
En Cocoa:
- un message associé à l'article de menu est envoyé.
Comme sous Windows
(3.1, 9x, 2000, XP), à la différence que le gestionnaire d'évenement de la fenêtre reçois un identifiant pour l'entrée de menu, et que cet identifiant peut être partagé par plusieurs entrées de menu ou controles, si plusieurs entrées de menus ou controles sont conceptuellement associés à un même action.
Développer sous Carbon est long, fastidieux et difficile. Il s'agit d'une solution qui a permis de faire évoluer les logiciels existants pour qu'ils profitent des avantages de Mac OS X [...]
Tu m'as convaincu. Et j'ai effectivement appris aussi de mon côté que Carbon est progressivement abandonné.
J'aurais tendance à dire que la "culture" se fait à l'utilisation.
Mais je vais devoir me contenter de la litérature
(et du bon sens un peu aussi).
Je te remercie, j'en aurai bien besoin !
De rien :rose:
Pas tout à fait, mais ils ont fait du très beau travail. On retrouve ses repères (barre de menus, raccourcis clavier), et c'est très réactif. C'est bien mieux qu'une appli Java, par exemple. Si je devais écrire une appli multi-plateforme, ce serait sans doute avec le couple WxWidget + Python.
À ce sujet, je viens de faire une petite découverte. Je me suis inscrit sur le « Apple Developper Network »
(si je ne me trompe pas de nom). Aprés m'être inscrit, j'ai récupéré un fichier
xcode313_2736_developerdvd.dmg que j'ai ouvert avec 7-Zip
(un archiveur sous Windows, qui est capable d'ouvrir les DMG de Mac). Il contenait entre autre, un
MacOSX10.4u.sdk qui contient des entêtes pour wxWidgets et wxPython
Et encore un autre fichier
DevSDK.pkg, qui contenait lui aussi des définitions pour wxWidgets. Comme l'environnement XCode est fourni par Apple, on peut peut-être en conclure que Apple donne une reconnaissance à wxWidgets.
Oui, mais tu dois pouvoir la placer facilement à l'intérieur de l'appli.
Oui, bundle, ou encore mieux, liaison statique.
Si, tu peux utiliser CoreAudio, mais forcément, il faudra reprogrammer pour l'équivalent pour la version PC. Ou alors utiliser une bibliothèque multi-plateforme comme OpenAL.
Comme le problème est pour moi de tester sous Windows parce que je ne peux pas tester sous Mac, ça ne m'avancera pas. Plutôt OpenAL alors.
Je vais finir par une question: tu n'as pas de Mac, pourquoi veux-tu absolument développer sur Mac ?
Cela va te demander deux fois plus de travail. Je serais toi, je ne développerais que sous Windows.
Parce que ce qui m'interesse avec Mac, ce n'est pas seulement l'environnement logiciel, mais également l'environnement utilisateur. Je crois deviner que les utilisateurs de Mac accordent plus de valeur à leurs applications, d'ailleurs il font proportiellement plus régulièrement les mise à jour système que les utilisateurs de Windows.
Sous Windows, le climat et la culture ambiante ne sont pas bonne, et pour un utilisateur de Windows, une application n'a généralement pas de valeur, c'est « un dû », et même s'il la considère comme un dû, il dira systématiquement que ça ne vaut rien, raison pour laquelle également il ne fait pas les même à jour système
(mais il y a d'autres raisons aussi, ce n'est pas toujours si simple). Pour résumer, pour l'utilisateur moyen sous Windows, un logiciel, n'a jamais aucune valeur.
Le nombre d'utilisateurs d'une plateforme n'est rien, si ce ne sont pas de bons utilisateurs. Mieux vaut la qualité que la quantité, et sous Windows, la culture est plutôt « piratage et téléchargement à gogo »
Évidement, je ciblerai Windows également, parce que techniquement ce sera plus facile
(vu que je suis sous Windows), mais je n'en attend rien de bon à priori.
Remarque : j'avais au préalable tenté une application en ligne
(mais pas pour le même domaine), en pensant que c'était plus facile avec une application en ligne, de se protéger contre le piratage et d'offrir aux utilisateurs potentiels, un essai directe et aisement accessible. Mais les seuls personnes interessées, ont été des entreprises.... mais qui la voulait gratuitement
(parce que dans leur esprit, sur internet = gratuit, même si eux voulaient faire des bénéfices avec). Donc je vais finalement tenter les applications « sur poste » et laisser tomber les applications en ligne. Et comme je le disais, je pense que les utilisateurs Mac, sont plus regardant sur la qualité, et cherche peut-être moins à remplir leur disque dur de téléchargements en tout genre
(gratuit, évidement) pour rien et sans savoir pourquoi.
---------- Nouveau message ajouté à 12h53 ---------- Le message précédent a été envoyé à 12h48 ----------
Pour la vidéo, on peut "attaquer" QuickTime avec Carbon également, donc même réponse.
L'API QuickTime existe sous Windows également, donc ce serait interessant.
Mais un point essentiel à mon avis, c'est que pour vraiment utiliser Cocoa il faut écrire en Objective-C et non en C.
Quand on écrit en Objective-C, le code devient difficilement portable. Ça existe Obj-C ailleurs que sur Mac ?
Oui, ça existe ailleur que sous Mac. Objective-C est un des langages pris en charge par GCC. Mais GCC n'est pas le seul, il en existe d'autres. Avec une bonne culture des abstraction informatique, il ne devrait pas être inabordable. J'avais lu un livre et quelques articles à son sujet en 1998, et même si c'est loin, j'en ai le souvenir de quelque chose d'accessible.
Tu dit que c'est plus rapide de développer sous Cocoa que sur Carbon, je suis d'accord avec toi.
Aprés ses explications, impossible de douter.
Par contre, pour avoir un peu pratiqué les deux, dès que l'application Cocoa devient un peu conséquente, je m'y perds rapidement. Certes en Carbon, on doit faire beaucoup de chose à la main, mais au moins quand on a un problème, on trouve rapidement ce qui se passe.
Des problèmes de typages ? De liaison dynamique ?
[/QUOTE]
---------- Nouveau message ajouté à 12h57 ---------- Le message précédent a été envoyé à 12h53 ----------
Et mon code en C est absolument portable, j'en fait l'expérience tous les jours puisque j'écrit en C+Carbon et que cela se recompile sans problème sur Windows.
[...]
Bon, il est vrai que nous avons écrit une librairie Carbon pour Windows...
Dis en plus, ça m'interesse énormément !
heureusement je suis pas obliger !
