Riscrivere Gnome su Qt?

[zephyr83]

Originariamente inviato da Barra

Hildon è un progetto open, sviluppato da nokia, abbandonato da nokia, praticamente morto (moblin non lo usa più dalla versione 2, ubuntu mobile non esiste + e non credo che ci siano altri progetti in giro a farne uso).

Non vorrei scrivere tra un paio di anni la stessa cosa riferendomi a QT. Ed è probabilmente per questo che grandi aziende come Google ed Opera abbandonano QT (cosa che tra le altre cose non sapevo!). Maemo è un sistema open ma che non gira da nessuna parte se non su 1 paio di dispositivi proprio per lo scarso interese che ha nokia verso il mondo open.

detta così pare quasi che nokia abbia abbandonato hildon e che qualcuno l'abbia raccattato, invece nn mi pare sia andata così
http://arstechnica.com/open-source/n...n-upstream.ars
era il 2007 quando ancora nn esisteva alcun nokia N900 e maemo ora basato tutto sulle gtk!
Inoltre hildon è servito per la versione MID di ubuntu rilasciata a giugno del 2008! se poi il progetto è stato abbandonato è un altro discorso! E poi ubuntu remix deriva proprio da ubuntu mobile edition

Sulla mancanza di concorrenza sbagli di grosso. D-bus è nato come alternativa a DCOP, sviluppato da KDE (anche se poi ne ha preso il posto). Molte delle novità introdotte dai 2 DE sono poi state replicate anche dall'altro. Hanno spesso sperimentato strade diverse per poi adottare la soluzione rivale quando questa si è rivelata migliore (vedi zeitgeist, tracker e nepomuk che faranno a breve il salto della barricata).
L'avere 2 alternative forti (occhio ho detto 2 forti, non 400 di merda come succede spesso su linux) è positivo, sempre e comunque.

E dove ho sbagliato di grosso ho detto che la concorrenza c'è stata e anche tanta fra i due DE! ho detto che nn è ho vista così tanta fra gtk e qt che è ben diverso! anzi, per me usare le stesse librerie può solo far aumentare la concorrenza fra i due DE.
[quote]
Non credo molto nella portabilità dei vari applicativi. Firefox x windows e linux sono due applicativi ben diversi nel codice. Le ottimizzazioni necessarie per ottenere il meglio da un sistema rendono la portabilità un'utopia e lo ha dimostato anche KDE. Dovevano portare il DE su windows ma il lavoro è stato decisamente ostico e (e tutt'ora è incompleto) Certo molti programmi ci girano ma come ci girano?
Altro esempio Openoffice, è un colosso che si muove come una lumaca se paragonato alle alternative.
[quote]
Per me pensi male!! nn mi pare che firefox per windows usi le stesse librerie di firefox per linux! Inoltre l'esempio di kde nn ci azzecca molto perché si parla di un INTERO DE! Perché nn prendi altri esempi di software realizzati in qt che girano senza problemi, nella stessa maniera sia su windows che su linux e addirittura osx?
Ecco alcuni esempi: scribus, inkscape, vlc, smplayer, google earth, avidemux, virtualbox!!
poi ho fatto prima l'esempio di Marble, portato senza problemi da kde4 a windows mobile
http://labs.trolltech.com/blogs/2008...on-windows-ce/

Che altro aggiungere?

Sarebbe ottimo anche per programmi professionali! Da questa pagina
http://qt.nokia.com/qt-in-use
ho scoperto che esistono software realizzati in QT come FEKO che funzionano addirittura su linux!! Altro che programmi realizzati in .net cn la speranza che girino anche su mono meglio se realizzati direttamente cn le qt Se magari si diffondessero maggiormente diverse aziende potrebbero interessarsi maggiormente e realizzare i propri programmi proprio cn queste librerie!!

Google con il google summer of code finanzia sviluppatori e novelli programmatori. è IMHO uno dei maggiori contributi al free software.
http://socghop.appspot.com/gsoc/prog...09?limit_0=100

