Newsgroup: it.comp.macintosh
Titolo: Carbon e Cocoa

mi spiegate le differenze tra carbon e cocoa??

 mi spiegate le differenze tra carbon e cocoa??
il primo si programma in C e discende dal vecchio macos
e' il passato e' stato il ponte fra i 2 mondi che ha consentito di
portare le vecchie applicazioni da macos a osx
cocoa e' il discendente di nextstep si programma in Objective C (che
sebbene derivato ha poco a che vedere col C e sebbene ad oggetti ha poco
a che vedere col piu' diffuso C++) e' il futuro, tutte le nuove
applicazione apple sono sviluppate in cocoa
sembrerebbe facile se non ci fosse la portatilita' delle applicazioni di
mezzo
cocoa e' talmente diverso da quanto si vede in giro che le applicazioni
sviluppate in cocoa gireranno solo su mac (o su gnustep che e' una
riprposizione opensource di un vasto sottoinsieme di cocoa)
tutte le grosse applicazioni multipiattaforma commerciali e.g. office &
creative suite & ... sono sviluppate con carbon per questo motivo
poi c'e' il discorso unix/linux, anche qui gnustep ha diffusione pari a
0 e quindi le applicazioni da questo mondo sono quasi tutte in C++ col
supporto di librerie varie (forse le piu' diffuse sono le qt)
concludendo: cocoa e' una figata spaziale ma realisticamente ti limita
al mondo mac

 e' il futuro, tutte le nuove applicazione apple sono sviluppate in cocoa
Mica vero: Spotlight, per esempio, è Carbon ed adotta i suoi
plugin ispiratissimi al COM di Microsoft.
-- 
Guido

 Spotlight, per esempio, č Carbon
Altrimenti col cavolo che sarebbe stato cosě veloce. Quella che Carbon
sia "meno nativo" di Cocoa č una leggenda metropolitana...
-- 
Ve lo meritate Gil Amelio!

 plugin ispiratissimi al COM di Microsoft.
anche il finder e' carbon, ma sono comunque applicazioni in cui la gui
non e' complessissima

 sia "meno nativo" di Cocoa č una leggenda metropolitana...
Carbon is a set of APIs that enables C and C++ developers to take
advantage of Mac OS X-specific features, including an advanced user
interface tool kit, an efficient event-handling mechanism, the Quartz 2D
graphics library, and multiprocessing support. In addition, other
industry-standard C and C++ APIs are easily available to Carbon
developers, providing access to such services as the OpenGL drawing
system, the Mach microkernel, and BSD operating-system services. Because
Carbon is a collection of C programming interfaces, developers can use
virtually any Macintosh C development environment that supports PowerPC
to build Carbon applications.
Cocoa is an object-oriented application environment designed
specifically for developing Mac OS X native applications. The Cocoa
frameworks support rapid development and high productivity, and include
a full-featured set of classes designed to create robust and powerful
Mac OS X applications. Cocoa provides developers starting new Mac OS X
projects the fastest way to full-featured, extensible, and maintainable
implementations. Applications from UNIX and other platforms can also be
brought to Mac OS X quickly by using Cocoa to build state-of-the-art
Aqua user interfaces while retaining most existing core code.
questi sono i due cappellozzi introduttivi su carbon e cocoa
ora, la prima cosa che dice di cocoa e' che e' per progettare
applicazioni native OS X, di carbon non lo dice mentra vanta tutte le
compatibilita' col mondo esterno, chiediti perche'
(non sto affermando che in carbon non puoi farle neh!)

 una buona idea per sviluppare qualcosa di nuovo
Il Finder infatti è scritto in Obective-C++: speriamo in molti
che lo reimplementino da zero in Mac OS 10.5.
-- 
Guido

 che lo reimplementino da zero in Mac OS 10.5.
pensavo fosse carbon...

 applicazioni native OS X
Il fatto che Cocoa sia un ambiente progettato specificamente per
realizzare applicazioni native per Mac OS X, *NON* significa che
applicazioni sviluppate utilizzando altre API siano meno native.
Come puoi vedere nella figura di questa pagina:
<
http://developer.apple.com/documentation/Carbon/Conceptual/newtocarbon/
ch01.html>
"Carbon is one of several application environments available on Mac OS
X". Non ha alcun senso dire che Cocoa sia più nativo di Carbon. Sono due
ambienti diversi, ciascuno coi suoi vantaggi. Cocoa offre più vantaggi
soprattutto a chi programma, perché offre un notevole insieme di
"feature" prefabbricate. Ma Carbon è secondo me da preferire quando si
vuole dare priorità alla pulizia e all'efficienza del codice per
massimizzare la velocità.
-- 
"I have a very simple life, I have my family and I have Apple and Pixar.
And I don't do much else." S. J.

.
Questo per constatare come il troppo semplificato manicheismo
Cocoa<->Carbon non è una fedele rappresentazione dell'intima
architettura complessa e composita di Mac OS X, a partire
da quel kernel ibrido Mach-BSD in cui ci si riserva un posticino
pure all'Embedded C++ dell I/O Kit...
-- 
Guido

 massimizzare la velocità.
certo ci sono amime diverse all'interno di apple perche '
da qui
http://developer.apple.com/documentation/DeveloperTools/Conceptual/Tools
Ovr_Book/index.html?
http://developer.apple.com/documentation/DeveloperTo
ols/Conceptual/ToolsOvr_Book/DevProcess/chapter_4_section_2.html
puoi leggere
The fastest way to write a new Mac OS X GUI application from scratch is
to use the Cocoa application environment. The Cocoa frameworks do a lot
of the work for you, providing much of the user interface plus many
lower-level features such as I/O and interapplication communication.
Once you have developed an application in Cocoa, it is easy to maintain
and the code is easy to reuse, which makes updating your program even
faster than the original development. However, if you intend to port
your program to another platform, you might want to write all or a
portion of it using procedural calls instead of using the Cocoa
frameworks. In that case, you should use the Carbon application
environment.
in cui appare chiaro che carbon e' una "ruota di scorta" ;)
quanto alla pulizia ed efficienza del codice di carbon vs cocoa potrei
affermare che si tratti di leggenda metropolitana ( :-P) ma dico solo
che l'efficienza spesso piu' che dalla tecnologia dipende dal progetto

 pure all'Embedded C++ dell I/O Kit...
sara' per questo che con le I/O son "frequenti" i kernel panic?

 che l'efficienza spesso piu' che dalla tecnologia dipende dal progetto
Cocoa si porta dietro un bagaglio che in alcuni casi è del tutto
inutile.
-- 
Tristeza não tem fim, felicidade sim...

 il suo ruolo di riciclatore di vecchi programmi e tecnologie
Cazzata.
-- 
Ci sono solo 10 tipi di persone al mondo: chi capisce il binario e chi
no.

 inutile.
spiegati meglio, detta cosi mi pare un luogo comune
parli del runtime di Objective C?

 Cazzata.
beh allora trovami una paginetta di apple dove lo suggerisce apertamente
per lo sviluppo di nuove applicazioni NON vincolate dall'essere
multipiattaforma

allora sono entrambi set di Api per Mac giusto????
Pertanto se voglio sviluppare un'applicazione Mac oriented mi convine
utilizzare Cocoa, che sfrutta L'Object-C (Anche Java????), se voglio
fare un applicazione multipiattaforma, o cmq più compatibile con
l'universo non Mac uso Carbon??
un'ultima cosa, il livello di astrazione delle due api com'è???
sono simili alle Api Win32(Basso Livello) o alle MFC e simili(Alto Livello)
Thk avrei una mezza idea di fare qualcosina per Mac. 
 

 sono simili alle Api Win32(Basso Livello) o alle MFC e simili(Alto Livello)
so nulla di win, cmq basso basso per carbon e altissimo per cocoa

 senso generale almeno
Questo ruolo gli era stato attribuito all'indomani
dell'acquisizione di NeXT, quando fu previsto che
la compatibilità col vecchio System fosse confinata
all'interno dell'ambiente di emulazione della Yellow
Box.
Ma purtroppo la storia ha preso tutt'altra piega, visto
che Microsoft, Adobe, Macromedia e altre grandi
software house mostrarono verso Cocoa scarsissimo
interesse.
Travolta anch'essa dalla rivoluzione Java, Apple
decise di portare completamente su Java l'unica vera
tecnologia di successo sopravvissuta a NeXT, quell'
Enterprise Objects Frameworks alla base di WebObjects
(un suo rientro dalla finestra sarà rappresentato
in Tiger da Core Data, ripensato per la gestione
di database locali in XML e SQLite:
http://developer.apple.com/macosx/tiger/coredata.html
)
e di creare la Core Foundation affinché Carbon, risorto
nativamente in primo piano, potesse condividere le
strutture dati essenziali con Cocoa. Ricordo, ad esempio,
che i menù Cocoa sono solo dei wrapper di menù Carbon:
ogni applicazione Cocoa è sempre linkata con Carbon.
-- 
Guido

 interesse.
questo e' ovvio, perche' dovrebbero duplicare il loro lavoro?
si parla di applicazioni native appunto, non di multipiattaforma

 multipiattaforma
In quella che ti ho già segnalato:
"Each environment (including the optional BSD command-line environment)
has advantages and disadvantages, but for C and C++ programmers, Carbon
is the best choice."
E comunque, a ulteriore dimostrazione di quanto la tua affermazione sia
infondata:
<
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaOverview
/index.html>
"Cocoa taps into Carbon for some of the services it provides. This is
because various Carbon frameworks are situated as system-wide services
in the Core Services and Application Services layer. Carbon Core is a
particularly important one of these frameworks; for example, it has the
File Manager, which Cocoa uses for conversions between various
file-system representations."


 file-system representations."
e quindi?
carbon rimane li a basso livello, a basso livello possono metterci
quello che gli pare un vantaggio dell essere a oggetti, finche' non mi
cambiano l'interfaccia a basso livello possono metterci pure windows che
me frega a me?

 me frega a me?
Infatti gli sviluppatori di iTunes con Windows ci lavorano
quotidianamente per portarsi la pagnotta a casa.
-- 
Guido

 me frega a me?
Già, è proprio la stessa cosa che dire "carbon sta li a fare
il suo ruolo di riciclatore di vecchi programmi e tecnologie"...


 al mondo mac
Vero, finche` Apple non decide di rilasciare Cocoa anche per altri OS o
GNUStep non si "completa".
-- 
[ RiK0                                ]
[ Go away! The internet is full!      ]
[ Non credo negli schemi non vincenti ]

 sono simili alle Api Win32(Basso Livello) o alle MFC e simili(Alto Livello)
Carbon e` piu` di basso livello di Cocoa. Cocoa e` di livello
estremamente alto, e` molto raffinato.
Ma se non capisci come funziona l'ObjectiveC, quali sono i suoi pregi
etc, finirai per non capire certe scelte progettuali e la ragione per
cui certe cose si fanno in un certo modo.
Tieni presente che ObjectiveC e` un linguaggio di altissimo livello, con
un LanguageLevel doppio del C++ e probabilmente quasi doppio anche di
Java (sicuramente del vecchio Java senza generics).


 multipiattaforma
Poi anche li sull'essere multipiattaforma di Carbon ci andrei piano.
Diciamo che essendo piu` tradizionale e` solo questione di riscrivere la
GUI (e dici niente... :)) )
O mi sono perso qualcosa?
Qui quando si deve essere multipiattaforma per davvero Python + QT.


