Newsgroup: it.comp.macintosh
Titolo: xcode vs qualcos'altro

Ciao a tutti,
dopo qualche tempo di pratica con applicazioni client-server (roba
semplice) mi sono deciso ad aprire xcode per dare un volto a tutto quel
codice.. per farvi capire a che punto sono vi faccio un esempio:
ai tempi di Visual Studio, i vari oggetti sull'interfaccia (bottoni,
textbox etc..) erano facilmente accedibili, per esempio se volevo
modificare il valore di un testo in base ad una condizione, bastava
scrivessi text.num_caratteri = 100 (è solo un esempio) e grazie
all'autocompletamento ero in grado di vedere a colpo d'occhio i
metodi/membri della classe.. in xcode non so nemmeno che nome viene dato
alla text view che inserisco; per dire la verità faccio anche molta
confusione fra i vari progetti, Cocoa, Carbon etc, ma questo è un altro
discorso..
insomma, pur non conoscendo a pieno (direi per niente) Visual Studio,
ero comunque in grado di fare qualcosa, quantomeno modificare un campo
in base ad una condizione (e viceversa), qui mi trovo parecchio in
difficoltà..
avete un link che parli anzitutto di Carbon e Cocoa, ma soprattutto un
how-to (quelli ad esempi li preferisco nonostante non abbiano un
approccio molto ingegneristico!) su xcode?
eventualmente sarei disposto a testare qualche altra applicazione..
grazie mille
-- 
Ciao, Nicola

 scrivessi text.num_caratteri = 100 (è solo un esempio) e grazie
Approccio "maccheronico" senza teoria:
- apri xcode e crei un nuovo progetto cocoa
- crei una nuova classe (mela n-> new objc class)
- nel file .h dentro le due { } scrivi IBOutlet NSTextField *campoTesto;
- dopo la } chiusa scrivi invece - (IBAction) cambiaTesto:(id) sender;
- copia il metodo scritto sopra anche dentro il file .m dopo tra
@implementation e @end e aggiungici le { e } a posto di ;.
- dentro la funzione che hai creato scrivi [campoTesto
setStringValue:@"ciao"];
- salva, clicca sul file mainMenu.nib (colonna a sinistra) e si aprirà
Interface Builder. Premi mela-shift-1
- trascina il file .h di xcode dentro la finestra MainMenu.nib di IB
(quella dove sta File'sOwner, Window etc...). Ti comparirà una lista di
classi.
- control-click sulla tua classe e seleziona Istantiate...
- ora apri la finestra Window con un doppio click e dalle palette
inserisci un campo di testo e un pulsante
- control click sul pulsante e sposta il mouse sulla classe istanziata
(un cubo blu)...si formerà una specie di collegamento
- nella finestra di inspector (mela-shift-1), seleziona il metodo
dichiarato (cambiaTesto) e premi connect.
- fai la stessa cosa ma questa volta dal cubo verso il campo di testo e
seleziona la v ariabile outlet CampoTesto; premi quindi connect.
- fai mela-s e chiudi
- fai mela-r da xcode e aspetta
- una volta aperta l'app premi il pulsante e vedi la magia
ovviamente tutto questo è molto lontano dalla realtà della
programmazione in cocoa (ci sarebbero molte cose da spiegare)...ma ora è
tardi ^_^... se hai altri dubbi contattami pure.
ciao
dan
-- 
----------------------------------
Criticalkernel Software
http://www.criticalkernel.com/
in...@criticalkernel.com

Prova Revolution o SuperCard

 Prova Revolution o SuperCard
visto quello che pare interessare a lui, non credo siano piu` indicati di
un tot.
-- 
RiK0

 eventualmente sarei disposto a testare qualche altra applicazione..
Per questo dipende da quello che devi fare.
Se quello che ti interessa sono applicazioni client e server, con Python ti
dovresti trovare divinamente. Eventualmente Python + Twisted. Io mi sono
innamorato. Ogni poche righe di codice mi passa per la testa il pensiero
'non puo` essere cosi` semplice'.
Se per client server poi intendi roba *nix classica, allora direi che anche
usare i tools standard non e` affatto male come cosa. Vim o Emacs. E il
buon gcc.
Se Java... beh, io mi riempio di bolle rosse quando leggo questo nome, ma a
parte questo, ci sono alcuni thread in giro su buoni ambienti per questo
ambiente.
Dove Xcode e` veramente insuperabile e` nella produzione di applicazioni
ObjectiveC. Li veramente e` ottimo.
Anche se in effetti lo ho usato per prova anche per il Python, con apposito
plugin. Ad ogni modo preferisco vim. Eventualmente Vim.app.
Se non avessero ancora l'ultima versione compilata (6.3) sul sito ufficiale
http://www.anubics.org/~riko/resources/Vim.zip
Ad ogni modo, pur non essendo eccelso, xcode fa bene il suo mestiere. 
Se poi me lo paragoni al visual studio... e` molto piu` avanti... :))
IBuilder + Xcode sono veramente un'accoppiata micidiale.
Dopo di che puoi provare ad abilitare l'autocompletamento anche su Xcode.
Detto questo, se vuoi programmare seriamente con Cocoa, oltre ai vari
tutorial Apple su Cocoa e ObjectiveC [ li trovi nella cartella
Documentazione sotto Developers Tools o sul sito Apple ], potresti trovare
comodo 'Cocoa in a Nutshell', dove ti elenca i vari metodi delle classi
dell'AppKit e del FoundationKit.
-- 
RiK0

 un tot.
Mi semrbava si lamentasse della mancanza di immediatezza di XCode
rispetto VS. Quelli sono anche piu' immediati di VS.

 rispetto VS. Quelli sono anche piu' immediati di VS.
si, ma non sono indicatissimi per applicazioni (immagino) client - server,
networking etc etc :))
-- 
RiK0


"The goal of AppKiDo is to help you find what you want in the Cocoa
documentation."
-- 
nif from outer space

 networking etc etc :))
Le fai tranquillamente anche con HyperCard.

 Le fai tranquillamente anche con HyperCard.
il punto non e` farlo o non farlo. il punto e` quanto uno strumento e`
adatto per un certo compito.
e scusa se te lo dico, ma mettersi a scrivere server di rete con
HyperCard non mi sembra certo una delle migliori idee della storia. 
-- 
RiK0
 Il sonno del teschio genera troll, e il quoting li manifesta.

 IBuilder + Xcode sono veramente un'accoppiata micidiale.
 
Salvo quando IBuilder va ripetutament in crash :)
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

 Salvo quando IBuilder va ripetutament in crash :)