Forse nn sn stato chiaro! certo che contribuisce, avevo detto anche io che ci mette molti soldi! intendo dire che nn lo fa "attivamente" mettendo mano al codice o rilasciando i propri programmi cn una licenza open source. Al kernel linux mi pare nn contribuisca minimamente! Android è libero solo per il 30% circa. Anche cn altri progetti è un po' "ambigua" (vedi chrome, chromium).
[quote]
Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.
[quote]
nn mi pare proprio sia così! se nn sbaglio per c++ si parla di gtkmm e nn mi pare che abbia avuto un gran successo! se il problema è solo il linguaggio quello si poteva risolvere anche cn le qt e ci avevano anche provato, qtjampi dove si programmava in java. inoltre le qt possono benissimo essere usati in altri linguaggi di programmazione via language binding! esistono interfacce per Java, Python, C, Perl e PHP.

Detto questo: tutte queste sono chiacchiere abbastanza inutili visto che NESSUNO tra gli sviluppatori di gnome si è mai sognato di riscrivere gnome in QT perchè stanno benone così. Hanno introdotto così tanti cambiamenti in GTK che probabilmente con l'uscita di GTK3 tanti inizieranno a parlare di un porting verso GTK di KDE

ovvio che sn chiacchiere inutili ma siamo su un forum! possiamo anche discutere e fantasticare un po' Cmq in questa discussioni ho letto tanti vantaggi delle QT ma nn ho letto nessuna contro indicazione nel loro utilizzo oppure in cosa le gtk sono meglio (o portano vantaggi).
Cmq nn dovrebbe essere obbligatorio un intervento degli sviluppatori gnome, potrebbero farlo anche persone "esterne"....ovviamente sarebbe tutto più difficile e complicato e penso che nessuno si imbarcherà mai in una impresa del genere visto che nn porterebbe ad alcun risultato davvero utile (nn credo che qualche distro userebbe questa versione di gnome ).......però.......mai dire mai! magari qualcuno preoccupato da mono e c# potrebbe addirittura farlo magari la FSF stessa ovviamente le mie sn chiacchiere inutili

Ah, se a qualcuno può interessare questa è la roadmap relative alle qt
http://qt.nokia.com/developer/qt-roadmap
questo è un elenco di applicazioni open source realizzate in qt
http://www.qt-apps.org/
qui invece programmi proprietari realizzati in qt (ovviamente nn tutti quelli esistenti, mancano quelli delle software house "note")
http://qt-prop.org/

[AnonimoVeneziano]

Fare il porting di gnome alle QT4 è un progetto assurdo, bisognerebbe riscrivere tutte le applicazione oltre a tutto il DE.

Tanto fare un "rm -rf /gnome" in tal caso se si decidesse di seguire questa strada.

Guardate cos'è successo a KDE nel tentare di fare un complete rewrite. Ora si è ripreso , ma ne è passato di tempo da quando era stato annunciato alla 4.2 (release in cui si è ripreso).

Se si vuole riscrivere tutto Gnome allora tanto vale rimanere con solo KDE.

Ciao

[zephyr83]

Originariamente inviato da AnonimoVeneziano

Fare il porting di gnome alle QT4 è un progetto assurdo, bisognerebbe riscrivere tutte le applicazione oltre a tutto il DE.

Tanto fare un "rm -rf /gnome" in tal caso se si decidesse di seguire questa strada.

Guardate cos'è successo a KDE nel tentare di fare un complete rewrite. Ora si è ripreso , ma ne è passato di tempo da quando era stato annunciato alla 4.2 (release in cui si è ripreso).

Se si vuole riscrivere tutto Gnome allora tanto vale rimanere con solo KDE.

Ciao

basterebbe iniziare piano piano! in fondo stanno già andando lentamente nello sviluppo no? Anziché migrare piano piano alle gtk# e a mono si migrava alle qt! prima si migliorava l'integrazione e tutte le parti nuove si realizzavano in qt senza dare un taglio netto cn il passato (proprio come già stanno facendo adesso per gnome 3). Ovvio sarebbe stato un lavoro lungo ma in futuro si sarebbero raccolti i frutti IMHO

