Newsgroup: it.comp.java
Titolo: Eventi: "le origini".

Quando "clicco" con il mouse sullo schermo il server grafico (che sa 
dov'e' il mouse e ne cattura gli eventi) trasmette all'applicazione 
attiva nella finestra (lui sa qual'e' perche' tiene traccia della 
posizione e della dimensione delle finestre e le associa ad una 
applicazione) un messaggio indicante in quale posizione relativa alla 
cornice della finestra l'utente ha "cliccato".
Nel caso in cui l'applicazione sia una JVM essa ha un thread 
indipendente da quello di esecuzione del programma che legge nel buffer 
degli eventi in arrivo (dal server grafico) e chiama tutti i listener 
interessati.
Un JFrame, per esempio, avra' un suo listener di default registrato 
nella JVM che cattura tutti gli eventi e li trasmette agli oggetti 
contenuti nell'area interessata con coordinate raltive; tali oggetti a 
loro volta, conterranno oggetti che riceveranno gli eventi con lo stesso 
criterio: la finestra conterra' probabilmente un Panel il quale e' a sua 
volta un oggetto grafico che ha un'area ed una posizione per cui 
trasmette a tale oggetto la posizione del click relativa alla sua area; 
il Panel sua volta sa quali oggetti sono contenuti al suo interno e le 
relative aree e posizioni per cui trasmettera' solo all'oggetto 
interessato l'evento (in cui sono contenute le coordinate relativa alla 
sua area), eccetera, eccerata.
Il problema e' come la JVM sa quali oggetti grafici "root" (come i 
JFrame) siano in ascolto degli eventi: probabilmente ha una lista dei 
listener ma come crea questa lista?
Io presumo che all'istanziazione di tali oggetti vengano eseguite 
istruzioni che indichano alla JVM di aggiungere un listener alla sua 
tabella di oggetti listener ma non ho nessuna certezza che sia cosi' ed 
in caso affermativo quali istruzioni sono? Dove si trovano?
Se qualcuno ne sa qualcosa e se la sente di rispondere ne sarei grato.

Non son sicuro di capire bene; alla base c'e' sempre i s/o che emette
eventi per i widget nativi; poi dipende dal toolkit grafico e da come
e' scritto; infine dal tipo di widget applicativo.


Non sono i widget ad essere registrati nel sistema operativo ma la JVM 
che quindi riceve tutti gli eventi e li distribuisce ai widghet che lei 
stessa ha creato.

Questo era vero una volta. Oggi, la GUI di un s/o moderno di solito
gira come processo di sistema - e finestre e widget sono, a tutti gli
effetti, oggetti di sistema. Poi, il toolkit specifico puo' decidere
che uso farne: AWT e SWT, per esempio, sono dei layer piu' o meno
leggeri sul s/o, Swing invece fa quasi tutto con lightweight component.


Non puoi generalizzare: e' vero che in Windows le finestre sono oggetti 
di sistema in quanto il kernel del S.O. ha una sezione dedicata a 
gestire la grafica (ovvero lo schermo) che, utilizzando parti di codice 
quali i driver video, scrive sull'HW grafico. Mi spiego meglio: i 
cosiddetti "programmi" in Windows vengono spesso (se non fatti con 
cognizione di causa: quasi sempre) eseguiti dallo stesso processo che 
disegna le finestre ed il loro contenuto. Essi girano quindi in un 
processo dedicato ma hanno anche accesso diretto al layer grafico 
essendo essi stessi gli esecutori delle librerie grafiche (per questo i 
giochini sono piu' pronti e veloci).
In Linux il server video esiste come programma esterno gestito da un 
normale processo schedulato dal kernel come tutti gli altri. In questo 
caso il dialogo avviene attraverso socket e, a differenza del 
precedente, i programmi non hanno accesso diretto al layer grafico.
In definitiva la struttura generale del processo di comunicazione tra un 
programma e lo schermo e' molto simile in quanto il programma sfrutta le 
funzioni di un layer predisposto alla gestione grafica ma in Linux e' 
presente un processo indipendente che fa da intermediario.
La JVM di per se istanzia subito 2 thread, all'avvio di un programma, di 
cui uno dei quali dialoga con il server grafico, qualunque esso sia, 
mentre l'altro inizializza il tutto dopo di che, se non lo si utilizza 
per fare altro, conclude.
AWT SWT o Swing, che tu lo voglia o no, utilizzano tutti il primo thread 
e i messaggi verso lo stesso layer grafico (di sistema per Windows, 
server per Linux) per costruire le immagini all'interno dei Widghet. 
Quello che cambia e' la gestione iterna dei layout, il numero e la 
pesantezza dei messaggi verso il layer grafico, che esse inviano per 
costruire la GUI.
Ti sei mai chiesto perche', utilizzando Windows, un programma 
strutturato in modo mediocre che fa dell'IO pesante, o si congestiona, o 
fa operazioni molto lunghe, spesso mette in crisi tutta l'interfaccia 
grafica mentre in Linux questo non succede?
E' molto semplice, se leggi attentamente quanto ho scritto sopra lo puoi 
intuire.....
E' vero che XP ha una buona preemption e strategie oscure per prevenire 
quanto meglio tale inconveniente ma la confusione aumenta e questo e' 
origine di errori.....
Windows is dying....
Ciao.

Ecco, un'introduzione eccentrica a sistemi GUI mi serviva proprio. A
parte gli scherzi: prima di spiegare ad altri, conviene sapere. ;-) Nei
tuoi primi (e ultimi) paragrafi ci sono un numero di inesattezze o
imprecisioni per le quali - non essendo questo il posto giusto - non
entro in dettagli. Se vuoi proseguiamo via email.
Per quanto riguarda inesattezze ed imprecisioni su argomenti in toipic:
1) studiati l'architettura di AWT - in particolare i peers per capire
la relazione tra widget nativi e no. 2) il dispatcher thread di AWT (e
Swing, che con AWT condivide il component model) viene fatto partire
solo per programmi GUI AWT o Swing e serve per fare il dispatching di
eventi AWT o Swing (in particolare, parte quando viene creato un
java.awt.Toolkit). Domani posso scrivere un toolkit grafico che di quel
thread se ne strabatte; un esempio di tale toolkit scritto ieri e' SWT.
3) Studiati un po' di codice di SWT (e' open source) per vedere com'e'
fatto - vale piu' di mille mie spiegazioni (evidentemente ;)


Ammetto che il mio itervento era assieme in po provocatorio ed un po 
movimento di pensieri per riordinare le idee.
Rileggendo il messaggio radice si nota, dalla domanda che faccio, che 
per quanto riguarda le interfaccie grafiche in Java la mia conoscenza e' 
superficiale ed infatti e ti ringrazio per la risposta anche se il punto 
interrogativo che avevo all'inizio non e' ancora svanito.
Per quanto riguarda le imprecisioni e' chiaro che sono inevitabili qui 
(esistono i libri apposta) ma potresti dirmi in quali punti, a parte il 
discorso Java, sono presenti inesattezze?
Cerchero' di non inviare piu' alcuna risposta per non andare troppo off 
topic.
Ciao.