a me mai capitato mi e` :)
comunque in che condizioni si verifica?


 l'indentazione conta come in (non riesco a dirlo :) ) ?
Haskell?  Occam?  Quel che 30 anni fa sognava il grande, irragiungibile
Knuth?  Se non riesci a dire in quale altro linguaggio conta
l'indentazione non e` facile indovinarlo, questi sono gli unici tre
candidati che mi vengono in mente.  Nella maggior parte dei linguaggi
gli spazi contano solo come separatori, oppure addirittura, come
nell'antico Fortran sino al '66, non contano proprio per nulla (cosi`
che puoi scrivere GOTO o GO TO, con o senza spazio, fa lo stesso!)...
Alex

 gli spazi contano solo come separatori
poi c'e` il whitespace... dove contano solo gli spazi :))


 che puoi scrivere GOTO o GO TO, con o senza spazio, fa lo stesso!)...
O anche G O T O.
Peccato  che  proprio  oin  FORTRAN  77  (aaaaargh,  che  bruciore  di
stomaco!) il codice se non ricordo male debba cominciare in colonna 6,
se  c'e` un carattere  in colonna  5 e`  una continuazione  della riga
precedente, le prime  5 colonne sono per le label, e  le ultime 8 sono
ingnorate perche` servivano a numerare le schede...
Il colpo di grazia comunque lo da lo statement DO.
DO 10 I = 1,5
e
DO 10 I = 1.5
(dovrei riprendere il Libro del Drago per l'ortografia corretta, ma mi
pare sia giusta).
La NASA ci perse un fottio di soldi :).
* So che ci sulle macchine parallele FORTRAN fa dei numeri notevoli.
* Datemi una macchina parallela e riabilitero` il FORTRAN :) :) :)
E poi c'e` il C... No quello  non riesco a dirlo :)! Provoca una grave
malattia  alle  articolazioni  (Dita   del  Co....  -  no  basta,  non
chiedetemi di continuare :), piuttosto il FORTRAN :) ).


 se hai altri dubbi contattami pure.