[Barra]

Fai un pò di confusione...
GTK e mono non sono alternative. Mono per le applicicazioni su linux usa gtk#, una serie di bindings a GTK.

GTK3 esistono e godono di ottima salute.
gnome-shell utilizza un nuovo gestore di temi basato su CSS. Clutter diventerà parte di GTK (dalla versione 1.1 di clutter quindi non con GTK3.0), mossa estremamente intelligente (non si reinventa la ruota, si ricicla la migliore in circolazione). oltre a questo puoi vedere qui http://live.gnome.org/ChristianHergert/Gtk3Wishlist una serie di nuovi strumenti introdotti.

Tenete comunque presente che è da gnome 2.24 che si è iniziato a lavorare per introdurre gtk3. Sono state introdotte nuove librerie, affiancandole però alle vecchie (gnome-vfs e gvfs ad esempio) e deprecando queste ultime pian piano, dando quindi il tempo ai programmatori di mettere mano un pò per volta al codice.

Inoltre in gnome foundation ci tengono a precisare che GTK3.0 non è un punto di arrivo ma un punto di partenza, una base solida, pulita e stabile sulla quale costruire un futuro.

[AnonimoVeneziano]

Ma riscrivere per cosa? Per buttare via tutto il codice che è stato scritto in tutti questi anni e la retrocompatibilità con tutto il software che già esiste per avere un qualcosa con le stesse funzionalità, scritto solo con un toolkit diverso?

Si è già visto con KDE cosa una rivoluzione può portare, ossia blocco totale dello sviluppo per tutto il periodo in cui si fa la riscrittura. E' un illusione pensare di poter portare avanti tutto insieme.

Vi chiedete perchè i programmatori di KDE hanno deciso di buttare fuori KDE 4.0 incompiuto? Il motivo è che non avevano le risorse per sviluppare il 4.0 come si doveva mentre dovevano continuare lo sviluppo della 3.x . Dovevano fare una scelta: portiamo avanti seriamente la versione 4 o continuiamo con la 3? E hanno deciso di passare alla 4.

Inoltre facendo questo passaggio i programmatori di KDE hanno perso tutto quello che avevano fatto fino alla versione 3 , dal codice del DE stesso alle applicazioni che su questo giravano. Si è dovuto riscrivere tutto.

Per questa ragione Gnome 3 non sarà una complete rewrite come KDE4 , ma sarà un insieme di cambiamenti notevoli si, ma solo incrementali e non rivoluzionari rispetto alla versione 2 .

E' la stessa ragione per cui Windows è simile e usa le stesse librerie di base dal 1986. Le rivoluzioni non hanno mai fatto bene a nessuno e loro lo avevano già capito all'epoca.

Ciao

[zephyr83]

Originariamente inviato da Barra

Fai un pò di confusione...
GTK e mono non sono alternative. Mono per le applicicazioni su linux usa gtk#, una serie di bindings a GTK.

io parlavo di mono e gtk# relativo a gnome! sempre più programmi per gnome vengono realizzati in mono e le gtk# hanno sempre più consensi!! Se gli sviluppatori di gnome un giorno decidessero di integrare ad esempio gnome-do in gnome-base? Poteva già esser accaduto!! nn è così remota come possibilità!! a sto punto io preferirei vedere uno gnome che migra, anche se a fatica, alle qt.
Inoltre cn le gtk3 si perderà ugualmente la compatibilità cn il vecchio software quindi dove sta il problema?

[zephyr83]

Originariamente inviato da AnonimoVeneziano

Ma riscrivere per cosa? Per buttare via tutto il codice che è stato scritto in tutti questi anni e la retrocompatibilità con tutto il software che già esiste per avere un qualcosa con le stesse funzionalità, scritto solo con un toolkit diverso?

Si è già visto con KDE cosa una rivoluzione può portare, ossia blocco totale dello sviluppo per tutto il periodo in cui si fa la riscrittura. E' un illusione pensare di poter portare avanti tutto insieme.

