Newsgroup: it.comp.java
Titolo: Output grafico: perche' Java e' cosi' dannatissimamente complicato?

Ciao: il problema e' abbastanza semplice.
Sto facendo un programma che simula la vita (ci sono
dei thread in esecuzione che interagiscono fra di
loro uccidendosi o procreando ecc. ecc.) e vorrei
rappresentare su di un JFrame dei punti rappresentanti
le loro posizioni ed eventualmente spostamenti.
Ho un paio di problemi:
- Vorrei che ci siano delle scrollbar se la dimensione
 dell'ambiente e' piu' grande di quella visualizzata
 dalla finestra. Beh, con VB avrei usato una PictureBox
 (che non riesco a trovare in Java, ne' sotto Images
  ne' sotto Pictures ecc. ecc. Devo usare un JPanel?).
 Qui non posso aggiungere la JScrollpane alla finestra,
 come posso fare?
- Vorrei poter tracciare le linee degli spostamenti
  AL DI FUORI del metodo paint, perche' NON voglio
  ridisegnare tutto ogni ciclo. Solo che se chiamo
  il drawLine (a proposito qualcuno mi spiega perche'
  non esiste un drawPoint!?) mi spunta il NullPointerException.
  Ma allora come faccio a rappresentare un output grafico
  alla pressione di un tasto???
Grazie 1000.
--
 |\-/|                    Con Affetto e Rispetto,
 \\ //                        Andrea De Togni
  | |                          ICQ#28636782
   -
FantaCalcio? FC Manager: 
http://www.fantacalcio.it/fantamanager

  alla pressione di un tasto???
Hmm, mi sa che sei un po' troppo abituato al VB :-)
Ciao,
 P.
+++ Boing Boom Tschak

 le loro posizioni ed eventualmente spostamenti.
Ho fatto qualcosa di analogo per un gioco (deve girare sui browser e
quindi mi sono limitato al JDK 1.0.2) ed ho avuto molti problemi con i
thread. In poche parole ho dovuto inserire dei Thread.yield() nel
codice eseguito dai thread, altrimenti i browser (o anche
l'appletviewer) si piantavano irrimediabilmente.
L'applet e' qui 
http://www.uno.it/utenti/tetractys/jj
devi cliccare su "Match Applet" nel menu'.
Com'e' stata la tua esperienza con i thread?
--
Ciao. Leonardo 
bos...@uno.it
 
www.uno.it/utenti/tetractys

 Hmm, mi sa che sei un po' troppo abituato al VB :-)
 A parte il vb mi sembra una cosa decisamente logica:
io eseguo un'azione e voglio che il mio output cambi
in qualcosa ma non voglio salvare tutto lo stato
e ridisegnarlo da capo!
Ho girato parecchio la guida del JDK, il tutorial
di Java e la guida di JBuilder e diamine nessuno che
mi dicesse in maniera semplice come fare alcune
cose basilari *della programmazione windows*:
- Creare una finestra e metterci un pulsante dentro
- Aprire una "zona" di output grafico (non la
  chiamo picturebox ma in sostanza e' quella) delle
  dimensioni volute.
- Disegnare una linea.
- Java ha il suo sistema di coordinate che converte
  automaticamente: perche' diavolo non si riesce a
  capire quale conversione viene fatta dallo
  User Space al Device Space??? Vengo mandato ad
  un oggetto affineTrasform che e' assolutamente
  oscuro.
E il mio prof universitario diceva che Java era facile...
CiaO! E grazie per l'aiuto.

E il mio prof universitario diceva che Java era facile...
E' facile (se si considera facile la programmazione OO).
Sono le librerie che ad essere diventate tante e grosse.
Se devi lavorare seriamente con la grafica, ti consiglio vivamente
Java Swing e Java 2D della O'Riley.


E' facile (se si considera facile la programmazione OO).
Vero: e' facile, per quanto puo' essere facile. E' come se vuoi guidare una 
Ferrari: anche con la piu' facile, devi imparare.. ;-)
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

Ferrari: anche con la piu' facile, devi imparare.. ;-)
Forse non e' il paragone piu' felice per invogliare a programmare in
Java.. :-)


Java.. :-)
Gia', ma e' proprio questo il punto. E' meglio non dare illusioni iniziali, no? 
:)
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

 Java Swing e Java 2D della O'Riley.