stai attento a dire così!! le domande sono mille (naturalmente!).. la
prima è:
in 3 righe di codice non ho visto niente che assomigli al C++, giusto le
classi, ma quelle si possono fare anche con gli style-sheet! :-P.
in dettaglio:
IBOutlet NSTextField *campoTesto;
creo una oggetto (anzi un puntatore a oggetto) NSTextField di nome
campoTesto
- (IBAction) cambiaTesto:(id) sender
{
        [campoTesto setStringValue:@"ciao"];
} 
come hai detto tu questo è un metodo di nome cambiaTesto, immagino che
sender sia una parola chiave per il discorso bottone ma faccio fatica ad
interpretarla..
sto provando a fare quello che era nella mia testa inizialmente ma
faccio comunque molta fatica; in primo luogo non capisco perchè quando
creo una textfield non inserisce direttamente il codice (in pratica non
creo la classe), qual'è il vantaggio di non avere oggetti "connessi"?
probabilmente da queste parole capirai che non ho capito molto la
filosofia di xcode, ti toccherà postare qualche link per apprendisti!
:-)
ciao e grazie mille per aver contribuito alla realizzazione della prima
applicazione (un pò come si fa con tutti i linguaggi di programmazione:
"Hello world!")
-- 
Ciao, Nicola

 Se Java... beh, io mi riempio di bolle rosse 
non sei il solo
per il resto, credevo che Carbon e Cocoa fossero delle parole che
stessero ad indicare il tipo di interfaccia/progetto ed invece sono
linguaggi di programmazione C-compatibili?!
non volgio qualcosa tipo VS, vorrei solo dare un'interfaccia al codice
che ho scritto in C e vorrei farlo con il C++..
-- 
Ciao, Nicola

 rispetto VS. Quelli sono anche piu' immediati di VS.
forse ha ragione Enrico, non parlo di quel tipo di immediatezza, pensavo
a qualcosa del tipo:
creo una finestra (bottoni, textfield etc), inserisco il mio codice C ed
accedo a tutti gli oggetti nella maniera piů classica che conosco,
nome_oggetto.campo (tutto senza tanto collegamenti, connect e roba
varia!!)
-- 
Ciao, Nicola

 linguaggi di programmazione C-compatibili?!
Dal sito 
http://developer.apple.com/cocoa/index.html
Cocoa is a rich set of object-oriented frameworks that allow for the
most rapid development of applications on Mac OS X.
Č un insieme di tecnlogie e librerie per scrivere programmi in
Objective-C, specifici per OS X. Č la libreria piů usata.
-- 
Andrea Bergia - studente              Linux Registered User #281550

 interpretarla..
La gestione degli eventi in Cocoa avviene mediante metodi definiti
nei controller, non negli elementi che costituiscono l'UI.
Un controller tiene traccia dei widget tra i quali fa l'intermediario
proprio tramite le variabili Outlet.
Quando un controller è il target di un widget esso deve implementare
le azioni fatte scaturire da questo: i metodi-azione hanno per
unico argomento proprio il widget (in questo caso il pulsante) che
le ha originate.
-- 
Guido


è molto interessante.. :-)
ribadisco in ogni caso un concetto:
per chi ha una pseudo-padronanza del C++, non vedo il motivo per il
quale si dovrebbe complicare la vita con Cocoa, ok a voi sembrerà uno
strumento eccezionale (e magari lo è, spero di impararlo..) ma a mio
avviso ha una logica lontana dal renderlo uno strumento immediato; il
mio prof di Fondamenti di Informatica disse:
"la sintassi di un linguaggio di programmazione deve essere il più
vicino possibile al nostro modo 'leggere' le cose"
ed io aggiungo:
"la programmazione ad oggeti è nata proprio per questo"..
in conclusione mi sento di dire che xcode è (alla luce degli applicativi
che girano) uno strumento potente, ma è lontano dall'essere uno
strumento facilmente abbordabile, richiede uno studio sintattico e
"filosofico" che impedisce anche a chi possiede strumenti base della
programmazione ad oggetti, di procedere per gradi, isomma non sono una
cima, ma ho avuto a ch fare con strumenti (a quanto dite voi meno
potenti) ma in grado di fornire uno strumento immediato ed efficace, so
anche che questi due termini non dovrebbero far parte del vocabolario di
un informatico, ma è sempre da li che si comincia:
"Hello world!!!"
questa è una mia *impressione* naturalmente, spero di sbagliarmi dopo
aver approfondito la questione..
grazie a tutti!!!
-- 
Ciao, Nicola

 quale si dovrebbe complicare la vita con Cocoa