Vi chiedete perchè i programmatori di KDE hanno deciso di buttare fuori KDE 4.0 incompiuto? Il motivo è che non avevano le risorse per sviluppare il 4.0 come si doveva mentre dovevano continuare lo sviluppo della 3.x . Dovevano fare una scelta: portiamo avanti seriamente la versione 4 o continuiamo con la 3? E hanno deciso di passare alla 4.

Inoltre facendo questo passaggio i programmatori di KDE hanno perso tutto quello che avevano fatto fino alla versione 3 , dal codice del DE stesso alle applicazioni che su questo giravano. Si è dovuto riscrivere tutto.

Per questa ragione Gnome 3 non sarà una complete rewrite come KDE4 , ma sarà un insieme di cambiamenti notevoli si, ma solo incrementali e non rivoluzionari rispetto alla versione 2 .

E' la stessa ragione per cui Windows è simile e usa le stesse librerie di base dal 1986. Le rivoluzioni non hanno mai fatto bene a nessuno e loro lo avevano già capito all'epoca.

Ciao

ma la compatibilità nn si perderà lo stesso? l'errore di quelli di kde è stato voler dare un taglio troppo netto e cercare di fare tutto in fretta!! potevano benissimo prendersela cn più calma e fare passaggi più graduali e aspettare che ANCHE il software passasse alle qt4!

[AnonimoVeneziano]

Tutto infretta? Lo sviluppo di KDE4 è partito nel 2005 con l'uscita di QT4. KDE 4 è uscito 3 anni dopo, non mi sembra uno sviluppo fatto "di fretta" Tant'è che in quanti si sono lamentati che ci hanno messo troppo ... etc.

La verità è che se nel fare la rivoluzione ci sono voluti 3 anni (in realtà 4 anni perchè KDE4.0 non era completo) , immaginiamoci incrementalmente quanto tempo ci sarebbe voluto ... sarebbero già uscite le QT6

E' troppo problematico per guadagnarci troppo poco. Richiede di cambiare tutta l'infrastruttura sottostante (innanzitutto bisogna riscrivere tutto perchè le QT sono C++ e Gnome è scritto in C) .

Ciao

[zephyr83]

Originariamente inviato da AnonimoVeneziano

Tutto infretta? Lo sviluppo di KDE4 è partito nel 2005 con l'uscita di QT4. KDE 4 è uscito 3 anni dopo, non mi sembra uno sviluppo fatto "di fretta" Tant'è che in quanti si sono lamentati che ci hanno messo troppo ... etc.

La verità è che se nel fare la rivoluzione ci sono voluti 3 anni (in realtà 4 anni perchè KDE4.0 non era completo) , immaginiamoci incrementalmente quanto tempo ci sarebbe voluto ... sarebbero già uscite le QT6

E' troppo problematico per guadagnarci troppo poco. Richiede di cambiare tutta l'infrastruttura sottostante (innanzitutto bisogna riscrivere tutto perchè le QT sono C++ e Gnome è scritto in C) .

Ciao

hanno dato un taglio NETTO senza neanche aspettare che altre applicazioni passassero alle qt4! si poteva anche fare un passaggio più graduale cambiando di volta in volta in volta qualche componente fondamentale e facendo convivere più a lungo qt3 e qt4! certo, ci sarebbe voluto più tempo ma ci sarebbero stati meno problemi!
in fondo nn è quello che stanno facendo quelli di gnome? E anche cn le gtk 3 si perderà la compatibilità cn i programmi scritti cn le gtk2.
Oppure potrebbero continuare cn gnome come è adesso e pensare ANCHE allo sviluppo, parallelo, di gnome in QT....un po' come ha fatto apple che ha preparato il passaggio a osx su piattaforma x86 in "segreto" per anni! Certo, anche qui ci vorrebbe più tempo e più risorse ma per me alla fine il gioco varrebbe sempre la candela! Avessero iniziato al tempo delle qt4 ora sarebbero sicuramente a buon punto

EDIT cmq il mio "troppo infretta" si riferiva al fato che la prima versione definita stabile, cioè kde 4.0 è uscita solo dopo un ano e mezzo di sviluppo!! Nn dovevano semplicemente definire stabile quella questione (o nn chiamarla kde 4.0)

