Newsgroup: it.comp.macintosh
Titolo: OS X e files

Oggi per la prima volta in maniera semi-seria mi sono trovato a
spippolare con i file di OS X.
facendo questo mi sono sorte alcune domande, la prima di utilità, le
altre due per curiosità, quindi chiedo a voi Macchisti da lungo tempo:
1-Come faccio a creare una icona che lancia un comando?
(In pratica creare una icona dicendole di eseguire un comando)
2-Il fatto di avere piazzato i file di alcune Applicazioni in
/Applicazioni (ad es. Safari) e altri in /usr/bin (ad es. Python e il
relativo editor) come da Unix non è poco coerente?
Oltretutto quello che è presente in /Applicazioni non è di default fra
le impostazioni di Path, e bisogna aggiungerlo manualmente, volendo
lanciarne una da terminale senza usare il percorso intero.
3-Pensavo che per lanciare Safari da terminale bastasse dare il comando
/Applicazioni/Safari, invece quella risulta essere una directory, mentre
il comando corretto è invece /Applicazioni/Safari/Contents/MacOS/Safari,
perchè la directory Safari.app contiene le impostazioni e la
configurazione del programma.
In pratica l'icona in Applicazioni è un link a se stessa?
Per carità, comodo il "trascina e avrai installato", ma per un utente
che è abituato a lanciare da /Applicazioni con il mouse, una volta
avendo le necessità di lanciarlo da terminale per verificare qualche
errore, non può risultare ingarbugliata come cosa? Sopratutto per il
fatto che non è evidente che sia una cartella andando di Finder.
Oppure tutto questo ha un motivo ben preciso che mi sfugge?
Saluti curiosi ;)
-- 
Through the darkness of futures past, the magician longs to see.
One chants out between two worlds: "Fire Walk With Me".

 In pratica l'icona in Applicazioni č un link a se stessa?
Quella che vedi sul Finder č proprio la cartella Safari.app
solo che il suffisso ".app" viene nascosto e non č possibile
navigarci dopiocliccandoci ma solo da menů contestuale.
-- 
Guido

> In pratica l'icona in Applicazioni è un link a se stessa?
Il meccanismo seguito dal Finder per lanciare i programmi è piuttosto
complesso e c'è un framework intero apposito, i Launch Services.
Fondamentale è la property list "Info.plist" che trovi in Contents:
l'icona di un programma è tipicamente memorizzata nella cartella
delle Risorse e viene puntata dalla voce CFBundleIconFile.
-- 
Guido

 lanciarne una da terminale senza usare il percorso intero.
Un'applicazione individuabile dai Launch Services può essere lanciata
usando semplicemente l'opzione -a del comando open, quindi:
open -a Safari
o aprendo un file il cui tipo vi è stato associato:
open index.html
Per le applicazioni X Window esiste il comando open-X11 che
avvia automaticamente l'X server se questo non è attivo.
Se attivi il flag eseguibile di uno script shell mediante il
comando
chmod +x script
il Finder lo esegue automaticamente cliccandoci. Se aggiungi il
suffisso ".command" al nome del file, lo script viene eseguito
direttamente in Terminale senza dover specificare la shebang
"#!/bin/bash" come prima riga dello script.
-- 
Guido

 fatto che non è evidente che sia una cartella andando di Finder.
E non deve esserlo. L'implementazione all'utente non frega.
Per quello che vuoi tu, man open.
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 delle Risorse e viene puntata dalla voce CFBundleIconFile.
Grazie


 "#!/bin/bash" come prima riga dello script.
Tutto molto utile, grazie


 Per quello che vuoi tu, man open.
Bene, grazie


 come il percorso di un applicazione, e come lanciarla
E perche' dovrebbe? L'utente sa come trovare il percorso di una
applicazione (10.3 con il campo Cerca del Finder, 10.4 con Spotlight).
Sa anche come lanciarla (facendoci doppio clic sopra).
E' stato tutto progettato e pensato apposta perche' l'utente NON ci
debba pensare.
Comodo, eh?
 - ∞

 come il percorso di un applicazione, e come lanciarla