ma qt non è solo una libreria grafica?

 Usa QT e vivi felice. QT gira su MacOS, Linux e Windows[0]
Piena di bachi QT sotto OSX. A detta di Bob Ippolito.
Aiutiamo tutti il port delle GTK+ su carbon :)
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: 
http://vvolonghi.blogspot.com
http://weever.berlios.de

 GNUStep non si "completa".
e ti diro' che non mi sembrerebbe una brutta mossa commerciale! anzi
ampierebbe la fetta di sviluppatori interessati al framework e di
conseguenza i sw disponibili per mac. Temo pero' che sia un casino
portare cocoa lontano da os x, anche gnustep nonnostante esista da anni
non mi sembra che abbia raggiunto troppi risultati.
-- 
Ciao
Fabio

 il suo ruolo di riciclatore di vecchi programmi e tecnologie"...
guarda c'e' ma non l'ho trovato con tutte le cose che ho avuto da fare,
appena ci ripasso te lo posto un pezzo della documentazione apple che
dice chiaro e tondo "se devi fare una applicazione nuova lascia perdere
carbon e usa cocoa", il fatto che loro stessi  eccezionalmente la
smentiscano e' una cosa, ma alla domanda "che cosa sono carbon e cocoa"
credo tuttora che la mia prima risposta fosse valida

 GNUStep non si "completa".
