Basare GNOME sulle Qt? La cuadratura del cerqhio!
In News e altre Sciccherie, Riflessioni il 31/07/08 @ 8:30 , trackback
Loading ...
Prima che questo pazzo pazzo luglio finisca, voglio assolutamente trovare il tempo di incastonare nel mio diarietto l’ultima perla di post ispirato a quella che potrei definire l’ennesima insolazione collettiva.
Qualcuno di voi forse avrà già letto qualcosa a riguardo. Il tutto è iniziato da alcune parole di Mark “Star Child” Shuttleworth, travisate ad arte1 per far girare la voce che avrebbe prospettato una riscrittura di GNOME per basarlo sulle Qt di Trolltech, ora di Nokia, che incidentalmente sono le librerie alla base di KDE, il diretto e storico ambiente concorrente.
GNOME basato sulle Qt? Talmente assurdo che…
Non credo ce ne sia gran bisogno, ma ricordo che GNOME è nato esattamente con la scusa di avversare KDE, che all’epoca era basato su una vecchia versione non sufficientemente libera delle Qt… Adesso la situazione è completamente stravolta:
- La questione della licenza delle Qt, supposto motivo della primitiva diffidenza nei confronti di KDE, è stata ampiamente superata da Trolltech, azienda che non esito ad indicare come storicamente una delle più illuminate dell’interno panorama legato al software libero.
- Le Qt sono diventate uno dei pochissimi esempi di progetto opensource d’eccellenza, in grado di competere qualitativamente ad armi pari con controparti a codice chiuso.
- Le GTK+ al contrario hanno vissuto un lunghissimo momento di stasi e difficoltà a recuperare sviluppatori in grado di occuparsene in maniera dedicata, come denunciato dagli stessi sviluppatori più di un anno fa (cfr “Grave carenza di sviluppatori GTK“).
- Da qualche anno Nokia ha parecchio investito nella creazione di una piattaforma, Maemo, basata su GTK+/GNOME, ma con il rilevamento di Trolltech (cfr “Nokia compra Trolltech.“), ha ora messo le mani sulle Qt.
- Adesso, nel giro di poco tempo dall’acquisizione di Trolltech da parte di Nokia, è saltata fuori una versione di Maemo che usa le Qt2.
- Uno dei più influenti sviluppatori GNOME, John Palmeri di Red Hat (se ben ricordo), ha scritto un lungo e interessante articolo in cui disquisisce di eventuali pro e contro dell’adozione di Qt per GNOME3. Così tanto per scrivere…
Beh sono solo suggestioni. Eppure viene voglia di pensare che all’improvviso l’intera faccenda non sembra quasi più il semplice frutto di una insolazione collettiva… vi pare? E poi qui oggi è anche un po’ nuvoloso.
— Note all'articolo:
- cfr “Mark Shuttleworth: Apple is driving innovation” e i risultati di questa ricerca [↩]
- cfr “Antonio Aloisio: Qt 4 Maemo: the new experience“ [↩]
- cfr “Flames Welcome (Is a Qt GNOME Desirable?)“ [↩]
— Pagine forse correlate:
- Nokia compra Trolltech.
- Qt 4.4 demo sul telefoninux
- Nautilus supporta OBEX grazie a Maemo (Nokia)
- “We don’t need your education” (cit.)
- Nautilus e OBEX, aggiornamenti
- debug: GNOME Qt KDE Maemo Nokia GTK Trolltech cuadratura sulle La Basare cerqhio!
Commenti »
Non penso sia la soluzione, passare alle QT, semplicemente non sarebbe più Gnome…
quelli di gnome e di kde dovrebbero unirsi per fare un desktop veramente UBBAH!
quella sarebbe una bella mossa…
bè nell’intervista Shuttleworth diceva più qualcosa del tipo “non sarebbe difficile portare le caratteristiche distintive di gnome su qt”.. però magari un pensierino ce l’ha fatto pure lui ;)
secondo me riscrivere gnome in qt non sarebbe snaturarlo, non diventerebbe mica uguale a kde.. pensate al look ‘n feel di gnome basato su librerie potenti come le qt.. e poi sarebbe un passo in più verso la standardizzazione.
il problema è che alcune applicazioni (vedi amarok e k3b) diventerebbero parte integrante anche di gnome per manifesta superiorità.. e questo non succederà mai lo so, piuttosto ricominciano da capo e reinventano la ruota :)
Io baserei GNOME3.x sulle QT e KDE4.2+x sulle GTK. Sarebbe grandioso…
Sarebbe un’ottima cosa in tutto e per tutto
una delle maggiori pecche che i detrattori di linux gli addossano, è la frammentazione in più progetti separati, e questo parte tutto da qt vs gtk.
Con una libreria comune, l’integrazione sarebbe maggiore, gli sforzi sarebbero minori.
Per il resto, cercate QGtkStyle su google e vedrete che gnome potrebbe benissimo mantenere la sua “identità” grafica usando le qt… e al contempo ci guadagna tutti i programmi scritti per kde, perfettamente integrati.
Inoltre è anche un vantaggio in risorse: io uso kde ma devo tenere le gtk per diversi programmi… idem vorrei proprio incontrare una persona che usa gnome ma non ha le qt installate nel proprio pc…
Ricordo quel post. I possibili vantaggi che enumera sono men che meta’ dei problemi cui darebbe luogo la conversione. Di piu’, i primi sono del tutto aleatori e potrebbero essere apprezzati solo a lavoro compiuto, magari nel corso di anni, e sempre che si realizzi, come dire, una certa concordia tra le visioni e le scalette di tutti. Gli svantaggi della sua lista, d’altra parte, sono assai piu’ concreti e temibili, ed avrebbero ripercussioni immediate, come osserva, non solo sulla tecnologia ma sull’intero ambiente Gnome: utenti, vendors, sviluppatori. E sono osservazioni tutto sommato oculate. Senza valutare tutti gli altri imprevedibili problemi, sono sufficienti per archiviare l’intera questione come esercizio intellettuale futile ed altamente flammogeno, da tenere lontano dalla portata dei bambini :D Poi basta considerare che le Gtk non sono messe tanto male come, leggendo qua e la, si possa intendere, e sono ancora un ottima base per un desktop - le qt non avranno meno pregi, suppongo, ma non le conosco affatto - su cui costruire (=sono costruite) ottime applicazioni. Certamente possono ancora migliorare, potrebbero avere un qualche luccichio in piu’, una documentazione piu’ curata, ecc. Ma allora, la cosiderazione piu’ ovvia (e sfuggente, direi) fra tutte che si possa fare e’ una sola: e’ piu’ sensato colmare le lacune delle Gtk o buttare in vacca un decennio abbondante di lavoro e passione di innumerevoli persone per ricominciare quasi da zero, senza alcuna garanzia e tante rogne? Boh, io scuoto mestamente la testa quando ci penso :D
@Dass: io solevo usare giusto giusto Kile come app qt, ma cosi’ per pigrizia nel cercare alternative. Dopo aver scoperto auxtex per emacs, ho falciato le qt definitivamente (e con gioia, che mi trovo anche meglio che con kile). Ho una partizione dove sto spippolando con KDE4.1 in questi giorni, ma nel quotidiano l’impronta delle qt non calca e non calchera’ mai piu’ il mio disco :)
riguardo alla mancanza di dev per le gtk…ma chi sano di mente oggi si metterebbe ad imparare ed usare gobjects?? Quando dall’altra parte ci sono le qt,il non plus ultra delle librerie grafiche,aperte e non?
Il problema principale è la licenza: Qt è GPL, GTK+ è LGPL. Gnome è stato scelto come desktop predefinito da Red Hat e Canonical proprio per questo! ;-)
Per lo sviluppo di software closed-source, anche se freeware non a scopo di lucro,
le qt sono a pagamento.
Le gtk hanno una licenza molto piu’ permissiva,
e non vorrei che si rinunciasse a questo.
Io che sono amante del c++ mi sono messo ad imparare le gtkmm, avevo usacchiato un po’ le QT e per certi versi sono meglio nel senso che per certe cose ci sono meno passaggi da fare, meno righe di codice ecc.. Ma le gtk restano le gtk!
Poi va, come per ogni cosa, a gusti. Saranno (saremo) matti a programmare in c/c++ con gtk/gtkmm ma a me quando riesce bene ho una soddisfazione ragazzi che le QT non me la darebbero neanche lontanamente.
Bho certe cose non le capisco. Le auto celebrazioni dei programmatori sono assurde.
Penso che per le interfacce grafiche servano necessariamente librerie ad oggetti (in c++ preferibilmente).
Chiunque abbia un minimo di esperienza di programmazione a pattern sa di cosa parlo.
Non a caso le QT adesso sono totalmente cross-platform pur mantenendo le interfacce standard per tutti i sistemi.
Una cosa del genere fatta in C sarebbe abbastanza delirante da manutenere.
Detto questo penso anche che la possibilita’ di scelta sia molto importante sicche’ che decidano di basare il codice del futuro gnome sulle QT probabilmente non sarebbe una scelta buona per l’utente finale.
Sulle licenze oramai non c’e’ piu’ nulla da dire. GPLv2 e v3 accompagnano le QT.
Le GTK probabilmente oramai sono da riscrivere.
Il futuro di GNOME e GTK sono iddissolubilmente legati.
La cosa che più conta in un desktop è l’usabilità. Poi viene la configurabilità.
GTK e Qt danno entrambi il minimo necessario per costruire un buon desktop, usabile e configurabile. GNOME ha raggiunto lo scopo, KDE4 ci sta vicina (dategli un annetto e vedrete).
Dimenticatevi Qt per GNOME, è solo una discussione da ombrellone ;)
@fray
come non quotare,ma si vede che la gente ci tiene a perdere tempo con il C,contenti loro…i risultati si vedono cmq,le gtk fannò pietà e nessuno vuole svilupparle….
Sulle licenze,prima perchè le qt erano poco aperte,ora troppo, ci vuole la lgpl,insomma mettetevi d’accordo
@10:
Embè? Questo lo vedo come punto a favore delle Qt. Il software proprietario è sbagliato a prescindere, non c’entra il fatto che sia a scopo di lucro o meno.
E ricordo che Qt è GPLv2/3/e quasi +, e in più con un’eccezione: non richiede strettamente programmi GPL, ma vanno bene la maggior parte delle licenze open source (BSD, MPL, Apache, …)
Comunque invece di perdere tempo a riscrivere la ruota per l’ennesima volta, sarebbe intelligente usa un toolkit che funziona come le qt4 e lavorare ad applicazioni su quelle.
Ma cìè troppa gente che deve difendere il proprio orticello con i denti e quindi buttare alle ortiche tempo ed energia per riscrivere le gtk per poi riscrivere le applicazioni e continuare il muro contro muro, come fosse una tifoseria calcistica.
Infantilismo? Egocentrismo? Sete di (piccolo) potere?
Ci chi rimette? Gli utenti.
scusate qualcuno pensa anche che domani ci sara’ la fine del mondo? io ho preparato un arca nel caso.cazzo ho lo cispa dal sonno!
Sono d’accordo che si tratti di discussioni da ombrellone.
E secondo me sarebbe anche una bestemmia farlo. :)
Ho provato diverse volte a programmare con le Qt, e non mi sono mai piaciute, a partire dal dover precompilare la GUI prima di compilare il software, per finire col supporto solo per il C++ e non per il C, passando per le complicazioni di fare interfacce fluide infilando “molle” dappertutto.
Le Gtk sono molto più avanti in diversi punti, soprattutto con l’integrazione di Pango, Cairo, GtkPrint, Clutter, ecc. ecc.
Cosa hanno le Qt in più? Controlli per la rete. E cosa ci fanno in un framework per le GUI?
GObject sarà complicato da programmare, ma dà una potenza spaventosa (e OO, visto che qualcuno lamentava che le Gtk non sono OO) anche in C, oltre che in C++ (Gtkmm), e per scrivere software non serve imparare a usare GObject, è tutto astratto dalle Gtk. Inoltre c’è Vala che permette di sfruttarne tutta la potenza con prestazioni da linguaggio C e semplicità da linguaggio ad alto livello come C# o Python.
Per Qt non esiste niente del genere. O programmi in C++ (per le prestazioni) o in Python o altri linguaggi ad alto livello (scordandoti le prestazioni).
Ci sono molti più binding per Gtk che per Qt.
Inoltre, se non fosse per Gnome, oggi forse non ci sarebbero GStreamer, PulseAudio, dbus, e la maggior parte delle tecnologie di freedesktop.org
Ricordo che anche XFCE e LXDE dipendono dalle Gtk, assieme ad altri window manager e a parecchi programmi molto diffusi, tra cui Gimp.
Che Nokia abbia spostato lo sviluppo di Maemo su Qt ha un’importanza relativa, visto che è già nato Hildon per Gtk che è molto più libero.
Firefox in qt? Naaaa…
come non essere d’accordo con #16?
@Riccardo:
No. Le Qt sono GPL2.1, e se le vuoi linkare a qualcosa (anche dinamicamente) devi rilasciare quel “qualcosa” come GPL. Non puoi usare BSD, Apache o altro. Solo GPL.
Oppure paghi la licenza a TrollTech.
@16 e 20:
E perché la Trolltech si è messa a reinventare la ruota di nuovo, visto che aveva già le Qt3 e le Gtk, e ha fatto le Qt4?
Proprio per difendere il suo orticello fatto da una licenza proprietaria per vendere le sue applicazioni (Qtopia, per esempio).
E ha fatto bene. Così come fa bene la comunità Gtk a portare avanti lo sviluppo delle sue librerie.
Forse non vi rendete conto che le più grosse innovazioni degli ultimi 5 anni, su Linux, sono avvenute proprio grazie alla “lotta” tra Gtk e Qt e tra Gnome e KDE?
Volete finire come su Windows, dove dipendono da una sola azienda tutte le innovazioni?
Lo sapete che se modificate il sorgente delle Qt dovete cedere i diritti alla Trolltech (per poterle distribuire loro con licenza chiusa)?
@Alex
Se leggessi la licenza delle Qt, forse, daresti ragione a Riccardo.
Basta leggere questa pagina:
h t t p ://doc.trolltech.com/4.4/license-gpl-exceptions.html
(ricostruite la URL, se no il messaggio mi rimane in moderazione).
p.s. guardate questo esempio degli sviluppatori GTK che mette a confronto Qt e GTK :P
http://markmail.org/message/5dcwrc5vrqp6pt6f
Non ho mai usato GTK ma… mi son spaventato vedendo quello…
@Alex:
beh, volendo puoi mantenere un set di patch separate, magari in un repository, quello sta a te (vedi qt-copy/patches in KDE). Che poi molta gente per motivi pragmatici preferisca cedere i diritti è un altro discorso…
Gnome ha paura che se passasse a qt non avrebbe più ragione di esistere. Crollerebbe il progetto, gli sviluppatori comincerebbero a conoscere troppo bene l’ambiente qt —>kde = fine dei giochi.
Per salvare la baracca si stringono fortemente alle gtk che pian piano stanno rischiando di diventare obsolete.
p.s. ogni volta che mi collego ho un nome diverso, stavolta ero “urcuz”
Io penso che si debba essere pragmatici - essendo un programmatore :D
GNOME e GTK non devono essere per forza legati… Come Qt e KDE d\’altronde, visto che e\’ Kde e non Qde :D.
Io, da programmatore, la mia scelta l\’ho gia\’ fatta: Qt strabatte qualitativamente le GTK 2 e dubito che qualcosa mi faccia tornare indietro nel breve periodo. Semplicemente: C++ e\’ piu\’ veloce da usare che C, le Qt sfruttano benissimo il linguaggio, sono semplici e veloci e soprattutto di una potenza assurda. Ah gia\’, dimenticavo l\’ottimo supporto (visto che trolltech ci campa.)
Detto questo: insistere sul binomio GNOME + GTK credo sia una cosa da \”religiosi\” o \”fondamentalisti\”: gnome e\’ un desktop environment. GTK e\’ un toolkit. L\’obbiettivo di gnome e\’ fare un d.e. che soddisfi certi parametri d\’usabilita\’ e certe caratteristiche per l\’utente, se il mezzo per fare cio\’ lo consente (e visto che, come ha detto felipe, la nascita di gnome era dovuta alla licenza delle prime Qt, questione ora superata), allora non vedo perche\’ fissarsi.
Mah, sempre peggio. Posto che l’invocare a gran voce la migrazione verso qt per il bene degli utenti e sviluppatori - senza spiegare come e perche’ - lo trovo al limite della flamebait, chi vuole davvero uno gnome basato su qt perche’ non passa semplicemente a kde4.1? Non tanto perche’ l’uno o l’altro si equivalgano; ma per il poco che ho provato, pare a me, che kde abbia intrapreso una direzione comune a gnome. Il cammino che hanno seguito non sara’ lo stesso, ma di fatto hanno messo su un ambiente semplice, curato e luccicante abbastanza da risultare gradevole persino a me, che gnome non lo mollo :). Ci sono tante differenze sottili tra i due, ma molte nascono dalla differente base dei due desktop piu’ che dagli obiettivi degli sviluppatori a mio avviso. Migrare a qt non e’ solo cambiare look, vuol dire appiattire tutte le peculiarita’ dell’uno sull’altro, insomma perdere quasi tutto quello che c’e’ di gnomoso in gnome. Eppoi bisognerebbe reimplementare buona parte dello stack di applicazioni e librerie col risultato… ? Tutto per avere qualcosa che kde - per chi proprio non puo’ fare a meno del feeling tipico delle qt e la semplicita’ di un desktop come gnome - offre gia’ ora. Per chi sviluppa invece, non mi risulta, ci sia alcun obbligo ad usare le gtk in c, ma, come ha gia’ detto qualcuno, esistono binding per ogni gusto e molte applicazioni di rilievo o moduli in ambito gnome sono gia’ scritte in python o mono. E poi c’e’ vala che ormai mi sembra sia a buon punto per l’uso. E se pure fosse il contrario, le gtk permettono di programmare a oggetti e implementare tutti i design pattern che si desidera (beh, poi quali abbiano piu’ o meno senso e’ da vedere caso per caso). Tutte le terribili_atroci_temutissime complicazioni consistono solo in qualche macro e codice boilerplate da scrivere in piu’, cosa a cui, per lo piu’, si fa presto l’abitudine. Per dire, credo che il piu’ grande ostacolo per chi sviluppa su gnome non sia tanto il c e l’infrastruttura di gobjects (molto potente, anzi, come hanno gia’ scritto), quanto una documentazione non sempre curata, aggiornata o - in qualche caso - esistente.
Non c’è un cazzo da fare, Gnome sarà sempre il desktop realizzato con le GTK e KDE quello con le QT. Fullstop.
@28
Ma gnome puo mantenere le linee guida e la sua filosofia d’interfaccia a precindere dal toolkit usato.
Oppure, siccome casa mia usa i mattoni come base allora è la stessa cosa di una villa in costa azzurra?
Il toolkit è un mezzo per costruire una cosa, la cosa costruita vive poi con le proprie caratteristiche.
A me kde4 non piace come “concetto” mentre gnome (concetto di DE) in qt4 o kk26 o PPPZZ6567 andrebbe benissimo.
Mi pare che il problema delle gtk+ non sia nelle stesse, ma nella complessità ad usarle ed evolverle, quindi forse meglio cambiare lingua anche se qualche guru perderebbe tutto il “mana power”.
Altrimenti sono solo i soliti giochetti faziosi.
IMHO
@26, Murdok:
Mah, devo dire che penso che passando alle Qt il male peggiore si faccia a KDE, o meglio, GNOME sorpasserebbe KDE notevolmente avendo la stessa piattaforma di base (facilità/velocità di sviluppo, su cui ha investito molto KDE) e molti più investimenti.
In ogni caso un po’ di standardizzazione non farebbe male.
Ah ma che dico sto’ bestemmiando qui non si riesce nemmeno ad avere uno standard sui pacchetti (rpm,deb,tar.gz, etc etc).
Bha effettivamente troppi orticelli, troppe flame war senza alcun senso, troppi interessi (per poveri secondo me), quando invece la LSB dovrebbe essere un dogma per creare le linee guida per le distribuzioni del futuro.
Sono almeno 15 anni che uso linux e ci programmo sopra. Penso che se non si risolvono questi problemi di base poco si andra’ avanti.
@Riccardo (24):
guarda alla fine del messaggio che tu stesso hai linkato, e vedi che Vala (che usa GTK e GObject) fa la stessa cosa in 3 righe.
Tra l’altro, è un esempio montato ad arte per complicarsi la vita con GObject, che serve solo se stai creando nuovi widget, in pratica.
In tutti gli altri casi userai normali oggetti Gtk e non avrai tutto quello sbrodolamento di #define e typedef.
E se fai la stessa cosa con C++ e Gtkmm probabilmente il risultato è simile a quello delle Qt (ma non ho mai usato Gtkmm).
@27
Tu hai fatto la tua scelta. Non capisco perché definire religiosi o fondamentalisti quelli che fanno una scelta diversa.
Personalmente ho trovato più potenti e flessibili (e con molte più estensioni sotto forma di librerie aggiuntive) le Gtk rispetto alle Qt.
@30: la tua opinione in effetti e’ plausibile, ma io non ne sono del tutto convinto. Dopo tutto, a sciogliere questo tipo di dubbi dovrebbe essere qualcuno abbastanza esperto di ambedue i toolkit, e io non lo sono. Posso pero’ osservare che in questi anni molto del lavoro svolto intorno a gtk e’ stato fatto con gnome in prospettiva e, viceversa, molte responsabilita’ dello stack gnome sono state migrate in gtk. Metafora per metafora, solo perche’ ho due abiti da sera dello stesso tessuto - anche simili -, non e’ detto l’uno mi stia altrettanto bene o comodo dell’altro, se poi sono gnomo ce ne vuole uno cucito su misura :D Ma a parte queste considerazioni, piu’ o meno opinabili, con cui rispondevo soprattutto a chi dice “qt si, gtk no perche’ qt e’ meglio, qt e’ bello, o perche’ si e basta e le gtk sono cattive brutte e limitate”, bisogna ricordare comunque che una migrazione a qt implicherebbe un lavoro enorme. Un cambio di piattaforma e’ gia’ avvenuto, e si e’ trattato di passare da una major version all’altra dello stesso toolkit. Ci son voluti anni per stabilizzare il desktop e avere un parco applicazioni appena sufficiente a coprire tutte le esigenze degli utenti, e ancora ne mancano. Mo che si fa? Si passa ad un altro toolkit del tutto differente per poter dire, tra qualche anno se va bene, che abbiamo il miglior desktop qt in circolazione? Insomma, a prescindere da ogni altra considerazione, e tenendo presente che le gtk non sono cosi brutte come le descrivono, e’ semplicemente assurdo invocare una migrazione del genere, e ancora peggio riproporla ogni tot. mesi, con le solite trite argomentazioni (non che fosse questa l’intenzione del post di felipe, che anzi cita un post in cui e’ ben messo in evidenza quanto problematico e distruttivo sarebbe il passaggio).
Ragionamento dell’uomo qualunque…
Da non programmatore, posso solo auspicare che esistano sempre - almeno - due progetti separati: Qt e GTK. Se poi una delle soluzioni avrà il sopravvento per manifesta superiorità tecnica, spero che continueremo comunque a poter scegliere tra tanti DE: Gnome, KDE e tutti gli altri.
Più confronto, più idee, miglioramento per tutti.
Visto che ho un casso da fare oggi mi accodo alla risposta di Alex (33) :D. Quell’esempio mostra un po’ del boilerplate (incompleto) che va scritto per subclassare un gobject. Praticamente e’ routine per chi programma le gtk in c e non e’ cosi spaventoso dopo averlo digerito la prima volta e non e’ che cambi molto da implementazione a implementazione, sono poche macro in croce e qualche funzione standard. Poi si puo’ discutere su quanto piu’ rumoroso e’ un sorgente c rispetto a uno c++, ma siam sempre li: non c’e’ un linguaggio d’elezione per sviluppare le applicazioni, e tutti usano un po’ quel che gli pare - c++, python, c#, basic, pascal, modula, perl, ecc. - e quella roba brutta non la vedono piu’. Poi c’e’ vala (sembra che ci sia bisogno di ripeterlo) con sintassi c#-like che produce l’equivalente c automaticamente. Ovviamente le librerie stesse sono in c, ma, come detto, a parte un po’ di boilerplate piu’ o meno standard, non c’e’ nulla di inguardabile, solo un po’ di zucchero sintattico in meno. Tempo fa c’era (ma forse e’ ancora supportato) un tool per scrivere quella roba in automatico. Per il resto basta abituarsi a sostituire mentalmente la dot notation con qualche underscore e passare l’”istanza” come primo argomento di un metodo (un po’ come il self di python, se vogliamo)… ci voglion veramente 10 minuti a impratichirsi con questo standard di codifica. Insomma non e’ proprio il c l’handicap piu’ grave delle gtk.
Mah… non ci credo, una delle cose che mi paice di questo blog e\’ che di solito chi commenta e\’ abbastanza assennato da non cadere in luoghi comuni come \”[gtk|qt] e\’ meglio di [qt|gtk]\”….
A prescindere dal fatto che, come ha fatto notare baghera (3), Shuttleworth parlva solo di portare le caratteristiche distintive, non di riscrivere gnome in qt (o almeno non l\’ha detto espicitamente), provo a dire la mia su questa improbabile idea.
Per quanto riguarda l\’utente finale, chissenefrega: la cosa importante e augurabile e\’ che entrambi i framework, gtk e qt, siano un giorno in grado di dare applicazioni che si integrino completamente con il mio desketop, qualunque essos sia (se io uso gnome e amarok, oppure kde e firefox, dovrebbe essere tutto bello e funzionare bene, i dialoghi e i pulsanti al posto giusto). Certo, riscrivere gnome in Qt potrebbe portare a questo, ma come dicevo e\’ improbabile…
Dal punto di vista dello sviluppatore, e\’ puramente un fatto di preferenze: c\’e\’ chi si trova meglio in Gtk, chi si trova meglio in Qt, in C, C++ o qualunque binding (per entrambi i framework sono un\’infinita\’ di bindings…). I modello a oggetti e\’ pero\’ abbastanza diverso in alcune parti, cosa che mi spinge a pensare che sara\’ difficile vedere l\’ecosistema di sviluppatori Gnome che riscrive tutto da GObject a QObject…. I thread, le funzioni, insomma, molte cose sono diverse. Che ci sia poi a chi piace di piu\’ l\’uno o l\’altro, e\’ mia opinione che sia un fatto puramente di gusto, mi sembra ridicolo dire che uno \”e\’ meglio\” dell\’atlro.
Ultimo punto di vista e\’ quello le aziende produttrici di software. La loro scelta si basera\’, penso su due fattori: licenza e \”time-to-market\”, tutto il resto non sono grandi ostacoli, e secondo me non uno e\’ meglio dell\’altro perche\’ ha il pulsante \”OK\” a destra o sinistra…
Insomma, spero in un futuro roseo, mi piacerebbe vedere Gnome in Qt (perche\’ personalemtne mi paicciono le applicazioni in Qt, KDE in testa), ma ci credo poco. E non credo ceh nessuno abbia abbastanza interessi, capacita\’ ed energie per riscrivere Gnome in Qt. Peccato.
sarei più che d’accordissimo issimo :)
@ Dass: ne hai trovato un altro che non usa Qt su Gnome.
Ho vinto qualche cosa?!
@ felipe: che barba, che noia.
Un altro punto a favore di Celeste: parla per dire qualcosa.
Benvenga il basso profilo (da blogger) e il buon “codare”.
Ovvero più fatti e meno pugnette.
Quando qualcuno riscriverà GNOME sulle Qt ne discuteremo, fino ad allora gossip da veline.
Davvero non capisco i toni di certi commenti. Ipotesi per ipotesi, vediamo di immedesimarci nelle possibili categorie che verrebbero toccate da un simile passaggio:
1) UTENTI: non vedo davvero in cosa dovrebbero notare la differenza. Gnome e’ Gnome per le sue preciese scelte di design dell’interfaccia, per la sua usabilita’ e per i programmi a corredo. Il fatto di usare un framework diverso non vedo cosa dovrebbe snaturare.
2) PROGRAMMATORI: non si parlerebbe di passare da Ruby a ASM per codare le applicazioni. Una textbox e’ sempre una textbox, un bottone e’ sempre un bottone, un engine HTML e’ sempre quello. Insomma, non mi sembra che le due implementino un set di framework COSI’ differente, tant’e’ vero che esistono gia’ soluzioni per utilizzare le QT come engine per le GTK e viceversa.
Secondo me il passaggio non sarebbe cosi’ drastico, e avrebbe l’indubbio vantaggio di concentrare risorse verso un obiettivo comune.
3) VENDORS/ALTRI/SARCAZZI: finora l’unico punto oscuro e’ quello delle licenze, che andrebbe chiarito.
Personalmente mi intriga l’idea di avere un KDE4 flessibile e versatile con il suo tema grigio pirla e i suoi mille frameworks basati su QT e un Gnome 3.0 con un bel Murrine RGBA, compiz e la sua semplicita’ d’uso che a tanti piace e a tanti no basato ANCHE’EGLI su QT. E mi piace pensare che il giorno che mi servira’ K3B su gnome potro’ servirmene senza dover installare un altro mezzo chilo di librerie e senza un’incoerenza dell’interfaccia.
O che posso imparare a usare un framework potente come le QT sapendo che viene utilizzato in pianta stabile su desktop, cellulari, umpc e tostapane.
(certo che sarebbe un lavoro non da poco)
Ah! E non dimentichiamo il fatto di poter usare Gnome o parte di esso come shell per windows o macosX!
Ma ce la vedete la soddisfazione!?? :-D
@/V:
OK, allora abbandoniamo (abbandonate) le Qt e passiamo (passate) tutti alle Gtk, compreso KDE.
Ha tutte le caratteristiche che hai elencato (potente e multipiattaforma), ma ha binding per più linguaggi, quindi è più flessibile.
Non credo che KDE mi piacerà di più basato su Gtk, ma così non devo impararmi un altro framework e poso continuare a sfruttare quello che già conosco.
Oggi non c’e’ tregua :D
/V tu non hai capito il tono, ma soprattutto il contenuto di certi commenti, con simpatia eh :) A parte che sintetizzi tutto in una analisi profonda e bucata quanto un colapasta :D
Se vuoi avere un sommario di problemi e vantaggi del porting a qt - che non vedrai mai prima degli infausti eventi del 2012 :D - leggi pure il post di John Palmieri che cita Felipe. E’ solo un elenco, neppure completo secondo me, ma rende bene l’idea in poche parole. Comunque, punto per punto:
per gli sviluppatori il porting vuol dire prendere una consistente quota del codice prodotto fin’ora (desktop e applicazioni) in svariati anni/uomo di lavoro e migrarlo nel branch /Rumenta, ammesso che vogliano farlo. Ti e’ venuto in mente per caso, che in un progetto opensource su base per lo piu’ volontaria come gnome, la maggior parte degli sviluppatori sia ben contenta di farlo in gtk e non e’ affatto spaventata da qualche macro c? Poi, se mi vieni a dire che un textbox e’ sempre un texbox, boh, rido. Cosa si risponde a tanta ingenuita’?
Per gli utenti, beh, queste assunzioni a nome di tutti lasciano il tempo che trovano. In ogni caso, gli utenti si troverebbero praticamente abbandonati fin tanto che il desktop non sia nuovamente stabile. Il passaggio da GTK+1.2 a GTK+2.0 non e’ stato tremendo, ma quasi e ci e’ voluto un bel po’ per avere uno gnome competitivo e adeguato ad un uso quotidiano (e che non crashasse ovunque -.-). E parliamo del porting allo stesso toolkit, praticamente.
La questione licenze non e’ affatto oscura, e gia’ da sola e’ quasi un’ottima ragione per non pensare neppure ad un cambiamento.
@24, Alex:
semplicemente perche’ le due cose non devono essere strettamente legate e vederle legate credo vada ben oltre gli scopi di GNOME (altrimenti non ci sarebbe tutto questo discorso, no?)
Se gnome fosse legato inevitabilmente a GTK per scelta filosofica dei suoi developer, se GTK permettesse di esprimere idee in modo ineguagliabile dagli altri toolkit, allora il problema non si porrebbe nemmeno.
KDE e GNOME hanno seguito due strade diverse, e i toolkit hanno fatto lo stesso. E’ ridicolo dire (come si e’ letto in qualche commento) che gnome non puo’ esistere senza GTK… E’ come dire che una automobile non puo’ esistere senza i pistoni. No: quella e’ solo una via. Se un fabbricante di automobili mi venisse a dire che “non c’e’ auto senza pistoni”, sarebbe un fondamentalista/religioso. Se invece mi vieni a dire “preferisco fare automobili con i pistoni” allora e’ un’altra cosa, ma stiamo discutendo proprio perche’ c’e’ qualcuno che non dice cosi’.
@Alex
“OK, allora abbandoniamo (abbandonate) le Qt e passiamo (passate) tutti alle Gtk, compreso KDE.”
Apprezzo il sofismo, ma guarda che per me non ci sarebbe davvero nessun problema, anzi!
La mia considerazione iniziale (che poi si e’ espanza in una gran pippa mentale) e’ semplicemente che quello che contraddistingue KDE da Gnome agli occhi degli utenti NON E’ il framework QT/GTK.
Gnome ha intrapreso una certa filosofia a livello funzionale, differente da KDE e piu’ o meno apprezzata, che poi certe funzionalita’ siano implementate con l’una o l’altra libreria a me (utente) frega ben poco.
@AkiRoss: Enno’ senza considerare altri legami, gnome e gtk sono indissolubilmente legati a livello di implementazione. No dico, lo vorrete fare a botte di sed s/gtk/qt/g il porting? :D Lol allora porting per porting, non voglio ne’ qt ne’ cocoa, lo portassero a mono o vala, avremmo un desktop scritto in gtk, compatibile con gtk, “orientato agli oggetti”(TM) e con codice meno “spaventoso” :D
@44
e invece riscrivere le gtk( 3? ) e poi tutte le applicazioni ti sembra più semplice/veloce e si butta in /rumenta meno roba?
Tuute le volte bisogna riscrivere il toolkit?
Non è meglio guardarsi intorno prima se esiste già qualcosa?
O tutti i programmatori del mondo prima di scrivere una linea di codice, non contenti dei linguaggi a disposizione , prima si scrivono il loro linguaggio personale e poi scrivono il codice?
Poi ci si lamenta dei 1000 progetti 1000 standard.
E per i soldi, ma tutte le donazioni dei vari sponsor che fine fanno?
Penso che per cose di importanza come Gnome Gnu potrebbe “cacciarne ” fuori
altrimenti lasciamo perdere tutto e arrivederci.
Le cose o si fanno seriamente oppure si va a fare gli agricoltori che con la penuria di grano “c’è bisogno”.
Commento di un utente stufo di questo continuo infinito logorante asfittico campanilismo A vs B.
@horace: “tu non hai capito il tono, ma soprattutto il contenuto di certi commenti, con simpatia eh :) A parte che sintetizzi tutto in una analisi profonda e bucata quanto un colapasta :D”
Eh lo so, purtroppo scrivo tra un build e l’altro e non ho tantissimo tempo di mettermici (anche i commenti non li ho prorpio letti tutti lo ammetto :-P )
Il post di Palmieri l’ho letto, e mi pare che alcune sue controargomentazioni siano un pochino debolucce, non volevo citarle tutte qui, ma gia’ che ci siamo:
“More bickering on how to write applications”
“Less focus and a return to writing applications without a shared guideline
“A loss of identity”
Queste 3 non mi paiono verosimili. Si tratterebbe COMUNQUE di scrivere applicazioni PER Gnome o PER KDE, ciascuno con le sue linee guida. Semplciemente nel momento in cui avessi bisogno di K3B o di Amaroko di Cheese o di quel che vuoi avrei meno inconsistenza nelle interfacce, che mi pare gia’un gran bel passo avanti.
“Loss of amazing GTK+ developers who may feel abandoned”
Lo capisco, ma perdere una persona perche’ fa i capricci e si sente abbandonato per una scelta tecnica non mi pare una cosí gran perdita.
“Splintering of the community so we have parallel GTK+ GNOME and Qt4 GNOME development”
Mi pare che KDE stia giá affrontando un problema simile e non é ancora morto nessuno, in piú gnome ci si ritroverá comunque in questa situazione se é vero che le GTK han bisogno di una revisione e di uno stacco dal passato come mi pare sia stato riportato qualche tempo fa (susate, poi ritroveró la fonte)
“GTK+ isn’t just a license - we would be losing a lot by switching away from the codebase”
detta cosí vuol dire tutto e niente.
“A loss of activity at Freedesktop.org which is actually sometimes useful in producing dialogue and shared practices”
Non capisco. Laddove ci sia bisogno di dialogo Freedesktop sará lí a promuoverlo. Laddove non ce ne sará piú bisogno sará perché l’interoperabilitá é stata raggiunta. Dove sta il problema?
“# A loss of control over the direction of the toolkit effecting the quality and feel of the GNOME desktop
# Really a lot of development is moving to the web - will toolkits be important enough to warrant the pain of the move”
Mi paiono le uniche 2 plausibili.
“per gli sviluppatori il porting vuol dire prendere una consistente quota del codice prodotto fin’ora (desktop e applicazioni) in svariati anni/uomo di lavoro e migrarlo nel branch /Rumenta, ammesso che vogliano farlo.”
Questa é una cosa che andrá fatta COMUNQUE, che si passi a QT o che si rifacciano le GTK3.
” Ti e’ venuto in mente per caso, che in un progetto opensource su base per lo piu’ volontaria come gnome, la maggior parte degli sviluppatori sia ben contenta di farlo in gtk e non e’ affatto spaventata da qualche macro c? ”
Infatti io vedevo con favore la cosa non perche’ sia partita dal basso ma perche’Canonical stessa sembra appoggiarla. Altrimenti OVVIO che non ci penserei neanche di striscio.
Poi, se mi vieni a dire che un textbox e’ sempre un texbox, boh, rido. Cosa si risponde a tanta ingenuita’?”
Ok, allora fammi il favore di mostrarmi la sitassi per creare una textbox GTKTextBox e una QT Textbox e anche dove la sintassi sia cosí stravolta tra le due…
————————-
Poi io parto dall’assuno che ci si stia muovendo verso un GROSSO rinnovamento delle GTK
A fronte di questo, per riscrivere tutto un framework E il prodotto che lo utilizza, non si potrebbe risparmiare del tempo e usare qualcosa di collaudato e supportato giá da un bell’ecosistema di sviluppatori? Tipo, mmhhh, fammi pensare… LE QT4?
Poi quando penso a questa eventualitá lo scenario a cui é:
1) ah! le GTK scontentano
2) Le GTK 3 dovranno staccare dal passato
3) Canonical promuove l’uso delle QT per Gnome, mette un po’ di fondi, fa partnerships con Nokia etc etc
4) Gli utenti si trovano il nuovo Gnome, identico e skinnato come il precedente, nella ubuntu 10.04 “Methaphysics Mangusta”
Chiaro che se manca uno di questi prerequisiti allora parliamo di due cose diverse (e di conseguenza si capisce perche’non ci intendiamo)
Sinceramente è da un pezzo che credo che la distinzione tra GNOME e KDE travalichi - e di molto - la differenza di librerie. GNOME piace perchè è studiato in un certo modo, perchè è pulito, semplice e sviluppato con scrupolosità anche maniacale per non stravolgere mai l’esperienza d’uso degli utenti. Se GNOME mantenesse tutti questi principi, non avrei alcun problema ad accettare uno gnome basato su QT anzichè su GTK, magari effettuando un piccolo fork, giusto per godere di qualche piccola personalizzazione. In effetti mantenere GTK e QT attualmente costituisce un ostacolo nella creazione di applicazioni per linux, ostacolate nel loro voler essere “universali” ovvero compatibili al 100% con tutti i DE.
Se le QT sono piu avanzate e meglio mantenute, non ha senso riscrivere tutto solo per poter usare GTK. Questa è ovviamente l’opinione di un utente non tecnico, però a livello logico non urlo allo scandalo quando si parla di basare GNOME3 su QT… è semplicemente una scelta razionale che non mira all’omologazione ma all’integrazione sempre migliore dei due desktop.
Ecco i miei due cents….
@48: mi pare un po’ eccessivo parlare di riscrittura. Anzitutto i piani per gtk+3 sono in discussione da tempo, se ne parla oggi un po’ piu’ concretamente, ma sono pur sempre qualcosa a lungo termine, quindi non si sa bene neppure cosa accadra’ veramente. Non sono uno storico delle gtk, ed e’ una storia lunghetta, ma la riscrittura piu’ consistente che mi risulti e’ stata quando hanno rotto l’abi col passaggio alla 2.0. E in quel caso hanno pesantemente modificato la struttura stessa di gtk, hanno cambiato parecchie cose al sistema dei tipi, astraendolo dal toolkit grafico, hanno reimplementato tanti widgets e altre classi come GtkStyle e introdotto nuove api. Ossia, hanno cambiato il core stesso delle gtk (anche se concettualmente la libreria non e’ cambiata poi tantissimo). Da quel momento in poi non e’ che abbiano riscritto il toolkit ad ogni versione, eh, eppure ne hanno fatto di lavoro e hanno introdotto un mucchio di roba. Boh, le prime che mi sovvengono sono GtkRecent o GVFS. Insomma nuove funzionalita’ o pesanti riscritture senza rompere drasticamente col passato. E per gtk+3 si parla di mantenere branch paralleli. Ora non dico che sara’ immediato o semplice, ma non mi aspetto faranno terra bruciata e ricominceranno da zero. Perche’ ora il problema maggiore di gtk sono le (neppure troppe) funzionalita’ mancanti e non la maturita’ del toolkit, che mi pare piu’ che buona. Insomma il cuore di gtk non vedo perche’ debba essere buttato, se e’ stato distillato e rifattorizzato nel corso di molti anni. Poi chissa’, potrebbero anche decidere di riscrivere tutto in python :D
A parte questo, il campanilismo lo vedo piu’ nelle tue parole che nelle mie - ho pur detto che trovo pregievole kde4.1 - facendo affermazioni tra il gossip e la leggenda urbana poco appropriate alla questione, eh, solo per dire che e’ meglio passare a qt. Scusa ma la seconda parte del tuo commento fa a dir poco sorridere.
@49: /V a te devo una risposta perche’ con una battuta cattiva t’ho obbligato a scrivere tutta quella roba :D Ma saro’ breve: questione di opinioni. Cioe’ te interpreti in un certo modo le cose che dice J. Palmieri e io in un altro. In particolare quando dice “A loss of identity” io gli do pienamente ragione, perche’ quella osservazione sottende molte piu’ cose di quanto sembri a prima vista. Scusa ma dovrei aprire un blog a parte solo per nominarle tutte :D
Per la faccenda del textbox (credo che tu parli dell’equivalente di un GtkEntry) non metto in dubbio che due toolkit pensati per fare piu’ o meno la stessa cosa abbiano api *semanticamente* simili. E non mi stupisce. Ma il tutto mica e’ solo un lavoro (non da poco) di riscrittura? bisognera’ rifattorizzare tutto, tenendo conto dell’impedenza tra i due toolkit (non ci credo che siano isomorfi, giuro), fare testing, riscrivere la documentazione, ecc. . Ma, seriamente, come si puo’ credere che i benefici siano tali da giustificare un’opera del genere? Ci vorranno anni per farlo, c’e’ poco da discutere. Sono evidenti le difficolta’ del passaggio da gtk1.2 a gtk2.0, da qt3 a qt4, c’e’ da sperare che vada meglio da gtk a qt? Visto che poni lo stesso argomento di molti, ti rimando la palla chiedendoti, perche’ pensi che dovranno riscrivere le gtk3.0 da zero? puo’ essere, eh, ma non ho letto da nessuna parte cha accadra’ di fatto, e mi meraviglierei. Certo parlano di rompere l’abi, e questa non e’ una cosa che han tirato fuori dal cilindro per colmare il gap rispetto alle qt, eh, fa parte della normale schedulazione delle gtk.
Comunque, ho forse indovinato i termini della questione… sono sicuro che Shuttlewort abbia tirato il sasso e nascosto la mano. Scommetto che sta programmando una riscrittura di gnome in qt in house, per slegarsi dall’upstream, chiudere il bug #1 e dominare il mondo, la luna e gli anelli di saturno con Ubuntu. Ci sta solo preparando psicologicamente all’avvento di una nuova era di pace e prosperita’ e concordia tra fanboy :D
…sembra un concorso a chi ha il pisello informatico più lungo e performante.
in tal contesto mi definisco omosessuale.
@/V:
Per quanto riguarda le differenze tra Qt e Gtk, basti solo una cosa: Gtk si basa su segnali, Qt su slot. Sono due approcci praticamente opposti alla gestione degli eventi, quindi non basta trasformare una Gtk.Entry in una Qt.Entry, bisogna stravolgere tutta la gestione dei segnali.
Poi Qt si basa su Form e Gtk su Containers. In Qt specifichi le coordinate di un widget nel form, in Gtk specifichi la posizione rispetto al suo contenitore.
Tra Gtk1.2 e 2.x sono cambiate molte API, ma la filosofia di utilizzo è rimasta la stessa, al punto che un’applicazione in Python che avevo fatto per le Gtk 1.2 l’ho portata in Gtk 2.0 solo aggiungendo alcuni parametri a qualche funzione. Per applicazioni più grosse il lavoro di riscrittura è stato più lungo (vedi avidemux) perché usa molti widget, alcuni fatti apposta, o impossibile (vedi XMMS) perché non usava quasi niente delle Gtk e si era riscritto buona parte dei widget.
Per Gtk3, l’idea della riscrittura da zero è stata buttata lì da uno sviluppatore, secondo me come provocazione, ma già molti parlano semplicemente di rivedere le API, di nascondere un po’ meglio gli attributi (che ora sono in gran parte “public” per dirla alla maniera OO) tramite dei setter/getter, in pratica, in modo da rendere più semplice la modifica degli internals, e di integrare in Gtk alcune cose che ora sono esterne, tra cui buona parte della libgnome che si sta restringendo sempre di più.
Secondo me avrebbero bisogno anche di altre cosucce, tipo sistemi di misurazione in percentuali, millimetri o simili, oltre ai pixel, e una riveduta alle window standard (file chooser, color chooser, ecc.) per renderli più personalizzabili (per dispositivi palmari, per esempio), ma sono cose che probabilmente si potranno fare semplicemente aggiungendo funzioni ai widget già esistenti.
Passare alle Qt, in un modo o nel’altro, significa legarsi a un solo produttore, per di più commerciale (quindi coi suoi interessi) e per di più, ad oggi, semplice “divisione” di un’azienda che ha il suo core business sui cellulari. Ok che il futuro è mobile, ma non chiudiamoci potenzialmente le altre porte, abbandonando un progetto che, oggi, è in mano alla comunità.
Poi, il fatto che qualche sviluppatore sia scontento delle Gtk non significa che TUTTI gli sviluppatori sono scontenti.
E Canonical non sta affatto spingendo per convertire Gnome a Qt. E` stato semplicemente Shuttleworth a dire che “magari, forse, volendo, si potrebbe anche convertire”.
Per finire, non esiste solo Ubuntu. E` attualmente la distro più usata sul desktop, ma non dimenticare che in passato questa “posizione invidiabile” è stata assunta da RedHat (che l’ha abbandonata per concentrarsi sui server), Mandrake (fallita e poi molti ridimensionata in Mandriva), SuSE (persa, e poi “rinata” sotto Novell), Gentoo (molto ridimensionata nel giro di un paio d’anni) e ora Ubuntu. Magari nel 2010 ci sarà un’altra distro al suo posto, chi lo sa.
@Neff:
Le Qt non sono affatto “più avanzate e meglio mantenute”. Anzi, ci sono molte meno novità in Qt che in Gtk, soprattutto come supporto di terze parti (vedi le varie librerie aggiuntive che ho già elencato).
L’unico “vantaggio” delle Qt è che, essendo un prodotto commerciale che deve garantire alcuni standard ai clienti, hanno una velocità di modifica delle API molto più bassa (quasi nulla), quindi è più facile portare le applicazioni alle nuove versioni. Di contro, questo lega un po’ le mani agli sviluppatori, che non possono modificare facilmente le API per adeguare la libreria alle novità.
In pratica le Gtk seguono una filosofia più simile a quella del kernel di Linux: “se serve per migliorare, si rompono le API e anche le ABI”, mentre le Qt più simile a quella di Windows: “garantire sempre la compatibilità col passato, eventualmente aggiungere ma non modificare”.
@horace: “In particolare quando dice “A loss of identity” io gli do pienamente ragione, perche’ quella osservazione sottende molte piu’ cose di quanto sembri a prima vista.”
Posso immaginare, d’altronde io parlo molto da “esterno”, tendo a non sentire troppo lo spirito o il senso d’identita’ e non mi ritengo in grado di giudicarne la portata.
Per chiarirci, di primo acchito mi verrebbe da dire “ma chissenefrega dell’identita’! E’ un prodotto, mica una religione! Andrebbe implementato nel miglior modo senza tanti fanatismi!”
Poi pero’ penso alla Apple e a quanto il senso di identita’ faccia per i suoi prodotti, e mi dico che forse non e’ cosi’ da sottovalutare.
Quindi lascio la questione aperta e mi rimetto al parere di chi ne sa di piu’.
Per la faccenda della textbox, il mio era solo un esempio stupidissimo. D’altronde guardandomi in giro non posso nono notare che molti dei programmi piu’ diffusi spesso a livello di interfaccia non vanno oltre controlli “standard”, il cui porting richiederebbe si tante ore uomo per la riscrittura del codice, ma a livello implementativo potrebbero restare assai simili.
In ogni caso ribadisco, la mia opinione e’ molto circostanziata alle circostanze del momento: vedendo che si e’ cominciato a parlare COMUNQUE di una probabile discontinuita’ tra GTK2 e GTK3, che “grandi” come canonical sembrano essere interessati e che un’esperienza simile, seppur con minori ripercussioni, sembra essere stata affrontata dal team di KDE (cosa che fornirebbe un ottimo caso d’uso da prendere come studio per capire come muoversi e cosa non fare), diciamo che SEMMAI andasse fatto questo potrebbe essere un buon momento (questo=di qui a 2 anni eh!).
Per il resto mi affido al parere di chi con QT e GTK ci ha pacioccato piu’ di me.
(peraltro grazie a tutti per l’ottima piega che sta prendendo la discussione! Con il rischio flame che un argomento del genere puo’ portare direi che stanno saltando fuori al contrario delle argomentazioni davvero interessanti.
SIINE FIERO FELIPE)
Scusate ho problema con QNOME e con QIMP : qualcuno può aiutarmi ?
@/V
Beh io non ho molto altro da aggiungere, ma vorrei giusto dire che in riferimento all’identita’ non intendevo precisamente quello che menzioni tu. Volevo quanto meno dire che in quella piccola frase era racchiuso tutto quello che e’ gnome+gtk: tecnologia, esperienza, progetti, utenti, idee, marketing, comunita e… love :D E le ripercussioni di un cambio cosi’ radicale avrebbero effetti, stravolgenti o meno, a tutti questi livelli. Pero’ poi ripensandoci e’ giusto anche quello che dici, ma l’identita’ in tal senso esiste soprattutto se c’e’ prima tutto il resto. E questo dovrebbe sconfessare del tutto l’idea del pessimo stato delle gtk. Poi quoto Alex che oltre ad aver riassunto in modo mirabile molti dei problemi da fronteggiare sul versante tecnico ha aggiunto un’altra acutissima osservazione: passando a qt i due desktop principali per linux dipenderebbero strettamente da un solo vendor e questo di per se e’ male. Non che Trolltech sia il male, ma la cosa per se’ porta un intero mondo di altre questioni da considerare prima di solo osare pensare ad un cambio del genere. Mo’ basta pero :D
@alex:
lol giusto avidemux è stato portato in qt ;-)
vlc sta facendo la stessa cosa con il plugin principale
@Dass:
vlc non ha un’interfaccia gtk e credo abbiano le loro buone ragioni per migrare a qt. Le wx hanno una pessima resa (almeno su linux), rappresentano una dipendenza __pesante__ per un’applicazione e, qui parlo per sentito dire, hanno talmente tanti bug che a studiarne il codice puoi laurearti in entomologia. avidemux invece e’ gtk, ma ha versioni per windows e osx. Ora non saprei dire perche’ cambiano toolkit, ma un’ipotesi plausibile e’ quella di unificare il codice per la gui, dato che le qt sono effettivamente multipiattaforma. Non che le gtk non lo siano, ma in effetti il supporto a osx e’ ancora in lavorazione (ma quasi pronto, probabilmente) e la versione windows, anche se funziona egregiamente, e’ distribuita da far schifo. Pero’ insomma, e’ un difetto a cui stanno rimediando.
l’unione fa la forza!
beh io a lavoro (con winzoz) uso gimp per modificare le immagini… a cesare quel che è di cesare, mi trovo molto bene con gimp (e ho anche photoshop installato ma lo evito)
Alla fine, per l’utente medio, sarebbe come avere un’altra macchina con la stessa carrozzeria, se le prestazioni sono le stesse (o meglio?) perchè preoccuparsi di cosa c’è sotto il cofano?
Per i programmatori vedere sotto il cofano farebbe una gran differenza, poi penso che chi sviluppa in GTK sarabbe libero di continuare, non penso abbandonino il supporto.
Come qualcuno ha detto Avidemux o VLC hanno entrambe/anche le interfacce GTK e QT4 e non mi pare abbino riscritto TUTTO il codice ma solo la parte dell’interfaccia.
Il punto non è usare QT o chechessia. Il punto è non fossilizzarsi su una cosa, ma valutare se più conveniente aggiornarla, usare quello che già c’è o creare del nuovo.
Qt è si di una azienda ma questo allo stesso tempo garantisce un supporto sviluppo sicuro e portabilità completa.
Se gtk è affidato a quattro volontari in croce e basta, onestamente nel 2008 che futuro puo avere?
Perchè io programmatore devo impegnarmi a programmare in gtk avendo come unico sbocco Gnome, quando con qt posso creare programmi che possono essere usati praticamente ovunque?
È decisamente evidente che i programmatori GTK andranno via via diminuendo fino all’estinzione, chiudere gli occhi e far spallucce non li farà aumentare.
PS io uso gnome e non lo cambierei mai con kde4. Ma non facco del toolkit una religione, meglio il toolkit più semplice ed usato da tanti dev.
@anonimo (62):
Ti posso dare ragione sul fatto di riscrivere solo l’interfaccia (ma comunque si introduce uno strato di compatibilità. Non è come cambiare le scarpe nere con le rosse…) e di non fossilizzarsi su una cosa, ma non su tutto il resto.
Qt è un’azienda che è stata appena assorbita da un’altra azienda. Questo, a me, fa preoccupare, non tranquillizzare.
Gtk non è affidato a 4 volontari in croce. E` uno dei core project di Gnome Foundation, e viene sviluppato da centinaia di persone. Sicuramente più di quelle che lavorano a Qt.
Non hai come unico sbocco Gnome, visto che i programmi Gtk girano anche senza Gnome e dappertutto. L’unico problema, in fase di soluzione, è che sotto OSX girano dentro X e non nativi.
E` evidente solo a te che i programmatori Gtk andranno diminuendo. A me e` evidente il contrario. Forse la realtà è che non è affatto evidente nessuno dei due scenari, non essendoci statistiche che li provino.
@63
… Gtk non è affidato a 4 volontari in croce. E` uno dei core project di Gnome Foundation, e viene sviluppato da centinaia di persone. Sicuramente più di quelle che lavorano a Qt …
Ma allora che problema c’è? Si rimbocchino le maniche e creino gtk3 e lo inseriscano in gome poi con calma si fà il porting.
Tanto è evidente che qui si parla come al bar.
Solo aria fritta.
Nessuna di queste “divinità” che decidono darà mai retta al “popolo bue” ma deciderà a seconda delle proprie convenienze o per soddisfare i propri pruriti.
Con buona pace de “noaarti”
ha ragione john palmieri: in un futuro che si appoggia sempre più sui servizi web, la scelta del toolkit avrà sempre meno importanza.
intanto aspetto arora (qt+webkit) :)
> ha ragione john palmieri: in un futuro che si appoggia sempre
> più sui servizi web, la scelta del toolkit avrà sempre meno importanza.
Come no… mi suona come “640KB ought to be enough for anyone”.
Ed i servizi web dove li facciamo girare, nell’aria? I client si dovranno sempre sporcare le mani con i toolkit grafici.
#64
“Nessuna di queste “divinità” che decidono darà mai retta al “popolo bue” ma deciderà a seconda delle proprie convenienze o per soddisfare i propri pruriti.”
Non mi sembra che si stia urlando “GNOMEEEEE, USA CUTTIIIIIIIII”, si sta solo discutendo su quello che si dice riguardo QT e GTK, e finché non si sprofonda in una “Toolkit war” direi che si possa pure continuare
Non scrivo niente perché sono iNiorante riguardo queste cose, io uso il PHP, che è web, quindi non ho di questi problemi, tuttavia son sempre d’accordo con ndinisio (#66).
Ieri stavo parlando con un developer riguardo QT ed altri framework, e mi ha fatto cambiare idea su QT, la licenza GPL, per quanto libera sia, non da completa libertà all’utente che lo usa, cioè, non all’utente che non è disposto a spendere quei 3000€ per la licenza.
“Come no… mi suona come “640KB ought to be enough for anyone”.
Ed i servizi web dove li facciamo girare, nell’aria? I client si dovranno sempre sporcare le mani con i toolkit grafici.”
Mozilla prism sembra darti ampiamente torto. 1 finestra + il motore di rendering. Basta.
Che ci si stia spostando sempre piu’ verso le webapp per tutte quelle che sono le applicazioni non specialistiche é un fatto assodato, basti pensare a Google Docs che con il fatto che si interfaccia direttamente a gmail permette di fare operazioni come la getione il versioning e l’invio di documenti office basilari senza neanche passare per il sistema sottostante (e non mi sono reso conto pienamente della cosa finche’ non ho aggiornato il mio CV europass modificandolo dopo con google write senza MAI passare neanche di striscio per un hard disk).
In una prospettiva di applicazioni sempre piu’ cross platform come puo’essere una webapp mi pare inoltre ragionevole ritenere che un framework multipiattaforma si ritrovi anch’esso avvantaggiato. O no?
prendo spunto da @62 per fare una considerazione
le stesse persone che “temono” qt perchè c’è dietro una azienda… usano ubuntu che (sorpresa!) ha anch’essa dietro una azienda coi suoi interessi economici…
ah ma non tocchiamo la religione-ubuntu, giammai!
A chi dice che migrare un applicazione a qt e’ solo questione di cambiare un po’ la carrozzeria vorrei far notare che quando si parla di gtk in effetti si parla di tutto lo stack gobject+glib+gtk, piu’ varie ed eventuali. Ecco, per dire, che buona parte delle applicazioni gnome sono scritte in c e spesso dipendono fortemente dall’object model di gobject anche per la buisiness logic, non solo per la gui. Altro che cambiare qualche riga qua e la…
Fosse pure solo una questione di cambiare il codice relativo alla gui, Alex (53) ha sintetizzato benissimo alcuni esempi del conflitto d’impedenza che sussiste tra il modello gtk e quello qt, mettendo ben in risalto quanto lavoro costerebbe un porting: non solo una semplice traduzione, ma un totale ripensamento del codice. Ed e’ inutile portare avanti qualche applicazione isolata come esempio, perche’ se parliamo di gnome stiamo non troppo implicitamente parlando della riscrittura di parecchie (decine di) migliaia di linee di codice con tutti i problemi di cui sopra.
Vedo poi che dopo tutto gli argomenti contro gtk sono ancora quelli e sono per lo piu’ frutto di una mistificazione che, in effetti, affligge le gtk da tempo. Boh, in questo post son venuti fuori commenti parecchio estesi che li smentiscono uno per uno, o quasi. Non mi va di ripetere ancora le stesse cose, al limite leggetevi tutte le ottime osservazioni di Alex e magari le mie per convincervi che le gtk stanno bene, funzionano egregiamente e non hanno bisogno di nessuna riscrittura da 0 e col tempo avranno tutta la pornografia che vi aspettate nel terzo millenio. E magari capirete anche quanto sarebbe deleteria una migrazione tout court di gnome a qt.
Infine, devo dire che ripensando un po’ a tutte le critiche che vengono rovesciate come una bomba di fango su gnome+gtk ho fatto un po’ di somme, traendole anche dal post precedente sulle hig. Io davvero non capisco, qui pare che un po’ tutti vogliano che gnome migri a qt, perche meglio di gtk; che gnome cambi le sue hig perche’ quelle attuali non vanno bene; e, ho letto anche di questo in altre occasioni, che gnome venga riscritto in un linguaggio “veramente a oggetti”(TM) come c++. Oh cambia questo, cambia quello… vi rendete conto che la maggior parte di voi vuole una cosa che si chiama KDE4.1? Usate quello, no? E’ un ottimo desktop, e’ scritto su qt, ha (si fa per dire) delle hig che incontrano il favore di molti, e’ scritto in c++, e’ multipiattaforma(TM)… che senso avrebbe distruggere e ricostruire un progetto enorme come gnome quando quello che desiderate e’ pronto (quasi) oggi?
@Dass:
io sono quello che forse ha più “paura” dell’azienda dietro Qt, ma non uso Ubuntu, uso Debian. :)
Ma vorrei approfondire, perché la situazione è ben diversa.
Canonical, a parte pagare sviluppatori per migliorare i pacchetti Debian, e aver scritto un installer, non ha fatto molto altro.
Non ci sono (a parte forse il suddetto installer) applicazioni che vivono esclusivamente sui server Canonical. Il 99.999% di quelloche è in Ubuntu viene sviluppato dalla comunità, e ha il suo codice sorgente su Sourceforge, su Google Code, sui server GNU, ecc. ecc.
Canonical non può, domani, decidere di cambiare licenza a tutti i software di Ubuntu. Può chiudere e non fare Ubuntu 9.04, ma gli utenti possono passare ad altro o, volendo, prendersi la briga di ripristinare il progetto integrando le poche parti mancanti (l’installer e poco altro)
Nel caso di Qt, il codice delle librerie è esclusivamente sul server Trolltech. Se vuoi modificare le Qt hai due possibilità: cedere i diritti alla Trolltech o fare un fork.
Nel primo caso, lasci a loro la possibilità di modificare la licenza in qualsiasi momento e, visto che Nokia si è comprata anche Symbian e che parla di cambiare licenza con (mi pare) la APL, non è detto che non passi anche Qt ad APL o ad altre licenze, in modo da poterla sfruttare meglio commercialmente, o di dare la possibiltà ai licenziatari di modificarla senza distribuire il codice (come la BSD). Si vedrà nei prossimi anni.
Nel secondo caso, sei da solo. A meno che tu non riesca a tirare su una comunità molto numerosa, il tuo progetto è destinato a sparire, perché rimane indietro rispetto agli sviluppi delle Qt ufficiali, che la gente continuerà ad usare. Vedi, per esempio, le difficoltà che ha gnash di trovare sviluppatori e di raggiungere il livello di flash, nonostante questo sia un progetto closed source che quindi dovrebbe spingere i “puristi” a contribuire a gnash.
Dal mio punto di vista, questo significa che io, utente e/o sviluppatore, non ho alcuna possibilità di influire sullo sviluppo delle Qt. Non ho intenzione di cedere i diritti a nessuno e non posso sperare di veder fiorire un fork. Tradotto: sono nelle mani di Trolltech e dei suoi eventuali sbalzi d’umore.
Se invece voglio contribuire a Gnome non devo cedere niente. Questo, per me, è garanzia che il progetto rimarrà LGPL, e che se vorranno cambiare licenza dovranno rimuovere tutte le patch che ho mandato io oppure chiedermi il permeso di farlo, anche fossero solo 2 righe di codice (OK, esagero, ma si è capito cosa intendo). In pratica, mi senti più garantito, sia come utente che come sviluppatore, da Gnome/Gtk che da Qt/Trolltech.
guarda che i codici (completi) delle qt li scarico da un qualsiasi mirror di gentoo ogni volta che le voglio ricompilare… sono opensource e gpl, non risiedono solo sui server trolltech ma anche nel mio pc ;-)
e nessuno (nè nokia, nè trolltech) può impedirmi di usarle, modificarle, forkarle…
sono gpl!
se vuoi contribuire alle qt, puoi farlo volendo… nessuno te lo impedisce
io non sono un programmatore, ma sono sicuro che se fossi in grado di migliorare le qt non me lo vieterebbero…
@Dass:
non hai capito. :)
Si`, puoi usarli, modificarli, forkarli, ma non puoi contribuire al tree ufficiale senza cedere i diritti a Trolltech.
E` un’aberrazione dell’open source che, purtroppo, succede sempre più spesso (firefox, openoffice, …) e che a me non piace per niente.
La FSF lo ha reso opzionale: se le cedi i diritti, si arrangia lei a difendere il tuo codice in tribunale. E in ogni caso la FSF la trovo più affidabile, così come le fondazioni in genere, rispetto a un’azienda commerciale. Ma queste sono sensazioni mie.
Mi sembra che ci sono i “tifosi” gtk vs “qt”
A me non importa nulla del toolkit usato.
Si dice:
le gtk sono obsolete, difficili da programmare e quindi ci sono pochi dev per fare mautenzione sviluppo di nuove applicazioni.
a) non è vero sono fighissime “pullula” di programmatori c e binding vari.
E` uno dei core project di Gnome Foundation, e viene sviluppato da centinaia di persone. Sicuramente più di quelle che lavorano a Qt …
Molto bene allora tutta sta gente si dia una mossa e ci faccia vedere i “sorci verdi” in gtk.
se l’ipotesi a è falsa
allora valutare la possibilità di usare un altro toolkit (gpl-2 con tutti i pregi e difetti) non è una bestemmia.
Poi le frignerie “bisogna cambiare questo quello quell’altro” restano frignerie.
E no, KDE4 non è Gnome in QT, neppure sotto potenti acidi.
@anonimo (73)
Scusa se te lo dico, ma finora l’unico con atteggiamenti da troll/tifoso sei stato tu.
Praticamente tutti gli altri hanno discusso civilmente.
Io non ho mai detto che sia una bestemmia usare altri toolkit. Ho detto che è sbagliato pensare di buttare via Gtk e riscrivere Gnome in Qt, e ho spiegato i motivi.
I “sorci verdi” te li ho già elencati. Basta anche solo Clutter, per non parlare di Cairo e Pango o di Glade e GtkBuilder o di GVFS e GIO per farmi preferire Gtk a Qt dal punto di vista tecnico. Ma ti aggiungo anche Vala (che adoro ogni giorno di più) e Mono (anche se a me non piace).
Inoltre, come ho già detto, preferisco di molto la filosofia “tecnica” che sta dietro le Gtk rispetto a quella delle Qt. Sarà che somiglia a quella di MUI sull’Amiga che ho usato con soddisfazione estrema. :)
Il punto è che è, secondo me, stupido sperare che un toolkit apprezzato da milioni di sviluppatori, usato da migliaia di applicazioni, venga buttato alle ortiche solo perché Qt è la moda del momento, grazie a KDE4 e a Nokia o a una frase buttata lì di Shuttleworth.
Magari quando uscirà Gnome3 e Moblin userà Gtk+Clutter su tutti i MID, e magari Google userà Gtk per Android o che so io, ci sarà l’effetto opposto e la gente dirà di buttare alle ortiche Qt perché non lo usa nessuno.
@73: mai detto che kde e’ gnome in qt, anzi in uno dei primi commenti ho scritto succintamente cosa penso al riguardo. Hai travisato quello che ho scritto, perche’ mi limitavo ad osservare che, sommando e facendo media, di tutte le critiche che vengono proposte contro gnome si arriva a delineare un qualcosa che gnome non e’. Molto probabilmente kde4.1 e’ quanto abbiamo ora di piu’ simile a questo qualcosa. Ne ho lette davvero di tutti i colori in questi anni: abolire gconf perche’ troppo windows-like; sopprimere mono perche’ sarebbe il punto in cui microsoft potrebbe incuneare il suo controllo su linux (?); migrare a qt perche’ le gtk sono obsolete, non mantenute, troppo soft-core per i gusti degli utenti; cambiare nautilus perche’ konqueror gli da le piste; riscrivere tutto in un linguaggio diverso ad c, perche’ fa spavento; cambiare le hig perche’ non sono intuitive e naturali; e cosi’ andando… Oltretutto, queste son critiche mosse a furor di popolo, nel senso che vengono prese e riprese di continuo, da molti e mai pienamente argomentate. Insomma, volendo accontentare tutte queste voci bisognerebbe stravolgere gnome in qualcosa che di gnome non ha nulla… abbi pazienza, non sara’ kde quello che ne verrebe fuori, ma ora come ora e’ la cosa che ci assomiglia piu’ di tutto (e intendo il 4.1).
Tempo fa mi sono trovato a partecipare ad una discussione con sviluppatori Sun e non, della possibilita’ di integrazione del KDE (3.x) all’interno di opensolaris.Salto’ fuori che gia’ nel 1999 Sun si trovo’ a dover decidere quale desktop utilizzare come rimpiazzo del diffusissimo CDE basato su Motif.Si scelse GTK+ e Gnome per questioni di licenza (LGPL anziche’ solo GPL) e liberta’ d’utilizzo: QT era pur sempre di una societa’ che rivendeva il prodotto anziche’ di qualche consorzio tipo lo storico OSF.L’ideale sarabbe fare qualcosa tipo motif cioe’ libero,condiviso,standarizzato e con licenza non virale.Ricordo che purtroppo Gnome rimane pur sempre troppo legato a linux.Chi usa BSD oppure altri OS sa di che cosa parlo.
@66 ndinisio
prova a rileggere quello che hai scritto… non ha semplicemente senso.
se ci sono due toolkit entrambi ben funzionanti cosa te ne importa se il tuo client è scritto con uno o l’altro??
nota che ho scritto ‘ben funzionanti’ escludendo quindi le gtk, che sei ci fai qualcosa di troppo va a rilento tutto il desktop.
E comunque che cavolo c’entrano i 640kb?
…avessi mai sentito un utente windows lamentarsi delle proprie GDI.
Va bene essere esigenti e quant’altro però forse quelli che utilizziamo
sono due ottimi toolkit da non bistrattare. :)
@77
Scusa, sono stato troppo criptico, espando il mio pensiero ;)
La frase “ha ragione john palmieri: in un futuro che si appoggia sempre più sui servizi web, la scelta del toolkit avrà sempre meno importanza.” per me non ha senso, è una di quelle che sono buttate li per tappare la bocca all’interlocutore. Tendono a sminuire l’importanza del problema in esame presentando un presente ed futuro in cui il problema non si porrà e quindi sarebbe inutile discuterlo.
In un certo senso la stessa cosa che la frase “640KB ought to be enough for anyone” (now and in the future) avrebbe potuto dire Bill Gates ai detrattori dei limiti di memoria imposti dal DOS (pare che lui non l’abbia mai detta in realtà).
Quindi per concludere, a me non importa che esistano i servizi web, qui si parla di desktop e di tecnologie per farli, che c’entrano i servizi web? Mica sostituiranno i desktop, sono semplicemente un altro mercato, un altro argomento, un’altra cosa.
Il mercato dei servizi web non intacca, ma espande quello del Desktop computing, semplicemente perché ti servirà sempre un computer per accedere ai sempre più belli servizi web.
Vedete… sotto Winzozz tutti ’sti problemi non ci sono!
Scherzo ovviamente! :)
quoto 81… l’unico commento serio fatto da un non addetto ai lavori…
“Quindi per concludere, a me non importa che esistano i servizi web, qui si parla di desktop e di tecnologie per farli, che c’entrano i servizi web? Mica sostituiranno i desktop, sono semplicemente un altro mercato, un altro argomento, un’altra cosa.”
Ah quindi il fatto che Google docs (o zoho o quel che vuoi) rimpiazzi gli applicativi office per buona parte delle operazioni di base (risultando peraltro piu’ comodo quando gestisci allegati), che il prossimo Trillian (un instant messengere multiprotocollo) viaggi su Adobe Air e sia di fatto un servizio web che puo’ girare anche in locale, che adobe (e molte altre) stiano spingendo per portare l’editing foto e video online, che la gente usi ormai solo gmail come client di posta, e che per elaborare un allegato di un’email e rigirarlo oramai non serve piu’ nemmeno passare per l’hard disk, tutto questo non e’ un rimpiazzare il concetto di desktop?
La gestione dei documenti in linea, l’uso di strumenti come wiki e CMS nelle aziende per la gestione della base di conoscenze, i piu’ grandi fornitori di servizi che sstanno spostando tutto online, Apple con mobile.me, microsoft con i servizi Live, l’ottimizzazione dei motori javascript per permettere l’esecuzione piu’ snella di applicativi sempre piu’ pesanti…
Gnome che parla di desktop online.
I thin client che finalmente trovano una nicchia di mercato, forti del fatto che oramai se fai girare un browser fai girare buona parte degli applicativi SOHO, il cloud computing, l’integrazione delle ricerche online, l’affermarsi dei pc come media center piuttosto che come desktop.
No, tutto questo non centra un cavolo eh?
Io non so da che pianeta tu venga, ma per quel che riguarda me e molte (ma MOOOLTE) persone attorno a me sono quasi 2 anni che quasi ogni attivita’ legata al computer viene svolta esclusivamente da servizi online e per la quale l’unica cosa immportante e’ avere un browser che giri sotto.
In tutto questo il fatto che il desktop sia GTK/QT/XUL/COCOA/WPF/SRCZZI frega veramente poco.
straquoto /V, molte delle applicazioni desktop si sposteranno sulla rete, piaccia o non piaccia.
continuo a meravigliarmi però di come parecchie persone siano scettiche a riguardo, nonostante tutto questo stia già accadendo sotto i loro nasi da diversi anni.
andatevi a vedere le offerte di lavoro nel campo dell’IT, non ce n’è una che non richieda conoscenze in ambito di servizi web.
il computer medio del futuro? un piccolo terminale sarà più che sufficiente.
come garantire la libertà? facendo pressioni perché si usino formati e protocolli aperti e liberi da brevetti.