Ajout d'un menu contextuel au finder : uniquement en Carbon ?
LeChatNoir
Membre, Modérateur
Salut !
J'ai un mini projet qui consisterai à ajouter des éléments au menu contextuel du finder.
J'ai commencer à faire des recherches et j'ai l'impression que c'est faisable uniquement en Carbon...
Si c'est le cas, j'essayerai de m'y mettre mais ça m'embête de pas pouvoir utiliser Cocoa >:(
Qqu'un a t il une information contradictoire ?
Merci et a+
J'ai un mini projet qui consisterai à ajouter des éléments au menu contextuel du finder.
J'ai commencer à faire des recherches et j'ai l'impression que c'est faisable uniquement en Carbon...
Si c'est le cas, j'essayerai de m'y mettre mais ça m'embête de pas pouvoir utiliser Cocoa >:(
Qqu'un a t il une information contradictoire ?
Merci et a+
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je compatis, je suis pas fan de Carbon non plus...
Allez, voilà un Sample Code...
Merci de compatir... Pfffff, je connais pas du tout Carbon et mon mini projet devais utiliser un framework Cocoa :-(
Je voulais ajouter des items pour GPG...
Ca se tranforme en une tache monumentale !
Et comment ça va marcher avec Snow Leopard ? Ils vont réécrire le finder en Cocoa ? J'ai cru comprendre qu'ils laissaient tomber le Carbon...
Oui apparemment le PPC va virer aussi, en plus du Carbon. Donc ça va être chouette
De toute manière un bon programme tourne toujours sur au moins 1 voire 2 versions antérieures
En même temps c'est sympa de penser qu'ils leurs restent de la réserve sous le capot.
On est peut-être pas a l'abrit d'une 10.5.5 qui mettrait a jour le finder, non ? Ou une .6...
D'ailleurs, si c'était le cas, tous les appels Carbon devraient être étiquetés "Deprecated" dès à présent, non?
Pour ce qui est de la réécriture du Finder en cocoa, c'est annoncé depuis OS X.1, et je pense qu'Apple l'aurait fait depuis longtemps s'il le pouvait. Toutdefois, même si le Finder est réécrit en Cocoa, ça n'impliquerait pas automatiquement que ses plug-ins changent de technologie, ils pourraient rester Carbon...
Carbon, ce sont juste des API de bas niveau écrites en C, tout comme Core Foundation, ou un tas d'autres trucs. Apple ne vas pas les abandonner tout de suite, ça c'est sûr, ne serait-ce que parce que Cocoa l'utilise grandement.
Je sais bien que Carbon n'est pas synonyme de "vieilles techno" mais l'accent est tellement mis sur Cocoa+ objective C que naturellement, un développeur aura tendance à délaisser Carbon...
PS: Encore un débat intéressant qui permet d'apprendre des choses, merci à vous.
Je pensais que c'était la CS5 ça oO Me semble bien que CS4 sera tjrs en Carbon justement.
À mon avis Snow Leopard ne vire pas Carbon. Apple se charge de virer l'archi PPC de LEURS applications uniquement pour gagner de l'espace et accroà®tre les performances des applications Apple. Le Finder sera réécrit en Cocoa aussi pour accroà®tre les performances... Mais ça m'étonnerait énormément que Carbon disparaisse dans Snow Leopard oO Sinon je pense que y'a pas mal de choses qu'on pourra plus faire (comme jouer à Max Payne
* Apple ne portera pas les API Carbon en 64 bits,
* Adobe sortira la CS4 en Carbon a priori donc la CS4 restera 32 bits sous Mac. Ils travaillent à tout réécrire en Cocoa et pensent sortir Photoshop en Cocoa 64 Bits pour la CS5.
Voilà donc au final, Carbon perdurera mais est amené à mourir.
Donc Apple réécrira certainement le finder en Cocoa.
Ceci m'amène à une autre réflexion : itunes et Safari sont également écris en Carbon d'après mes souvenirs. Ceci permet de porter plus facilement le tout sous Windows (puisqu'à priori, les API Carbon sont compilables Windows et que le C++ ne pose pas de pb non plus).
Du coup, comment vont ils gérer le truc pour continuer à assurer des versions Windows et Mac OS ?
Je vois bien une réponse mais...
Toutes les API Cocoa portables sous windows ?
Ca parait fou et surtout un boulot colossale mais ça signifie aussi tout le monde sous Cocoa !
Et les développeurs iPhone, et les développeurs Mac et les développeurs Windows et pourquoi pas les développeurs Unix/Linux (tant qu'à faire, autant faire des API multi plateformes).
Un truc de fou mais la stratégie est remarquable !
A suivre...
En tous cas, ça signifie que s'ils réécrive le finder en Cocoa, il devrait y avoir moyen de faire des menu contextuels en cocoa :-)
Scusez mais je ne vois pas ce que cela veut dire : "Réécrire le Finder en Cocoa."
Pour moi tout cela c'est du C, alors on peut définir des fonctions C avec la syntaxe C en Carbon, ou/et déclarer des méthodes Cocoa avec la syntaxe Objective-C, mais c'est du pareil au même. Ce n'est qu'une question de localisation des librairies et de syntaxe au niveau de l'utilisation.
La seule chose que je vois de possible et d'agréable, c'est qu'il soit mis à disposition dans le framework Cocoa des fonctionnalités qui se trouvent actuellement dans Carbon.
Après cela, Apple peut décider de masquer Carbon, mais je ne vois pas ce que les développeurs y gagneraient.
Où as-tu entendu dire que REALBasic supporterai Cocoa ? Le sujet m'interesse beaucoup.
Pour mémoire REALBasic est écrit en C++, source d'un technico-commercial de Realsoftware.
A l'époque (Apple Expo 2005), il m'avait dit que les ingés texans avaient déjà effectués des essais pour implémenter Cocoa ! C'est compliqué pour au moins une raison:
Comment fait-on pour gérer les points d'arrêts dans les méthodes de délégation retournant une valeur ?
La gestion des Threads est également un sujet délicat.
Un mec qui dév sur REALBasic en a parlé... Mais après j'en sais pas plus
Ben aujourd'hui, le finder, c'est du C avec les API Carbon. Demain, s'ils nous vendent un Snow Leopard full 64 Bits alors que les API Carbon restent en 32 Bits, alors c'est qu'ils réécrivent le finder au moins avec les API Cocoa.
Autrefois, quand nous écrivions nos applis pour OS 9 (voire 8 ou 7), nous écrivions tout en utilisant les fonctions C de la Toolbox. Arrive OS X: Apple dit alors aux développeurs que s'ils voulaient que leurs applis tournent de façon transparente, il faudrait réécrire une partie du code. D'après mes souvenirs, il y avait la boucle d'événements et les dialogues de choix des fichiers. Une fois réécrité, l'appli était dite "carbonisée" et se lançait par un simple double-clic, sans avoir à lancer Classic (pour ceux qui n'ont pas connu, une grosse appli qui lançait en fait OS 9 !)
Qu'est ce Carbon ? Un ensemble d'API pour gérer cette ancienne Toolbox. On y trouve, par exemple, Quickdraw (l'ancienne API graphique) mais aussi, les gestions des ressources, des fichiers, etc. Apple a par ailleurs fait l'impasse sur d'autres API comme le Sound Manager ou Quickdraw 3D.
Les programmes qui existent donc sur Mac depuis plusieurs années comme Word, Photoshop ou Graphic Converter n'ont donc pas été réécrites totalement. Word, par exemple utilisait Quickdraw pour la première version sous OS X, mais utilise Quartz aujourd'hui, parce que c'est plus rapide, plus facile à utiliser, parce que ça évolue, et que le rendu est meilleur. Word n'est pas écrit en ObjC et ne fait pas appel à Cocoa, n'empêche que quand on l'utilise, on n'a pas l'impression d'avoir affaire à une vieille appli. Et c'est pareil pour le Finder !
Vous avez l'air de penser qu'un développeur sous OS X ne dispose que de deux alternatives: Carbon ou Cocoa. à‰videmment, c'est faux ! Où situez-vous CoreGraphics là dedans ? Il est évident que quand vous utilisez la classe NSBezierPath de Cocoa, c'est bien les API en C de CoreGraphics qui sont appelées pour fixer le contexte, la matrice de transformation courante et créer les points de contrôle de la courbe de Bézier. Sauf que quand on utilise Cocoa, on se fait moins chier pour le même résultat, parce que quelqu'un a conçu une belle classe pour emballer le tout.
Donc Cocoa ou pas, là n'est pas la question.
C'est pile ce que je disais 4 ou 5 posts plus haut
Par contre, demain, oui. Puisque les API ne seront pas portées en 64 Bits.
Et que tout sera en 64 Bits.
D'où la décision d'Adobe de tout réécrire (et photoshop, c'est pas une petite appli !).
J'imagine que microsoft en fera de même pour sa suite...
Après, il me semble que le finder s'appuie sur les API Carbon pour tout ce qui est gestion des fichiers. Donc pour avoir un finder 64 Bits, ils réécriront forcément ces parties là . Après, qu'ils le fassent en Cocoa, en pur C ou autre, effectivement, on sait pas.
Mais ce serait un moyen de démontrer que la solution vers laquelle ils poussent tous le monde est celle qu'ils utilisent aussi...
Il avait pas raison ?
http://www.macgeneration.com/news/voir/132226/apple-nettoie-le-finder-de-snow-leopard/
"Peu de détails émergent pour le moment, si ce n'est qu'un gros effort de réécriture en Cocoa a été fait pour les applications incluses avec le système. Cette modernisation du code concerne la quasi totalité d'entre elles.
Et la plus emblématique est le Finder. Apple est en train de le purger de son vieux code Carbon, soulignant que le chantier est bien avancé. A la clef, la perspective pour le Finder de tirer parti de fonctions et d'interfaces de programmation qui lui étaient interdites du fait de l'ancienneté de son code."