[Torav]

Trovo che sarebbe una follia portare gnome su Qt4, troppo lavoro. La cosa da fare semmai sarebbe scrivere le gtk in un linguaggio a oggetti, tipo c++, nativamente.

Originariamente inviato da Barra

Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.

Non per dire, ma le Qt4 hanno bindings per una quantità impressionante di linguaggi (io ad esempio uso pyqt), basta vedere qui

[Barra]

@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.

@Tutti
Perchè vi ostinate a dire che GTK3 romperanno la compatibilità con GTK2? perchè non sono più supportate libbonobo e simili? Librerie che hanno un'alternativa tecnicamente superiore da almeno 2 anni?
Aggiornare a GTK3 qualunque applicativo significa RISCRIVERNE UNA MINIMA PARTE. Avete presente il lavoro fatto con KDE4? stiamo parlando di 2 operazioni ben diverse.
Intregrare le funzionalità di clutter in un'applicativo è possibile farlo con 4/5 righe di codice (date un'occhio al blog di Mirko Muller), per le altre funzionalità nessuno obbliga ad usarla da subito, quando gli sviluppatori avranno tempo (e se lo riterranno opportuno) me faranno uso, altrimenti tanti saluti.

Mutter (fork di metacity che utilizza Clutter per effetti, trasparenze ecc) è stato portato avanti da UNA SOLA PERSONA per un paio di anni (mantenendo contemporaneamente Metacity che sarà cmq presente in gnome3) e ora è pronto per gnome3. Riscriverlo in QT quanto tempo avrebbe richiesto?

Affiancare il ramo GTK a uno in sviluppo QT avrebbe portato al disperdere forze (gli sviluppatori non sono poi tantissimi e cmq lavorano aggratis nel tempo libero, hanno mogli, fidanzate, forse figli da mantenere e con cui magari passare un pò di tempo libero).

Cosa avete contro GTK#, mono ecc ormai non lo capisco e sinceramente rinuncio a capirlo. Le 'menate politiche' non mi interessano. Se MS è il diavolo allora togliete il supporto a fat e ntfs, togliete samba, togliete amsn ed emesene dai vostri pc prima di pensare a una libreria contro cui MS ha messo nero su bianco che non si rivarra legalemente.


P.s. zephyr83 non mi sembra di avere letto in questo thread grandi i vantaggi tecnici di QT. E non mi sembra di averli mai nemmeno visti all'opera visto che alla fine KDE4 è una versione graficamente più carina di KDE3 ma nulla +. A livello di usabilità e funzioni cosa è stato introdotto con QT? (questo dovrebbe interessare a noi utenti finali. Una differenza di prestazioni nell'ordine dell 5% è poca roba).

[cionci]

Originariamente inviato da Barra

@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.

Python ha un ottimo wrap anche per le Qt

[zephyr83]

Originariamente inviato da Barra

@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.

Forse il problema è l'opposto.....chi usa le gtk sente maggiormente la necessità di usare qualcosa che nn sia il C cmq le qt si possono usare anche cn python!

Perchè vi ostinate a dire che GTK3 romperanno la compatibilità con GTK2? perchè non sono più supportate libbonobo e simili? Librerie che hanno un'alternativa tecnicamente superiore da almeno 2 anni?
Aggiornare a GTK3 qualunque applicativo significa RISCRIVERNE UNA MINIMA PARTE. Avete presente il lavoro fatto con KDE4? stiamo parlando di 2 operazioni ben diverse.
Intregrare le funzionalità di clutter in un'applicativo è possibile farlo con 4/5 righe di codice (date un'occhio al blog di Mirko Muller), per le altre funzionalità nessuno obbliga ad usarla da subito, quando gli sviluppatori avranno tempo (e se lo riterranno opportuno) me faranno uso, altrimenti tanti saluti.

perché è così e l'hai scritto pure tu

Molta della lentezza è data dall'abbondanza di "vecchio codice" mantenuto per questioni di compatibilità. Gnome3 romperà questa compatibilità e quindi tutto dovrebbe diventare più veloce.

