Sviluppo applicazioni grafiche cross-platform Mac/Linux


l.anderlini
 Share

Recommended Posts

Ciao a tutti.

Dovrei realizzare applicazioni grafiche che funzionino su SO Linux. Dal momento che io uso un macbook mi piacerebbe poter utilizzare l'applicazione sviluppata su entrambe le macchine senza emulazioni di SO o simili.

Mi piacerebbe anche scrivere in linguaggio C/C++.

Detto questo sono totalmente all'inizio. Programmavo in MS Visual Studio 6.0 sotto windows ma in questo caso non so che farmene. Ho letto che con XCode è semplice realizzare applicazioni utilizzando Cocoa e Carbon, ma, se ho ben compreso, sfruttano molto le api di OS X. Prendendo spunto di Inkscape e Gimp ho pensato che potrei sviluppare con tecnologia X11.

In una breve ricerca a questo proposito mi sono usciti ancora Carbon e Cocoa e mi sono sentito riportato al punto di partenza.

Scarico Xcode o è meglio qualche altro IDE? Vi chiedo subito anche se potete segnalarmi la documentazione relativa alle funzioni di libreria del compilatore che mi troverei ad utilizzare.

Grazie davvero.

Lucio

Link to comment
Share on other sites

Ciao a tutti.

Dovrei realizzare applicazioni grafiche che funzionino su SO Linux. Dal momento che io uso un macbook mi piacerebbe poter utilizzare l'applicazione sviluppata su entrambe le macchine senza emulazioni di SO o simili.

Mi piacerebbe anche scrivere in linguaggio C/C++.

So che è parzialmente OT, dato che specifichi chiaramente la tua predilezione per il C/C++, so che farà storcere il naso a molti, però... ho scritto e mantengo in Java un semplice editor grafico dedicato al disegno di schemi elettrici e circuiti stampati. Il programma non è immenso, ma neppure banale (18k linee). Sono totalmente soddisfatto della scelta che ho fatto, anche perché alcune estensioni (come Quaqua) permettono di eguagliare praticamente il look nativo di un'applicazione sotto MacOSX. Conosco abbastanza bene il C++ e sono anche rimasto piacevolmente impressionato dalla facilità con cui certi bug normalmente insidiosi vengono segnalati in Java.

Anche se uso esclusivamente il C/C++ per programmi di calcolo numerico dove le prestazioni e la gestione della memoria sono fondamentali, sono altrettanto certo che se dovessi scrivere in futuro un programma con una gestione di un'interfaccia utente a finestre, lo farei di nuovo in Java.

Link to comment
Share on other sites

So che è parzialmente OT, dato che specifichi chiaramente la tua predilezione per il C/C++, so che farà storcere il naso a molti, però... ho scritto e mantengo in Java un semplice editor grafico dedicato al disegno di schemi elettrici e circuiti stampati. Il programma non è immenso, ma neppure banale (18k linee). Sono totalmente soddisfatto della scelta che ho fatto, anche perché alcune estensioni (come Quaqua) permettono di eguagliare praticamente il look nativo di un'applicazione sotto MacOSX. Conosco abbastanza bene il C++ e sono anche rimasto piacevolmente impressionato dalla facilità con cui certi bug normalmente insidiosi vengono segnalati in Java.

Anche se uso esclusivamente il C/C++ per programmi di calcolo numerico dove le prestazioni e la gestione della memoria sono fondamentali, sono altrettanto certo che se dovessi scrivere in futuro un programma con una gestione di un'interfaccia utente a finestre, lo farei di nuovo in Java.

confermo

con java " Write once, run anywhere"

http://en.wikipedia.org/wiki/Write_once,_run_anywhere

ovviamente con compromesso di prestazioni e usabilità ;)

Quaqua nn conoscevo, interssante ... grazie ;)

sono anche rimasto piacevolmente impressionato dalla facilità con cui certi bug normalmente insidiosi vengono segnalati in Java.

potresti spiegarti meglio, nn ho compreso bene quello che hai scritto qui

sembra interessante

in sintesi su java è + facile individuare e correggere bug che su c++, o intendevi dire altro?

Link to comment
Share on other sites

ovviamente con compromesso di prestazioni e usabilità ;)

In realtà, soprattutto per alcune piattaforme come MacOSX è necessario personalizzare abbastanza l'applicazione per raggiungere un aspetto quasi nativo, perché la prima reazione degli utilizzatori è quasi sicuramente quella di storcere il naso senza andare molto oltre.