Nessuno vieta di riutilizzare in Cocoa sorgenti e librerie scritti in C
e in C++: ti ricordo che proprio a questo scopo NeXT/Apple ha congegnato
l'Objective-C++.
-- 
Guido

 io lo torvo
molto utile per spulciare la documentazione Apple
-- 
Ciao
Fabio

 l'Objective-C++.
il problema non è utilizzare il C o C++, il codice che ho viene
compilato, il problema sta altrove.. faccio un esempio banale:
cerco di fare una interfaccina banale, due TextField ed un bottone,
sulla pressione di quest'ultimo trasferisco il testo che è nel TextField
a sinistra in quello di destra..
bene sembra banale, ma ho già delle difficoltà nel capire che
identificativo/nome/chiamalo_come_vuoi hanno le tue TextField che ho
inserito nell'interfaccia per poterle indirizzare o semplicemente
prenderne il valore..
di concetto io la vedo funzionare così:
dichiaro due oggetti, a mio avviso dovrebbe essere automatico nel
momento in cui li aggiungo nella finestra
TextField text_left;    
TextField text_right;
dato poi che sono due classi con i vari campi funzioni membro, accedo ai
vari campi con il punto
text_right.stringValue = text_left.stringValue (*)
non voglio tornarci sopra, ma ad esempio in Visual C++ non credo che
avrei inserito righe in più rispetto a quella contrassegnata
dall'asterisco..
-- 
Ciao, Nicola

Wezzy wrote:
 > IBAction non son sicuro ma mi sembra che sia una macro.
E' cosě: č definita in AppKit/NSNibDeclarations.h:
#ifndef IBOutlet
#define IBOutlet
#endif
#ifndef IBAction
#define IBAction void
#endif
-- 
Guido

 filosofia di xcode
non e` la filosofia di xcode. e` l'objective-c. un altro linguaggio di
programmazione. semplicemente non e` C++.
Ed e` molto piu` gajardo, anche se non bello come il Python.
Diciamo che se non ci fosse il  Python, immagino sarebbe la mia scelta.
E per i tutorial, cerca nella cartella che ti ho detto :)
-- 
RiK0

 IBAction non son sicuro ma mi sembra che sia una macro.
un 'tipo'
-- 
RiK0

 varia!!)
ma perche` non ti guardi il Python?
-- 
RiK0

 E poi c'e` il C...
.OBOL?
o mi sono drograto io?
Comunque scherzi a parte, il Fortran non e` male.
Certo ormai e` usato specialmente per un dato tipo di compiti, e per fare
applicazioni 'generiche' ci sono linguaggi piu` comodi [ python, al limite
Perl... in fondo anche C++ ].
Ma per fare algoritmi numerici 'stretti' il Fortran e` una gran cosa. A
basso livello quanto basta, ma ben sopra al processore per lasciare al
compilatore l'ottimizzazione.
Poi eventualmente riesci abbastanza bene a chiamare le routines in codice C
o altro.. 
-- 
RiK0

 che ho scritto in C e vorrei farlo con il C++..