Perchè l'utente fa doppioclick sull'applicazione. Funziona così in tutti
i sistemi civili e lui farà così. Se poi vuole fare cose più esoteriche,
c'è la ricca documentazione (oppure basta un po' di naso).
Tipo quando uno si becca questo:
[09:32][riko:Dome2] <<riko>> /Applications/TextEdit.app/
-bash: /Applications/TextEdit.app/: is a directory
È già a metà strada per sapere che cosa succede sotto il cofano.


 Comodo, eh?
Comodo ma non del tutto coerente IMO


 È già a metà strada per sapere che cosa succede sotto il cofano.
L'appunto che faccio infatti (a parte la storia /usr/ /Applications/) è
che avrebbero potuto rendere la cosa più evidente anche da Finder


 Comodo ma non del tutto coerente IMO
Secondo me si' che e' coerente. Un'applicazione e' un entita' a se
stante e il sistema la mostra all'utente come una singola entita'.
Buttare l'applicazione la rimuove insieme a tutti i documenti associati.
A me pare del tutto coerente come cosa.
 - ∞

 che avrebbero potuto rendere la cosa più evidente anche da Finder
No. Non deve essere evidente. All'utente non deve fregare una fava di
cosa succede. Per lui cliccare sul programma lo fa partire, punto e
basta.
Tanto quanto sotto un generico *nix non interessa sapere se un
eseguibile parte perchè è un binario o perchè la shell trova uno
she-bang e chiama il corretto interprete.
Sono cose che quando uno usa il programma, se ne deve fottere.


 basta.
D'accordo


 A me pare del tutto coerente come cosa.
Quello si, probabilmente č coerente come la cartella Programmi in Win,
se non di piů, solo facevo un appunto sulla dispersione delle cartelle
degli eseguibili /usr/bin/ /Applications/...


 di alias
Certo che si puň. Tra i vari modi, il piů comodo secondo me č un
AppleScript salvato come applicazione, con dentro un comando da shell:
do shell script 'comando_che_vuoi'
-- 
Salutandovi indistintamente

 per rincorrere la cartella programmi di Win
Dammi retta: il Mac non fa per te, ti consiglio spassionatamente di
tornare a Linux.
-- 
Salutandovi indistintamente

 tornare a Linux.
Problema di doppia personalità?


 do shell script 'comando_che_vuoi'
Ok, grazie


 Problema di doppia personalità?
Per quello non ti so dare consigli: rivolgiti a uno bravo...
-- 
Salutandovi indistintamente

 Per quello non ti so dare consigli: rivolgiti a uno bravo...
Vabbè su, oggi ti sei svegliato male, capita a tutti


 per rincorrere la cartella programmi di Win
Veramente la cartella Applicazioni io la ricordo dal MacOS 6.0.
 L'alternativa sarebbe scusa? Sparpagliare le applicazioni grafiche in
mezzo alle 4 cartelle (che possono diventare fino ad 8, se si usa un po'
di /opt, anche se verosimilmente saranno solo 5 o 6) dei programmi
testuali?
Oppure fare una cartella /usr/applications (che acquista immediatamente
senso in quanto sotto /usr, "più linux, più meglio", insomma)?
Oppure ancora piazzare tutto in /usr/bin? Così 
1) devi rendere noto all'utente l'esistenza di /usr.
2) gli poni davanti `ls -l /usr/bin/ | wc -l` (che qui vale 750) 
programmi con icona nera, la maggior parte dei quali se ci clicchi sopra
non fanno nulla di utile se non farti vedere l'help?
E in mezzo un centinaio (meno di default, penso una quarantina) di
applicazioni con icona colorata che invece riesce ad usare.
Mi chiedo se tu ste cose le pensi davvero.
Io mi chiedo se tu sei un troll. Me lo chiedo davvero, perchè quando fai
discorsi come quello di cui sopra, o non ragioni, oppure dici scemenze
consapevolmente.
Pare che tu ti diverta a criticare ogni scelta di Apple, anche le più
universalmente riconosciute come buone.
Nel caso in cui tu sia un troll, ti consiglio di continuare ad usare
Linux. Sei convinto che qualunque cosa fatta alla maniera Linux sia
giusta, sostieni di trovarti tanto bene con tale sistema.. bene. La
scelta è ovvia.


 Vabbè su, oggi ti sei svegliato male, capita a tutti
