Newsgroup: it.comp.macintosh
Titolo: da uno sviluppatore Windows.

E' vero che APPLE fornisce gratuitamente il proprio ambiente di sviluppo SW 
?
... quindi se comprassi - ipotesi - un miniMac
potrei cominciare a sviluppare applicazioni per MacOS
senza costi aggiuntivi ?
Grazie e ciao a tutti.

 E' vero che APPLE fornisce gratuitamente il proprio ambiente di sviluppo SW ?
Si:
http://developer.apple.com/tools/xcode/index.html
-- 
bye
donger

 senza costi aggiuntivi ?
al *costo* di impararti l'objective C + cocoa 

 senza costi aggiuntivi ?
Si
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 senza costi aggiuntivi ?
Esatto. Beh, la corrente la paghi, chiaro. Il caffè pure. :)
-- 
USB Priests for only 10$

 al *costo* di impararti l'objective C + cocoa
Beh, ma quello è un piacere. Cocoa è davvero una bella libreria.
E se conosce già Python o Ruby o Perl può benissimo usare uno dei 3.
O anche brrr... Java.


 senza costi aggiuntivi ?
Becchi l'installer dei devtools in Applicazioni > Installer sui Mac
preinstallati, e sul DVD di Tiger se hai aggiornato. Puoi scaricare
l'ultima versione di Xcode e strumenti di sviluppo vari da
developer.apple.com
.
 - ∞
-- 
http://millenomi.altervista.org/

 Beh, ma quello è un piacere. Cocoa è davvero una bella libreria.
mica detto il contrario, solo non s'aspetti d'arrivare col c++ e
spaccare il culo ai passeri

 senza costi aggiuntivi ?
Si

 spaccare il culo ai passeri
tzk
#include <animals/sparrow.h>
#include <sex/sex.h>
#include <sex/anal.h>
#include <sex/anal/helpers.h>
class BrokeBackableSparrow : public Animals::Birds::Common::Sparrow
{
private:
Sex::Forbidden::Ass *ass_;
BrokeBackableSparrow() : ass_( new Sex::Forbidden::Ass(1.4) )
{
  Sex::Forbidden::Anal::Lube lube;
 
  // not lubing may end with unhandled exceptions
  ass_.lube(lube, 2);
 
  try {
    ass_.finger();
  } catch VirginAsshole {
    ass_.lube(lube, Sex::Forbidden::Anal::Lube::ALL);
  }
 
}
 
void assFuck(const Sex::Member::Dick& dick) {
   assert(Animals::Birds::Lipu::nearest() > 1000);
   try{
   	ass_.insert(dick);
   } catch (Sex::Exception::Ouch) {
   	if (this.horny)
   	    ass_.spit_on();
   	else{
   	    Animals::Adapter::SanFrancesco sf(this);
   	    sf.talk_softly(Sex::Romance::rand());
   	    if (ass_.finger()){
   	      ass_.insert(dick);
   	    } else {
   	      throw;
   	    }
   	}
   }
}
}
Piuttosto mi chiedo chi vorrebbe spaccare il culo ad un passero... (evito
ulteriori battute...)


 senza costi aggiuntivi ?
si ma scordati di usare lo stesso approccio che si ha con visual basic,
visual c++ et similia.
vedrai che con xcode, cocoa e objective-c sei praticamente obbligato a
creare un'interfaccia utente estremamente intuitiva e user-friendly, solo
che la cosa viene praticamente quasi da sé.
per inciso, anche l'interface builder è intuitivo e potentissimo non tanto
per la gestione della grafica della gui quanto per l'associazione tra
elementi grafici e metodi/relazioni dell'applicativo.
in più tutta una serie di opzioni di menu (come per esempio le preferenze o
i menù canonici) sono "già" impostate in modo assolutamente coerente con
l'ambiente OS X senza che tu debba preoccuparti di questo. tu devi solo
"agganciarle" agli specifici parametri della tua applicazione.
tutt'altra musica rispetto ai developer tools tipici del mondo windows.
saludos
germano il gatto grigio
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 senza costi aggiuntivi ?
Come gia` tanti ti hanno detto, si`.  Come nessuno ti ha detto, se per
qualche ragione preferisci non imparare ObjectiveC e Cocoa, che pure
sono dei bei sistemini, puoi anche usare dei toolkit "portatili" che ti
permetterebbero in futuro di portare le tue app a Windows o Linux con
poca fatica -- ce ne sono di completamente liberi e gratuiti scaricabili
dalla rete, come wxWidgets, mentre altri come Qt sono disponibili o con
GPL (forse poco pratico per app commerciali) o con licenza commerciale
(ma tutt'altro che gratuita, quest'ultima -- comunque, sono politiche
commerciali di venditori terze parti, Apple in se non c'entra).
Tutte queste scelte le hai sia in C++ sia in Python; per altri linguaggi
come Perl o Java le possibilita` sono un po' diverse (e non sono del
tutto sicuro dei dettagli, sorry).
In pratica, se non hai davvero bisogno di poter portare un domani le app
anche ad altri ambienti, io andrei con Cocoa (e quindi un minimo di
ObjC, se non altro per poter capire le abbondanti doc gratuite su Cocoa,
anche se poi ad es puoi programmare in Python con PyObjC e di codice
ObjC vero e proprio scriverne poco o nulla).
Se poi sei invece un patito del Basic a tutti i costi c'e` un prodotto
terze parti chiamato RealBasic, ma a parte che e` non gratis e ci fai
app portabili su Windows (ma non su Linux) non so molto di esso.
Alex

 ulteriori battute...)
Be di gente strana il mondo ne e` pieno.
-- 
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo

 commerciali di venditori terze parti, Apple in se non c'entra).
ottima scelta se si vogliono svilpuuare applicazioni multipiattaforma,
generalmente integrate malissimo nell'ambiente OS X...

       if (this.horny)
this->horny 
:-)

 wrote in message 
