Macromedia rilascia Flash Player 7 per Linux

E anche l'API posix non e` che cambi poi cosi` velocemente

Ma stavolta si comincerebbe bene, no?

Non sono l'unico a pensarla così: io vedo più vantaggi che svantaggi...

Quindi le Xlib gestiscono i seguenti livelli:

1) interfaccia con l'hardware video (tramite driver)
2) gestione delle risorse (bitmap, font, canvas, pennelli, ecc.)
3) gestione layer (per la sovrapposizione delle finestre)
4) gestione primitive/oggetti grafici (finestre, pulsanti, menù, messaggi e interazioni fra di essi)
5) interfaccia con la clipboard

?

Se è così, siamo a cavallo: le GUI dovrebbero implementare solamente il livello successivo (il render grafico, le impostazioni di default dei vari oggetti), ma ognuno solamente col look & feel che più gli aggrada.

Sì certo, chiamiamolo "windows XP manager"

Forse perché è un mammut...
Il kernel di Amiga, Exec, e l'AmigaDOS invece sono cambiati molto col passare delle release, ma hanno offerto delle funzionalità sempre nuove/migliori (vabbé che già in partenza le API erano molto avanzate... )

Sì. Per il 3d c'è bisogno anche di un piccolo kernel driver.

Alcune sì alcune non so. I font di sicuro.
Non ho mai tenuto ad approfondire troppo le xlib cmq.

Mi sembra di sì, dovrebbe avere il concetto di "asse z"

Solo finestre e messaggi, non so/non credo per gli altri oggetti. I menu sicuramente no, sono prerogativa del wm, ma il protocollo è standard (ovvero: il modo di disegnare i menu è lo stesso, per questo puoi eseguire una appl gnome sotto xfce e viceversa).

Sì

No, qualcosa di simile ad AmigaOS...

Allora non è messo molto male: manca poco per realizzare una stratificazione che permetta di astrarre completamente le funzionalità base delle GUI...
Non capisco allora tutte queste differenze/problemi che leggo fra chi usa KDE, Gnome o altro: se i programmatori usano le Xlib, le applicazioni dovrebbero rispondere in modo "omogeno". Boh.

P.S. Vado a nanna: domani mi aspetta l'esame finale di Fisica2...

Le xlib sono delle primitive...molto primitive. Usarle direttamente è un panico. Inoltre, il protocollo X standardizza delle funzionalità specificamente demandate al wm. Non capisco cosa per te ci sia di sbagliato nel demandare la parte del look'n'feel e una maggiore programmabilità ai wm. Il problema non è il numero di wm e toolkit a disposizione: è un bene, ce ne sono di tutti i gusti e per tutte le potenze di calcolo.

Il problema vero non è l'abbondanza di scelta per i wm, ma la scarsissima scelta per il server X. Non hai seguito le ultime vicende su xfree, vero? Lì è uscito fuori come, per linux, una scarsità di scelta equivale ad una debolezza.

AmigaOS & Co non sono linux. Linux è unico OS che trae vita dalla pluralità di voci. I recenti problemi con xfree lo hanno dimostrato.

Premetto che non ho una grandissima familiarità con linux e in particolare con le peculiarità dei wm, quindi il mio intervento vuol'essere da un lato propositivo, dall'altro una richiesta di chiarimenti.

L'omogeneità, IMHO, dovrebbe stare nell'interfaccia con le API del WM, prevedendo dei sistemi di wrapping per le funzionalità aggiuntive e/o diverse dallo standard, che sia esso xlib o una versione meno "primitiva".

Mi spiego: credo che sarebbe opportuno standardizzare (o ristandardizzare, laddove l'implementazione nelle xlib sia troppo complicata da usare) l'implementazione di base della maggior parte delle funzionalità, delegando al WM la sola cura della veste grafica, o al più parte dell'implementazione, purchè siano fissati i nomi delle librerie, delle funzioni, e i tipi dei parametri e dei valori di ritorno. Fatto questo, si può sempre garantire agli sviluppatori di WM la possibilità di aggiungere funzionalità allo standard e/o di modificare o anche sovvertire lo standard, purchè si mantenga un'implementazione parallela dello standard, con le sue intarfacce fisse, e si circoscrivano le modifiche e le aggiunte in librerie a parte, avendo cura di produrre delle librerie di wrapping con gli stessi nomi di quelle non standard che implementino le stesse funzioni (con gli stessi nomi e parametri) appoggiandosi alle API standard (cioè risolvendosi in una serie di chiamate opportune alle funzioni standard), in modo che il programmatore di applicazioni possa decidersi se appoggiarsi, per la sua interfaccia, allo standard, o se sfruttare la programmabilità, comunque mantenuta, di uno specifico WM, sapendo che la sua applicazione avrà comunque un comportamento omogeneo con tutti i WM, poichè gli vengono comunque fornite delle interfacce di wrapping che la sua applicazione (non conforme allo standard) installerà sulle macchine che presentano un diverso WM.

In questo modo si dovrebbe ottenere una omogeneità di comportamento delle applicazioni a prescindere dal WM installato, senza limitare né la pluralità dei WM, né la loro programmabilità e libertà di innovazione rispetto ad uno specifico standard, rendendo semplicemente più "dolce" la transizione da uno standard a un altro. Insomma, penso a qualcosa di simile a quello che si fa con grosse applicazioni di front-end per la gestione di database: si prevede una classe (libreria o quant'altro) di wrapping in modo che l'applicazione possa interrogare il database secondo le proprie necessità e/o peculiarità "infischiandosene" di come vada realmente interrogato il database, così se cambio il database che c'è sotto dovrò solo modificare la mia libreria di interfaccia, lasciando inalterato il resto del front-end.

Ciao a tutti