Nient'affatto, dormito benissimo. Confermo quanto detto, Mac OS non fa
per te: per chi vuole Linux, non c'è niente di meglio di Linux...
-- 
Salutandovi indistintamente

 scelta è ovvia.
Ragazzi, voi avete dei problemi, e parlo di te e Mad Prof.
Allora, faccio una proposta: visto che non posso io mettere voi nel mio
KF perchè alltrimenti mi giocherei il 95% dei messaggi qui su icm, vi
chiedo di mettere me nei vostri, così magari riuscirò ad interagire con
gente meno "sensibile", qualora dovesse succedere.


 per te: per chi vuole Linux, non c'č niente di meglio di Linux...
Leggiti quanto detto al Franchi, oltretutto non ho alcuna voglia di
giocare con te


 giocare con te
Tranquillo, non è mia abitudine giocare con bambocci imbecilli...
-- 
Salutandovi indistintamente

 (In pratica creare una icona dicendole di eseguire un comando)
Non e` cosi` immediato come in kdx o gnome, pero` si puo fare:
I modi di farlo sono sotanzialmente due dioende molto se vuoi usare funzioni 
della gui di Macosx e funzioni riguardanti la parte *nix ed il terminale.
Se vuoi usare funzione della Gui e far eseguire dei comandi a delle 
applicazione che usano la gui la cosa migliore e` usare applescrit:
Per fare questo devi usare sull'editor di applescript  che si trova in  
"/Applications/AppleScript/Script Editor.app" 
Quindi clicchi su record, a questo punto apri l'applicazione che vuoi  far 
aprire e subito dopo ritorni sul editor di applescript e clicchi su stop.
nel caso tu volessi aprire l'applicazione safari otteresti una cosa tipo 
questa:
tell application "Safari"
	activate
end tell
A questo punto lo salvi con Save as avendo cura di selezionare come file 
format Application tutto qui.
In alternativa puoi crearti uno script in bash o tash e usare i comandi 
appropiati quali open ecc, quindi salvi lo script dove vuoi e gli dai i 
diritti giusti, primo tra tutti quello di esecuzione.
-- 
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo

 e /usr/binperlepersonenormali/
Gia` e poi tutti i programmi *nix che si aspettano di avere una cartella 
/usr/bin sopartutto in fase di compilazione come fanno a funzionare ?
User bin ci deve essere perche` fa parte del cuore *nix di MacOS X, ma per 
scelta di apple, che anche io in questo caso approvo in pieno non e` 
normalmente accessibile direttametne dall'utente, in modo da non creare 
confusione.
in /Applications invece ci stanno tutte le applicazioni con gui che usano 
aqua e che normalmente gli utenti usano. 


 degli eseguibili /usr/bin/ /Applications/...
E` qui che ti sbagli:
all'utente normale di /user/bin o /bin o /sbin non deve importare 
assolutamente nulla perche` normalmente non a avra` mai motivo di averci a 
che fare, visto che in quelle cartelle risiedono le applicazione *nix che 
salvo qualche rarissima eccezione non hanno una gui aqua al massimo x11.
ed infatti non a caso non sono direttamente accessibile all'utente tramite 
l'interfaccia grafica.
Per questo e` stata creata la cartella applicazioni che esiste da ben prima 
di MacOS X, dove coerentemente risiedono tutte le applicazione con gui aqua e 
che normalmente l'utente usera`. 


 frustrazioni perché Campo Fiorito non gli riesce.
In realtà su icod Cipria quando si parla di Win e Linux dimostra delle
conoscenze che non sospetteresti.
E' quando si passa a parlare di Mac che comincia a sbarellare e a fare
l'idiota... 


 e chi piů ne ha piů ne metta 
/bin, /opt/bin, avoglia, ce ne sono almeno 8 di /bin nel sistema :)


 ci sia un limite...
...poi rileggi i tuoi messaggi?


 voglia esplorarla, in modo da non confonderlo. 
Appunto


 gente meno "sensibile", qualora dovesse succedere.