Per questo, trovo interessanti alcuni accorgimenti come l'uso di Quaqua, che consentono di ottenere prestazioni accettabili con uno sforzo tutto sommato limitato, senza intaccare la portabilità del programma. Quest'ultima è per me più che primordiale. Quello che non mi fa impazzire di Quaqua è che il mio file bundle da 400 KiB contenente l'applicazione diventa circa 2 MiB. Ma ormai è più una questione di filosofia che un reale problema pratico.

Sulle prestazioni, per adesso l'unico scotto da pagare che ho trovato nel programma su cui lavoro è la necessità di far partire la macchina virtuale all'avvio del programma, che quindi ci impiega qualche secondo per partire.

Sull'uso da parte dell'utente, probabilmente non userei Java per fare elaborazioni numeriche (per quello uso spesso il C++), ma i risultati che ho ottenuto sono più che soddisfacenti per il mio piccolo editor. Rispetto alle prime versioni di Java che ho provato negli anni 90 i passi avanti sono stati considerevoli anche in questo senso.

Ho provato ed usato su calcolatori molto vecchi (uno dei primissimi G4 ed un G3) il programma che sviluppo e mi è parso avere prestazioni più che accettabili se comparate all'hardware.

in sintesi su java è + facile individuare e correggere bug che su c++, o intendevi dire altro?

Sulla base della mia esperienza, mi è sembrato più semplice fare il debug di un software in Java rispetto al C++. Devo tuttavia precisare che la mia esperienza si basa su ambiti estremamente diversi, come quello più legato all'interfaccia utente per Java e quello del calcolo numerico per il C++ (dove tra l'altro faccio largo uso di librerie scritte in Fortran). Le esigenze erano molto diverse e sono sicuro che qualcuno potrebbe avere avuto esperienze opposte in altri campi.

Alcuni bug di Java o meglio delle sue implementazioni si sono rivelati solo su alcune piattaforme o casi particolari. Write once, debug everywhere... è l'aforisma scherzoso, ma che contiene probabilmente un po' di verità. In realtà, la maggior parte dei bug di questo tipo si sono rivelati delle tecniche non troppo ortodosse e/o non documentate che avevo implementate dopo aver osservato che "sotto MacOSX funziona".

Non ho nessuna esperienza di programmazione Objective C e Cocoa, sembrano delle tecnologie interessanti e molto potenti, ma essendo confrontato ad una realtà multipiattaforma sarebbe troppo rischioso per il mio poco tempo libero legare indissolubilmente a MacOSX i programmi che scrivo.

Ho un collega che ha usato QT e si è trovato bene. Io non lo conosco, ma mi pare pure interessante.

Link to comment
Share on other sites

Ciao,

grazie per le tante risposte!

Ammetto che la soluzione del Java mi affascina, non lo conosco abbastanza ma probabilmente varrebbe la pena mettersi a studiarlo.

La soluzione dei wxWidgets mi piace, ho provato a installare il tutto, ma non sono ancora riuscito a compilare un Hello World, quindi mi manca qualcosa.. ci lavorerò sopra.

Il programma che dovrei arrivare a sviluppare riguarda l'acquisizione dati da una scheda GPIB della National Instruments da una macchina che monta Linux. Per il momento rimando il problema dell'utilizzo delle librerie specifiche (vedi http://linux-gpib.sourceforge.net/) e cerco di sviluppare poco più di hello world con un'architettura che mi consenta poi di aggiungere queste funzionalità. Da qui il C.

Grazie ancora.

Link to comment
Share on other sites

Il problema è interessante ma c'è la complicazione di dover accedere all'hardware. In questo caso, un minimo di dipendenza dalla piattaforma c'è sicuramente, il che comunque sia condiziona le tue scelte.

Avevo usato anni fa la tecnologia JNI per fare chiamate a codice in C. Magari potrebbe essere utile per la tua applicazione.

Terrei a dire che sviluppare un'interfaccia utente decente è un lavoro non troppo difficile, ma che prende *molto* tempo per fare qualcosa di un minimo accettabile. Se l'interazione che è richiesta è limitata, puoi magari scrivere dapprima un programmino a linea di comando che esegua le funzioni essenziali, per poi affrontare in un secondo tempo il problema dell'interfaccia.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share