se il passaggio sarà più indolore rispetto a KDE4 è perché quelli di gnome hanno deciso di fare un passaggio graduale e nn netto!

Mutter (fork di metacity che utilizza Clutter per effetti, trasparenze ecc) è stato portato avanti da UNA SOLA PERSONA per un paio di anni (mantenendo contemporaneamente Metacity che sarà cmq presente in gnome3) e ora è pronto per gnome3. Riscriverlo in QT quanto tempo avrebbe richiesto?

ci sarebbe voluto molto così come ci stanno mettendo a passare alle gtk3 e a gnome 3........ma a quest'ora sarebbero a buon punto e in futuro i vantaggi si sarebbero visti

Affiancare il ramo GTK a uno in sviluppo QT avrebbe portato al disperdere forze (gli sviluppatori non sono poi tantissimi e cmq lavorano aggratis nel tempo libero, hanno mogli, fidanzate, forse figli da mantenere e con cui magari passare un pò di tempo libero).

Si è vero, ma, sempre secondo il MIO parere, alla fine avrebbe giovato a molti!

Cosa avete contro GTK#, mono ecc ormai non lo capisco e sinceramente rinuncio a capirlo. Le 'menate politiche' non mi interessano. Se MS è il diavolo allora togliete il supporto a fat e ntfs, togliete samba, togliete amsn ed emesene dai vostri pc prima di pensare a una libreria contro cui MS ha messo nero su bianco che non si rivarra legalemente.

ma che diavolo! la questione è ben diversa! un conto è usare un "programmino" come amsn! un conto è basare la maggior parte dei programmi e addirittura un intero DE (il rischio c'è) su un'implementazione di .net e C# che hanno alcune parti coperte da BREVETTI. nn si parla SOLO di implementare le parti "aperte" e libere da brevetti ma di TUTTO (è questo che fa mono). E a quale scopo? tanto la compatibilità cn .net nn si avrà mai e si dovrà stare sempre dietro allo sviluppo di microsoft! per me è una cosa assurda visto che c'era già una valida alternativa (QT).
Si corre il rischio che si ripeta una questione simile a quella del file system fat!!
E poi, anche trolltech a suo tempo aveva messo nero su bianco tutte le garanzie del caso per le QT cn una licenza "adeguata".......allora nn bastò mentre oggi basta?

P.s. zephyr83 non mi sembra di avere letto in questo thread grandi i vantaggi tecnici di QT. E non mi sembra di averli mai nemmeno visti all'opera visto che alla fine KDE4 è una versione graficamente più carina di KDE3 ma nulla +. A livello di usabilità e funzioni cosa è stato introdotto con QT? (questo dovrebbe interessare a noi utenti finali. Una differenza di prestazioni nell'ordine dell 5% è poca roba).

L'usabilità dipende principalmente dal DE e da chi lo sviluppa! i vantaggi nell'uso delle QT sn principalmente quelli di interoperabilità cn altre piattaforme! anche come sviluppo e prestazioni sn "migliori" ma qui ci vorrebbe qualcuno che spieghi più nel tecnico il perché! Inoltre a livello "grafico" le qt hanno sempre avuto una marcia in più........cosa che cn le gtk si sta avendo solo ora grazie a clutter se no chissà a che punto erano ancora
Ecco un "confronto" fra le funzioni di qt 4.5 e gtk 2.14
http://techfreaks4u.com/blog/?p=1021
si vedo come lo sviluppo di qt sia stato decisamente più intenso e "completo" rispetto a quello delle gtk. Però diciamo anche che riflette molto bene i due differenti sistemi di sviluppo: da una parte una società che ci investe e si occupa di tutto (trolltech cn le qt) e dall'altra dove nn arrivano gli sviluppatori (di gtk) arriva il contributo della community (cn cairo, clutter, ecc). Nn dico che sia meglio il primo dal secondo metodo, anzi! però se ci fosse stato un po' meno "campanilismo" magari si poteva sfruttare fin dall'inizio una solo libreria che negli anni si è dimostrata sempre eccellente e cn un ottimo sviluppo! poi per assurdo, attualmente meglio le QT come licenza (che sn anche gpl) delle gtk+ (che sono solo lgpl)