No, sei un pupazzo divertente. E poi credo che tu possa essere da monito
per i nuovi utenti linux che purtroppo si stanno avvicinando al sistema,
e sinceramente sono preoccupato. Sei un buon esempio di come *non*
bisogna essere.
Ma credo che tu lo faccia apposta, non credo tu sia "vero".
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 e /usr/binperlepersonenormali/
Infatti la cartella \programmi è bella incasinata ed ai programmi si
accede tramite pulsante start.
-- 
Long Playing

 sbin e compagnia).
Tanto su KDE si accede alle applicazioni tramite pulsante
/copiadistart/. Non ricordo su Gnome.

 Non ricordo su Gnome.
Beh, li è più variegata la cosa. Comunque si usa spesso una specie di
menu, che a parte sotto Debian e Ubuntu è spessissimo fuori
sincronizzazione con le applicazioni realmente installate.
Dopo di che adesso pare che finalmente sia stato fatto un programmino in
grado di aggiungere comodamente le applicazioni ai menu e tutto. Prima
bisognava editare a mano, oppure usare Debian.
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 Ma credo che tu lo faccia apposta, non credo tu sia "vero".
Occavolo, mi hai scoperto, sono Cipria.
A Franchi, ma và, và...


 aqua e che normalmente gli utenti usano. 
Per creare una distinzione fra "questo è Unix" e "questo è Mac"?
Mi fido


 format Application tutto qui.
Ok, lo farň, grazie


 accede tramite pulsante start.
Non sempre basta il menu Start, molte volte devi arrivarci comunque


 grado di aggiungere comodamente le applicazioni ai menu e tutto.
Anche chiamato: "tasto destro-aggiungi voce a questo menu"


 che normalmente l'utente usera`. 
Gui Aqua = /Applications, non gui Aqua = /usr/bin?


 non gui Aqua = /usr/bin?
Esatto. Di solito pero' si tende a usare /usr/local/bin perche' Apple
non lo usa di suo ed e' quindi piu' facile non avere conflitti. Comunque
e' indifferente. (Ci sono anche /sw usato da Fink e /opt/local da
DarwinPorts, ma l'idea quella e'.)
 - ∞

 Per creare una distinzione fra "questo è Unix" e "questo è Mac"?
E' una cosa piu' sottile... in un pacchetto .app ci sono tutti i file
necessari a far girare un'applicazione, organizzati secondo le modalita'
di NeXTStep. Puoi spostare un'.app dove vuoi e potrai continuare a
usarla senza problemi; buttandola rimuovi tutti i file. L'utente puo'
manipolarla come se fosse una singola entita' e non deve ammazzarsi con
sistemi di packaging o con programmi a parte (Installazione Applicazioni
win32) se vuole aggiornarla o rimuoverla.
Le applicazioni UNIX hanno il loro bell'ambiente UNIX dove i file
eseguibili sono in una posizione (es /usr/bin) e eventuali file di
supporto in altre posizioni (es /usr/share). Per gestire questi bisogna
fare a mano o appoggiarsi a un sistema di packaging (rpm, fink,
darwinports, Installer di Apple...).
 - ∞ 

 [megasnip]
Per dirla in parole poverissime:
 Sotto Applicazioni ci sono le cose che l'utonto sotto la media puo'
manipolare col Finder senza fare macelli.
 Sotto /usr e compagniabbella ci sono le cose che se l'utonto sotto la
media manipola col Finder, fa disastri. Inoltre Apple dice: scriveteci
il meno possibile, cosi' incasiniamo la cosa il meno possibile e se
l'utonto sotto la media vuole buttarvi via, puo' farlo senza rovinarsi
la vita.
 - ∞

 Gui Aqua = /Applications, non gui Aqua = /usr/bin?
in linea di massima si, se vuoi essere ancora piu` preciso:
Gui Aqua = /Applications
linea di comando o aterminale che dir si voglia: /usr/bin.
Per quanto riguarda invece le applicazioni che usano X11 le cose sono 
leggermente meno precise, ad esempio il programma vero e proprio puo` stare 
in una delle cartelle /bin ma magari esiste anche un programmino in 
/Applications che serve per lanciarlo, oppure puo` stare tutto dentro alla 
cartella /Applications.


 cartella /Applications.
Le applicazioni X11 sono una specie di "cittadino di seconda categoria"
in OS X, a causa del fatto che non sono single-file e non sono bundle.
Le applicazioni Java (.jar), ad esempio, se la passano meglio...
 - ∞

 Per creare una distinzione fra "questo è Unix" e "questo è Mac"?
In parte si, ma la ragione alla base e quella di nascondere il piu` possibile 
ad un utente normale la parte *nix di os X a meno che ovviamente lui non 
voglia esplorarla, in modo da non confonderlo. 
-- 


 Le applicazioni Java (.jar), ad esempio, se la passano meglio...