Uh? se hai scritto codice in C, perche` non fare anche l'interfaccia in C?
E se lo hai scritto in C++, perche` chiamarlo C :))
Dopo di che come GUI C++ io mi orienterei verso QT... veramente piacevole [
anche se ci sono alcune magagne perche` reimplementa parte della libreria
standard, o meglio, offre classi alternative... e perche` ha fatto alcune
altre cosette... ma complessivamente e` parecchio comodo ].
Carbon posso dirti che non mi ha colpito... e poi e` in C. Anche se
chiaramente puoi usarlo anche in C++.. ma nzomma, la differenza con cose
'concettualmente' piu` moderne, si vede.
-- 
RiK0

 dall'asterisco..
malcom stesso ha definito "maccaronico" il mini-tutorial capostipite di
questo thread.
Sul Web non mancano tutorial introduttivi a Cocoa (un buon punto
di partenza è 
http://cocoadev.com/index.pl?CocoaTutorials
): noterai
che non c'è in realtà alcun bisogno di scrivere a mano le dichiarazioni
di IBOutlet e IBActions: è lo stesso Interface Builder a generarle
automaticamente.
-- 
Guido

 "Hello world!!!"
#include <stdio.h>
int main(){
	printf("Hello World!\n");
	return 0;
}
questo e` pure un programma Objective C.
Dopo di che... lavorati un espressione regolare in C++.. non puoi. Hai
bisogno di una libreria esterna. In Python o in ObjC la hai gia` dentro...
e qualunque oggetto altrove che abbia bisogno di una simile funzionalita`
la ha a disposizione.
Ma poi anche i cosidetti delegati... sai come ti semplificano la vita?
Ad ogni modo ogni linguaggio di programmazione ha la sua filosofia. Se tu
pretendi che siano tutti uguali al C++... beh, rimarrai deluso.
C++ non é la via.
Secondo me tu pero` non hai voglia di guardarti un manuale (o un tutorial )
di programmazione Objective C.
Bene.. guardatene uno di Python, e vivi felice.
-- 
RiK0

 * Datemi una macchina parallela e riabilitero` il FORTRAN :) :) :)
Ce l'hai: il tuo Mac (se e` almeno un G4) ha Altivec (calcolo vettoriale
e quindi parallelo).  Trovare un compilatore Fortran professionale in
grado di sfruttarla pienamente e che non ti costi piu` di un iBook e`
meno semplice;-).
Alex

 HyperCard non mi sembra certo una delle migliori idee della storia. 
Dipende da che tipo di servizio devi offrire ovviamente..

 Dipende da che tipo di servizio devi offrire ovviamente..
scusa, ma tu per che servizio lo useresti?
per come e` nato, non mi pare particolarmente scalabile...


 generazioni successive alla mia!
io di recente ho lavorato con OpenMPI... ed effettivamente mi ha dato
errore di compilazione per una storia di colonne.
O meglio, mettendo a posto la colonna, l'errore e` sparito, quindi
deduco fosse quello :))


 Non piu` di qualunque linguaggio di programmazione.
non volevo dire esattamente che l'Objective C è innaturale, anzi, si
parla di OOP (che ritengo una delle cose più naturali), volevo salemente
dire che creare una interfaccia in xcode non è così banale come
pensassi..
per il resto non posso far altro che darti ragione, specialmente sul
discorso C (non è l'unica via), volevo però cercare di sfruttare un
bagaglio culturale che fino ad ora è rimasto li in un cassetto; i
compiti dell'Università erano del tipo:
fammi la classe "numeri complessi", poi sono andato sul "difficile",
calcolo della complessità, un prof mi faceva tradurre le classi C++ in
Assembler e così via.. insomma tutti quei libri e poi?!
una cosa sola non capisco Enrico (così rispondo ad altri tuoi post):
perchè insisti con Python?! non ho il problema di scegliere il
linguaggio, ma quello di usare un tools che mi aiuti nella costruzione
di una interfaccia, ovvio è che se esiste un tools del genere in Python
ben venga.
in questo ultimo anno fra perl/php/bash/etc, alcune volte faccio un pò
di confusione (specialmente quando uso editor tipo "vi"!) ma non mi
costerebbe niente aggiungere Python, vorrei solo capire il perchè!
-- 
Ciao, Nicola

 costerebbe niente aggiungere Python, vorrei solo capire il perchè!
Vim e` comodissimo :)
vi meno ;)
Per python poi c'e` un comodo modulo.


 Per python poi c'e` un comodo modulo.
mi hai convinto! non è stato difficile! sono bastati 3 messaggi e 4
righe!
comunque per ora mi accontento, il programmino di scambio di messaggi
sembra prendere forma, l'unico problema è la temperatura dell'Ibook,
siamo sui 63 gradi (generalmente sta sui 50) e la cosa mi preoccupa..
-- 
Ciao, Nicola


|._/|_|\__/\__/\__/ | * An out of control ego will sometimes get in the
       /_/ /_/      |   way of your success.                  (Todd H.)


