Newsgroup: it.comp.macintosh
Titolo: Finder in Cocoa

Non mi pare di aver letto topic su questo argomento, eppure la notizia è
di questi giorni.
Tempo fa ricordo aspre polemiche, ora è stato annunciato come novità del
leopardo delle nevi...
-- 
Guru       Non coltivate i beni terreni,
               non rimarrà niente.
         Coltivate l'amore delle persone,
            vale più di qualsiasi oro. 

 leopardo delle nevi...
è cosa buona ?
-- 
Bye ... Angelo ...


No. Sarebbe cosa MOLTO buona.
Ma tanto dubito che la notizia sia reale.

 come una iena se ne tolgono una!" [quasicit da nonno simpson]
mio figlio non è un comunista, è un criminale, un idiota, un comunista,
ma non è una pornostar!

 è cosa buona ?
Nell'esperienza utente si vedrà forse qualche miglioramento per il resto
c'è gente che aspetta la cosa come l'apetura della porta del Giubileo...


 No. Sarebbe cosa MOLTO buona.
Non č che sia buona perchč č Cocoa. Č buona perchč indica riscrittura
massiccia e, si spera, miglioramento termonucleare globale.
-- 
-riko

 massiccia e, si spera, miglioramento termonucleare globale.
Ti posso umilmente (visto che non sono nessuno) correggere?
Direi che non è che sia buona *solo* perché è Cocoa. È buona *anche*
perché indica riscrittura...
[da qui correggimi il più possibile, mi adentro in terreno minato]
In effetti il cambio di seti di API ha dei vantaggi, non tanto pe la
grafica sbrilluccicante che tanto ama Stefano Lavori, quanto per la
leggerezza che avrebbe il Finder e la conseguente velocità, la migliore
integrazione con tutti quei "core" del sistema operativo che paiono
davvero strumenti fatti bene, e grazie ai quali OSX è quel bel sistema
che è.
La riscrittura poi vuol dire eliminare tutti quei refusi del passato e
avere un Finder 2.0 che pensa al futuro, che è progettato per supportare
e fare da appoggio a un sistema operativo moderno.
Il tutto dovrebbe fare anche comunella con il cambio del filesystem (chi
ha detto ZFS alzi la mano), si spera, e altre cose interessanti e utili,
non solo per chi scrive applicazioni, ma anche per chi usa il computer
per navigare, scrivere una letterina, e guardare il filmetto o ascoltare
l'ultimo CD di Nilla Pizzi!!


 ha detto ZFS alzi la mano),
Io alzo la mano! Sperém!
d

 
Ciao,
mi permetto solo di precisare una cosa (in qualità di sviluppatore quale 
sono), Cocoa è un framework object oriented che incapsula tutta una 
serie di funzioni (da quelle di basso livello per la gestioen della 
memoria a quelle per la user interface) che sono nativamente scritte in 
C (almeno per la maggioranza).
Ora introdurre un framework di questo tipo vuol dire interporre uno 
strato in più tra il programma che usa l'API e l'API stessa il che non 
può che ridurre le performance. Penso che Finder sia rimasto carbon fino 
ad oggi anche per questo motivo. Ovviamente sto semplificando 
all'estremo e la riduzione di performance in molti casi non c'è o è 
talmente bassa da risultare non significativa.
Detto questo ribadisco comunque che è un vantaggio ed un notevole passo 
avanti portare anche Finder in Cocoa sia in termini di coerenza 
funzionale che in termini di nuove features diversamente molto più 
difficili da integrare ma il lato performance vorrei vederlo dal vivo 
prima di pronunciarmi.
Per fare un parallelismo Microsoft aveva (e probabilmente ha ancora) 
l'intenzione di fare la stessa cosa con il Microsoft .Net Framework su 
Windows ma attualmente, sebbene utilizzato da molte applicazioni di 
terze parti, non esiste praticamente nessun componente di sistema che 
sia sviluppato in .Net, e se mai porteranno i vari esplora risorse & C. 
c'è da augurarsi che intanto siano usciti processori veramente potenti 
perchè il decadimento di performance del Microsoft Framework è assai più 
significativo di Cocoa (del resto sono molto diversi tra loro anche a 
livello strutturale e progettuale).
ciao
fg

 sono), Cocoa è un framework object oriented che incapsula tutta una 
