Pourquoi pas, mais il serait temps que le ménage soit fait entre Carbon, CoreFoundation, CoreGraphics, etc ... et toutes ses librairies C qui se chevauchent, on finit par ne plus savoir quelle ressource prendre pour optimiser son code. Ok pour une belle librairie C à utiliser sous Objective-C, mais unifiée, et avec une logique documentaire telle qu'on l'apprécie habituellement avec les outils XCode.
Ces bibliothèques (et pas " librairies ") ont chacune leur spécialité et leur doc associée qui est bien faite ???
Tiens, ça me rappelle une autre discussion il y a deux ou trois mois où je disais que le remplacement du C de Carbon par Obj-C n'était qu'une question de dénomination des routines C ...
Ce qui est faux :P Une partie de Carbon n'est pas compilable en 64 bits... Cette partie est à réécrire
Bah non, il suffit d'implémenter pour Cocoa, les fonctions qui sont dans Carbon mais encore absente de Cocoa, et c'est ce qu'ils font en ce moment pour Snow Leopard...
Apple donne prépare un Cocoa qui sera totalement libéré de Carbon, tout ce qu'on peut faire en Carbon sera possible sans Carbon directement dans Cocoa, quel intérêt à ce moment de convertir Carbon en 64 bits ? C'est de toutes façons un framework de transition qu'Apple n'a jamais cherché à conserver au-delà de cette transition, ça fait longtemps que ç'aurait du disparaà®tre, mais bon ça traà®ne un peu...
Ces bibliothèques (et pas " librairies ") ont chacune leur spécialité et leur doc associée qui est bien faite ???
Non il y en a trop
dans 1229285142:
Tiens, ça me rappelle une autre discussion il y a deux ou trois mois où je disais que le remplacement du C de Carbon par Obj-C n'était qu'une question de dénomination des routines C ...
Ce qui est faux :P Une partie de Carbon n'est pas compilable en 64 bits... Cette partie est à réécrire
Faut pas faire semblant de pas comprendre. Qu'il réécrive ou pas, on s'en fout, ce qui compte c'est qu'ils éclaircissent la situation, afin que cela ne deviennent pas une affaire de spécialistes spécialisés qui savent qu'à la page 62543, on trouve une indication qui renvoie à la page 1246821.
Sachant qu'il est difficile de dépasser UINT_MAX ;D
Bah non, il suffit d'implémenter pour Cocoa, les fonctions qui sont dans Carbon mais encore absente de Cocoa, et c'est ce qu'ils font en ce moment pour Snow Leopard...
Faut pas faire semblant de pas comprendre. Qu'il réécrive ou pas, on s'en fout, ce qui compte c'est qu'ils éclaircissent la situation, afin que cela ne deviennent pas une affaire de spécialistes spécialisés qui savent qu'à la page 62543, on trouve une indication qui renvoie à la page 1246821.
Sachant qu'il est difficile de dépasser UINT_MAX ;D
J'avais compris que tu disais qu'il suffisait de prendre le même code et de changer le nom : " le remplacement du C de Carbon par Obj-C n'était qu'une question de dénomination des routines C "
Faut pas faire semblant de pas comprendre. Qu'il réécrive ou pas, on s'en fout, ce qui compte c'est qu'ils éclaircissent la situation, afin que cela ne deviennent pas une affaire de spécialistes spécialisés qui savent qu'à la page 62543, on trouve une indication qui renvoie à la page 1246821.
Sachant qu'il est difficile de dépasser UINT_MAX ;D
Moi je trouve ça très clair au contraire :P Cocoa c'est le framework généraliste... Core Foundation le framework bas niveau donnant accès à la gestion des collections et autres accès systèmes. Core Graphics framework bas niveau gérant les graphismes Core Animation framework permettant l'optimisation des animations Core Video framework bas niveau gérant les vidéos, Core Audio framework bas niveau pour l'audio, etc.
C'est sûr ça fait beaucoup de trucs, mais vaut mieux que ce soit en plusieurs frameworks qu'en une seule grosse usine à gaz
dans 1229285836:
dans 1229285666:
Bah non, il suffit d'implémenter pour Cocoa, les fonctions qui sont dans Carbon mais encore absente de Cocoa, et c'est ce qu'ils font en ce moment pour Snow Leopard...
C'est ce que j'entendais par " réécrire "...
Ouais, enfin ce que je voulais dire c'est que Carbon restera en 32 bits, et que les fonctions qui ne sont pas encore couvertes par Cocoa le seront.
Ouais, enfin ce que je voulais dire c'est que Carbon restera en 32 bits, et que les fonctions qui ne sont pas encore couvertes par Cocoa le seront.
Ben oui, c'est exactement ce que j'ai dit :P Philippe avait l'air de dire que pour passer du Carbon au Cocoa il faudrait juste changer le noms des fonctions, et j'ai dit qu'il faudrait en réécrire (ce qui supposait dans le passage de Carbon à Cocoa).
Moi je trouve ça très clair au contraire :P Cocoa c'est le framework généraliste... Core Foundation le framework bas niveau donnant accès à la gestion des collections et autres accès systèmes. Core Graphics framework bas niveau gérant les graphismes Core Animation framework permettant l'optimisation des animations Core Video framework bas niveau gérant les vidéos, Core Audio framework bas niveau pour l'audio, etc.
C'est sûr ça fait beaucoup de trucs, mais vaut mieux que ce soit en plusieurs frameworks qu'en une seule grosse usine à gaz
Moi je trouve ça très clair au contraire :P Cocoa c'est le framework généraliste... Core Foundation le framework bas niveau donnant accès à la gestion des collections et autres accès systèmes. Core Graphics framework bas niveau gérant les graphismes Core Animation framework permettant l'optimisation des animations Core Video framework bas niveau gérant les vidéos, Core Audio framework bas niveau pour l'audio, etc.
C'est sûr ça fait beaucoup de trucs, mais vaut mieux que ce soit en plusieurs frameworks qu'en une seule grosse usine à gaz
+1
-1
Ce que je vois dans votre liste c'est un congloméra de librairies plutôt décousues. Où est la cohérence dans tout ça? J'entends par là quelque chose de raisonné dans un contexte globlal. En l'état c'est plutôt des librairies développées les unes après les autres et qu'on a fait cohabiter tant bien que mal.
Je rejoins donc Philippe sur le souhait d'une bibliothèque C unifiée (en plusieurs morceaux ou pas). On pourrait alors avoir un véritable parallèle à Cocoa.
La grande force de Cocoa à mon sens est justement cette clareté de manière générale. Core Animation en est néanmoins un beau contre exemple où l'on se retrouve à mélanger haut niveau et bas niveau sans même savoir pourquoi (une librairie qui sent le développement à l'arache comme on en trouve un peu trop ces derniers temps dans OSX).
Ces bibliothèques (et pas " librairies ") ont chacune leur spécialité et leur doc associée qui est bien faite ???
MDR sur la doc bien faites. Tu as déjà jeté un oeil à la doc d'IOKit par exemple? Et c'est pas les exemples qui vont avec qui aident. Notre ami Wisky qui s'arrache les cheveux sur les communication usb peut confirmer.
Ok, c'est pas pire que la MSDN (quoi que, des fois...) mais quand même. Apple a de très gros progrès à faire de ce côté.
On ne peut réellement unifié que ce qui est unifiable, je trouve les séparations actuelles très claire et propre, et je trouve aussi la doc très pratique et très utile ; vous allez dire "t'es un fan boy tout ce que fait Apple est formidable", bah non je m'excuse, ce que je pense là -dessus est tout à fait réfléchis.
Si vous avez l'impression que tout est décousu, c'est tout simplement parce qu'il n'y a pas de réel lien entre chaque framework parce qu'ils ne s'appliquent aux même domaines. Il faut utiliser les bons outils aux bons endroits, et pour l'instant moi je n'ai jamais eu de problème avec la doc d'Apple ou les outils d'Apple... Les problèmes que j'ai eu avec ça, c'est lorsque je n'utilisais pas les bons outils...
Au passage IOKit c'est un peu la vieille garde de Mac OS X... Pour ne pas dire "legacy"...
Ces bibliothèques (et pas " librairies ") ont chacune leur spécialité et leur doc associée qui est bien faite ???
MDR sur la doc bien faites. Tu as déjà jeté un oeil à la doc d'IOKit par exemple? Et c'est pas les exemples qui vont avec qui aident. Notre ami Wisky qui s'arrache les cheveux sur les communication usb peut confirmer.
Ok, c'est pas pire que la MSDN (quoi que, des fois...) mais quand même. Apple a de très gros progrès à faire de ce côté.
Les exemples font partie intégrante de la doc... Pour faire un plugin Finder par exemple, il n'y a que l'exemple de valable :P
On ne peut réellement unifié que ce qui est unifiable,
Pourtant Cocoa s'en sort déjà pas mal dans les grandes lignes.
dans 1229290008:
On ne peut réellement unifié que ce qui est unifiable je trouve les séparations actuelles très claire et propre, et je trouve aussi la doc très pratique et très utile ; vous allez dire "t'es un fan boy tout ce que fait Apple est formidable", bah non je m'excuse, ce que je pense là -dessus est tout à fait réfléchis.
A mon sens, tu as plutôt une vision d'expert qui baigne dedans depuis longtemps. Cela te parait claire parce que tu en connais bien les rouages et non parce qu'ils sont bien huilés. Au final, on est peut-être pas les mieux placés pour avoir un avis objectif sur cette question.
dans 1229291204:
Les exemples font partie intégrante de la doc... Pour faire un plugin Finder par exemple, il n'y a que l'exemple de valable :P
On ne peut réellement unifié que ce qui est unifiable,
Pourtant Cocoa s'en sort déjà pas mal dans les grandes lignes.
Justement, Cocoa permet de faire tout ce que les autres frameworks permettent, mais avec moins de finesse, de souplesse, et surtout mieux optimisé. Cocoa réuni surtout la haut niveau, les cores c'est plus bas niveau.
dans 1229293451:
dans 1229290008:
On ne peut réellement unifié que ce qui est unifiable je trouve les séparations actuelles très claire et propre, et je trouve aussi la doc très pratique et très utile ; vous allez dire "t'es un fan boy tout ce que fait Apple est formidable", bah non je m'excuse, ce que je pense là -dessus est tout à fait réfléchis.
A mon sens, tu as plutôt une vision d'expert qui baigne dedans depuis longtemps. Cela te parait claire parce que tu en connais bien les rouages et non parce qu'ils sont bien huilés. Au final, on est peut-être pas les mieux placés pour avoir un avis objectif sur cette question.
Il est clair qu'étant développeur de métier ma vision est sans doute différente de la plupart des gens... Bon alors en tant que professionnel, je n'ai pas encore trouvé de la doc d'aussi bonne qualité que celle d'Apple. Il "suffit juste" (c'est sûr que ça demande de la pratique quand on ne sait pas trop s'y prendre) de savoir l'utiliser.
Bon alors en tant que professionnel, je n'ai pas encore trouvé de la doc d'aussi bonne qualité que celle d'Apple. Il "suffit juste" (c'est sûr que ça demande de la pratique quand on ne sait pas trop s'y prendre) de savoir l'utiliser.
En tant qu'amateur (forcené), je trouve également la doc (que j'ai lue) bien faite, je dis simplement que beaucoup d'innovations ont été faites dans ces années 2000, et qu'Apple n'a pas eu le temps de suivre la ligne directrice qu'il s'était fixée avec Cocoa. Il est grand temps qu'il réorganise tout cela de fond en comble. Pourquoi a-t-on des CGImage en parallèle avec des NSImage ? Bon, acceptons deux niveaux pour admettre une différence par la complexité, la rapidité et le niveau de programmation. Mais pourquoi alors les CIImage, les CGDataProvider, les CGImageSource ... et j'en passe. C'est clairement le résultat d'un historique d'équipes différentes de développeurs, que certes les anciens ou très actifs arrivent à manipuler masi les autres ? Il faut faire le ménage pour ceux qui arrivent sur Mac.
Entièrement d'accord avec toi Philippe. Je rajouterai même qu'il m'a toujours semblé un peu dégeulasse de ne pas retrouver la simplicité d'utilisation de NSImage avec CIImage ou CGImage. Je sais que ça a un but différent, mais ça me tue de ne pas pouvoir initialiser une CGImage aussi simplement que NSImage.. Et puis y'a des trucs tout con qu'on peut faire avec NSImage qu'on ne retrouve pas avec CIImage ou CGImage.. berf..
Euh, CGImage c'est du C, ne confondons pas tout CIImage, si je ne me trompe pas c'est un mini wrapper Obj-C au dessus de Quartz Quant à NSImage, il me semble que sous le capot il y a soit des CGImage, soit des CIImage, avec des optimisations de cache etc.
Il faut faire le ménage pour ceux qui arrivent sur Mac.
Absolument pas d'accord ! Dans ce que tu cites, il y a en général la couche C, et la couche Cocoa au dessus de la couche C correspondante (et qui l'utilise donc !). Faire le ménage ça voudrait dire supprimer l'interface publique de la couche C...
Pourquoi supprimer la possibilité d'optimisation aux développeurs ? Ceux qui ne veulent pas utiliser la couche C en ont le droit, c'est leur problème...
Bon alors en tant que professionnel, je n'ai pas encore trouvé de la doc d'aussi bonne qualité que celle d'Apple. Il "suffit juste" (c'est sûr que ça demande de la pratique quand on ne sait pas trop s'y prendre) de savoir l'utiliser.
J'ai souvenir des produits Borland qui étaient de très bonne facture en terme de documentation. Les amateurs de Delphi ou autre pourront confirmer.
Avec la doc Apple, on passe bien souvent plus de temps à scruter des forums ou des listes de discussions pour trouver la personne qui s'est posée la même question avant nous.
dans 1229329768:
Faire le ménage ça voudrait dire supprimer l'interface publique de la couche C...
Je pense que Philippe entendait par là de clarifier un peu la situation.
dans 1229329768:
Ceux qui ne veulent pas utiliser la couche C en ont le droit, c'est leur problème...
Non, ce n'est pas le cas. Par exemple, Core Animation t'impose de passer par la création d'un CGImageRef pour charger le content d'un layer. Idem pour la gestion des couleurs sous CA qui passe systématiquement par des CGColorRef. Où est la logique la dedans pour un framework Cocoa? Et pourtant Core Animation c'est loin d'être du "Legacy"...
Avec la doc Apple, on passe bien souvent plus de temps à scruter des forums ou des listes de discussions pour trouver la personne qui s'est posée la même question avant nous.
En toute honnêteté, je faisais un peu ça au début, mais ça fait longtemps que je n'ai pas eu besoin de chercher autre part que dans la doc d'Apple, sauf peut-être pour quelques tutoriels d'introduction, mais en général, une fois lancé, la doc Apple me suffit...
Son seul problème étant qu'elle est très volumineuse et qu'il s'attarde sur beaucoup de détails qui peuvent gêner la compréhension globale.
Ceux qui ne veulent pas utiliser la couche C en ont le droit, c'est leur problème...
Non, ce n'est pas le cas. Par exemple, Core Animation t'impose de passer par la création d'un CGImageRef pour charger le content d'un layer. Idem pour la gestion des couleurs sous CA qui passe systématiquement par des CGColorRef. Où est la logique la dedans pour un framework Cocoa? Et pourtant Core Animation c'est loin d'être du "Legacy"..
Effectivement... Je n'ai jamais utilise Core Animation (ni Core Video, ni Core Audio, ni Core Image en fait...). Mais CoreFoundation / Foundation suit une logique.
Après, c'est quand même logique quelque part ; ils ne vont pas s'amuser à prendre une NSImage pour gérer tous les cas et conversions coûteuses derrière. Mais c'est vrai qu'un mini-wrapper Obj-C CAImage avec une interface proche de NSImage aurait été malin...
Le plus drôle c'est qu'il ne lui reste rien à apprendre pour être capable de l'utiliser sans problème. ;D
Héhé Nan mais jvais m'y mettre. En fait j'ai commencé Cocoa avec des tutos à 14-15 ans (j'en ai 20 maintenant), et comme je viens de rentrer à SupInfo et que le C est 'achement au programme.. Juste pour dire que je m'étais mis à Cocoa de moi même, mais que j'attendais surtout SupInfo pour le reste, y'a que ça qui me boostera
Je suis assez d'accord avec les derniers posts de psychoh13, à savoir que : - On aura jamais un unique framework unifiant tout. Déjà parce que c'est pas logique, il faut mieux avec un framework pour chaque chose spécialisé, un spécialisé dans le traitement vidéo poussé, l'autre dans la sécurité, l'autre dans les entrées/sorties... - MAIS je suis d'accord qu'il faut par contre une cohérence entre les frameworks Apple. Qu'on ait pas à réapprendre tout un framework quand on a à en utiliser un pour la première fois, mais qu'on retrouve nos marques avec les autres frameworks, et qu'on puisse facilement manipuler les mêmes données. L'exemples des CGImageRef/NSImage/CIImage est flagrant de ce côté.
- Franchement je suis loin d'être un programmeur assidu d'Objective-C, en gros je n'en fait que tous les 36 du mois chez moi quand j'ai le temps et que j'en ai pas marre d'avoir fait du C++ au taf toute la journée (bon ok ces derniers temps j'en ai fait un peu plus genre un WE sur 2 pour me plonger dans l'iPhone mais bon c'est loin d'être tous les soirs)... pourtant, dans 80% des cas la doc Apple non seulement me suffit, mais en plus je la trouve super bien foutue - MAIS je précise quand même qu'à mes débuts, je ne savais pas forcément bien l'utiliser et concernant les bases et les automatismes je trouvais pas mal de réponses dans les forums plutôt que la doc Apple. - Et c'est vrai qu'autant pour les frameworks haut niveaux et ne nécessitant pas de descendre en C pour raisons d'optimisation, c'est plutôt bien foutu, cohérent et bien documenté... autant pour les frameworks bas niveaux ou orientés optimisation, je pense à CoreAnimation, mais aussi IOKit, ... ça c'est le boxon et on retrouve pas nos marques par rapport à Cocoa c'est sûr !
Je le vois déjà bien quand je veux faire des trucs sur iPhone et que le wrapper en Objective-C n'existe pas sous iPhone OS là où il existait sous OSX, ne pense en particulier aux NSBezierPath pour dessiner dans une CustomView... qu'ils n'aient pas implémenté NSBezierPath aussi complet que sur OSX ok, mais devoir passer par du C et attaquer direct Quartz, berk :P
Pour résumer, c'est bien foutu quand on utilise Cocoa et les frameworks haut niveau qu'il y a autour, bien documenté et cohérent... mais ça part vite en c**ille quand c'est plus bas niveau genre IOKit ou même CALayer où soit ce n'est pas aussi bien documenté soit ça manque de cohérence avec Cocoa.
Il faut faire attention quand on compare UIKit et Cocoa, UIKit est clairement un framework allégé et optimisé pour l'iPhone pour des raisons évidentes : les ressources limités. D'ailleurs, quand on regarde un peu plus en détail UIKit, c'est non seulement un framework optimisé pour l'iPhone, mais en plus c'est un framework qui a bénéficié des leçons apprises lors du développement et de l'utilisation à grande échelle de Cocoa, je pense par exemple à la classe UIView qui est beaucoup plus légère que NSView et qui a permis de se passer des classes graphiques comme NSCell. Parce qu'il faut savoir que si NSCell existe c'est parce que les objets NSView sont très lourds, de vrais usines à gaz, alors pour éviter d'en créer beaucoup ils ont conçu les NSCell qui sont plus légères, mais dans l'iPhone au contraire, on conseille de beaucoup utiliser UIView, simplement parce que ces objets sont beaucoup plus légers que leurs homologues Cocoa...
De même je le répète, il ne faut pas oublier que Cocoa avait une vocation très généralistes, pour l'iPhone, étant donné les contraintes, Apple en a profité pour repartir à zéro question interface et ne pas trop surcharger la partie objet et plutôt optimiser les graphismes avec des appels direct à quartz...
Mais comme je l'ai déjà dit, pour être capable de bien utiliser les outils outils Apple et notamment la doc, il faut de la pratique et de la persévérance, pour notamment arriver à voir quel outil utilisé et surtout si l'outil qu'on pense utiliser est réellement approprié... Et à force, on arrive à voir que chaque chose a sa place ; même si ça a l'air un peu décousu, c'est surtout à cause de l'objectif généraliste de Cocoa... Ce que je ne lui reproche aucunement, au contraire !
Il faut faire attention quand on compare UIKit et Cocoa, UIKit est clairement un framework allégé et optimisé pour l'iPhone pour des raisons évidentes : les ressources limités. [...] De même je le répète, il ne faut pas oublier que Cocoa avait une vocation très généralistes, pour l'iPhone, étant donné les contraintes, Apple en a profité pour repartir à zéro question interface et ne pas trop surcharger la partie objet et plutôt optimiser les graphismes avec des appels direct à quartz...
Heu on est bien d'accord que Apple a eu raison de repartir de zéro pour l'iPhone, vu que ce ne sont pas les mêmes contraintes, ressources limitées, etc. Ca je dis pas le contraire. D'ailleurs je suis très content de ce qu'ils ont fait de UIView par rapport à son homologue NSView : optimisé, avec juste de quoi faire des animations basiques facilement si on veut pas se lancer dans CoreAnimation, et pas lourd côté mémoire comme objet, donc parfait partout...
Mais justement, pourquoi ils n'ont pas fait la même chose pour NSBezierPath ? Pourquoi ils n'ont pas créé un UIBezierPath, super alléger, juste pour dessiner des rectangles et des ovales à la limite sans forcément permettre de tracer des courbes de bezier complexes s'ils trouvaient que ça faisait trop côté surcharge pour l'iPhone à la limite...
J'ai fait justement une petite "démo" ce WE à un pote, un petit jeu qu'il a programmé qu'il voulait porter sur iPhone... quand on en est arrivé à la phase où l'on a voulu dessiner des ronds vides et pleins... ben j'ai pas su comment faire, et j'ai pas trouvé clairement dans la doc de suite (et plus rapidement par les forums, même si la doc Apple existe) : en fait faut faire appel direct à Quartz, en C pur, avec des CGContextRef et tout. un [tt][[UIBezierPath bezierPathWithOvalInRect:r] fill][/tt] qui fait les appels à Quartz sous-jacents aurait été tellement plus simple à utiliser... ça m'a moitié fait peur l'équivalent en C pur ^^ (bon ok c'est pas méchant mais j'ai toujours trouvé que ça faisait tâche en plein milieu du code ObjC)
Après, si les programmeurs de jeu 3D qui ont besoin d'optimiser et tout veulent faire des appels à Quartz pour accélérer les graphismes, libres à eux... justement, dans la doc qui parle du Drawing pour iPhone ils montrent qu'il y a plusieurs façon de faire, par OpenGL, par Quartz... rien ne les empêchent de laisser à la fois le bas niveau (Quartz) et mettre une API haut niveau (UIKit) pour faciliter la prise en main ou pour quand on préfère du code clair à du code super-optimisé-là -où-c'est-pas-nécessaire :P
Je pense que c'est aussi ça qui me gène, à la fois sous OSX la non homogéneà¯té entre certains frameworks, qu'il y ait des API plus bas niveau ou plus optimisées on est tout à fait d'accord, avec un framework par domaine, ok, mais tant qu'à faire autant reprendre les mêmes conventions ! Et qu'il y ait encore tant d'API en C pur dans l'iPhone qui ne soient pas wrappées dans des API en Objective-C (je pense entre autres au Carnet d'Adresses). Pour tous les débutants qui n'ont jamais fait d'objective-C avant et doivent mélanger dans un même programme à la fois l'objet dans le langage ObjC et le C pur avec appel de fonctions, sans trop savoir pourquoi des fois faut faire en C des fois en ObjC... déjà moi je trouve ça super dommage voire un grand manque, mais pour avoir donné qques "formations" iPhone à d'autres je vous assure que ça en gêne plus d'un.
Ceci dit pour en revenir aux API OSX et laisser l'iPhone de côté, c'est quand même mieux sous OSX ou tout ou presque est "wrappé", mais tout n'est pas toujours homogène entre les divers frameworks et API, et ça c'est très con aussi parfois. Quand on n'utilise que Cocoa on ne s'en rend pas compte, mais dès qu'on va vers CA ou IOKit... Gageons que Snow Leopard mettra un peu d'ordre !
Réponses
Ces bibliothèques (et pas " librairies ") ont chacune leur spécialité et leur doc associée qui est bien faite ???
Ce qui est faux :P Une partie de Carbon n'est pas compilable en 64 bits... Cette partie est à réécrire
http://www.roughlydrafted.com/2008/08/26/road-to-mac-os-x-106-snow-leopard-64-bits/
Il faudra bien... Il y a certaines de ces fonctions qu'on ne peut remplacer par aucune en 64 bits.
Apple donne prépare un Cocoa qui sera totalement libéré de Carbon, tout ce qu'on peut faire en Carbon sera possible sans Carbon directement dans Cocoa, quel intérêt à ce moment de convertir Carbon en 64 bits ?
C'est de toutes façons un framework de transition qu'Apple n'a jamais cherché à conserver au-delà de cette transition, ça fait longtemps que ç'aurait du disparaà®tre, mais bon ça traà®ne un peu...
Non il y en a trop
Faut pas faire semblant de pas comprendre.
Qu'il réécrive ou pas, on s'en fout, ce qui compte c'est qu'ils éclaircissent la situation, afin que cela ne deviennent pas une affaire de spécialistes spécialisés qui savent qu'à la page 62543, on trouve une indication qui renvoie à la page 1246821.
Sachant qu'il est difficile de dépasser UINT_MAX ;D
C'est ce que j'entendais par " réécrire "...
J'avais compris que tu disais qu'il suffisait de prendre le même code et de changer le nom :
" le remplacement du C de Carbon par Obj-C n'était qu'une question de dénomination des routines C "
Moi je trouve ça très clair au contraire :P
Cocoa c'est le framework généraliste...
Core Foundation le framework bas niveau donnant accès à la gestion des collections et autres accès systèmes.
Core Graphics framework bas niveau gérant les graphismes
Core Animation framework permettant l'optimisation des animations
Core Video framework bas niveau gérant les vidéos,
Core Audio framework bas niveau pour l'audio, etc.
C'est sûr ça fait beaucoup de trucs, mais vaut mieux que ce soit en plusieurs frameworks qu'en une seule grosse usine à gaz
Ouais, enfin ce que je voulais dire c'est que Carbon restera en 32 bits, et que les fonctions qui ne sont pas encore couvertes par Cocoa le seront.
Ben oui, c'est exactement ce que j'ai dit :P Philippe avait l'air de dire que pour passer du Carbon au Cocoa il faudrait juste changer le noms des fonctions, et j'ai dit qu'il faudrait en réécrire (ce qui supposait dans le passage de Carbon à Cocoa).
+1
-1
Ce que je vois dans votre liste c'est un congloméra de librairies plutôt décousues. Où est la cohérence dans tout ça? J'entends par là quelque chose de raisonné dans un contexte globlal. En l'état c'est plutôt des librairies développées les unes après les autres et qu'on a fait cohabiter tant bien que mal.
Je rejoins donc Philippe sur le souhait d'une bibliothèque C unifiée (en plusieurs morceaux ou pas). On pourrait alors avoir un véritable parallèle à Cocoa.
La grande force de Cocoa à mon sens est justement cette clareté de manière générale. Core Animation en est néanmoins un beau contre exemple où l'on se retrouve à mélanger haut niveau et bas niveau sans même savoir pourquoi (une librairie qui sent le développement à l'arache comme on en trouve un peu trop ces derniers temps dans OSX).
MDR sur la doc bien faites.
Ok, c'est pas pire que la MSDN (quoi que, des fois...) mais quand même. Apple a de très gros progrès à faire de ce côté.
Si vous avez l'impression que tout est décousu, c'est tout simplement parce qu'il n'y a pas de réel lien entre chaque framework parce qu'ils ne s'appliquent aux même domaines. Il faut utiliser les bons outils aux bons endroits, et pour l'instant moi je n'ai jamais eu de problème avec la doc d'Apple ou les outils d'Apple...
Les problèmes que j'ai eu avec ça, c'est lorsque je n'utilisais pas les bons outils...
Au passage IOKit c'est un peu la vieille garde de Mac OS X... Pour ne pas dire "legacy"...
Les exemples font partie intégrante de la doc... Pour faire un plugin Finder par exemple, il n'y a que l'exemple de valable :P
Pourtant Cocoa s'en sort déjà pas mal dans les grandes lignes.
A mon sens, tu as plutôt une vision d'expert qui baigne dedans depuis longtemps. Cela te parait claire parce que tu en connais bien les rouages et non parce qu'ils sont bien huilés. Au final, on est peut-être pas les mieux placés pour avoir un avis objectif sur cette question.
;D
Justement, Cocoa permet de faire tout ce que les autres frameworks permettent, mais avec moins de finesse, de souplesse, et surtout mieux optimisé.
Cocoa réuni surtout la haut niveau, les cores c'est plus bas niveau.
Il est clair qu'étant développeur de métier ma vision est sans doute différente de la plupart des gens... Bon alors en tant que professionnel, je n'ai pas encore trouvé de la doc d'aussi bonne qualité que celle d'Apple. Il "suffit juste" (c'est sûr que ça demande de la pratique quand on ne sait pas trop s'y prendre) de savoir l'utiliser.
En tant qu'amateur (forcené), je trouve également la doc (que j'ai lue) bien faite, je dis simplement que beaucoup d'innovations ont été faites dans ces années 2000, et qu'Apple n'a pas eu le temps de suivre la ligne directrice qu'il s'était fixée avec Cocoa. Il est grand temps qu'il réorganise tout cela de fond en comble.
Pourquoi a-t-on des CGImage en parallèle avec des NSImage ? Bon, acceptons deux niveaux pour admettre une différence par la complexité, la rapidité et le niveau de programmation. Mais pourquoi alors les CIImage, les CGDataProvider, les CGImageSource ... et j'en passe. C'est clairement le résultat d'un historique d'équipes différentes de développeurs, que certes les anciens ou très actifs arrivent à manipuler masi les autres ?
Il faut faire le ménage pour ceux qui arrivent sur Mac.
Je rajouterai même qu'il m'a toujours semblé un peu dégeulasse de ne pas retrouver la simplicité d'utilisation de NSImage avec CIImage ou CGImage. Je sais que ça a un but différent, mais ça me tue de ne pas pouvoir initialiser une CGImage aussi simplement que NSImage..
Et puis y'a des trucs tout con qu'on peut faire avec NSImage qu'on ne retrouve pas avec CIImage ou CGImage..
berf..
CIImage, si je ne me trompe pas c'est un mini wrapper Obj-C au dessus de Quartz
Quant à NSImage, il me semble que sous le capot il y a soit des CGImage, soit des CIImage, avec des optimisations de cache etc.
Il y a donc différents niveaux
Absolument pas d'accord !
Dans ce que tu cites, il y a en général la couche C, et la couche Cocoa au dessus de la couche C correspondante (et qui l'utilise donc !).
Faire le ménage ça voudrait dire supprimer l'interface publique de la couche C...
Pourquoi supprimer la possibilité d'optimisation aux développeurs ?
Ceux qui ne veulent pas utiliser la couche C en ont le droit, c'est leur problème...
J'ai souvenir des produits Borland qui étaient de très bonne facture en terme de documentation. Les amateurs de Delphi ou autre pourront confirmer.
Avec la doc Apple, on passe bien souvent plus de temps à scruter des forums ou des listes de discussions pour trouver la personne qui s'est posée la même question avant nous.
Je pense que Philippe entendait par là de clarifier un peu la situation.
Non, ce n'est pas le cas. Par exemple, Core Animation t'impose de passer par la création d'un CGImageRef pour charger le content d'un layer. Idem pour la gestion des couleurs sous CA qui passe systématiquement par des CGColorRef. Où est la logique la dedans pour un framework Cocoa? Et pourtant Core Animation c'est loin d'être du "Legacy"...
En toute honnêteté, je faisais un peu ça au début, mais ça fait longtemps que je n'ai pas eu besoin de chercher autre part que dans la doc d'Apple, sauf peut-être pour quelques tutoriels d'introduction, mais en général, une fois lancé, la doc Apple me suffit...
Son seul problème étant qu'elle est très volumineuse et qu'il s'attarde sur beaucoup de détails qui peuvent gêner la compréhension globale.
Effectivement... Je n'ai jamais utilise Core Animation (ni Core Video, ni Core Audio, ni Core Image en fait...).
Mais CoreFoundation / Foundation suit une logique.
Après, c'est quand même logique quelque part ; ils ne vont pas s'amuser à prendre une NSImage pour gérer tous les cas et conversions coûteuses derrière.
Mais c'est vrai qu'un mini-wrapper Obj-C CAImage avec une interface proche de NSImage aurait été malin...
Voilà à à à à à à
Oui, toi t'aimes pas le C, on sait :P
Mais faudra bien t'y mettre si tu veux faire de l'optimisation poussée
Héhé
Nan mais jvais m'y mettre. En fait j'ai commencé Cocoa avec des tutos à 14-15 ans (j'en ai 20 maintenant), et comme je viens de rentrer à SupInfo et que le C est 'achement au programme..
Juste pour dire que je m'étais mis à Cocoa de moi même, mais que j'attendais surtout SupInfo pour le reste, y'a que ça qui me boostera
Je suis assez d'accord avec les derniers posts de psychoh13, à savoir que :
- On aura jamais un unique framework unifiant tout. Déjà parce que c'est pas logique, il faut mieux avec un framework pour chaque chose spécialisé, un spécialisé dans le traitement vidéo poussé, l'autre dans la sécurité, l'autre dans les entrées/sorties...
- MAIS je suis d'accord qu'il faut par contre une cohérence entre les frameworks Apple. Qu'on ait pas à réapprendre tout un framework quand on a à en utiliser un pour la première fois, mais qu'on retrouve nos marques avec les autres frameworks, et qu'on puisse facilement manipuler les mêmes données. L'exemples des CGImageRef/NSImage/CIImage est flagrant de ce côté.
- Franchement je suis loin d'être un programmeur assidu d'Objective-C, en gros je n'en fait que tous les 36 du mois chez moi quand j'ai le temps et que j'en ai pas marre d'avoir fait du C++ au taf toute la journée (bon ok ces derniers temps j'en ai fait un peu plus genre un WE sur 2 pour me plonger dans l'iPhone mais bon c'est loin d'être tous les soirs)... pourtant, dans 80% des cas la doc Apple non seulement me suffit, mais en plus je la trouve super bien foutue
- MAIS je précise quand même qu'à mes débuts, je ne savais pas forcément bien l'utiliser et concernant les bases et les automatismes je trouvais pas mal de réponses dans les forums plutôt que la doc Apple.
- Et c'est vrai qu'autant pour les frameworks haut niveaux et ne nécessitant pas de descendre en C pour raisons d'optimisation, c'est plutôt bien foutu, cohérent et bien documenté... autant pour les frameworks bas niveaux ou orientés optimisation, je pense à CoreAnimation, mais aussi IOKit, ... ça c'est le boxon et on retrouve pas nos marques par rapport à Cocoa c'est sûr !
Je le vois déjà bien quand je veux faire des trucs sur iPhone et que le wrapper en Objective-C n'existe pas sous iPhone OS là où il existait sous OSX, ne pense en particulier aux NSBezierPath pour dessiner dans une CustomView... qu'ils n'aient pas implémenté NSBezierPath aussi complet que sur OSX ok, mais devoir passer par du C et attaquer direct Quartz, berk :P
Pour résumer, c'est bien foutu quand on utilise Cocoa et les frameworks haut niveau qu'il y a autour, bien documenté et cohérent... mais ça part vite en c**ille quand c'est plus bas niveau genre IOKit ou même CALayer où soit ce n'est pas aussi bien documenté soit ça manque de cohérence avec Cocoa.
D'ailleurs, quand on regarde un peu plus en détail UIKit, c'est non seulement un framework optimisé pour l'iPhone, mais en plus c'est un framework qui a bénéficié des leçons apprises lors du développement et de l'utilisation à grande échelle de Cocoa, je pense par exemple à la classe UIView qui est beaucoup plus légère que NSView et qui a permis de se passer des classes graphiques comme NSCell.
Parce qu'il faut savoir que si NSCell existe c'est parce que les objets NSView sont très lourds, de vrais usines à gaz, alors pour éviter d'en créer beaucoup ils ont conçu les NSCell qui sont plus légères, mais dans l'iPhone au contraire, on conseille de beaucoup utiliser UIView, simplement parce que ces objets sont beaucoup plus légers que leurs homologues Cocoa...
De même je le répète, il ne faut pas oublier que Cocoa avait une vocation très généralistes, pour l'iPhone, étant donné les contraintes, Apple en a profité pour repartir à zéro question interface et ne pas trop surcharger la partie objet et plutôt optimiser les graphismes avec des appels direct à quartz...
Mais comme je l'ai déjà dit, pour être capable de bien utiliser les outils outils Apple et notamment la doc, il faut de la pratique et de la persévérance, pour notamment arriver à voir quel outil utilisé et surtout si l'outil qu'on pense utiliser est réellement approprié... Et à force, on arrive à voir que chaque chose a sa place ; même si ça a l'air un peu décousu, c'est surtout à cause de l'objectif généraliste de Cocoa... Ce que je ne lui reproche aucunement, au contraire !
D'ailleurs je suis très content de ce qu'ils ont fait de UIView par rapport à son homologue NSView : optimisé, avec juste de quoi faire des animations basiques facilement si on veut pas se lancer dans CoreAnimation, et pas lourd côté mémoire comme objet, donc parfait partout...
Mais justement, pourquoi ils n'ont pas fait la même chose pour NSBezierPath ? Pourquoi ils n'ont pas créé un UIBezierPath, super alléger, juste pour dessiner des rectangles et des ovales à la limite sans forcément permettre de tracer des courbes de bezier complexes s'ils trouvaient que ça faisait trop côté surcharge pour l'iPhone à la limite...
J'ai fait justement une petite "démo" ce WE à un pote, un petit jeu qu'il a programmé qu'il voulait porter sur iPhone... quand on en est arrivé à la phase où l'on a voulu dessiner des ronds vides et pleins... ben j'ai pas su comment faire, et j'ai pas trouvé clairement dans la doc de suite (et plus rapidement par les forums, même si la doc Apple existe) : en fait faut faire appel direct à Quartz, en C pur, avec des CGContextRef et tout.
un [tt][[UIBezierPath bezierPathWithOvalInRect:r] fill][/tt] qui fait les appels à Quartz sous-jacents aurait été tellement plus simple à utiliser... ça m'a moitié fait peur l'équivalent en C pur ^^ (bon ok c'est pas méchant mais j'ai toujours trouvé que ça faisait tâche en plein milieu du code ObjC)
Après, si les programmeurs de jeu 3D qui ont besoin d'optimiser et tout veulent faire des appels à Quartz pour accélérer les graphismes, libres à eux... justement, dans la doc qui parle du Drawing pour iPhone ils montrent qu'il y a plusieurs façon de faire, par OpenGL, par Quartz... rien ne les empêchent de laisser à la fois le bas niveau (Quartz) et mettre une API haut niveau (UIKit) pour faciliter la prise en main ou pour quand on préfère du code clair à du code super-optimisé-là -où-c'est-pas-nécessaire :P
Je pense que c'est aussi ça qui me gène, à la fois sous OSX la non homogéneà¯té entre certains frameworks, qu'il y ait des API plus bas niveau ou plus optimisées on est tout à fait d'accord, avec un framework par domaine, ok, mais tant qu'à faire autant reprendre les mêmes conventions ! Et qu'il y ait encore tant d'API en C pur dans l'iPhone qui ne soient pas wrappées dans des API en Objective-C (je pense entre autres au Carnet d'Adresses). Pour tous les débutants qui n'ont jamais fait d'objective-C avant et doivent mélanger dans un même programme à la fois l'objet dans le langage ObjC et le C pur avec appel de fonctions, sans trop savoir pourquoi des fois faut faire en C des fois en ObjC... déjà moi je trouve ça super dommage voire un grand manque, mais pour avoir donné qques "formations" iPhone à d'autres je vous assure que ça en gêne plus d'un.
Ceci dit pour en revenir aux API OSX et laisser l'iPhone de côté, c'est quand même mieux sous OSX ou tout ou presque est "wrappé", mais tout n'est pas toujours homogène entre les divers frameworks et API, et ça c'est très con aussi parfois. Quand on n'utilise que Cocoa on ne s'en rend pas compte, mais dès qu'on va vers CA ou IOKit... Gageons que Snow Leopard mettra un peu d'ordre !