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.
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.
Comme j'avais lancé mon affirmation un peu par hasard (pas totalement non plus), j'ai tenté de vérifier sur le site d'Apple, mais la partie OpenSource semble en rade. Bon...
Avec l'aide de google, j'ai quand même pu récupérer des codes sources de cfdictionary.c et autres cfstring.c
A moins que les choses n'aient bien changé ou ne soient très différentes sur cette source (opendarwin.org donc ils ont pu faire ce qu'ils voulaient en théorie, mais pas au point de tout réécrire je suppose...), ça m'a tout l'air d'être du bon vieux C.
Ces fichiers sont remplis de fonctions C toutes banales. Les fichiers .m n'ont pas l'air de pulluler d'après mon rapide coup d'oeil.
A quelques endroits dans ces fichiers C, on trouve tout de même quelques rares appels Objective-C encapsulés sous forme de fonctions C (CF_OBJC_FUNCDISPATCH0). Mais ce sont des cas bien particuliers.
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.
Oui, même si les choses semblent avoir été progressives. Je n'ai pas la chance d'avoir le code source, mais tout laisse à penser que pour le cas de NSMenu par exemple, il y avait encore pas mal de code propre à Cocoa au début. Avec aujourd'hui la migration que l'on connait (enfin, qu'Apple essaie de cacher malgré tout)
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.
Un soucis d'intégration est lié à une volonté de rationalisation à mes yeux...
Tout dépend aux yeux de qui la chose est présentée... certaines personnes chez Apple doivent voir la dedans un moyen d'éviter de perdre du temps de main d'oeuvre (travail inutile car dupliqué). D'autres y voient sans doute un moyen de garantir une plus grande robustesse. D'autres préfèrent voir un moyen d'approcher du but initial : que Cocoa et Carbon ne puissent être différenciés aux yeux de l'utilisateur final.
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.
Eh oui, un PowerPlant customisé...
D'ailleurs, il n'y a pas à chercher bien loin, l'outil de recherche du Finder suffit à localiser la bête...
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.
Oui. La légende veut aussi que l'écriture de logiciels en Carbon a pu permettre de corriger de nombreux bugs dans Carbon...
Des histoires de nourriture pour chien...
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)
Je trouve le Finder toujours aussi plantogène mais bon :-)
Au moins, les bug d'affichage ont quasi totalement disparu avec le temps.
Terminal ne m'a jamais posé de soucis, mais PB/XCode... Enfin, c'est une appli très complexe. Sans doute plus que le Finder... Et par gain de temps, il y a eu du refactoring massif à plusieurs reprises, qui a engendré des bugs là où une réécriture aurait été peut-être nécessaire.
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).
Tout est question d'optimisation. Rien n'empêche de mixer C++ et Obj-C en différenciant la partie interface du moteur de l'appli. Ca marche bien, et ça permet d'être très décemment rapide.
L'abus d'Obj-C peut nuir dans certains cas... quant à optimiser de l'obj-C à la geek, même si c'est possible, autant utiliser du C/C++ lorsque nécessaire...
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.
En théorie oui.
Maintenant, en regard du temps de développement... on en viendrait à espérer un framework C++ relativement light mais complet au dessus d'un Carbon moderne... peut-être PPx... mais je n'ai jamais regardé.
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.
Je n'ai jamais proné la réécriture en Cocoa du Finder.
Un intérêt, ce serait de simplifier le code toutefois. Quand je vois le nombre de bugs d'affichage auquel Apple a dû faire face... ainsi qu'au nombre de plantages. Tout ça, c'est du temps de dev.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Faut peser le pour et le contre.
Vu ce qu'Adobe, Macromedia et Quark font de Carbon a priori, comment les utilisateurs peuvent-ils penser que Carbon puisse être une bonne solution ?
Car c'est bien là l'origine du problème, toutes ces applis Carbon merdiques sur le marché.
Et quand un utilisateur rale parce que le menu service ne marche pas avec Word, c'est de la faute à mon appli, pas à Word...
-- Bruno
Hubert Figuiere <hub@free.fr> wrote:
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.
Comme j'avais lancé mon affirmation un peu par hasard (pas totalement
non plus), j'ai tenté de vérifier sur le site d'Apple, mais la partie
OpenSource semble en rade. Bon...
Avec l'aide de google, j'ai quand même pu récupérer des codes sources de
cfdictionary.c et autres cfstring.c
A moins que les choses n'aient bien changé ou ne soient très différentes
sur cette source (opendarwin.org donc ils ont pu faire ce qu'ils
voulaient en théorie, mais pas au point de tout réécrire je suppose...),
ça m'a tout l'air d'être du bon vieux C.
Ces fichiers sont remplis de fonctions C toutes banales. Les fichiers .m
n'ont pas l'air de pulluler d'après mon rapide coup d'oeil.
A quelques endroits dans ces fichiers C, on trouve tout de même quelques
rares appels Objective-C encapsulés sous forme de fonctions C
(CF_OBJC_FUNCDISPATCH0). Mais ce sont des cas bien particuliers.
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.
Oui, même si les choses semblent avoir été progressives. Je n'ai pas la
chance d'avoir le code source, mais tout laisse à penser que pour le cas
de NSMenu par exemple, il y avait encore pas mal de code propre à Cocoa
au début. Avec aujourd'hui la migration que l'on connait (enfin,
qu'Apple essaie de cacher malgré tout)
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.
Un soucis d'intégration est lié à une volonté de rationalisation à mes
yeux...
Tout dépend aux yeux de qui la chose est présentée... certaines
personnes chez Apple doivent voir la dedans un moyen d'éviter de perdre
du temps de main d'oeuvre (travail inutile car dupliqué).
D'autres y voient sans doute un moyen de garantir une plus grande
robustesse.
D'autres préfèrent voir un moyen d'approcher du but initial : que Cocoa
et Carbon ne puissent être différenciés aux yeux de l'utilisateur final.
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.
Eh oui, un PowerPlant customisé...
D'ailleurs, il n'y a pas à chercher bien loin, l'outil de recherche du
Finder suffit à localiser la bête...
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.
Oui. La légende veut aussi que l'écriture de logiciels en Carbon a pu
permettre de corriger de nombreux bugs dans Carbon...
Des histoires de nourriture pour chien...
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)
Je trouve le Finder toujours aussi plantogène mais bon :-)
Au moins, les bug d'affichage ont quasi totalement disparu avec le
temps.
Terminal ne m'a jamais posé de soucis, mais PB/XCode... Enfin, c'est une
appli très complexe. Sans doute plus que le Finder... Et par gain de
temps, il y a eu du refactoring massif à plusieurs reprises, qui a
engendré des bugs là où une réécriture aurait été peut-être nécessaire.
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).
Tout est question d'optimisation. Rien n'empêche de mixer C++ et Obj-C
en différenciant la partie interface du moteur de l'appli. Ca marche
bien, et ça permet d'être très décemment rapide.
L'abus d'Obj-C peut nuir dans certains cas... quant à optimiser de
l'obj-C à la geek, même si c'est possible, autant utiliser du C/C++
lorsque nécessaire...
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.
En théorie oui.
Maintenant, en regard du temps de développement... on en viendrait à
espérer un framework C++ relativement light mais complet au dessus d'un
Carbon moderne... peut-être PPx... mais je n'ai jamais regardé.
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.
Je n'ai jamais proné la réécriture en Cocoa du Finder.
Un intérêt, ce serait de simplifier le code toutefois. Quand je vois le
nombre de bugs d'affichage auquel Apple a dû faire face... ainsi qu'au
nombre de plantages. Tout ça, c'est du temps de dev.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Faut peser le pour et le contre.
Vu ce qu'Adobe, Macromedia et Quark font de Carbon a priori, comment les
utilisateurs peuvent-ils penser que Carbon puisse être une bonne
solution ?
Car c'est bien là l'origine du problème, toutes ces applis Carbon
merdiques sur le marché.
Et quand un utilisateur rale parce que le menu service ne marche pas
avec Word, c'est de la faute à mon appli, pas à Word...
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.
Comme j'avais lancé mon affirmation un peu par hasard (pas totalement non plus), j'ai tenté de vérifier sur le site d'Apple, mais la partie OpenSource semble en rade. Bon...
Avec l'aide de google, j'ai quand même pu récupérer des codes sources de cfdictionary.c et autres cfstring.c
A moins que les choses n'aient bien changé ou ne soient très différentes sur cette source (opendarwin.org donc ils ont pu faire ce qu'ils voulaient en théorie, mais pas au point de tout réécrire je suppose...), ça m'a tout l'air d'être du bon vieux C.
Ces fichiers sont remplis de fonctions C toutes banales. Les fichiers .m n'ont pas l'air de pulluler d'après mon rapide coup d'oeil.
A quelques endroits dans ces fichiers C, on trouve tout de même quelques rares appels Objective-C encapsulés sous forme de fonctions C (CF_OBJC_FUNCDISPATCH0). Mais ce sont des cas bien particuliers.
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.
Oui, même si les choses semblent avoir été progressives. Je n'ai pas la chance d'avoir le code source, mais tout laisse à penser que pour le cas de NSMenu par exemple, il y avait encore pas mal de code propre à Cocoa au début. Avec aujourd'hui la migration que l'on connait (enfin, qu'Apple essaie de cacher malgré tout)
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.
Un soucis d'intégration est lié à une volonté de rationalisation à mes yeux...
Tout dépend aux yeux de qui la chose est présentée... certaines personnes chez Apple doivent voir la dedans un moyen d'éviter de perdre du temps de main d'oeuvre (travail inutile car dupliqué). D'autres y voient sans doute un moyen de garantir une plus grande robustesse. D'autres préfèrent voir un moyen d'approcher du but initial : que Cocoa et Carbon ne puissent être différenciés aux yeux de l'utilisateur final.
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.
Eh oui, un PowerPlant customisé...
D'ailleurs, il n'y a pas à chercher bien loin, l'outil de recherche du Finder suffit à localiser la bête...
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.
Oui. La légende veut aussi que l'écriture de logiciels en Carbon a pu permettre de corriger de nombreux bugs dans Carbon...
Des histoires de nourriture pour chien...
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)
Je trouve le Finder toujours aussi plantogène mais bon :-)
Au moins, les bug d'affichage ont quasi totalement disparu avec le temps.
Terminal ne m'a jamais posé de soucis, mais PB/XCode... Enfin, c'est une appli très complexe. Sans doute plus que le Finder... Et par gain de temps, il y a eu du refactoring massif à plusieurs reprises, qui a engendré des bugs là où une réécriture aurait été peut-être nécessaire.
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).
Tout est question d'optimisation. Rien n'empêche de mixer C++ et Obj-C en différenciant la partie interface du moteur de l'appli. Ca marche bien, et ça permet d'être très décemment rapide.
L'abus d'Obj-C peut nuir dans certains cas... quant à optimiser de l'obj-C à la geek, même si c'est possible, autant utiliser du C/C++ lorsque nécessaire...
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.
En théorie oui.
Maintenant, en regard du temps de développement... on en viendrait à espérer un framework C++ relativement light mais complet au dessus d'un Carbon moderne... peut-être PPx... mais je n'ai jamais regardé.
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.
Je n'ai jamais proné la réécriture en Cocoa du Finder.
Un intérêt, ce serait de simplifier le code toutefois. Quand je vois le nombre de bugs d'affichage auquel Apple a dû faire face... ainsi qu'au nombre de plantages. Tout ça, c'est du temps de dev.
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Faut peser le pour et le contre.
Vu ce qu'Adobe, Macromedia et Quark font de Carbon a priori, comment les utilisateurs peuvent-ils penser que Carbon puisse être une bonne solution ?
Car c'est bien là l'origine du problème, toutes ces applis Carbon merdiques sur le marché.
Et quand un utilisateur rale parce que le menu service ne marche pas avec Word, c'est de la faute à mon appli, pas à Word...
-- Bruno
ol.g+news
Hubert Figuiere wrote:
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.
Je serais un poil plus nuancé ici. CoreFoundation, c'est du C, avec un modèle objet habilement conçu pour pouvoir être bridgé de façon transparent avec des objets Objective-C.
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.
Et réciproquement: cf. les color panels et font panels de 10.3, qui, exploités depuis Carbon n'en sont pas moins des panneaux ... Cocoa (cf. la WWDC de l'an dernier).
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-) Faut peser le pour et le contre.
Absolument. Tout comme pour Carbon.
Ol. -- Olivier Gutknecht
Hubert Figuiere <hub@free.fr> wrote:
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.
Je serais un poil plus nuancé ici. CoreFoundation, c'est du C, avec un
modèle objet habilement conçu pour pouvoir être bridgé de façon
transparent avec des objets Objective-C.
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.
Et réciproquement: cf. les color panels et font panels de 10.3, qui,
exploités depuis Carbon n'en sont pas moins des panneaux ... Cocoa (cf.
la WWDC de l'an dernier).
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-)
Faut peser le pour et le contre.
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.
Je serais un poil plus nuancé ici. CoreFoundation, c'est du C, avec un modèle objet habilement conçu pour pouvoir être bridgé de façon transparent avec des objets Objective-C.
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.
Et réciproquement: cf. les color panels et font panels de 10.3, qui, exploités depuis Carbon n'en sont pas moins des panneaux ... Cocoa (cf. la WWDC de l'an dernier).
Maintenant, ne nous y trompons-pas, Cocoa rulezzzzzzz :-) Faut peser le pour et le contre.