ecco io non osavo dirlo, ma ad esempio ai tempi del passaggio 
openoffice/neooffice da java 1.3 a 1.4  mi pareva di aver capito che a 
livello di disegno e ridisegno il java appoggiato a cocoa era più lento 
  di quello appoggiato a carbon...
-- 
http://www.venerandi.com

fabrizio venerandi ha scritto:

Bhe nel caso di java penso che il discorso sia ancora diverso, grazie a 
Dio ad oggi non c'è una virtual machine (o CLR per usare termini MS) nel 
sistema Apple quindi all'atto pratico Cocoa è un framework di classi ma 
non ha un runtime il che rende i problemi di performance assai meno 
pensanti. Se introduci Java il discorso diventa molto più articolato 
senza contare che questo bridge tra java e cocoa non l'ho mai compreso 
(ne mi sono particolarmente impegnato a comprenderlo).

 Io alzo la mano! Sperém!
Anche tu come Torvalds??
Traducimi dall'inglese che "nin zono imbarato":
HFS, complete and utter crap!
Ma poi, cosa andrebbe meglio e me che "nin zono imbarato" avere ZFS?


 prima di pronunciarmi.
I tester che l'hanno in mano (il felino delle nevi) dovrebbero saperlo
presto, giusto?
Mi pare che in giro per il mondo ci sia già qualcuno che lo sta testando
in beta, vero?


 Ma poi, cosa andrebbe meglio e me che "nin zono imbarato" avere ZFS?
Eeeh.... Io lo sto usando sotto OpenSolaris.... Guarda, e' proprio un
altro modo di concepire i dischi e il filesystem.
Onestamente trovo che lato server sia una gran cosa. Dal lato client
direi che e' estremamente utile per la possibilita' di avere
self-healing e le snapshot (per intenderci... time machine e'
*integrata* nel filesystem), per non parlare del fatto che e'
praticamente impossibile perdere i dati...
d

 velocità, 
Non credo proprio che ne guadagni in velocità passando a Cocoa.
L'aspetto _fondamentale_ è che finalmente potrò ridimensionare le 
finestre del Finder con NuclearZoom.

 significativa.
I motivi sono altri ed io almeno, non lavorando in Apple, non li conosco.
Ciao
Mirko

 Hai la lentezza del dispatch ObjC
Alt! Questo mi manca, e zio Google mi ha detto cose fumose e
incomprensibili...


 praticamente impossibile perdere i dati...
Si, avevo letto della questione "autobackup" o Time Machine, però
l'utente base vuol solo sapere se dovrà usare un programma per
deframmentare. Su HFS non è che ce ne sia tanto bisogno, si può fare eh,
ma se anche non si fa funge bene comunque, su ZFS, mi pare, nessuno si è
sbilanciato... (o forse non ho trovato articoli su internet che ne
parlassero...)


 incomprensibili...
Vai alla fonte e hai tutte le risposte, altrimenti prendi i src del 
runtime (apple o gnu, ma sono diversi)
e li studi:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_8_section_2.html#//apple_ref/doc/uid/TP30001163-CH14-SW2
Questo 
e' un test di un 'matto':
http://www.mulle-kybernetik.com/artikel/Optimization/opti-9.html
Renderlo equivalente ad una chiamata C vuol dire chiamare direttamente 
il puntatore
al metodo (IMP caching).
Ciao
Mirko

 parlassero...)
