Ce n'est pourtant pas le temps qui a manqué pour faire un portage 100% cocoa. Alors pourquoi ? Peut-être que Cocoa ne présente pas que des avantages / Carbon… Adobe avait aussi déclaré il y a quelques années que Cocoa c'était bien lent par rapport à Carbon. Ceci explique peut-être cela.

C'est surtout le choix de Carbon plutôt que Cocoa qui parait curieux à l'heure où Apple incite tout le monde à passer à Cocoa ! Le 32bits plutôt que le 64bits pour le Finder, à mon avis, ça ne change pas grand chose.

ce n'est pas non plus comme si le finder allait nécessiter d'allouer + de 4go de ram. pour une prévue d'un projet final cut démentiel ? _non_ parce que vous avez 1 millions 600 345 pdf dans un dossier et vous les voulez en "coverflow" ? NON. bref, rien à battre d'un finder 32b. en terme de calculs, ca serait rien. d'ailleurs être "64b" ne garantit pas d'avoir un processeur + rapide, et en terme de mémoire le finder n'a jamais eu de tels besoins et n'en aura pas encore avec Leopard. parlez moi plutôt d'amou.. parlez moi plutôt d'un photoshop 64b, d'un aperture 64b, d'un mysql 64b, etc.

Je suis loin d'être expert en la matière (Carbon, Cocoa, j'y comprends pas grand chose) mais quelque chose m'échappe : pourquoi faire un tel barnum autour du 64 bits et de Cocoa si l'application centrale de Leopard n'adopte même pas ces nouvelles dimensions ? Décidément, et n'en déplaise à certains, cette WWDC 2007 est pour le moins déceptive...

Le 64 bits ne sert qu'à certains types d'application manipulant des données énormes (+4 Go), ça ne sert à rien de tout mettre en 64 bits !

A mon avis c'est juste qu'ils avaient autre chose à faire que de recoder le Finder. Je vous rappelle que Leopard a été repoussé soit disant à cause de l'iPhone, c'est dire si le Finder est le cadet de leurs soucis. <br /> Quant à avoir un Finder en 32 bits ou 64 ça ne changerait pas grand chose...

Applllleeeee ton univers impitoyaaableeeee ... Je suis entièrement d^'accord avec toi, sauf sur ce que tu dis ;-)

Surtout que le 64 bits peut être au final plus lent que la même application en 32 bits. Tout dépend de son mode de fonctionnement et des calculs (et données) à traiter. Le Finder reste peut-être plus performant en 32 bits

C'est pas pour faire pour mon embêtant, mais Apple continue de mentionner que Carbon passe aux 64 bits avec Leopard dans les pages dédiés aux développeurs (http://developer.apple.com/leopard/overview/) : "First implemented at the UNIX level in Tiger, Leopard brings complete 64-bit support to all of Mac OS X’s application frameworks. Using either the Carbon or Cocoa frameworks, you can create applications that can address extremely large data sets, up to 128TB using the current Intel-based CPUs. The 64-bit model used in Mac OS X is known as LP64 and is the same model used by other 64-bit UNIX systems from Sun and SGI as well as 64-bit Linux."

Non c'est comme si vous envoyez vos sms en 64 bits ridicule n'est pas pour coder du text 8 bits suffit nintendo 64 bits c'est mieux pour les effet 3d donc le finder n'est pas en 3d voilà il passera en 64bits quand il sera en vrai 3d

Non c'est comme si vous envoyez vos sms en 64 bits ridicule n'est pas pour coder du text 8 bits suffit nintendo 64 bits c'est mieux pour les effet 3d donc le finder n'est pas en 3d voilà il passera en 64bits quand il sera en vrai 3d

Qu'il soit en 32 ou 64 je ne pense pas que ça change gd chose, par contre j'espère que son fonctionnement sera moins buggé qu'actuellement. Rafraichissement des fenêtres aléatoire, affichage des images à la place de l'icône aléatoire, agrandissement (bouton vert) faisant parfois n'importe quoi... Le finder est le centre du système, il est important qu'il soit le plus efficace possible.