Si in effetti le applicazioni X11 sono davvero figlie di un dio minore per 
Apple, e difficile capire dove vengono installate e come fare poi a 
rimuoverle a meno che l'autore stesso non metta anche un programma di 
disinstallazione od un file di documentazione con le istruzioni passo passo


 Occavolo, mi hai scoperto, sono Cipria.
No, quello no. Cipria non sa nemmeno che esista una cartella


 Gui Aqua = /Applications, non gui Aqua = /usr/bin?
+ o  meno.
O se preferisci roba *nix posti *nix. Roba MacOS X /Applicazioni


 Occavolo, mi hai scoperto, sono Cipria.
Di solito penso che al connubio di niubbaggine, ignoranza e tracotanza
ci sia un limite. Mi illudo sempre.
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 standard, quindi solo /usr/bin/
ti posso confermare che questa č una balla ;)
/usr/bin /usr/local/bin
/opt/local/bin   /usr/whatever/bin
e chi piů ne ha piů ne metta 
-- 
=== *Mablung The Heavy Hand* ===

 qualcosa di non "standard"
Bene che qualcuno lo alzi. Tanto piů che non č mica sigillato :-)
L'importante č non trovare l'astina per misurare l'olio nel cassetto
portaoggetti, che poi mi farebbe un po' schifo metterci i biscottini.
Ah, comunque in famiglia abbiamo avuto un Fiat 900T, dovevi vedere che
carini i serbatoi rispettivamente del liquido freni accanto ai pedali e
del lavavetro davanti al passeggero, dentro la _ruota di scorta_
:-DDD

 bisognava editare a mano, oppure usare Debian.
Carino. Dici che lo metteranno anche su Vista? :-)

 
Appunto ma se uno alza il cofano si presume anche che sappia dove mettere le 
mani, altrimenti se fa danni o si fa` male sono solo cavoli suoi.


 mani, altrimenti se fa danni o si fa` male sono solo cavoli suoi.
"presuppone" č il punto


 darwinports, Installer di Apple...).
Si, infatti


 DarwinPorts, ma l'idea quella e'.)
Ok


 cartella /Applications.
Capito


 Qusto non è del tutto vero, metti un prompt interattivo
Se e' per questo un prompt interattivo non serve manco al programmatore
se non per fare del testing o delle provettine al volo... o meglio, io
per altro non lo uso. Al peggio: print string.split.__doc__ quando non
mi ricordo gli argomenti o robe cosi'.
 - ∞

 Si, infatti
E tada'. Nessun problema :p
 - ∞

 Capito
Mi fa piacere che alla fine siano riusciti a spiegarci.


 "presuppone" č il punto
Se uno non sa dove mettere le mani, neanche lontanamente, solitamente non 
alza neanche il cofano, perche` non sa` come alzarlo :).
Ci sono tantissimi utenti di OS X che la parte *nix non l'hanno mai vista ne 
la vogliano vedere, non sanno neanche che esiste una applicazione che si 
chiama terminale, o magari lo sanno ma non la usano perche` sanno che con 
quella si puo` far danni.
Non a caso spesso ci sono post di utenti che chiedono appunto cosa sia il 
termnale e come si usa.


 prevedono installer) il menu perde la sincronizzazione.
Infatti. E non ci vuole molto.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 ...poi rileggi i tuoi messaggi?
Ohibň... di tre cose due non credo proprio mi si possano applicare. Non
in questo gruppo, per lo meno. La terza.. beh, me la fai sal
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 Mi fa piacere che alla fine siano riusciti a spiegarci.
Basta non ragionare in maniera isterica come altri qui dentro :)


 termnale e come si usa.
