I temi GTK+ potranno essere CSS, com’è già per Qt4
In Estetica, News il 18/07/08 @ 14:16 trackback
Ogni web designer che si rispetti ha imparato già da parecchi anni ad odiare e amare i “fogli di stile a cascata”, altrimenti detti CSS1. Irripetibili le maledizioni sibilate rancorosamente dopo la milionesima volta che si aggiorna il foglio di stile e un fottutissimo elemento della pagina decide di cambiare posto…
Beh a parte la caratterizzazione ironica, i CSS nel web design offrono immensi vantaggi legati soprattutto (ma non solo) alla mantenibilità dello stile che è così reso indipendente dai contenuti, per cui ad esempio per cambiare totalmente aspetto a tutto pollycoke mi basterebbe apportare poche modifiche ad un solo file. Un esempio classico delle possibilità offerte dall’uso di CSS è Zen Garden.
Le Qt supportano già nativamente questa capacità a partire dalla versione 4, su cui si basa KDE 4. Una dimostrazione delle potenzialità del supporto al CSS la fornisce l’installer Qt di OpenSUSE. Guardatelo prima senza foglio di stile:
|
|
E sempre lo stesso installer Qt, ammiratelo adesso con alcuni esempi di fogli di stile associati:
Molto interessante, no? Adesso leggo su Ars Technica, fonte anche delle immagini delle Qt-CSS che avete visto qui sopra, che c’è una proposta di introdurre un nuovo engine GTK+ in grado di accettare anche esso le istruzioni in stile CSS per apportare modifiche all’aspetto dei vari temi che ad esso si appoggeranno. Pare che questa proposta sia venuta fuori nell’ottica delle discussioni riguardanti il futuro di GTK+ e il fantasma di GNOME 3. Ecco un primo prototipo di implementazione:
Non esattamente un esempio bellissimo, ma apprezzate le due finestre di gedit in basso, con il codice, ovviamente quella a destra in particolare che mostra come vengano creati i box dal bordo nero puntato e con la base rossa.
Che ne penso io? Ho sentimenti contrastanti di fronte a questa continua invasione del desktop da parte di tecnologie nate per il Web. D’accordo, nelle applicazioni GTK+ o Qt non avremo certo DIV che prendono vita autonoma ma sia chiaro: neanche l’incredibile flessibilità di Zen Garden! Semmai mi chiedo se questo potrà facilitare in futuro lo sviluppo di comode e potenti interfacce per creare o modificare temi.
— Note all'articolo:
— Pagine forse correlate:
Commenti »
non lo so ma le api di windows hanno questa cosa da un bel po di tempo ormai. cmq, non sarà certo questa “stupidaggine” a risollevare le GTK dal loro stato pietoso.
Uhm… ho paura che tutto questo rischia di appesantire ulteriormente le GTK+. Spero facciano ingenti modifiche alle GTK così da renderle più reattive e implementare questa “tecnologia” in modo nativo.
Trovo che sia un’ottima idea poter gestire un tema tramite css!
L’unica cosa che mi rendeva poco sopportabili i CSS era il supporto pietoso ad alcuni comandi da parte dell’internet explorer dell’epoca…..
Sono uno strumento di una potenza mostruosa…
E’ veramente una OTTIMA idea….
il CSS è ancora il futuro. lunga vita al CSS
non ci capisco niente :| ..su ubuntu girano le interfacce con qt4, allora non ho capito perchè gnome dovrebbe pensare di non avvalersene…me lo dite?
gnome in qt4 eh … si certo e poi c’era la marmotta che confezionava la cioccolata
Felipe non fa altro che ostacolare il progetto GNOME da quando è stato sbeffeggiato dalla comunità. Questo titolo è un altro della serie “GNOME è in ritardo e KDE 4 è bellissimo” con tanto di immagine che fa scena.
Sicuramente non si avrà la flessibilità del layout di CSS Zen Garden, ma vogliamo mettere presentare i temi coi CSS al posto di dover scrivere ogni volta un engine diverso per avere questo o quell’effetto? [e qui sarebbe divertente sentire il signor Cimi] Ai tempi dell’uscita delle QT4 ero stato molto soddisfatto di questa nuova possibile interazione con tecnologie nate per il web; il discorso è lo stesso anche per le GTK.
Di fatto dietro a tutto questo dev’esserci WebKit, altrimenti il discorso non ha senso. Gecko non è all’altezza e basta vedere cos’è Firefox 3 oggi (e cosa sarà Firefox 3.1 domani) per rendersene conto. Konqueror e Safari sono sempre i primi a supportare funzionalità provenienti dalle bozze CSS3 e questo è un bel vantaggio per tutti coloro che vorranno sbizzarrirsi con trasparenze, animazioni e quant’altro oggi ci venga utopisticamente offerto dalle (imminenti?) raccomandazioni. Ben venga il supporto ai CSS, quindi, purché ne sia WebKit il garante.
Ad ogni modo non condivido chi ne parli come una stupidaggine, né mi permetto di considerare quegli aspetti relativi alle prestazioni delle librerie in termini di reattività e pesantezza. Mi auguro solo di poter in futuro permettermi di modificare il mio tema GTK senza dover imparare qualche strano linguaggio pseudo-cirillico come quello dei file gtkrc.
intendevo questo…io uso ubuntu e le librerie qt4 sono nelle dipendenze di molti programmi tipo skype. Ora se posso installarle e molti programmi le usano…se posso io stesso fare su ubuntu dei programmi che funzionano con le qt4, mi ponevo la domanda..perchè gnome deve preoccuparsi di reinventare la ruota?
@7
Beh… un salto enorme si potrebbe fare. Ma vuoi mettere riscrivere tutte le applicazioni di Gnome in QT4?
Questo potrebbe essere poco piacevole per lo sviluppatore addetto alla conversione.
L’uso di quelle librerie non abbasserebbe il livello di Gnome ma al contrario lo alzerebbe, e comunque anche una razionalizzazione migliore e un alleggerimento delle GTK lo vedo come uno sforzo veramente grande.
Il problema, ripeto, secondo me e’ la riscrittura.
Non sono uno che fa programmi con GTK+ o QT4, però conosco HTML, CSS e PHP, quindi so fare siti statici e dinamici, il CSS è una manna, è semplice ed efficace, io lo trovo come un vantaggio, poi anche se ci sono gli svantaggi c’è sicuramente il vantaggio più grande, la comodità di poter modificare tutto con poche righe, che ne trae sempre spunta.
Sarebbe una cosa ottima. E non per nulla pesante o complessa. I problemi che possono sorgere per una pagine web non dipendono mica dai CSS ma di come i browser interpretano gli standard del w3c ( e fatemelo dire, da come certi web designer o che si spacciano per tali scrivono il loro codice xhtml/css).
Dopo tutto c’è da dire che la sintassi usata nei gtkrc per costruire i temi è un tantino contorta e non proprio chiara ed intuitiva.
gp
Usare una notazione XML, fa schifo?
gnome in qt !!! e’ una pazzia ma sarebbe un’idea da non scartare, un unico toolkit per gnome kde e gran parte delle applicazioni
xml per il layout?mangiamolo pure colazione sto xml
@14: non so quanto la notazione XML in questo specifico sia efficace. Qui non bisogna impostare la struttura ma definire uno stile, quindi in questo contesto è più ovvio usare i CSS nati proprio per tale scopo.
Ad esempio la notazione XML è già usata per i temi di Metacity sia per definirne la struttura che lo stile e ti assicuro che non è una cosa semplice.
gp
AHI AHI XAML ti fa schifo, khelidan?
mah… l’idea a mio avviso non è male anzi, le GTK+ avrebbero bisogno di un modo più standard ed accessibile a tutti per modificare anche di poco lo stile… Basta che questo non comporti ancora più latenza…
@14. XML
Xml può usare i css per il rendering, e da sempre. Provare per credere.
OT
Ma fa davvero così schifo Gecko???
La vera figata sarebbe poter scrivere applicazione GTK sfruttando XML …. così da gestire un file per il layout della gui uno per lo stile (magari compilabili) e poi associare ai componenti gli attacchi al controller.
MVC all’estremo !!!!!!!!!!! :D
perchè non pensare un unione GTK+XAML ?? … in rete si legge qualche cosa, anche se parecchio datato
@XML: sì fa cagare, ecco perché esiste libglade (lol)
@eKoeS: webkit per parsare i CSS non è un po’ un overkill?
@443 #1
continua a ripeterlo, alla fine diventera’ vero
@Yattamax #22
Hai presente glade?
Se ne parla da molto ma il cambiamento potrebbe essere non retrocompatibile o creare altri problemi. Per ora non c’è niente di certo a riguardo ma è uno dei goal per future versioni di GTK.
Notate che l’idea non è che ogni applicazione usi i CSS per il suo stile ma che i temi siano basati largamente su fogli di stile invece che su codice scritto in C. La ragione è semplice: i programmatori sono generalmente pessimi grafici e i grafici pessimi programmatori.
@443:
“non lo so ma le api di windows hanno questa cosa da un bel po di tempo ormai. cmq, non sarà certo questa “stupidaggine” a risollevare le GTK dal loro stato pietoso.”
Di che parli? O non conosco o stai parlando di una cosa leggermente diversa.
@Wonderland:
Non consuiderare l’esistenza di GNOME/GTK e KDE/QT come una lotta fra nemici. Sono gli utenti che hanno questa visione, non gli sviluppatori.
@eKoeS:
“Di fatto dietro a tutto questo dev’esserci WebKit, altrimenti il discorso non ha senso.”
No no, sarebbe come uccidere una mosca con un cannnone, sicuramente non vuoi che il tema dipenda da WebKit (e nemmeno da gecko). E lo dico come sviluppatore di WebKit.
@XML:
“Usare una notazione XML, fa schifo?”
L’xml è molto prolisso e non così piacevole da scrivere a mano.
“AHI AHI XAML ti fa schifo, khelidan?”
XAML è un altro discorso ed è paragonabile ai file glade (che sono XML).
@Nethan:
“Ma fa davvero così schifo Gecko???”
No, e di nuovo lo dico da sviluppatore WebKit ;)
@Yattamax:
“La vera figata sarebbe poter scrivere applicazione GTK sfruttando XML …. così da gestire un file per il layout della gui uno per lo stile (magari compilabili) e poi associare ai componenti gli attacchi al controller.”
Se vuoi mantenere coerenza fra le diverse applicazioni non vuoi avere uno stile per ogni applicazione.
“perchè non pensare un unione GTK+XAML ?? … in rete si legge qualche cosa, anche se parecchio datato”
Hm… glade/GtkBuilder?
ma scusate, tirate in ballo xml e non sapete nemmeno cos’è, a giudicare da certi discorsi…
ma i linguaggi di marcatura sono così concettualmente difficili?
i css sono stati creati per disarticolare un linguaggio di marcatura (html) dalla resa grafica, e ora volete che un altro linguaggio di marcatura si occupi della grafica stessa?
lo so, per un ingegnere è difficile questo concetto, ma almeno provateci a sforzarvi…
Ma tutto questo
http://msdn.microsoft.com/en-us/library/bb613545.aspx
non vi piace?
vi sembra scomodo?
Cosa c’è che non va?
Ragazzi io ci sto provando a rendere GNOME 3 un qualcosa di interessante.
Ma mi bocciate c++, mi bocciate xml…
BOH
@XML:
“Ma tutto questo
http://msdn.microsoft.com/en-us/library/bb613545.aspx
non vi piace?
vi sembra scomodo?
Cosa c’è che non va?”
Piacere proprio no, e poi come puoi dire che quella roba sia leggibile!
Comunque si parla di cose diverse, il ruolo di XAML è simile a quello dei file glade/GtkBuilder. Qui si parla principalmente di temi globali, che in Windows sono implementati direttamente in C/C++.
“Ragazzi io ci sto provando a rendere GNOME 3 un qualcosa di interessante.
Ma mi bocciate c++, mi bocciate xml…
BOH”
Mi mandi per favore qualche link alle tue patch per rendere GNOME migliore?
beh io credo che con un DTD appropiato si potrebbero definire tutti gli elementi di un’interfaccia grafica e la loro gerarchia
http://www.w3schools.com/dtd/default.asp
il che va a nozze con un Cascading Style Sheet
quindi direi XML va bene in questo caso e anche CSS …
Basta che non lo usiamo per scambiare dei dati (XML intendo) che ci sono dei metodi migliori ad esempio JSON ( http://www.json.org ) o quello nuovo di google com’e’ che si chiama ?
Cmq mi ha fatto sorrider quella persona che ha detto: “perchè non usano Qt4 ?” fantastico lo spirito giusto :)
Devi saper che oltre alla riscrittura del codice, come qualcuno ha già fatto notare, c’e’ di messo l’orgoglio, i programmatori sono mooooolto orgogliosi, e delle clausole insormontabili (tipo quella della K nei nomi dei software hihihi) che rendono tutto ciò impossibile.
Cmq sberleffi apparte, quelli che ti sei preso adesso, qualche mese fa si parlava per l’appunto di una rotta comune per un futuro in cui gnome e KDE sarebbero stati fusi o per lo meno intercambiabili
@lifeless: la Document Type Definition che c’entra con lo stile?
semmai l’xls (http://it.wikipedia.org/wiki/Extensible_Stylesheet_Language)
@LiFeleSs:
“Cmq sberleffi apparte, quelli che ti sei preso adesso, qualche mese fa si parlava per l’appunto di una rotta comune per un futuro in cui gnome e KDE sarebbero stati fusi o per lo meno intercambiabili”
Non se ne è mai parlato, queste discussioni sono venute fuori solo da frasi mal attribuite e citate senza contesto.
@commenti-moderati:
Gente, ho dovuto eliminare alcuni commenti fuoritema, aggressivi e perfino un po’ deliranti (e relative risposte). Atteniamoci all’argomento trattato (Temi CSS per GTK/Qt) e al tono pacato che contraddistingue le discussioni civili.
E meno enfasi por favor :)
In questo momento mi sto immaginando valanghe di temi css standard funzionanti sia su kde, sia su gnome, sia su xfce, sia su windows 20xx.
e in più ogni applicazione può avvalersi del tema impostato dall’utente, di un tema default, di temi personalizzati per l’applicazione stessa pubblicati da utenti volenterosi oppure di temi creati dall’utente stesso.
ma forse è soltanto un bel sogno.
Vi racconto questo fatto curioso:
ieri ho casualmente incontrato alcuni amici Vistari,
e abbiamo discusso brevemente sulle recenti tematiche opensource.
Essendo io un linaro solitamente queste discussioni sono molto animate,
invece questa volta ho scoperto che i Vistari si augurano
- una ampia diffusione di KDE4 tra le distro linux
- che Gnome 3 sia ancora in C, con i temi stile CSS
Raramente siamo andati così d’accordo!
Purtroppo non ho avuto tempo per chiedere loro il motivo di queste affermazioni,
ma penso che si siano ormai stufati del loro SO,
e vogliano finalmente passare a qualcosa di superiore!
L’ennesima piccola vittoria dell’opensource!
[...] – grazie a un intervento molto interessante – che, quanto prima, sarà possibile utilizzare i CSS per i temi Gtk+: ignoravo, peraltro, che [...]
vogliono passare a qualcosa di superiore? quello che è kde da anni! di sicuro non stanno parlando di gnome. la gui di windows è di per se piu avanzato.
Riposto la mia osservazione che sembra esere finita nel contenitore dell’indefferenziata.
I fogli CSS per la specifica dei temi sono stati usati per la prima volta su firefox , sin da quando si riscrisse il motore di rendering decidendo di adottare xul ( allora firefox era meglio noto come phoenix )
Peccato che nessuno lo ricordi.
@NoWhereMan, Marco Barisione: Vada per il risparmiare la mosca e il colpo di cannone, come ho già detto prima a livello di prestazioni (e aggiungerei dipendenze) non mi permetto di giudicare, non essendo nemmeno lontanamente uno sviluppatore. Al massimo posso permettermi di dire che i CSS3 portano con sé tante ghiotte novità che su Gecko tardano ad essere implementate, mentre di fatto il supporto agli standards in WebKit è superiore da alcuni anni.
Background, Text e Color/) sono solo alcuni dei moduli CSS3 di cui mi piacerebbe poter usufruire per scrivere – utopisticamente parlando – possibili temi GTK. E forse sono anche quelli più utili, visto che si portano appresso sistemi di gestione di sfondi, bordi, testo e colori più complessi (e al tempo stesso completi) dei CSS2.1. Su Safari, Konqueror e per certi versi Opera gran parte di queste proprietà sono già largamente supportate (su Firefox alcune dovrebbero arrivare con la 3.1). Ecco spiegato il motivo per cui io (da utente GNOME) opterei per un rendering engine come WebKit. Per il resto, ripeto, non mi esprimo, anzi spero di non essere stato troppo aggressivo lì sopra. ;)
Ops, commento un po’ pasticciato, ad ogni modo si dovrebbe capire, scusate. :)
@eKoeS:
Ci sono due problemi diversi, il parsing dei CSS e il rendering. Il parsing è ralativamente semplice e probabilmente non vale la pena copiarlo da WebKit – e tantomeno da gecko, chi ha letto almeno una volta il codice per il parsing dei CSS in gecko sa il perché ;)
Il rendering è la parte difficile ma non si può usare un browser per questo a meno di perdere compatibilità, rallentare tutto, rendere impossibili molte cose. In più non verrà supportato completamente CSS perché molte cose non hanno senso per una UI gtk e verranno probabilmente aggiunte altre proprietà specifiche di GTK.