news:1hbz4ye.1in8n7dj203kiN%ale...@yahoo.com...


 generalmente integrate malissimo nell'ambiente OS X...
Mah, ho visto girare Photoshop Elements e non mi pare male (usa Qt,
infatti Trolltech lista Adobe fra i suoi "testimonials"); lo stesso
posso dire del lato client di prodotti Strakt come CAPS, pure Qt, anche
se non sono certo cosi` diffusi come PE. Nel caso di Strakt, visto il
mio passato ruolo di consulente, posso asserire che vista la frazione di
Mac nel loro target non avrebbero mai sviluppato client per Mac se non
gli fosse venuto "praticamente gratis" come in effetti fu grazie a Qt
(dovevano comunque supportare Windows e Linux, Qt lo selezionarono per
questo scopo, il Mac fu un "piacevole effetto collaterale";-).
Tu che prodotti commerciali hai in mente, basati su Qt, che si integrano
male in MacOSX?  Non e` che io ne abbia visti poi tanti, baso le miei
opinioni sui due che ho visto, e quei due vanno bene...
Alex

 opinioni sui due che ho visto, e quei due vanno bene...
commerciali e' una discriminante? non mi pareva facesse parte del topic
iniziale...  a dire il vero ho visto poca roba in giro sviluppata con qt
wx penso di non averlo mai visto e tutta con un interfaccia tra
l'orribile e la pessima
dirai tu, grazie al pene sara' stato qualche hobbista domenicale...
certo magari si (ma magari pure no) eppure gli obbisti domenicali
producono robina di ben altro livello con cocoa... (e, suppongo, fanno
pure prima)

 pure prima)
Cosa conosci, multi-piattaforma, fatto da hobbisti e (su Mac) con Cocoa?
Alex

 Cosa conosci, multi-piattaforma, fatto da hobbisti e (su Mac) con Cocoa?
ROTFL :-)
lo sviluppo di applicazioni integrate con osx e lo sviluppo di
applicazioni multipiattaforma portano in direzioni *necessariamente*
divergenti: tanto piu' qualcosa e' multipiattaforma tanto piu' deve
basarsi sull'intersezione delle features offerte dalle varie piattaforme
tale intersezione tende a un minimo a mano a mano che le piattaforme si
sviluppano

 hai mai provato amule?
Sacre Bleu! chemmerda.
-- 
Lo sentivo: sarei stato stritolato da un meccanismo omicida.
Otto ore di lavoro al giorno, tre settimane di ferie l'anno; avrei
venduto l'unica cosa che mi era rimasta di mio oltre il culo: il tempo.
E a pochi mesi dalla pensione avrei scoperto di avere il cancro.


Neppure io lo conosco bene, cmq  c'è anche per linux
Luca

 basarsi sull'intersezione delle features offerte dalle varie piattaforme
Questo ovviamente se uno si limita alle features x-plat della libreria.
Nessuno poi vieta di scrivere pezzetti aggiuntivi che permettono una buona
ottima o per lo meno decente integrazione con il sistema host.
Certo, bisogna sapere quello che si fa. Questo porta verso aziende
commerciali con grossi fondi (Adobe, Google, bene; Opera così così -- che
mi hanno poi detto essere stata presa da google ) oppure verso progetti ben
organizzati.
Per esempio NetBeans 5 sotto MacOS ha come problema l'elefantiasi (ma
quella è colpa un po' delle GUI Java un po' della JVM di MacOS X). Ma i
menu li piazza correttamete come qualunque applicazione Mac (integrazione
decente anche per il resto, senza mai strabiliare).
Flock pure mi pare ben integrato. Il problema di molti programmi Open è che
semplicemente c'è poca voglia di lavorarci. Adobe deve lavorarci, visto che
altrimenti li prendono a calci.
Magari in un progetto Open (anche se di altissima qualità) non hanno
nemmeno un mac su cui testare il sw o giù di li... e alla fine hanno altre
priorità che non rifinire l'integrazione.


 organizzati.
alt 
adobe mica usa tulkit multipiattaforma
adobe rifa l'interfaccia adattandola al kit nativo, son altro paio di
maniche
non confondiamo le carte ;)