Guarda, su ZFS non solo non c'e' bisogno di fare tutto cio', ma non c'e'
nemmeno bisogno di fare fsck quando la macchina si riavvia in maniera
non pulita (tipo quando va via la corrente). E quando dico che non c'e'
bisogno intendo dire che non esistono nemmeno i tool perche' e'
inutile...
d

 non pulita (tipo quando va via la corrente).
Neanche con l'HFS+ Journaled.
-- 
In montagna ci si rompe il cazzo.
Al mare c'è l'afa.

 Neanche con l'HFS+ Journaled.
Tranne quando si spippola il Journal (e mi e' successo) :-(
Scherzi a parte, oltre alla consistenza del filesystem (self-healing
compreso) sono gustose anche tutte le possibilita' di volume management
al volo.
d

 Tranne quando si spippola il Journal (e mi e' successo) :-(
Anche a me. E neanche tanto di rado. :-(
Per fortuna l'ho quasi sempre preso in tempo...A quanto ho visto i
dischi in hfs+ (come in qualsiasi altro formato, suppongo...) danno
spesso problemi se il computer viene "sbatacchiato". Ma vai a farti
ascoltare da amici, parenti e familiari su queste cose: sì, sì, tanto
poi non cambia niente*...
----
*Uno che prevede un prossimo, ennesimo, formattone dell'ibook del
fratello, sempre per lo stesso motivo...

 Non credo proprio che ne guadagni in velocità passando a Cocoa.
Io credo che non ne perda nemmeno. Buona parte del "costo" è dovuto alle
syscall. Il resto è relativamente trascurabie. 
-- 
-riko

 pensanti.
Non scherziamo. Perfino il C ha un runtime, per quanto minimale. In
particolare Objective-C ha un runtime eccome. Quando scrivi
void bar(id foo) {
        [foo quack];
}
chi credi che vada a risolvere quack? Precisamente il runtime. Per dire.
Oltretutto Java di per se non è lento. Le librerie grafiche di Java sono
lente. *E* Java prende un fottio di memoria.
-- 
-riko

 al metodo (IMP caching).
Grande. Si è fatto il conto della pipeline a mano. :P
-- 
-riko

 talmente bassa da risultare non significativa.
Io non so perchč č cosě, ma quando "non riscrivono qualcosa" il motivo
tipico č "č costoso farlo". Per cui non ne avevano voglia/bisogno e non
lo hanno fatto. Poi ovviamente la mia scommessa č buona quanto la tua. 
-- 
-riko

 diversi...
C'è anche HFS case sensitive il punto è che le applicazioni non se le 
aspettano.

 aspettano.
E non e' nemmeno il default, mi sembra...
d

 lo hanno fatto. Poi ovviamente la mia scommessa è buona quanto la tua. 
quoto.
Ciao Jack
-- 
http://motoko.dyndns.org
http://jack471.labrute.fr

 lente. *E* Java prende un fottio di memoria.
Java e' lento quando deve accedere all'esterno (GUI, I/O). Se devi fare 
number crunching e' veloce quasi quanto il C.


 number crunching e' veloce quasi quanto il C.
Sull'IO dipende. È solo più difficile farlo bene. :P
-- 
-riko

 d
Ma vi serve così tanto? Usate applicazioni che lo richiedono o ne
traggono veramente vantaggio?
Apple l'ha implementato essenzialmente perché le serve nello sviluppo
del sistema (alcuni pacchetti di darwin, in primo luogo il kernel, ne
hanno bisogno)...

 hanno bisogno)...
Ma no, tutto e' nato col fatto che l'unica volta che mi sono dovuto
lamentare di HFS e' quando ho avuto un problema di case sensitivity...
ed e' successo una volta sola... 
d

On 23 Ott, 09:15, 
m...@adomain.no
 (dawe) wrote:

Pensa che ho pensato che fosse case-sensitive per anni, mi sono
accorto che nn lo era quando apple ha introdotto il case sensitive, in
tiger, se non erro!

 tiger, se non erro!
LOL!