Cmq, da alcuni test, il sistema base di kde4 consuma il 30% in memoria rispetto al sistema base kde3! è da prendere un po' cn le pinze come sempre in confronti del genere ma sicuramente le qt4 hanno avuto migliorie anche sotto questo aspetto rispetto le qt3, cosa che ormai è rara da vedere! cmq si nota anche ad occhio, kde4 è bello veloce e reattivo nonostante gli effettini grafici

[cionci]

Programmare con le GTK+ è davvero un macello, sono di una verbosità assoluta. Le Qt sono da questo punto di vista sicuramente più "programmer friendly". Senza contare gli strumenti messi a disposizione da Nokia (vedi l'ottimo QtCreator).
C'è più o meno la stessa differenza che su Windows c'è fra programmare con le API Win32 e con la piattaforma .Net (gestione della memoria a parte).
Senza contare che le GTK+ da sole non coprono assolutamente tutto lo spazio di funzionalità offerte dalle Qt. Per fare quello che fanno le Qt per KDE, su Gnome c'è bisogno di libpango, gettext, libcairo, libpthread, expat/libxml, decine di system call per i socket, una decina di librerie diverse per la connessione ai DB e altro ancora. Tutto questo con documentazione eterogenea (a volte incompleta), con minor revision delle librerie che variano mediamente ogni 30 giorni, problemi di portabilità su sistemi non Linux o a volte anche fra sistemi Linux stessi.
Mi sembra evidente che i vantaggi di Qt siano notevoli per l'intera comunità, per i vecchi e per i nuovi sviluppatori.

I problemi nel passaggio di Gnome a Qt sono comunque immensi, quasi invalicabili:
- fossilizzazione degli sviluppatori su GTK+ e sul C (le Qt con il C non si possono usare)
- riscrittura completa do Gnome e di tutte le applicazioni (hanno avuto la bella idea di appoggiarsi direttamente a tutte le varie librerie senza fare una libreria wrapper che le raggruppasse tutte)

L'ideale sarebbe riscrivere le GTK+ tramite le Qt, sinceramente non ho mai esplorato le problematiche relative alla scrittura di una libreria C che fa da wrapper per una librerie C++, ma credo che non sia comunque semplice (anche la gestione degli eventi è completamente diversa).

[Torav]

Originariamente inviato da Barra

@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.

io uso le PyQt4 e francamente aveva dato un'occhiata (molto superficiale senza dubbio) alle pygtk e onestamente non mi sembra ci sia alcuna possibilità di paragone... le Qt integrano il 95% delle funzionalità che servono normalmente. Per le gtk ti devi scaricare classi aggiuntive per un sacco di roba

[Barra]

Molti programmatori dicono esattamente il contrario (Andrea Cimitan ad esempio ha messo mano al codice di KDE ed è scappato perchè la parte di gestione dei temi era un CASINO TREMENDO http://www.cimitan.com/blog/2008/02/...l-mio-oxygen/). In ogni post che si trova cercando "GTK vs QT" ci sono sempre 2 fazioni, ognuna che elogia le qualità della propria soluzione.

Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...
Con Monodevelop e Vala (se proprio non si vuole usare Mono) sviluppare in GTK mi sembra decisamente semplice!

Su mono mi sono già espresso, per me ci possono fare tutto il DE che (carte alla mano) non ci sono problemi, salvo un'eventuale porting su windows (dove invece restano problemi di licenze e brevetti per alcune parti del codice).

[cionci]

Originariamente inviato da Barra

Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...

Certo non è un punto a favore delle GTK+
Il problema c'è perché appunto:
- hai documentazione eterogenea e non sempre ben fatta
- devi stare dietro ai cambiamenti di tutte le librerie
- le modalità di utilizzo delle librerie non sono uniformi
- eterogeneità nei rilasci dei bugfix, nella politica di gestione dei bug e nei test
Sono tutti problemi a cui un programmatore che scrive un programma per un DE non si dovrebbe dover trovare a trattare.

Originariamente inviato da Barra

Molti programmatori dicono esattamente il contrario (Andrea Cimitan ad esempio ha messo mano al codice di KDE ed è scappato perchè la parte di gestione dei temi era un CASINO TREMENDO http://www.cimitan.com/blog/2008/02/...l-mio-oxygen/). In ogni post che si trova cercando "GTK vs QT" ci sono sempre 2 fazioni, ognuna che elogia le qualità della propria soluzione.

Nessuno ha detto che KDE sia migliore o sia più facilmente programmabile. Dipende anche dalle scelte dei progettisti.

[cionci]

Tra l'altro quello sopra è il motivo principale per cui Python si è diffuso su Gnome. Proprio perché a questi problemi poi ci deve stare dietro chi programma il wrapper per Python e non il programmatore. Insomma...è un modo dire: "A lavorare con le librerie di basso livello ci pensino gli altri".

Il problema in Gnome sta nel progetto iniziale. Studiato intorno alle GTK+ e con altre decine di librerie. Per KDE invece, oltre alle QT, le funzionalità aggiuntive sono state messe tutte in librerie mantenute dal progetto. E quindi abbastanza facile cambiare una dipendenza di queste librerie, mentre il programmatore che le usa di fatto non deve fare assolutamente niente.

E tutto questo lo dico da utente di Gnome, ormai da molti anni.

[ArtX]

Io trovo che le qt siano fantastiche, e poi ora sono. come già detto da altri, anche gpl e lgpl. Dunque l'unico vero vantaggio che ha favorito le GTK alle QT è stato superato.

Magari linux diventasse una piattaforma un pò più chiusa, con solo le qt come gui grafica (per kde però ci vorrebbe una rasatina ). ( ah ma ci sono solo loro nell'LSB ?).
E poi quà vi chiedete perchè non riscrivere gnome in qt?
cavolo ma dovete inventare la ruota 4 volte per fare un'auto???
non basterebbe usare le librerie di kde4, visto che ormai sono belle pronte e più stabili delle applicazioni che le usano, per fare il desktop secondo la loro filosofia, perchè le gtk dovrebbero servire a creare un desktop secondo la filosifia gnome... ah nò scusate un programmatore gnome è troppo razzista per poter usare le qt o le kdelibs.

Sulle GTK ognuno pensi quello che vuole, ma ormai sono a dir poco obsolete e a quanto pare hanno anche pochi sviluppatori. Le qt invece sono in ottima forma e sono anche molto più facili e potenti. Inoltre provate a usare un software QT4 e uno GTK su windows o macosx. Non esiste paragone!!!

E poi ora mono..... lol

[zephyr83]

Originariamente inviato da Barra

Molti programmatori dicono esattamente il contrario (Andrea Cimitan ad esempio ha messo mano al codice di KDE ed è scappato perchè la parte di gestione dei temi era un CASINO TREMENDO http://www.cimitan.com/blog/2008/02/...l-mio-oxygen/). In ogni post che si trova cercando "GTK vs QT" ci sono sempre 2 fazioni, ognuna che elogia le qualità della propria soluzione.

la gestione dei temi? e pensare che una volta era proprio il contrario ma questo cn le qt CHE C'ENTRA? nn si sta discutendo di gnome o kde ma di librerie!

Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...
Con Monodevelop e Vala (se proprio non si vuole usare Mono) sviluppare in GTK mi sembra decisamente semplice!

Ma anche io ho detto che nn è un grosso problema ma se parliamo delle librerie in se non si può negare che le QT siano molto più evolute e complete mentre le gtk+ devono compensare cn "parti" esterne! Cmq Cionci alcuni inconvenienti li ha elencati.

Su mono mi sono già espresso, per me ci possono fare tutto il DE che (carte alla mano) non ci sono problemi, salvo un'eventuale porting su windows (dove invece restano problemi di licenze e brevetti per alcune parti del codice).

il futuro ci dirà se la strada intrapresa è stata "corretta"