aspettiamo con ansia (la II che la prima e' fantapolitica .-) )

 quotidianamente per portarsi la pagnotta a casa.
e ricadiamo sul multipiattaforma...

 Qui quando si deve essere multipiattaforma per davvero Python + QT.
beh c+ qt non e' multipiattaforma per daffalso e qt o altri sono
appoggiati su carbon
(anche cocoa :-O)

 appoggiati su carbon
Beh... insomma... ci si ragiona :)


 ma qt non č solo una libreria grafica?
Si e no. Hai anche strutture dati (container), socket, threads etc etc
etc
Diciamo che hai un sacco di roba e facciamo prima. La cosa "brutta" e`
che spesso duplica roba gia` presente nella libreria standard del C++
(non che il problema non si risolva in modo relativamente facile...)
Comunque se accedi in Python le strutture e i tipi del python e quelle
di QT interoperano abbastanza bene senza grossi pensieri.


 non mi sembra che abbia raggiunto troppi risultati.
La libreria da cui Cocoa discende (nel senso che immagino che
addirittura portebbero condividere ancora un po'  di codice) era
multipiattaforma.


 carbon e usa cocoa"
Hai mai provato a fare un'applicazione con Carbon? Io ho dovuto. Diciamo
che non userei la parola "comodo" (semmai "divertente come un dito
puntato nell'ano" -- questa pero` non l'ho provata... vado solo per
ANAlogia di cose sgradevoli).
Comunque... loro sconsigliano di usare Carbon perche` se uno non lo
conosce gia` e` estremamente frustrante, con Cocoa parti che quasi tutto
quello che con Carbon fai a mano, lo trovi gia` fatto, e puoi
concentrarti sulla logica dell'applicazione.
Non e` che Carbon e` li per "riciclaggio". E` solo che Cocoa e` mollto
piu` comodo, per quello lo consigliano.
Inoltre uno sviluppatore che venisse da altri ambienti vedendo Cocoa
direbbe... quanto sono gagliardi questi qui del MacOS che ci hanno pure
il framework user-friendly. Con Carbon... diciamo che mi vengono in
mente numerose librerie di gran lunga piu` comode. Tutto qui :))


 ma non c'e' sul mac