Ohibò, mi immagino le risposte.
Voglio dire che non è la cosa più semplice da spiegare su un NG, l'uso
del terminale :)


 mi ricordo gli argomenti o robe cosi'.
Non dico che non si possa fare senza, per carità


 in questo gruppo, per lo meno. La terza.. beh, me la fai sal
...


 E tada'. Nessun problema :p
Questa č stata indubbiamente una buona idea (rendere compatibile il
software per X11, dico), mi sembra ci sia dal 10.3, giusto?


 del terminale :)
Be dipende da chi a risposto, se fai qualche ricerca con google probabilmente 
riesci a trovare i post vecchi.
Comunque in molte risposte e` sottolineato il fatto che con il terminale se 
non si sta` attenti si possono fare danni.


 anche per sapere se era un Unix o roba simile
Si era *nix. Il kernel derivava dal Mach. (e tuttora deriva dal mach).
-enrico
-- 
Never argue with a logician.

 ...
... tare fuori quasi solo tu.


 (e tuttora deriva dal mach).
Questo lo sapevo


 non si sta` attenti si possono fare danni.
Immaginavo :)


 ... tare fuori quasi solo tu.
E altre N mila persone, la cosa non regge, mi spiace, c'è google a
testimoniare


 testimoniare
Tipo? Ad ogni modo io posso anche essere un mangia-noobs... non mi crea
problemi questa figura. Alla luce di questo comunque ho rilettuto e
"alleggerito" questo mio post. Spiace per i passati, tenterō di tenerlo
presente nei futuri.
*DISCLAIMER* stasera ho le dita invirgolate, il messaggio potrebbe
essere condito da vari errori di battitura e/o grammatica.


 presente nei futuri.
Ho raggruppato in fondo le parti inutili delle tue repliche, notato di
quanto si tratta?
Come ho detto al tuo compare, comunque, non è mio interesse giocare a
lanciarci le palline di carta


 pazzo!
Ma certo che si... ma tu i contro non li hai valutati. E se li hai
valutati, perdonami, ma li hai valutati male. Perchè non hai tenuto
conto di un paio di cose non certo trascurabili.
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 conto di un paio di cose non certo trascurabili.
Sarebbero?


 Sarebbero?
Leggi più sopra.


 *interessanti* arrivano molto dopo.
f


 Per te se fossero un unico file, non ci sarebbe differenza.
Beh, insomma, diciamo spesso, ma non sempre
Esempio terra-terra: Valknut (non proprio un SW per smanettoni), vado
nelle preferenze e trovo dove inserire il percorso per averlo in
italiano.
Qual'è sto percorso? Spotlight non mi trova nulla, allora vado di "find
/ | grep" da terminale e trovo che il file di traduzione è dentro
Valknut.app.
Poi scopro che con CTRL+Click-Mostra contenuto pacchetto posso entrare
anche da finder all'interno del file Valknut.app, cosa che prima non
immaginavo, ma non credo che identificare in maniera più chiara il fatto
che quella in Applicazioni è (anche) una cartella all'utente faccia un
soldo di danno.
Sopratutto se all'utente non va di leggersi il manuale (come succede di
solito)


 I glossary su tutto
Si, ma non per tutti i "linguaggi"/ambienti sono effettivamente comodi.
In C per dire non servono quasi a nulla (a meno di non scriversi un
glossario fatto come si deve). ;)


 italiano.
Ecco.. io non ho vista la cosa, ma da come la descrivi significa che lo
sviluppatore di tale programma ha toppato. È un errore suo. Punto.
Se lui avesse fatto il suo mestiere, tu non avresti dovuto ficcare le
mani in cose che non sei obbligato a sapere.
Ribadisco: l'errore è *suo*.


 guarda che ci vuole *davvero* poco.
Non tanto per "scriverlo", quanto semmai per pensarlo.
Dopo di che il numero delle funzioni che uno dovrebbe inserire sarebbe
"digitativamente" abbastanza grosso. A meno di usare un tool automatico.
Poi per il C++ bisognerebbe anche rendere il tutto "intelligente" al
contesto, in pratica ci vuole un qualcosa che analizza il codice, un
glossario non sarebbe sufficiente.
In effetti l'autocompletamento per questi linguaggi (quello "vero") non
ce lo hanno tutti...


 Ribadisco: l'errore č *suo*.
Intendi che avrebbe dovuto piazzare i file di traduzione da qualche
parte piů visibile all'utente?
Tipo la home, ma mi sembra un forzatura, facessero tutti cosě noi si
avrebbe una home enorme


 avrebbe una home enorme
No. MacOS X ha un sistema automatico di gestione dei files di 
traduzione. Stanno tutti nel bundle e se uno fa il bundle fatto bene il 
sistema carica automaticamente la localizzazione corretta
Guarda:
EasyPopServer] $ ls /Applications/iTunes.app/Contents/Resources/
Dutch.lproj          iTunes-cd.icns       iTunes-playlist.icns
English.lproj        iTunes-database.icns iTunes-sd2.icns
French.lproj         iTunes-device.icns   iTunes-snd.icns
German.lproj         iTunes-eq.icns       iTunes-visual.icns
Italian.lproj        iTunes-generic.icns  iTunes-wav.icns
Japanese.lproj       iTunes-itms.icns     iTunes-wma.icns
Spanish.lproj        iTunes-movie.icns    iTunes.icns
complete.aif         iTunes-mp2.icns      iTunes.rsrc
da.lproj             iTunes-mp3.icns      iTunesHelper.app
fi.lproj             iTunes-mpeg4.icns    ko.lproj
iTunes-aac.icns      iTunes-mpeg4p.icns   no.lproj
iTunes-aacp.icns     iTunes-mpg.icns      sv.lproj
iTunes-aiff.icns     iTunes-nvf.icns      zh_CN.lproj
iTunes-audible.icns  iTunes-ogg.icns      zh_TW.lproj
ecco, i vari .lproj olandese, inglese e compagnia vengono caricati 
automaticamente quando quella è la lingua di sistema (in realtà sono 
caricati nell'ordine in cui sono specificati nelle preferenze di lingua 
dell'utente. Per esempio se un italiano che parlasse benissimo il 
francese potrebbe volere che un pacchetto se non è localizzato in 
italiano, venga caricato in francese prima che in inglese).
Il sistema c'è e funziona. Io il programma che citi non lo conosco e non 
lo ho usato. Ma posso dirti che per gli sviluppatori MacOS il sistema di 
fare il tutto in automatico esiste ed è abbastanza diffuso (tra l'altro 
per localizzare non sono necessarie doti di programmazione, basta 
mettersi li e farlo, è spiegato, ed è semplice -- anche se, a mio gusto, 
noioso, ma quello prescinde dal fatto di come lo fai).
-riko

 sistema carica automaticamente la localizzazione corretta
Ah, ho capito che intendi per errore dello sviluppatore, mi sembra
sensato.


 /Applications
Uh? Li c'è un motivo di usabilità. Quale è il motivo di usabilità di non 
tenere la roba in /usr/bin. Il path penso che tu lo sappia settare (e ad 
ogni buon conto qualche pkg e/o programma che installa in /usr/local 
esiste (ammesso che non sia settato di default). Poi ti è del tutto 
trasparente.
-riko

 trasparente.
Si, ma non è questione solo di Path (anche perchè di solito
/usr/local/bin è già presente) che comunque si può settare, è questione
di avere le cose nello stesso posto, come le icone, come le librerie e
file di configurazione


 file di configurazione
Perchè non metti nello stesso posto anche le pagine di man le librerie e
le applicazioni, già che ci sei. Anzi, metti tutto indistintamente nella
root.


 le applicazioni, già che ci sei.
Perchè le pagine di man e le librerie sono cose diverse concettualmene
da un'applicazione. Mentre un'applicazione è sempre un'applicazione, che
sia in /usr/bin o in /usr/local/bin


 sia in /usr/bin o in /usr/local/bin
Povero ingenuo. Spero solo di non dovere mai avere a che fare con un 
server amministrato da te (non prima per lo meno che tu capisca quali 
sono i fondamenti della filosifia di *nix).
-riko

 sono i fondamenti della filosifia di *nix).
Spero di non avere altre discussioni con te, almeno non prima tu abbia
imparato a leggere