trattasi di bridge Python/Objective C che ti permette di usare quasi
tutto quello che trovi nei framework Cocoa in, appunto, Python.
con PyObjC la tanto temuta applicazioncina "Hello World!!!" si riduce (a
parte un po' di contorno che qui ometto) ad un:
self.massagioTextField.setStringValue_("Un saluto a tutti gli amici di
internet")
-- 
nif from outer space

 con i vecchi MacOS.
Giusto per fare un po' la punta... :)
Carbon non e` solo una libreria grafica, ma un set di API con cui fare
di tutto di piu`.
Ad esempio, se vuoi accedere al Resource Fork di un file, l'unica via e`
Carbon.


 Carbon.
Oppure una riga di Python... (che pero` si appoggia a carbon, in effetti
per quella cosa).


 ... per questo acrocco di X.
non so cosa intendi per accrocchio, la cosa che mi confonde i neuroni è
vedere applicazioni di pochi mega puppare centinaia di mega di swap, non
è che non può essere così, ma vedere TextEdit che gioca con 105MB di
swap mi fa pensare.. con questa gestione, il disco non può far altro che
macinare con ovvi incrementi di temperature..
ho letto molte diatribe sulla gestione della memoria Linux/Win, ho
sempre trovato molto efficente quella di Linux, più ne ho e più ne uso,
Win sembra essere più parzimonioso ma meno efficente se si hanno grosse
quantità di memoria a disposizione, immagino che OSX faccia una cosa
simile a Linux con l'unica differenza che Aqua è probabilemente più
esigente di una Gnome o Kde (considerazione mooolto personale)..
sarei curioso di vedere i page-fault e di sapere quali meccanismi sono
implementati, tipo copy-on-write etc.. c'è modo con Activity Monitor?
Considerazione:
se non avessi scelto di montare 512MB di ram sull'iBook avrei
*sicuramente* maledetto l'acquisto di questo portatile, o quantomeno la
prima esperienza con Apple sarebbe stata pessima..
-- 
Ciao, Nicola

 prima esperienza con Apple sarebbe stata pessima.
La mia e' stata ottima: l'iBook arrivava con MacOS 9 .-D
E ci ho messo abbastanza presto 640 MB, piu' di cosi' non posso.
Comunque direi che la prima cosa da fare e' entrare in utility disco e
ammazzare il journaling. Il disco dovrebbe lavorare la meta'.


 ammazzare il journaling. Il disco dovrebbe lavorare la meta'.
Guarda non sono un conoscitore di OS9 e non voglio alimentare una guerra
ma le poche volte che ci ho messo le mani ho solo tirato improperi. Mia
madre ha un iMac con OS9 ed e' una disperazione, porta avanti una sola
operazione alla volta, se devi per dire stampare ti si impianta tutto
fino a quando non ha finito di elaborare. allucinante. Se io sono un
utente Mac e' proprio grazie a os x (ok non che questo sia un gran vanto
:-)
PS 
dici che il journaling toglie cosi' tanto ? la meta' mi sembra eccessivo
no ?
-- 
Ciao
Fabio

 prima esperienza con Apple sarebbe stata pessima..
Altri che comunque ci giochicchiano con il mac non si son trovati poi
cosi' male con 256 mb certamente 512 sono tutta un altra storia e li
consiglio come entry level
-- 
Ciao
Fabio

 no ?
Ad ogni scrittura dovrebbe corrispondere un aggiornamento del journal.
Dunque almeno le scritture sono senz'altro raddoppiate.


 ma perche` non ti guardi il Python?
O ancora PythonCard ?

 Dunque almeno le scritture sono senz'altro raddoppiate.
Si ok ma se scrivi 1M su disco non penso che il journaling venga
aggiornato di 1M gli accessi sono in effetti 2 ma non direi paragonabili
come tempo richiesto.
Da qualche parte ho visto dei bench (mi sembra barefeats ma non ci
giurerei) dove si facevano le stesse operazioni con il journaling e
senza e si concludeva che le prestazioni erano veramente molto simili.
-- 
Ciao
Fabio

 O ancora PythonCard ?
Beh, non porta vantaggi sul Python puro. 
-- 
RiK0
Non credo negli schemi non vincenti.

 dici che il journaling toglie cosi' tanto ? la meta' mi sembra eccessivo
per la mia esperienza non cambia molto.


 strana cosa controllero'.
qualcosa tipo 'stampa in background' se la memoria non mi inganna.
in sostanza mette in coda per la stampante. invece cosi` come e` ora
stampa direttamente dal programma.


 un opzione tipo : "vuoi che la stampa porti via tutte le risorse ? "
Le *cosa*? o_O
E' un Mac, al massimo ti chiede "vuoi stampare subito subito o lo faccio
con calma piu' tardi?" .-)
Ne uccide piu' X che windows... almeno quelli erano gia' zombie .-D


 per la mia esperienza non cambia molto.
Boh, se il problema e' il caldo, il journaling scalda: il disco resta
acceso praticamente sempre.


 acceso praticamente sempre.
si. da questo punto di vista si. io parlavo di risorse intese come
'batterie' e 'processore' :))


 Beh, non porta vantaggi sul Python puro. 
era (quasi) una battuta.
Cmq a me PC piace, peccato non sia di uso immediato come HC e derivati..

 'batterie' e 'processore' :))