Purtroppo non nativa :((


 Aiutiamo tutti il port delle GTK+ su carbon :)
Ne sai qualcosa? Le GTK1 mi parevano piu` o meno fatte... le GTK2?


 Mi fido... anche se io in effetti non ne ho ancora trovati.
bob e' uno che tira l'acqua al suo mulino...
;)

 Ne sai qualcosa? Le GTK1 mi parevano piu` o meno fatte... le GTK2?
Uno degli sviluppatori di abiword ha iniziato il port proprio in questi
giorni.
http://www.figuiere.net/hub/blog/?2005/04/08/144-sane-build
Questo e` l'ultimo post della saga, e io non vedo l'ora che sia tutto
pronto perche` sinceramente non riesco a usare altri toolkit.


 multipiattaforma
mi inserisco qui, ma forse non ho capito una mazza anche perche' a
carbon ho dato solo una velocissima occhiata pero' a me non sembra che
sia troppo multipiattaforma. In quale altro sistema esiste carbon ? se
ho un programma carbon non credo sia facilissimo portarlo su altre
piattaforme.
Mi sbaglio ?
discorso diverso ovviamente per la retrocompatibilita'
-- 
Ciao
Fabio

 wrote:

e' la base per portare tutte le librerie multipattaforma
se vuoi portare gtk lo devi incollare su carbon
quelli che hanno portato qt e wxwindows li hanno incollati su carbon
essendo a basso livello permette la costruzione di astrazioni di livello
superiore comuni fra piu' piattaforme:
io credo che chi scrive applicazioni come photoshop DEBBA usare carbon
per metterci sopra il suo framework che fa la gui che sara' sviluppato
in modo da contenere le stesse astrazioni sia sotto mac che sotto win
senno' hai voglia a fare programmi compatibili...
questo intendevo
(e' chiaro che carbo per se e' assolutamente propietario)

 pronto perche` sinceramente non riesco a usare altri toolkit.
Interessante. Anche se io con gtk non programmo dalla versione 1.2.
La "filosofia" e` sempre la stessa?


 La "filosofia" e` sempre la stessa?
Io non ho mai programmato con le 1.2 :).
Sbirciando l'architettura delle QT4 dai proclami di trolltech posso
dirti che le GTK+ sono cosi` sin dagli albori della versione 2.0. L'API
magari e` un po` piu` bellina nelle QT (ma neanche di tanto). Io mi
trovo meglio sulle GTK+.


 trovo meglio sulle GTK+.
Paiono carine le modifiche. Purtroppo hanno sempre la mania dei
container specializzati... non che sia un gran problema, ma da quanto ho
capito preferisco la strada di GTK in questo.
Poi e` sempre li nella lista dei TODO (guardare GTK)... ma alla fin fine
fin quando non ho un port sul MacOS... Ormai GNU/Linux lo accendo una
volta ogni dieci giorni. E credo ancora di avere perfino installato KDE
che l'avevo messo da provare per i servizi di samaritanato linuxaro...
vabbe`.
