- alla mia vista mancano 5 gradi e mezzo
- potrebbe trattarsi di un problema di nomenclatura o idioletto
- alla visita di leva ho risposto SÌ alla domanda "Vedi cose che altri non vedono" per una pura e semplice questione di logica e fisica (il mio punto di vista è unico e irripetibile nel tempo e nello spazio, per cui "ciò che io vedo" sarà sempre e comunque diverso da "ciò che vedono gli altri")
La schermata qui accanto non è presa da Ubuntu, ma da GNOME Desktop 2.25.x prelevato da svn, compilato e installato sotto /opt/gnome2 senza patch alcuna, infine mandato in esecuzione.Durante l'esecuzione ho provveduto ai seguenti cambiamenti rispetto alla configurazione predefinita:
- attivare il "composite manager" di Metacity
- usare come tema per i controlli MurrinaChrome
- cambiare tema per i bordi delle finestre
- cambiare sfondo della scrivania con uno più cangiante e colorato
Stesso discorso, per il terminale: nelle stesse condizioni di prima, e non relativamente al widget VTE, la barra dei menù e le schede lasciano maliziosamente intravedere lo spettacolo sottostante.... mmmmmmmm....¹
Ribadisco: non accade sempre e comunque, appare solo sotto determinate condizioni (cioè attivazione del composite manager E uso di un particolare tema basato su Murrine).
Però, questa cosa, io la chiamo avere una (semi)trasparenza nel monitor di sistema, magari potenziale, ma c'è.
Stabilito che io la chiamo così, anche se magari non è esatto, ripongo la domanda: è "corretto" che il codice che rende attive le due (semi)trasparenze nelle particolari condizioni i cui sopra sia presente anche se convergiamo universalmente (cioè io, te, ebassi, e tanti tanti altri) sul consenso che l'alpha compositing dovrebbe essere a livello di libreria e meglio ancora se con il "blur"?
Ribaltando la domanda: non sarebbe meglio rimuovere quel codice, per ora e in attesa di sviluppi futuri, onde evitare che nelle particolari condizioni di cui sopra ci si ritrovi con 2 applicazioni semitrasparenti e le altre nisba?
Già che siamo in tema temi e visto che oggi la rete non mi conduce fino a bugzilla, non si potrebbe fare qualcosa per le GtkEntry con "progress" (GTK+ 2.15/16) in Clearlooks? Al momento è usata solo in Epiphany, ma così appare verameeeeente brutta :([1] nota: le tette riuscite a vederle non perché il vestito è trasparenete, ma perché nella foto è presente un alpha channel; infatti, come è indicato in letteratura: in graphics, a portion of each pixel's data that is reserved for transparency information. 32-bit graphics systems contain four channels -- three 8-bit channels for red, green, and blue (RGB) and one 8-bit alpha channel. The alpha channel is really a mask -- it specifies how the pixel's colors should be merged with another pixel when the two are overlaid, one on top of the other
15 commenti:
Sei come uno che installa compiz e si lamenta di avere le ombre :)
ahahahah
Io con Clearlooks o con la versione stable di Murrine (0.53.1) non vedo nessuna trasparenza :)
"Ribaltando la domanda: non sarebbe meglio rimuovere quel codice, per ora e in attesa di sviluppi futuri, onde evitare che nelle particolari condizioni di cui sopra ci si ritrovi con 2 applicazioni semitrasparenti e le altre nisba?"
Ovvio che se ti metti ad installare software in sviluppo, dal trunk, con temi non ufficiali (non ce ne sono di ufficiali per il momento, c'è un branch su launchpad che contiene solamente temi con RGBA disattivata), può cascarci qualche problema.
Ma non si era detto che non ci si doveva lamentare quando si usa software in sviluppo?
Non vuoi le trasparenze? Usa una versione stabile di murrine, oppure cambia tema, o cancelli rgba = TRUE nel gtkrc del tema ;)
Ma cimi ci sei o ci fai?
Veramente mi sto chiedendo la stessa cosa di voi :)
Io non ci sono nè ci faccio, visto che da che mondo e mondo il monitor di sistema non è trasparente con Clearlooks e tutti gli altri temi forniti con GNOME o installati nelle distribuzioni. Che poi luca si pigli software in sviluppo che non hanno nulla a che fare con gnome dall'svn, scarica temi non ufficiali, e vuole dimostrare che questi permettono di ottenere le trasparenze... Ma che cavolo c'entra! :)
Ripeto è come installare compiz e lamentarsi che hai il cubo rotante.
ma cimi ma ci sei o ci fai?
http://www.cimitan.com/murrine/node/86
cito testuali parole tue:
On February 12th, 2008 Cimi says:
This patch has been approved in the bugzilla, so we will see a transparent system monitor in 2.22!
Great!
qua non c'entrano niente le versioni di sviluppo, e l'esempio di compiz non c'entra una mazza.
Qua si discute del perchè il monitor si e il launcher no. La questione è, o tutti si o tutti no.
Personalmente penso che sto alpha compositing sia una gran cosa, ma che me ne frega di averlo su tutte le applicazioni? Cioè, a che pro un monitor di sistema, o gedit o rhymthbox con l'alpha? Facciamo le robe perchè sono fighe ma senza uno scopo? allora usiamo windows vista e siam tutti contenti, no?
L'alpha può andare bene su alcune applicazioni, come apple per dire ha fatto con quicklooks, ma diobono se non vedo cosa c'è scritto su una finestra, sarà anche figa, ma non serve a niente.
Evidentemente non capite un cazzo:
RGBA colormap != Finestre trasparenti.
Avere la colormap RGBA non significa avere le finestre trasparenti, ma avere un canale in più (il canale Alpha) da utilizzare nell'engine Gtk+.
Gli utilizzi sono svariati, esempi lampanti sono tooltips rotondim menu rotondi sfumati (Oxygen di kde 4 utilizza proprio la colormap RGBA), treeview rotondi come in banshee.
Se non vi piace la trasparenza totale basta non utilizzare i temi, come MurrinaChrome che ha postato luca, che sono trasparenti. Ma non venite a dire che la colormap RGBA è un male solo perchè non sapete cosa sia :)
O ancora peggio, che IO ci farei perchè voglio avere il canale alpha.
"La questione è perchè il monitor sì ed il launcher no"
Ripeto, il monitor non è trasparente. Fatemi vedere uno screenshot con Clearlooks che sia trasparente. Mentre quel launcher lo sarebbe per qualsiasi tema, costringendo molti utenti gnome ad avere una trasparenza NON voluta.
"Evidentemente non capite un cazzo:
RGBA colormap != Finestre trasparenti."
Quindi la tua patch per il system monitor non faceva altro che abilitare RGBA, che unito ad un engine gtk che ne fa uso (Murrine trunk) comporta la traparenza...
Perfetto... allora perchè invece di comportarti come quello che ce l'ha più lungo (e offendere tutti dicendo che non capiscono un cazzo) sul bug di quei ragazzi non gli hai semplicemente detto, "questo non è il modo giusto di fare la cosa perchè abilita le transparenze per tutti indipendentemente dal tema, sarebbe meglio abilitare il canale RGBA sulla finestra del dialogo ("bastano 2 righe di codice per ogni widget" [1]) in modo che solo i temi che ne vogliono fare uso (e quindi esplicitamente scelti dall'utente) lo rendano trasparente", ma no meglio negare che due cose trasparenti anche se rese trasparenti con tecniche diverse alla fine sono comunque entrambe trasparenti... bastava spiegare subito per bene la differenza tecnica tra le due e dirgli quale delle due tecniche è quella giusta e che quindi puo' avere più possibilità di essere accettata in gnome (anche in virtù del tuo precedente...).
[1] http://www.cimitan.com/blog/2007/12/12/gtk-rgba-transparent-widgets-with-the-murrine-engine/
Perchè patchare tutte le applicazioni non è la scelta giusta.
Quella patch è stata fatta in un momento di confusione, quando con alcuni dev di canonical si era deciso di cominciare ad abilitare la colormap nelle applicazioni. Successivamente, visti i problemi che poteva causare, si è deciso di smettere di proporre patch per le applicazioni.
La speranza è abilitarla globalmente attraverso una variabile o un xsetting, senza dover riempire le applicazioni di patch.
In ogni caso, viste le grandi difficoltà di lettura del testo quando si è sprovvisti del blur ed il piccolo numero di schede che lo supporta, io propendo molto per il no.
Michele, anche come Cimi ha implementato la trasparenza nel monitor di sistema non e' il "modo corretto". E' esattamente quello che ha esposto Luca in questo post. Cimi puo' dire quello che vuole, che la trasparenza si vede solo con i temi che usano il canale alpha, che e' codice di sviluppo (?!?), che con Clearlooks non si vede (embeh'?)... Queste cose non vanno fatte a livello di applicazione, quelle riche di codice non devono stare li, anche se il 90% degli utenti non ne vedra' gli effetti. Si fanno nel toolkit. Punto. Su questo penso che siano tutti daccordo... A parte Cimi, forse. E' per quello che la patch al monitor di sistema andrebbe rimossa. Fatta cosi' non ha alcun senso.
Luca se leggessi i miei commenti scopriresti che anche io sono d'accordissimo che sia una patch che al momento non serve, solo che non fa male ad una mosca perchè non abilita nessuna trasparenza e non compromette l'usabilità :)
"Su questo penso che siano tutti daccordo... A parte Cimi, forse."
Ma leggi quello che scrivo o fai frecciatine e basta? l'avevo appena detto...
Se vuoi rimuoverla fà pure, a me non me ne frega niente tanto è una patch che al momento serve a poco, ma non fa neanche nessun danno! può essere rimossa in qualsiasi momento.
Un senso ce l'ha avuto comunque, e pure importante: dando ufficialità alla patch ho fatto vedere ad nvidia che avevano dei bug nei loro driver, che dopo aver testato il system monitor hanno sistemato con i 17x.xx.
Ma non ancora i 9x.xx, quindi un' alternativa sarebbe tenerla fino a che non sistemano le cose...
secondo me era meglio non considerarla come patch quella del lanciatore.
Magari come add-on, da fare gestire da quella cacca di compiz, oppure da metacity..
Comunque anche te luca: come pretendi di non avere trasparenze con murrine??
Ora cominciamo a ragionare. ;-) Sicuramente l'approccio di patchare ogni applicazione non è fattibile... quindi alla luce di questa discussione e del fatto che nessuna dalle due soluzioni è quella giusta non sarebbe il caso di fare una patch per rimuovere il setting RGBA sia da system monitor (e terminal?) in attesa Della soluzione definitiva? giusto per coerenza siccome sono tutte e due soluzioni errate nessuna dovrebbe risiedere in codice applicativo.
Poi sulla questione del blur, del supporto minimo da parte dei driver e del fatto che la cosa sia difficilmente leggibile in determinate situazioni penso siamo tutti d'accordo. :-)
Ma michele le patch non fanno male... Cioè l'RGBA non è il MALE!
Anzichè avere 24 bit ne hai 32.
Poi spetta all'applicazione usarli o meno.
Il terminale non è stato patchato, usa volutamente l'RGBA per avere trasparenze reali della console. Se abiliti la trasparenza dello sfondo vedi attraverso il terminale
Dunque, riassumendo e concludendo la questione: ok, abbiamo tutti ragione, viviamo solo in diversi universi semantici e linguistici
Pace fatta? In fondo dicono che so' bbuono e caro :D
Scusate se mi intrometto del flame, fose terminato, ma non basterebbe una semplice patch al toolkit GTK* in modo da avere la colormap RGBA abilitata di default? Ci sono stati parecchi cambiamenti alle GTK in quel senso, ovvero rendere alcune proprietà dei widget attivi di default al solo scopo di risparmiare linee di codice, visto che magari quella proprietà è la più usata.
Posso concordare che su Ubuntu, visto che il tema di default è basato su Murrine, il monitor di sistema è quasi l'unico ad essere semitrasparente, tra l'altro con quel brutto effetto nei grafici che essendo disegnati con Cairo (non so perché) perdono la semitrasparenza.
Ritengo anche utile abilitare la trasparenza (tramite il theme engine) solo alle finestre modali... vabbè andrebbe un po' riformare i metodi di rendering in base all'HINT della finestra secondo me. A tal proposito vorrei citare questa cosa: http://l3on.netsons.org/blog/2009/02/09/una-piccola-patch-per-gnome-panel/ E la relativa discussione sviluppatasi su PollyCoke.
Bye bye...
Posta un commento