Si tu lis le lien (ce que j'ai fait en diagonal), tu remarques, qu'ils doivent passer en 64-bit pour carbon. Si j'ai bien compris des parties du finder sont en 64-bit comme cover flow et d'autres gardent l'implementation carbon. J'ai aussi l'impression que Cocoa utilise des couches Carbon. Bon j'ai lu très très rapidmement alors ne vous excitez pas :-)

Akraig, tu as du mal me lire (Ou bien il y a un second "UnType" sans l'espace ?). J'ai parlé ces derniers jours plusieurs fois de Carbon/Cocoa :<br /> Pour OpenOffice : J'ai affirmé que ce n'était pas parce qu'on choisissait de faire une application avec un coeur en Carbon qu'on ne pouvait pas utiliser Cocoa pour l'interface. J'ai précisé qu'à mon avis c'était le meilleur choix, la difficulté étant de savoir comment profiter des avantages de Cocoa (correcteur orthographique pris en exemple) afin que l'utilisateur n'y voit rien. Pour le Finder de Tiger : J'ai affirmé qu'il avait un comportement différent des application avec une interface Cocoa (séléction de paragraphe en exemple) Pour le portage d'applications tierces : J'ai affirmé qu'on pouvait développer une application sans utiliser les API Carbon et qu'à mon avis, pour peut que l'application à porté soit développée en MVC, il était même plus simple d'utiliser Cocoa (c'est le cas de beaucoup de petites applications open source, la coeur est simplement une compilation avec les dépendances de l'application originel et l'interface un "mapping" des fonctions en cocoa). Pour la YellowBox : J'ai affirmé que QuickTime (une partie de Carbon donc...) avait été la pierre angulaire du développement d'application sous Windows pour Apple et que logiquement Cocoa (qui est à la base conçu pour ça...) devrait suivre. Je n'ai jamais dit que Cocoa n'utilisait pas Carbon. Merci.

Je crois qu'il y en a qui ne comprenne pas trop MacOS X et ils voient le Finder comme l'essentiel du système, ce qui n'est pas du tout le cas. Ce n'est pas parce qu'il ne reste que le Finder quand toutes les applications sont fermées que le Finder est l'élément central de MacOS X et que tout repose dessus ! Le Finder n'est qu'une application comme une autre, permettant de naviguer dans les fichiers. On peut même le remplacer, comme avec PathFinder par exemple. Ses 32 bits n'ont donc rien de choquant dans cet environnement, et Apple prépare peut-être des changements beaucoup plus profond au Finder pour ne pas envisager de redévelopper ce bon vieux Finder depuis le 1er bit ;)

J'espère qu'Apple a résolu les incohérences ergonomiques qui parasitent Tiger : clic-through, pas clic-through ; sélection de liste de fichiers par cliquer-glisser qui tantôt marche, tantôt marche pas…

tiens d'ailleurs, j'utilise "Path Finder" plutôt que Finder (même si on ne peut pas totalement enlever finder, il ne faut pas d'ailleurs hacker, finder fournit différents services ) je vais donc de ce pas harceler l'auteur de Path Finder pour une version 64b :) (path finder est majoritairement une application cocoa) -- le 64b de la tête au pied dans les fondations de os X ,c 'est _BIEN_, pour autant ne paniquez pas si itunes, bash ou adium reste 32B, tout va bien. les développeurs ne sont pas tous fous ou corrompus. c'est avant tout un argument technique (ultra important, mais pour les techniciens)

Et si une éventuelle version 32 et 64 Bits Cocoa du Finder était tout simplement en développement à Cupertino et qu'ils l'intègreront à une prochaine version bêta ? Je ne pense pas qu'on puisse beaucoup s'avancer sur ce que contiendra Leopard en Octobre, Apple aimant beaucoup créer des effets de suprise.

j'espère surtout qu'ils ont amélioré le multi-threading du finder parce que pour l'instant c'est pas génial. Il arrive souvent de bloquer l'interface utilisateur pour des tâches basiques ou plus facilement par un accès réseau coupé.

@TZ : oui

j'ai lu tous les commentaires je connais rien en programmation j'ai la tête qui fume par les oreilles <br /> **pars se raffraichir avec un Cocoa Cola Zero (avec zero carbon dedans)**

Est-ce que ça veut dire que le Finder et le Desktop vont être toujours aussi lent ?