Je n'ai jamais été satisfait des newsreaders existant sous OSX.
Soit il s'agit de logiciels fonctionnant avec le bricolage Carbon et le
moins médiocre était Hogwasher (mais enfin se croire retourné sous OS9
était assez déplaisant)
Soit il s'agit d'authentiques apps Cocoa mais les deux principales ont
été inachevées (Newsflash, prometteur mais interrompu trop tôt - Halime
à l'interface confuse et lourdingue et heureusement interrompu...)
Unison lui est super : il fonctionne très simplement. Le moteur est
excellent. Même un usenet newbie n'aura pas de peine à se configurer.
Bien sur il s'agit d'une version 1 et l'interface laisse à désirer :
multitude de fenêtres... Ils n'ont pas encore suivi l'approche Safari,
iTunes, mais vont le faire.
Les groupes que je consulte ne sont pas des alt.binaries.* et donc sur les serveurs que j'utilise le temps de dégagement est de 30 jours.
Celui que j'utilise au bureau a une duree d'une semaine.
Je n'ai songé qu'aux Fai grand public. Désolé d'avoir oublié les nombreux serveurs d'entreprise.
Question : slrn est-il uniquement un lecteur "online" ?
Ca veut dire quoi? Je ne sais pas s'il existe des lecteurs qui sauvegardent le corps des messages. Je pense qu'ils font tous appel au serveur pour retrouver les corps des messages. Mais slrn ne sauvegarde meme pas les headers. L'arborscence des messages se limite aux nouveaux messages.
Tu as eu la réponse dans le reste de l'enfilade. Mon passé de RTCiste et de forçat des serveurs Wanadiens fait que j'ai gardé l'habitude de fonctionner en "offline", soit directement dans le soft comme avec Macsoup, soit via un serveur privé comme Hamster sur pc.
-- Joseph
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
Les groupes que je consulte ne sont pas des alt.binaries.* et donc sur
les serveurs que j'utilise le temps de dégagement est de 30 jours.
Celui que j'utilise au bureau a une duree d'une semaine.
Je n'ai songé qu'aux Fai grand public. Désolé d'avoir oublié les
nombreux serveurs d'entreprise.
Question : slrn est-il uniquement un lecteur "online" ?
Ca veut dire quoi? Je ne sais pas s'il existe des lecteurs qui sauvegardent
le corps des messages. Je pense qu'ils font tous appel au serveur pour
retrouver les corps des messages. Mais slrn ne sauvegarde meme pas les
headers. L'arborscence des messages se limite aux nouveaux messages.
Tu as eu la réponse dans le reste de l'enfilade.
Mon passé de RTCiste et de forçat des serveurs Wanadiens fait que j'ai
gardé l'habitude de fonctionner en "offline", soit directement dans le
soft comme avec Macsoup, soit via un serveur privé comme Hamster sur pc.
Les groupes que je consulte ne sont pas des alt.binaries.* et donc sur les serveurs que j'utilise le temps de dégagement est de 30 jours.
Celui que j'utilise au bureau a une duree d'une semaine.
Je n'ai songé qu'aux Fai grand public. Désolé d'avoir oublié les nombreux serveurs d'entreprise.
Question : slrn est-il uniquement un lecteur "online" ?
Ca veut dire quoi? Je ne sais pas s'il existe des lecteurs qui sauvegardent le corps des messages. Je pense qu'ils font tous appel au serveur pour retrouver les corps des messages. Mais slrn ne sauvegarde meme pas les headers. L'arborscence des messages se limite aux nouveaux messages.
Tu as eu la réponse dans le reste de l'enfilade. Mon passé de RTCiste et de forçat des serveurs Wanadiens fait que j'ai gardé l'habitude de fonctionner en "offline", soit directement dans le soft comme avec Macsoup, soit via un serveur privé comme Hamster sur pc.
-- Joseph
jim
Anonyme wrote:
Mon mac a planté, il a fait un kernel
Il faut dire KP, non?
Une sorte de ROM man de KP épais
-- FA: C'est perturbant... SP: Le gros inconvénient du changement, c'est que c'est plus pareil SP: qu'avant :-) -+- SP in LTQFRJ -+- MacOOOOOSX c'était mieux avaaaaannnnnt -+-
Anonyme <nospam@thanks.com> wrote:
Mon mac a planté, il a fait un kernel
Il faut dire KP, non?
Une sorte de ROM man de KP épais
--
FA: C'est perturbant...
SP: Le gros inconvénient du changement, c'est que c'est plus pareil
SP: qu'avant :-)
-+- SP in LTQFRJ -+- MacOOOOOSX c'était mieux avaaaaannnnnt -+-
-- FA: C'est perturbant... SP: Le gros inconvénient du changement, c'est que c'est plus pareil SP: qu'avant :-) -+- SP in LTQFRJ -+- MacOOOOOSX c'était mieux avaaaaannnnnt -+-
jim
nospam wrote:
Et si Carbon était de plus en plus Cocoatisé ? Ce qui caractérise Cocao c'est l'orienté objet non ?
De même les Romains ont conquis les Grecs si tu vois ce qu je veux dire. Et les Ricains après avoir battus les nazis ont eu le McCarthisme... Mais j'ai peur que la portée de ces allusions ne t'échappent.
Incroyable ! C'est une mine d'or pour le GMP-X ce gars-là !
-- FA: C'est perturbant... SP: Le gros inconvénient du changement, c'est que c'est plus pareil SP: qu'avant :-) -+- SP in LTQFRJ -+- MacOOOOOSX c'était mieux avaaaaannnnnt -+-
nospam <nospam@nospam.com> wrote:
Et si Carbon était de plus en plus Cocoatisé ?
Ce qui caractérise Cocao c'est l'orienté objet non ?
De même les Romains ont conquis les Grecs si tu vois ce qu je veux
dire. Et les Ricains après avoir battus les nazis ont eu le
McCarthisme... Mais j'ai peur que la portée de ces allusions ne
t'échappent.
Incroyable ! C'est une mine d'or pour le GMP-X ce gars-là !
--
FA: C'est perturbant...
SP: Le gros inconvénient du changement, c'est que c'est plus pareil
SP: qu'avant :-)
-+- SP in LTQFRJ -+- MacOOOOOSX c'était mieux avaaaaannnnnt -+-
Et si Carbon était de plus en plus Cocoatisé ? Ce qui caractérise Cocao c'est l'orienté objet non ?
De même les Romains ont conquis les Grecs si tu vois ce qu je veux dire. Et les Ricains après avoir battus les nazis ont eu le McCarthisme... Mais j'ai peur que la portée de ces allusions ne t'échappent.
Incroyable ! C'est une mine d'or pour le GMP-X ce gars-là !
-- FA: C'est perturbant... SP: Le gros inconvénient du changement, c'est que c'est plus pareil SP: qu'avant :-) -+- SP in LTQFRJ -+- MacOOOOOSX c'était mieux avaaaaannnnnt -+-
laurent.pertois
Patrick C wrote:
Mais on a pu avoir une leçon de Carbon/Cocoa faite par différentes sources, on va pouvoir donner un prix au plus pédagogue.
Certes, mais, comme je te l'ai dit, ça a été à sens unique, malheureusement, pas de réponse, rien.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick C <cochardp@alussinan.org> wrote:
Mais on a pu avoir une leçon de Carbon/Cocoa faite par différentes
sources, on va pouvoir donner un prix au plus pédagogue.
Certes, mais, comme je te l'ai dit, ça a été à sens unique,
malheureusement, pas de réponse, rien.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Mais on a pu avoir une leçon de Carbon/Cocoa faite par différentes sources, on va pouvoir donner un prix au plus pédagogue.
Certes, mais, comme je te l'ai dit, ça a été à sens unique, malheureusement, pas de réponse, rien.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Patrick C wrote:
Déjà tu crois ? Il n'avait qu'une journée à nous consacrer pour ses insultes ? Sont un peu court de nos jours les trolls.
La qualité se perd...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick C <cochardp@alussinan.org> wrote:
Déjà tu crois ? Il n'avait qu'une journée à nous consacrer pour ses
insultes ? Sont un peu court de nos jours les trolls.
La qualité se perd...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Déjà tu crois ? Il n'avait qu'une journée à nous consacrer pour ses insultes ? Sont un peu court de nos jours les trolls.
La qualité se perd...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
michele
Joseph W : Un tel bouton existe-il dans son soft au nom imprononçable ?
Peut-être pas par un bouton. Mais même sur nunux, y'a une marche arrière et Hubert a, comme chacun de nous, su ramper sur le sol quand il était bébé, il sait donc ce qu'arrière et avant signifient. Et pour les amateurs de dysléxie, en rampant d'avant en arrière il a aussi appris, comme nous tous, ce que sont le passé et le futur.
Joseph W : Un tel bouton existe-il dans son soft au nom imprononçable ?
Peut-être pas par un bouton. Mais même sur nunux, y'a une marche arrière
et Hubert a, comme chacun de nous, su ramper sur le sol quand il était
bébé, il sait donc ce qu'arrière et avant signifient.
Et pour les amateurs de dysléxie, en rampant d'avant en arrière il a
aussi appris, comme nous tous, ce que sont le passé et le futur.
Joseph W : Un tel bouton existe-il dans son soft au nom imprononçable ?
Peut-être pas par un bouton. Mais même sur nunux, y'a une marche arrière et Hubert a, comme chacun de nous, su ramper sur le sol quand il était bébé, il sait donc ce qu'arrière et avant signifient. Et pour les amateurs de dysléxie, en rampant d'avant en arrière il a aussi appris, comme nous tous, ce que sont le passé et le futur.
michele
Saïd : Quand on repond a un message des news il faut laisser tout ce qui permet de comprendre la reponse.
Je vois que tu as parfaitement compris pourquoi je laisse au moins la ligne à laquelle je réponds. Je ne coupe que ce à quoi je ne réponds rien. Etonnant.
Saïd : Quand on repond a un message des news il faut laisser tout
ce qui permet de comprendre la reponse.
Je vois que tu as parfaitement compris pourquoi je laisse au moins la
ligne à laquelle je réponds. Je ne coupe que ce à quoi je ne réponds
rien. Etonnant.
Saïd : Quand on repond a un message des news il faut laisser tout ce qui permet de comprendre la reponse.
Je vois que tu as parfaitement compris pourquoi je laisse au moins la ligne à laquelle je réponds. Je ne coupe que ce à quoi je ne réponds rien. Etonnant.
michele
Patrick : Ildegarde.
Si tu écorches son nom, ça va pas aller. Hildegarde avec un H, voyons.
Patrick : Ildegarde.
Si tu écorches son nom, ça va pas aller. Hildegarde avec un H, voyons.
Si tu écorches son nom, ça va pas aller. Hildegarde avec un H, voyons.
blbl
nospam wrote:
Hélas ! Mais il y a plusieurs niveau d'utilisation de Carbon. Heureusement. iTunes, c'est ce qu'on peut faire de mieux. Il n'en reste pas moins que le système lui est Cocoa !!!
Afin que tu comprennes certaines moqueries...
Le système lui-même n'est pas du tout Cocoa, bien au contraire. Déjà, il y a un énorme mélange entre frameworks et langages de programmation dans ton esprit, mais ce serait un peu long de tout dire en détail.
En gros : - le coeur de MacOS X est en C (et C++ pour certaines parties). Tout ce qu'il y a de plus indépendant de Cocoa - Cocoa est divisé en deux parties officielles, Foundation et AppKit. Je pense que la première repose énormément en interne sur.... CoreFoundation, qui est écrit en C. D'ailleurs on classe souvent CoreFoundation dans Carbon :-). L'AppKit est visiblement progressivement réécrit pour s'appuyer sur... Carbon (mais du Carbon moderne, pas de la merde OS9-ienne. D'ailleurs, Apple ne devrait même pas appeler ça Carbon... ou alors appeler ça du NeoCarbon :-) )
De plus en plus, dans un but de rationalisation, Apple cherche à transformer Cocoa en un framework qui agit comme une surcouche à des fondations (qu'on les appelle Carbon ou autrement, une classification n'est pas évidente... mais comme les gens ont tendance à appeler Carbon tout ce qui est en C/C++)
Toute application Cocoa s'intégre à 100% et profite de tous les avantages d'OSX, ce qui n'est pas le cas de la quasi totalité des applications Carbon qui ne sont guère que des portages hatifs...
Exception notables (de développeurs tiers) : BBEdit, ..., oui j'ai beau chercher je n'en vois pas d'autres mais il y en a sans doute...
Ce qui rend Carbon merdique aux yeux des utilisateurs, c'est que les applis Carbon issues d'un portage MacOS 9-ien sont merdiques.
iTunes est/était assez merdique niveau fondations même s'ils corrigent petit à petit heureusement...
Le Finder serait bien mieux s'il était Cocoa.
Le Finder serait simplement mieux s'il était réécrit sur des fondations propres.
Cocoa ou Carbon récent (avec HIView et CoreFoundation), même combat, résultats similaires.
De toutes façons, le Finder ne peut pas facilement se passer de Carbon sans faire hurler nombre d'utilisateurs. Donc au mieux ce serait un mix de Cocoa et Carbon.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
-- Bruno
nospam <nospam@nospam.com> wrote:
Hélas ! Mais il y a plusieurs niveau d'utilisation de Carbon.
Heureusement. iTunes, c'est ce qu'on peut faire de mieux.
Il n'en reste pas moins que le système lui est Cocoa !!!
Afin que tu comprennes certaines moqueries...
Le système lui-même n'est pas du tout Cocoa, bien au contraire. Déjà, il
y a un énorme mélange entre frameworks et langages de programmation dans
ton esprit, mais ce serait un peu long de tout dire en détail.
En gros :
- le coeur de MacOS X est en C (et C++ pour certaines parties). Tout ce
qu'il y a de plus indépendant de Cocoa
- Cocoa est divisé en deux parties officielles, Foundation et AppKit. Je
pense que la première repose énormément en interne sur....
CoreFoundation, qui est écrit en C. D'ailleurs on classe souvent
CoreFoundation dans Carbon :-). L'AppKit est visiblement progressivement
réécrit pour s'appuyer sur... Carbon (mais du Carbon moderne, pas de la
merde OS9-ienne. D'ailleurs, Apple ne devrait même pas appeler ça
Carbon... ou alors appeler ça du NeoCarbon :-) )
De plus en plus, dans un but de rationalisation, Apple cherche à
transformer Cocoa en un framework qui agit comme une surcouche à des
fondations (qu'on les appelle Carbon ou autrement, une classification
n'est pas évidente... mais comme les gens ont tendance à appeler Carbon
tout ce qui est en C/C++)
Toute
application Cocoa s'intégre à 100% et profite de tous les avantages
d'OSX, ce qui n'est pas le cas de la quasi totalité des applications
Carbon qui ne sont guère que des portages hatifs...
Exception notables (de développeurs tiers) : BBEdit, ..., oui j'ai beau
chercher je n'en vois pas d'autres mais il y en a sans doute...
Ce qui rend Carbon merdique aux yeux des utilisateurs, c'est que les
applis Carbon issues d'un portage MacOS 9-ien sont merdiques.
iTunes est/était assez merdique niveau fondations même s'ils corrigent
petit à petit heureusement...
Le Finder serait bien mieux s'il était Cocoa.
Le Finder serait simplement mieux s'il était réécrit sur des fondations
propres.
Cocoa ou Carbon récent (avec HIView et CoreFoundation), même combat,
résultats similaires.
De toutes façons, le Finder ne peut pas facilement se passer de Carbon
sans faire hurler nombre d'utilisateurs. Donc au mieux ce serait un mix
de Cocoa et Carbon.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Hélas ! Mais il y a plusieurs niveau d'utilisation de Carbon. Heureusement. iTunes, c'est ce qu'on peut faire de mieux. Il n'en reste pas moins que le système lui est Cocoa !!!
Afin que tu comprennes certaines moqueries...
Le système lui-même n'est pas du tout Cocoa, bien au contraire. Déjà, il y a un énorme mélange entre frameworks et langages de programmation dans ton esprit, mais ce serait un peu long de tout dire en détail.
En gros : - le coeur de MacOS X est en C (et C++ pour certaines parties). Tout ce qu'il y a de plus indépendant de Cocoa - Cocoa est divisé en deux parties officielles, Foundation et AppKit. Je pense que la première repose énormément en interne sur.... CoreFoundation, qui est écrit en C. D'ailleurs on classe souvent CoreFoundation dans Carbon :-). L'AppKit est visiblement progressivement réécrit pour s'appuyer sur... Carbon (mais du Carbon moderne, pas de la merde OS9-ienne. D'ailleurs, Apple ne devrait même pas appeler ça Carbon... ou alors appeler ça du NeoCarbon :-) )
De plus en plus, dans un but de rationalisation, Apple cherche à transformer Cocoa en un framework qui agit comme une surcouche à des fondations (qu'on les appelle Carbon ou autrement, une classification n'est pas évidente... mais comme les gens ont tendance à appeler Carbon tout ce qui est en C/C++)
Toute application Cocoa s'intégre à 100% et profite de tous les avantages d'OSX, ce qui n'est pas le cas de la quasi totalité des applications Carbon qui ne sont guère que des portages hatifs...
Exception notables (de développeurs tiers) : BBEdit, ..., oui j'ai beau chercher je n'en vois pas d'autres mais il y en a sans doute...
Ce qui rend Carbon merdique aux yeux des utilisateurs, c'est que les applis Carbon issues d'un portage MacOS 9-ien sont merdiques.
iTunes est/était assez merdique niveau fondations même s'ils corrigent petit à petit heureusement...
Le Finder serait bien mieux s'il était Cocoa.
Le Finder serait simplement mieux s'il était réécrit sur des fondations propres.
Cocoa ou Carbon récent (avec HIView et CoreFoundation), même combat, résultats similaires.
De toutes façons, le Finder ne peut pas facilement se passer de Carbon sans faire hurler nombre d'utilisateurs. Donc au mieux ce serait un mix de Cocoa et Carbon.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
-- Bruno
Hubert Figuiere
CoreFoundation, qui est écrit en C. D'ailleurs on classe souvent CoreFoundation dans Carbon :-).
Non. CoreFoundation c'est de l'Objective-C avec des API C. Il suffit de voir les classes qui sont "toll-free bridged" avec Foundation.
L'AppKit est visiblement progressivement réécrit pour s'appuyer sur... Carbon (mais du Carbon moderne, pas de la merde OS9-ienne. D'ailleurs, Apple ne devrait même pas appeler ça Carbon... ou alors appeler ça du NeoCarbon :-) )
Dès le début pour les Event, les menus, etc. Du reste, pour les menus, pas mal d'API des NSMenu ont été rendues obsolète à cause de ca. Sans compter les bouts du printing et des NSFilePanel qui sont identique dans les deux cas, avec un "bridge" pour permettre les customs panel. Ca ne rend pas Cocoa inutile, bien au contraire.
De plus en plus, dans un but de rationalisation, Apple cherche à transformer Cocoa en un framework qui agit comme une surcouche à des fondations (qu'on les appelle Carbon ou autrement, une classification n'est pas évidente... mais comme les gens ont tendance à appeler Carbon tout ce qui est en C/C++)
Pas si sûr. C'est plus dans un soucis d'intégration entre les deux technologies.
Le Finder serait bien mieux s'il était Cocoa.
Le Finder serait simplement mieux s'il était réécrit sur des fondations propres.
Le Finder a été écrit avec <caugh> <caugh> PowerPlant. Pour la petite histoire, (il s'agit peut-être d'une légende), le Finder aurait été écrit en Carbon pour démontrer que Carbon n'est pas obsolète. Au look, on dirait pas, ca a une belle allure d'appli MacOS X. Ses défauts sont plutôt sur le manque de certaines fonctionnalité et sur les crash en 10.1... (depuis 10.2, c'est plus lui le top crasheur, mais plutot Terminal et Project Builder/XCode, des applis Cocoa)
Du reste, ca colle pas avec le reste de la stratégie Apple, vu que iMovie a été réécrit en Cocoa (avec toute la lenteur qui va avec).
Cocoa ou Carbon récent (avec HIView et CoreFoundation), même combat, résultats similaires.
Oui mais non. Cocoa c'est quand même pas mal plus lent.
De toutes façons, le Finder ne peut pas facilement se passer de Carbon sans faire hurler nombre d'utilisateurs. Donc au mieux ce serait un mix de Cocoa et Carbon.
Quel intérêt ? Actuellement Finder c'est pas un seul bout de Cocoa.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Faut peser le pour et le contre.
Hub -- AbiWord maintainer - Lille, France - http://www.figuiere.net/hub/ "according to gweather, it is "? --" degrees outside" -- dom on IRC GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3
CoreFoundation, qui est écrit en C. D'ailleurs on classe souvent
CoreFoundation dans Carbon :-).
Non. CoreFoundation c'est de l'Objective-C avec des API C. Il suffit
de voir les classes qui sont "toll-free bridged" avec Foundation.
L'AppKit est visiblement progressivement
réécrit pour s'appuyer sur... Carbon (mais du Carbon moderne, pas de la
merde OS9-ienne. D'ailleurs, Apple ne devrait même pas appeler ça
Carbon... ou alors appeler ça du NeoCarbon :-) )
Dès le début pour les Event, les menus, etc. Du reste, pour les
menus, pas mal d'API des NSMenu ont été rendues obsolète à cause de ca.
Sans compter les bouts du printing et des NSFilePanel qui sont
identique dans les deux cas, avec un "bridge" pour permettre les
customs panel.
Ca ne rend pas Cocoa inutile, bien au contraire.
De plus en plus, dans un but de rationalisation, Apple cherche à
transformer Cocoa en un framework qui agit comme une surcouche à des
fondations (qu'on les appelle Carbon ou autrement, une classification
n'est pas évidente... mais comme les gens ont tendance à appeler Carbon
tout ce qui est en C/C++)
Pas si sûr. C'est plus dans un soucis d'intégration entre les deux
technologies.
Le Finder serait bien mieux s'il était Cocoa.
Le Finder serait simplement mieux s'il était réécrit sur des fondations
propres.
Le Finder a été écrit avec <caugh> <caugh> PowerPlant. Pour la petite
histoire, (il s'agit peut-être d'une légende), le Finder aurait été
écrit en Carbon pour démontrer que Carbon n'est pas obsolète. Au look,
on dirait pas, ca a une belle allure d'appli MacOS X. Ses défauts sont
plutôt sur le manque de certaines fonctionnalité et sur les crash en
10.1... (depuis 10.2, c'est plus lui le top crasheur, mais plutot
Terminal et Project Builder/XCode, des applis Cocoa)
Du reste, ca colle pas avec le reste de la stratégie Apple, vu que
iMovie a été réécrit en Cocoa (avec toute la lenteur qui va avec).
Cocoa ou Carbon récent (avec HIView et CoreFoundation), même combat,
résultats similaires.
Oui mais non. Cocoa c'est quand même pas mal plus lent.
De toutes façons, le Finder ne peut pas facilement se passer de Carbon
sans faire hurler nombre d'utilisateurs. Donc au mieux ce serait un mix
de Cocoa et Carbon.
Quel intérêt ?
Actuellement Finder c'est pas un seul bout de Cocoa.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Faut peser le pour et le contre.
Hub
--
AbiWord maintainer - Lille, France - http://www.figuiere.net/hub/
"according to gweather, it is "? --" degrees outside" -- dom on IRC
GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3
CoreFoundation, qui est écrit en C. D'ailleurs on classe souvent CoreFoundation dans Carbon :-).
Non. CoreFoundation c'est de l'Objective-C avec des API C. Il suffit de voir les classes qui sont "toll-free bridged" avec Foundation.
L'AppKit est visiblement progressivement réécrit pour s'appuyer sur... Carbon (mais du Carbon moderne, pas de la merde OS9-ienne. D'ailleurs, Apple ne devrait même pas appeler ça Carbon... ou alors appeler ça du NeoCarbon :-) )
Dès le début pour les Event, les menus, etc. Du reste, pour les menus, pas mal d'API des NSMenu ont été rendues obsolète à cause de ca. Sans compter les bouts du printing et des NSFilePanel qui sont identique dans les deux cas, avec un "bridge" pour permettre les customs panel. Ca ne rend pas Cocoa inutile, bien au contraire.
De plus en plus, dans un but de rationalisation, Apple cherche à transformer Cocoa en un framework qui agit comme une surcouche à des fondations (qu'on les appelle Carbon ou autrement, une classification n'est pas évidente... mais comme les gens ont tendance à appeler Carbon tout ce qui est en C/C++)
Pas si sûr. C'est plus dans un soucis d'intégration entre les deux technologies.
Le Finder serait bien mieux s'il était Cocoa.
Le Finder serait simplement mieux s'il était réécrit sur des fondations propres.
Le Finder a été écrit avec <caugh> <caugh> PowerPlant. Pour la petite histoire, (il s'agit peut-être d'une légende), le Finder aurait été écrit en Carbon pour démontrer que Carbon n'est pas obsolète. Au look, on dirait pas, ca a une belle allure d'appli MacOS X. Ses défauts sont plutôt sur le manque de certaines fonctionnalité et sur les crash en 10.1... (depuis 10.2, c'est plus lui le top crasheur, mais plutot Terminal et Project Builder/XCode, des applis Cocoa)
Du reste, ca colle pas avec le reste de la stratégie Apple, vu que iMovie a été réécrit en Cocoa (avec toute la lenteur qui va avec).
Cocoa ou Carbon récent (avec HIView et CoreFoundation), même combat, résultats similaires.
Oui mais non. Cocoa c'est quand même pas mal plus lent.
De toutes façons, le Finder ne peut pas facilement se passer de Carbon sans faire hurler nombre d'utilisateurs. Donc au mieux ce serait un mix de Cocoa et Carbon.
Quel intérêt ? Actuellement Finder c'est pas un seul bout de Cocoa.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Faut peser le pour et le contre.
Hub -- AbiWord maintainer - Lille, France - http://www.figuiere.net/hub/ "according to gweather, it is "? --" degrees outside" -- dom on IRC GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3