Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Hubert Figuiere
Ma question a certaienement été posée, mais j'ai chercher dans les archives du groupe et j'ai rien trouvé...
Au que oui, mais pas forcément ici.
Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une application os 9 et os X...
Tandis que Cocoa est lui natif os X et rien que os X...
Comme Mac os 9 est doucement abandonné par Apple. Pourquoi alors maintenir Carbon aussi...
Cocoa requiert Carbon pour un certain nombre de techno Apple: AppleScript QuickTime
entre autres. Quand tu programme en Cocoa, tu fait du Carbon sans le savoir (comme M Jourdain et sa prose). Rien que la gestion des évenement et des menus.
Il arrivera bien un moment ou l'on aura plus besoin de programer en Carbon.
Cf ci-dessus. Tant que ca existera, Carbon restera indispensable.
Cela simplifierai le système non ?
Oui, mais non.
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
La frontière est de plus en plus floue. Disons qu'effectivement faire du Carbon sans Cocoa c'est évident. Faire du Cocoa sans toucher à Carbon, ca l'est moins.
Hub
Ma question a certaienement été posée, mais j'ai chercher dans les
archives du groupe et j'ai rien trouvé...
Au que oui, mais pas forcément ici.
Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une
application os 9 et os X...
Tandis que Cocoa est lui natif os X et rien que os X...
Comme Mac os 9 est doucement abandonné par Apple. Pourquoi alors
maintenir Carbon aussi...
Cocoa requiert Carbon pour un certain nombre de techno Apple:
AppleScript
QuickTime
entre autres.
Quand tu programme en Cocoa, tu fait du Carbon sans le savoir (comme M
Jourdain et sa prose). Rien que la gestion des évenement et des menus.
Il arrivera bien un moment ou l'on aura plus besoin de programer en
Carbon.
Cf ci-dessus. Tant que ca existera, Carbon restera indispensable.
Cela simplifierai le système non ?
Oui, mais non.
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même
système....
La frontière est de plus en plus floue. Disons qu'effectivement faire
du Carbon sans Cocoa c'est évident. Faire du Cocoa sans toucher à
Carbon, ca l'est moins.
Ma question a certaienement été posée, mais j'ai chercher dans les archives du groupe et j'ai rien trouvé...
Au que oui, mais pas forcément ici.
Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une application os 9 et os X...
Tandis que Cocoa est lui natif os X et rien que os X...
Comme Mac os 9 est doucement abandonné par Apple. Pourquoi alors maintenir Carbon aussi...
Cocoa requiert Carbon pour un certain nombre de techno Apple: AppleScript QuickTime
entre autres. Quand tu programme en Cocoa, tu fait du Carbon sans le savoir (comme M Jourdain et sa prose). Rien que la gestion des évenement et des menus.
Il arrivera bien un moment ou l'on aura plus besoin de programer en Carbon.
Cf ci-dessus. Tant que ca existera, Carbon restera indispensable.
Cela simplifierai le système non ?
Oui, mais non.
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
La frontière est de plus en plus floue. Disons qu'effectivement faire du Carbon sans Cocoa c'est évident. Faire du Cocoa sans toucher à Carbon, ca l'est moins.
Hub
david.remacle
Hubert Figuiere wrote:
Cocoa requiert Carbon pour un certain nombre de techno Apple: AppleScript QuickTime
entre autres. Quand tu programme en Cocoa, tu fait du Carbon sans le savoir (comme M Jourdain et sa prose). Rien que la gestion des évenement et des menus.
Ah ok merci pour l'info... je n'avais pas bien compris.. maintenant oui :) [SNIP]
Cela simplifierai le système non ?
Oui, mais non.
Donc on aura toujours le choix entre Carbon et Cocoa alors ?
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
La frontière est de plus en plus floue. Disons qu'effectivement faire du Carbon sans Cocoa c'est évident. Faire du Cocoa sans toucher à Carbon, ca l'est moins.
ok....
Hub
Merci
Hubert Figuiere <hub@free.fr> wrote:
Cocoa requiert Carbon pour un certain nombre de techno Apple:
AppleScript
QuickTime
entre autres.
Quand tu programme en Cocoa, tu fait du Carbon sans le savoir (comme M
Jourdain et sa prose). Rien que la gestion des évenement et des menus.
Ah ok merci pour l'info... je n'avais pas bien compris.. maintenant oui
:)
[SNIP]
Cela simplifierai le système non ?
Oui, mais non.
Donc on aura toujours le choix entre Carbon et Cocoa alors ?
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même
système....
La frontière est de plus en plus floue. Disons qu'effectivement faire
du Carbon sans Cocoa c'est évident. Faire du Cocoa sans toucher à
Carbon, ca l'est moins.
Cocoa requiert Carbon pour un certain nombre de techno Apple: AppleScript QuickTime
entre autres. Quand tu programme en Cocoa, tu fait du Carbon sans le savoir (comme M Jourdain et sa prose). Rien que la gestion des évenement et des menus.
Ah ok merci pour l'info... je n'avais pas bien compris.. maintenant oui :) [SNIP]
Cela simplifierai le système non ?
Oui, mais non.
Donc on aura toujours le choix entre Carbon et Cocoa alors ?
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
La frontière est de plus en plus floue. Disons qu'effectivement faire du Carbon sans Cocoa c'est évident. Faire du Cocoa sans toucher à Carbon, ca l'est moins.
ok....
Hub
Merci
Hubert Figuiere
Cela simplifierai le système non ?
Oui, mais non.
Donc on aura toujours le choix entre Carbon et Cocoa alors ?
Sans vouloir prédire l'avenir, oui. Peut-être qu'un jour l'évolution de Carbon s'arrêtera (je dis bien peut-être), mais sa disparition n'est à mon avis même pas à envisager. Pense à tous les trucs Adobe, Microsoft, Macromedia, etc.
Hub
Cela simplifierai le système non ?
Oui, mais non.
Donc on aura toujours le choix entre Carbon et Cocoa alors ?
Sans vouloir prédire l'avenir, oui. Peut-être qu'un jour l'évolution
de Carbon s'arrêtera (je dis bien peut-être), mais sa disparition
n'est à mon avis même pas à envisager. Pense à tous les trucs Adobe,
Microsoft, Macromedia, etc.
Donc on aura toujours le choix entre Carbon et Cocoa alors ?
Sans vouloir prédire l'avenir, oui. Peut-être qu'un jour l'évolution de Carbon s'arrêtera (je dis bien peut-être), mais sa disparition n'est à mon avis même pas à envisager. Pense à tous les trucs Adobe, Microsoft, Macromedia, etc.
Hub
david.remacle
Hubert Figuiere wrote:
Sans vouloir prédire l'avenir, oui. Peut-être qu'un jour l'évolution de Carbon s'arrêtera (je dis bien peut-être), mais sa disparition n'est à mon avis même pas à envisager. Pense à tous les trucs Adobe, Microsoft, Macromedia, etc.
Hub
Ah ben, oui...
En tout cas merci pour tes explication... j'y vois un peu plus clair dans cette histoire... :)
Hubert Figuiere <hub@free.fr> wrote:
Sans vouloir prédire l'avenir, oui. Peut-être qu'un jour l'évolution
de Carbon s'arrêtera (je dis bien peut-être), mais sa disparition
n'est à mon avis même pas à envisager. Pense à tous les trucs Adobe,
Microsoft, Macromedia, etc.
Hub
Ah ben, oui...
En tout cas merci pour tes explication... j'y vois un peu plus clair
dans cette histoire... :)
Sans vouloir prédire l'avenir, oui. Peut-être qu'un jour l'évolution de Carbon s'arrêtera (je dis bien peut-être), mais sa disparition n'est à mon avis même pas à envisager. Pense à tous les trucs Adobe, Microsoft, Macromedia, etc.
Hub
Ah ben, oui...
En tout cas merci pour tes explication... j'y vois un peu plus clair dans cette histoire... :)
phpinfo
David Remacle wrote:
[...] Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une application os 9 et os X...
Pas seulement, on peut très bien faire un logiciel en utilisant le Framework Carbon et que ça ne fonctionne que sur OS X ;-) Sinon effectivement Carbon est issut de MacOS 9 (refonte) avec pour principal fonction de faciliter la passage de macOS 9 à X pour les développeurs MacOS 9.
Tandis que Cocoa est lui natif os X et rien que os X...
Oui Cocoa est issut de Next (ancêtre de OSX pour résumer). Cocoa permet aux développeurs next de passer à OSX plus facilement...
[...] Comme Mac os 9 est doucement abandonné par Apple. Pourquoi alors maintenir Carbon aussi...
MasOS 9 est abandonné par Apple. Mais Carbon continu et continuera a vivre longtemps, bon nombre de logiciel même de chez Apple sont Carbon. Il faut aussi dire que Cocoa n'a pas été très complet au début d'OS X et que pour accéder a toutes les fonctionnalités il fallait parfois faire du Carbon quand même... Un joyeux casse tête...
[...] Il arrivera bien un moment ou l'on aura plus besoin de programer en Carbon.
Cela simplifierai le système non ?
Pas sur, ce sont des framework pour les développeurs. Le support de l'un et l'autre n'a guère d'influence sur l'OS lui même.
[...] Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
Permettre aux développeurs le choix entre 2 frameworks suivant leurs impératifs (portage depuis OS9 ou next par exemple, multiplateforme via Java, etc...). Chaque Framework a ces capacités, ses avantages et inconvénients.
Perso par exemple, étant ancien développeur MacOS 9, je connais Carbon, pas Cocoa. J'ai donc tendance a utiliser Carbon, car plus facile pour moi, d'autant que je développe de moins en moins...
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
David Remacle <david.remacle@NOSpamtiscalinet.be> wrote:
[...]
Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une
application os 9 et os X...
Pas seulement, on peut très bien faire un logiciel en utilisant le
Framework Carbon et que ça ne fonctionne que sur OS X ;-)
Sinon effectivement Carbon est issut de MacOS 9 (refonte) avec pour
principal fonction de faciliter la passage de macOS 9 à X pour les
développeurs MacOS 9.
Tandis que Cocoa est lui natif os X et rien que os X...
Oui Cocoa est issut de Next (ancêtre de OSX pour résumer). Cocoa permet
aux développeurs next de passer à OSX plus facilement...
[...]
Comme Mac os 9 est doucement abandonné par Apple. Pourquoi alors
maintenir Carbon aussi...
MasOS 9 est abandonné par Apple.
Mais Carbon continu et continuera a vivre longtemps, bon nombre de
logiciel même de chez Apple sont Carbon.
Il faut aussi dire que Cocoa n'a pas été très complet au début d'OS X et
que pour accéder a toutes les fonctionnalités il fallait parfois faire
du Carbon quand même... Un joyeux casse tête...
[...]
Il arrivera bien un moment ou l'on aura plus besoin de programer en
Carbon.
Cela simplifierai le système non ?
Pas sur, ce sont des framework pour les développeurs. Le support de l'un
et l'autre n'a guère d'influence sur l'OS lui même.
[...]
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même
système....
Permettre aux développeurs le choix entre 2 frameworks suivant leurs
impératifs (portage depuis OS9 ou next par exemple, multiplateforme via
Java, etc...).
Chaque Framework a ces capacités, ses avantages et inconvénients.
Perso par exemple, étant ancien développeur MacOS 9, je connais Carbon,
pas Cocoa. J'ai donc tendance a utiliser Carbon, car plus facile pour
moi, d'autant que je développe de moins en moins...
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st>
Clarus, the DogCow <www.clarus.mac-fan.com>
[...] Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une application os 9 et os X...
Pas seulement, on peut très bien faire un logiciel en utilisant le Framework Carbon et que ça ne fonctionne que sur OS X ;-) Sinon effectivement Carbon est issut de MacOS 9 (refonte) avec pour principal fonction de faciliter la passage de macOS 9 à X pour les développeurs MacOS 9.
Tandis que Cocoa est lui natif os X et rien que os X...
Oui Cocoa est issut de Next (ancêtre de OSX pour résumer). Cocoa permet aux développeurs next de passer à OSX plus facilement...
[...] Comme Mac os 9 est doucement abandonné par Apple. Pourquoi alors maintenir Carbon aussi...
MasOS 9 est abandonné par Apple. Mais Carbon continu et continuera a vivre longtemps, bon nombre de logiciel même de chez Apple sont Carbon. Il faut aussi dire que Cocoa n'a pas été très complet au début d'OS X et que pour accéder a toutes les fonctionnalités il fallait parfois faire du Carbon quand même... Un joyeux casse tête...
[...] Il arrivera bien un moment ou l'on aura plus besoin de programer en Carbon.
Cela simplifierai le système non ?
Pas sur, ce sont des framework pour les développeurs. Le support de l'un et l'autre n'a guère d'influence sur l'OS lui même.
[...] Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
Permettre aux développeurs le choix entre 2 frameworks suivant leurs impératifs (portage depuis OS9 ou next par exemple, multiplateforme via Java, etc...). Chaque Framework a ces capacités, ses avantages et inconvénients.
Perso par exemple, étant ancien développeur MacOS 9, je connais Carbon, pas Cocoa. J'ai donc tendance a utiliser Carbon, car plus facile pour moi, d'autant que je développe de moins en moins...
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
gutkneco+news
David Remacle wrote:
Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une application os 9 et os X...
Servait. Une grande justification de Carbon a été la transition 9 -> X, mais depuis Apple a sérieusement modernisé Carbon et à l'heure actuelle Carbon n'a absolument pas à rougir de la comparaison avec Cocoa et n'en est pas moins 'natif'.
Les parties modernes de Carbon ne sont pas disponibles sous 9, en particulier, tout le joli système des HIView (qui sont à certains égards plus fins que les NSView d'ailleurs). Voir par exemple <http://developer.apple.com/technotes/tn2002/tn2074.html> pour une comparaison entre API 'ancien style' et moderne dans Carbon.
Et comme dit Hub, Cocoa et Carbon sont étroitement liés dans leurs implémentations mutuelles.
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
Laisser le choix au développeur: une API plutôt dynamique, Objective-C/Java, et une autre procédurale-avec-un-look-objet axée plus C/C++, l'une plus rapide d'accès, l'autre plus proche du métal nu.
Ol. -- Olivier Gutknecht
David Remacle <david.remacle@NOSpamtiscalinet.be> wrote:
Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une
application os 9 et os X...
Servait. Une grande justification de Carbon a été la transition 9 -> X,
mais depuis Apple a sérieusement modernisé Carbon et à l'heure actuelle
Carbon n'a absolument pas à rougir de la comparaison avec Cocoa et n'en
est pas moins 'natif'.
Les parties modernes de Carbon ne sont pas disponibles sous 9, en
particulier, tout le joli système des HIView (qui sont à certains égards
plus fins que les NSView d'ailleurs). Voir par exemple
<http://developer.apple.com/technotes/tn2002/tn2074.html> pour une
comparaison entre API 'ancien style' et moderne dans Carbon.
Et comme dit Hub, Cocoa et Carbon sont étroitement liés dans leurs
implémentations mutuelles.
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même
système....
Laisser le choix au développeur: une API plutôt dynamique,
Objective-C/Java, et une autre procédurale-avec-un-look-objet axée plus
C/C++, l'une plus rapide d'accès, l'autre plus proche du métal nu.
Donc, si j'ai bien compris, Carbon sert en fait a la comptabilité d'une application os 9 et os X...
Servait. Une grande justification de Carbon a été la transition 9 -> X, mais depuis Apple a sérieusement modernisé Carbon et à l'heure actuelle Carbon n'a absolument pas à rougir de la comparaison avec Cocoa et n'en est pas moins 'natif'.
Les parties modernes de Carbon ne sont pas disponibles sous 9, en particulier, tout le joli système des HIView (qui sont à certains égards plus fins que les NSView d'ailleurs). Voir par exemple <http://developer.apple.com/technotes/tn2002/tn2074.html> pour une comparaison entre API 'ancien style' et moderne dans Carbon.
Et comme dit Hub, Cocoa et Carbon sont étroitement liés dans leurs implémentations mutuelles.
Ou alors, j'ai pas bien compris l'utilité d'avoir deux APi pour un même système....
Laisser le choix au développeur: une API plutôt dynamique, Objective-C/Java, et une autre procédurale-avec-un-look-objet axée plus C/C++, l'une plus rapide d'accès, l'autre plus proche du métal nu.