Confermo. COn RealBasic puoi sviluppare applicazioni per Mac, per
Windows e per Linux.

 non confondiamo le carte ;)
Cioe`?  Stai dicendo che Trolltech, il produttore di Qt, mente per la
gola quando dice che Adobe usa Qt (in Photoshop Album/Elements)?
Se cosi` fosse non capisco perche` Adobe dovrebbe permettere a un simile
impostore di usare impunemente, oltre che fraudolentemente, il marchio
registrato "Adobe", quindi sospetto invece che Trolltech dica la
verita`.
Alex

Ciao, potresti darmi qualche delucidazione in merito le librerie Qt?
Ho dato un'occhiata al sito ed a sentir loro è tutto molto facile, con
una portabilità delle applicazioni molto rapida ed indolore.
Hai qualche esperienza in proposito o conosci qualcuno che ne faccia
uso?
Grazie mille.
Stefano

 gola quando dice che Adobe usa Qt (in Photoshop Album/Elements)?
io album elements manco li caco
adobe e' photoshop, il resto so giocattolini

 wrote:

Ma prego!  Le ho usate piu` che altro da Python, con PyQt (ma anche
direttamente da C++), per conto di vari clienti, quando facevo il libero
professionista. Il supporto per Mac e` (relativamente) recente, data da
Qt3; in precedenza Qt supportava Windows, Unix e Linux, e (nella
versione Qtopia) vari PDA, cellulari, e simili. Non ho provato le nuove
Qt4, visto che e` un bel po' che non sviluppo GUI e simili. So che
Google Earth usa Qt 3 (non e` un segreto, basta guardare un attimo in
Program Files\Google\Google Earth nella versione Windows, ad es), e mi
dicono i colleghi che questo ha effettivamente facilitato il porting da
Windows a Mac, ma personalmente non ho lavorato a Google Earth (e non so
perche`, almeno a tutt'oggi, esista per Win e Mac ma non per Linux),
quindi non ho informazioni "di prima mano" in merito.
I problemi di Qt sono piu` che altro economici, visto che Qt esiste, o
in versione GPL (che richiede siano pure GPL tutte le applicazioni che
la usano), o in versione commerciale (costosetta anzicheno`). Sino a Qt3
il GPL non c'era per Windows, tra l'altro. Tecnicamente, le ho trovate
effettivamente facili da usare; davvero ottima la documentazione, molto
dettagliata e completa. Forse l'unico problema tecnico e` che in passato
le versioni nuove di Qt sono spesso state a lungo "poco stabili", con
cambiamenti frequenti alle API, non 100% compatibili da una versione
alla successiva; sospetto sia per questo che (ad es.) Google Earth usa
la solida, stabile Qt3 piuttosto che la nuova Qt4, ma queste sono
illazioni mie personali (come accennavo, non ho esperienza di Qt4).
Alex

Un'ultima cosa... per quanto riguarda il portin da Mac a Win di
un'applicazione, nella dicumentazione dice che "basta ricompilare"...
:)))
Per eseguire questa operazione si deve avere una macchina Windows con
installato il tool di sviluppo con le Qt o e possibile farlo
direttamente da Mac?
Di nuovo grazie.
Stefano

 wrote:

Se hai a disposizione un cross-compiler, cioe` un compilatore che
girando sulla piattaforma A produce codice binario eseguibile per la
piattaforma B, puoi fare tutto su A (meno i test su B che comunque
dovrai fare su B o un suo buon emulatore;-). Ma questo appunto dipende
dal linguaggio e dal suo compilatore: Python, come Java, puo` produrre
su qualsiasi macchina bytecode eseguibile su qualsiasi altra, mentre per
C++ i cross-compiler sono relativamente poco comuni (XCode puo` generare
codice binario anche per intel girando su processori PPC, e viceversa,
ma non credo supporti altri formati per emettere quel codice binario se
non quelli nativi Mac).
Alex

 non quelli nativi Mac).
Dicono dalla regia (io non ho provato) che in teoria mettere su un
cross-compiler con gcc non dovrebbe essere proibitivo. Una volta i darwin
ports li installavano in modo semiautomatico, ma non ho mai letto la doc
per sapere poi cosa bisognasse fare (per esempio per gestire le librerie
esterne).


 Windows e per Linux.
Che fanno ugualmente cacare ovunque, tra l'altro. In questo e' davvero
cross platform!



Questo dipende da CHI sviluppa COSA. Non certo dall'ambiente di
sviluppo.
Ti assicuro che ci sono programmi che fanno CACARE come dici tu anche
in Cocoa, C++ o quant'altro...

 sviluppo.
Si, certo... lo sviluppatore ha le sue colpe. Ma anche l'ambiente aiuta (o
incentiva pessime pratiche). Gia' il fatto nel 2006 a trovarsi a lavorare
con un obietto come il Basic, per quanto restaurato mi lascia interdetto.
Personamente gia' questo (assieme al fatto che esistono almeno 4
alternative a costo 0 tutte migliori senza appello) mi fa desistere
dall'intento.
In secondo luogo la roba di real basic sotto GNU/Linux e' davvero una pena,
per dire. 