Non voglio comprarmi un libro solo per un esame. :-)
Ciao e grazie

 Ferrari: anche con la piu' facile, devi imparare.. ;-)
:-) Ma nessuno va in giro a dire che la Ferrari sia facile :-)
Ciao

:-) Ma nessuno va in giro a dire che la Ferrari sia facile :-)
Come no? C'e' pure la Ferrari per famiglie ora.. :)
A parte gli scherzi, intendevo dire che ogni sistema ha una sua intrinseca 
complessita', a prescindere dal linguaggio di descrizione che usi; e anche il 
livello *piu'* semplice puo' essere abbastanza complesso. Sistemi object 
oriented non banali non sono facili da scrivere, che tu usi Java, C++ o 
PincoPallo.
Coordinare 300 thread su un contesto grafico condiviso non e' banale - ed e' 
li' che sta il tuo problema, non in Java. 


 li' che sta il tuo problema, non in Java.
In realta' coordinare 300 thread e' abbastanza banale (una volta
fatto per 3, per 300 o 3000 o 3000000 e' identico). In realta'
dovrebbe essere banale anche tracciare un dannatissimo punto
su di un contesto grafico, ma i progettisti di Java hanno pensato
di limitare l'oggetto Graphics alla paint(), cosa che trovo
assurda e limitativa. Ci saranno dei motivi, certo, ma quali
se negli altri sistemi invece si puo' fare? Bah...


se negli altri sistemi invece si puo' fare? Bah...
Il motivo e' lo stesso, per dire, per cui in OO esiste l'information hiding. 
Perche' nascondere *volontariamente l'accesso a certe variabili, che contengono 
informazioni potenzialmente utili?
C'e' - semplicemente - una scelta di design: per cui si valutano 
accuratamente vantaggi e svantaggi di un certo costrutto (a livello di 
paradigma, o meta-metamodello) o di un'API (a livello di linguaggio o librerie, 
o meta-modello) o di un design applicativo (a livello del sistema in 
costruzione, o modello), e si decide il tradeoff migliore per un certo 
obiettivo.
In Basic, COBOL, o altri linguaggi, non c'e' nemmeno un typecheck stretto sulle 
variabili. In Java, C++ e compagnia cantante non puoi assegnare una stringa con 
un intero. Ti sei mai domandato perche', se negli altri sistemi invece si puo' 
fare? ;-)


 fare? ;-)
Si, su queste cose siamo d'accordo e le conosco anche
io. Ma mi chiedevo appunto
quale sia il vantaggio di permettere la grafica solo
nella paint. Tu hai qualche idea?
Andrea De Togni

nella paint. Tu hai qualche idea?
I motivi sono parecchi, e del tutto simili a quelli su cui sei 
d'accordo. L'ottimizzazione delle chiamate e' centralizzabile a livello di 
toolkit grafico. Hai una interfaccia omogenea e coerente verso il 
programmatore. Si abbassano le probabilita' di side effect indesiderati. C'e' 
un unico punto da dove il flusso di controllo del "disegno" ha origine, 
migliorando quindi la manutenibilita'. Eccetera.
Inoltre, se proprio serve, c'e' Component.getGraphics(). ;-)


 Inoltre, se proprio serve, c'e' Component.getGraphics(). ;-)
AAAAAAAAAAGGGGGGH! E adesso mi tiri fuori 'sta funzione? :-)
ora mi documento un po'...
CiaO!

ora mi documento un po'...
LOL anche leggere la documentazione - per costruire sistemi reali - e' utile, 
tanto quanto la teoria di Hoare. ;-)