Insomma, il disco sempre acceso un po' di batteria la ciuccia .-)
Poi probabilmente dipendera' anche dalla macchina che hai, io con
l'iceBook prima serie piu' cose evito di far girare e piu' sono contento
.-)


 altre cosette... ma complessivamente e` parecchio comodo ].
Si`, Qt usa una specie di piccolo sovrainsieme del C++ con un
preprocessore per digerire le piccole aggiunte e questo lo rende assai
usabile (benche` leggermente problematico).  La versione gratuita
disponibile su Mac (come quella per Linux &c) e` GPL, usabile solo per
fare applicazioni GPL.  Se vuoi fare applicazioni closed source e/o per
Windows devi pagare.  Con Qt vengono strumenti di supporto eccellenti
come Qt Designer per disegnare graficamente le interfacce.
wxWindows e` l'alternativa principale: gratis dappertutto, niente
soprainsiemi ne` dialetti del C++, con tutti i + e - a cio` relativi,
meno strumenti diretti di supporto ma forse piu` popolarita` in generale
e quindi a lungo termine piu` strumenti free (immagino).
Qt e wxWindows hanno anche parecchio in comune: entrambi
multipiattaforma, supporto per C++ e per Python, look and feel
potenzialmente diversi (per default su ciascuna piattaforma il L&F di
quella specifica piattaforma).  Personalmente preferisco a livello
tecnico Qt, ma ci sono molte altre considerazioni non direttamente
tecniche da considerare nella scelta.
Alex

 dall'asterisco..
Forse ho scordato troppo VC++ (MFC, immagino tu intenda), ma per quanto
MFC violi la maggior parte dei canoni della programmazione a oggetti non
mi sembrava che arrivasse al punto di rendere pubblici i campi-dati; mi
pareva invece di ricordare che aveva una serie di metodi GetQuesto e
SetQuello come e` abbastanza tipico (in linguaggi che non supportano le
"property", cioe` l'idea che qualcosa che SEMBRA un semplice accesso a
dato o assegnamento a dato ma in realta` diviene internamente una
chiamata a metodo.
Alex

 Ne uccide piu' X che windows... almeno quelli erano gia' zombie .-D
Temo che questa fosse dovuta al mio retaggio di ex zombie
-- 
Ciao
Fabio

 chiamata a metodo.
effettivamente è così, se non ricordo male  però, come in Object C,
alcuni metodi agiscono direttamente sul campo.. diventra praticamente un
indirizzamento al campo più che una chiamata di metodo..
ma più che altro io mi ero soffermato sul discorso "creazione
interfaccia", sento la mancanza di una implementazione immediata (da
parte di IB) in xcode, probabilemente questo è dovuto a quel poco che ho
visto su VC++ (come dici tu Microsoft Fondation Class) dove ogni cosa
che inserivo nell'interfaccia veniva incorporato (come sorgente) nel
"main".. 
per ora sto approfondendo il discorso Object C, più in qua seguirò i
consigli di molti su Python (che già mi attraeva su Linux in alcuni
ambiti), alcune cose sembrano veramente maschere a codici C++ altre sono
nuove e molto interessanti.. staremo a vedere la prossima lezione del
tutorial che farà qualche esperimento con Interface Builder..
-- 
Ciao, Nicola