Ogni tanto capita a tutti di spararne una così grossa e improbabile che quasi suona geniale …e se succede ad un tipo come Cornelius Schumacher, alla guida di KDE e.V., rischia di diventare la storia del mese. Nella sua discussione in SocialBox, Jaicioth segnala infatti un articolo di Phoronix a proposito di questa idea di Cornelius:
We all love Qt, without it KDE wouldn’t exist. We also love the KDE development platform, it provides all that what Qt doesn’t have or didn’t have at some point in time. But is there still a real reason to keep them separate? Wouldn’t it be much more elegant, if you wouldn’t have to decide, if to use some KDE classes or write a “qt-only” application, if you would get all the wonders of KDE from Qt in one consistent way?
Unificare le librerie di KDE e Qt?! Respirate. Significherebbe un KDE 5 e forse anche un KDE 6, rottura di ogni traccia di compatibilità, dibattiti e polemiche infinite e soprattutto un immane lavoro; d’altra parte Phonon ha fatto esattamente questo percorso1… Sarebbe il modo più geniale che potrebbe escogitare KDE per assicurarsi un futuro in Symbian, MeeGo e nella tuttora sterminata base utenza di Nokia (cfr “Aspettate prima di dire che Nokia è morta…“).
Ah ma ecco un piccolo particolare: non sappiamo ancora come la prenderebbe Nokia ;)
Note all'articolo
- Originariamente creato come pilastro-libreria multimediale di KDE 4, è poi stato integrato nelle Qt [↩]
ah… quindi?
alcune cose si altre no … per i dettagli ci vorrebbero settimana di analisi immagino.
ottima idea
si dovrebbe fare.
se seguite un po’ il thread, noterete 3 tipi di commenti:
1) coloro che stanno prendendo l’idea seriamente, ed iniziano a discutere con esempi concreti dei pro (es: backportare a QUrl le funzionalità di KUrl) e dei contro (es: backportare kio aggiungerebbe una marea di dipendenze);
2) coloro che si lamentano riguardo a Qt e alla loro gestione chiusa delle patch, e che profetizzano problemi futuri rigurado al mantenimento del codice backportato da kde;
3) Thiago Macieira (l’uomo Qt) che, pur tenendosi fuori dalla discussione strettamente legata al futuro di kde, conforta gli animi sostenendo che dentro Qt sta facendo il possibile per realizzare una vera Open Governance.
Imho, per quanto la mail iniziale di Cornelius sia una boutade, la comunità di kde sta reagendo in modo piuttosto razionale valutando ciò che effettivamente è possibile guadagnare dall’idea.
Peccato che Phonon sia attualmente ‘deprecated’ e sostituito da QtMultimedia
QtMultimedia e QtMobility, già. Comunque Qt ha già preso da KDE, sia codice sia idee (l’ultima è QML, che non a caso verrà usato per riscrivere Plasma).
kde crea, altri rimaneggiano e successivamente kde reintegra.
è successo lo stesso per khtml -> webkit -> kwebkit e mi sembra che la comunità tutta ci abbia guadagnato, non solo kde! Se la filosofia di base è buona non è detto che lo sia anche la pratica…staremo a vedere!
In effetti non ho mai capito quale (e se) ci sia davvero un grosso bisogno di kdelibs. Personalmente io ho solo scritto piccoli programmi con GUI in linux, ma la scelta non è mai andata più in là di Qt: perché dovrei? Immaginiamo allora che chiunque scriva un programma in Qt scriva un programma che si integri al 100% con KDE (e non solo all’80%, come adesso). Secondo me sarebbe fico.
In quanto alla compotibilità direi che dei wrapper potrebbero far diventare il tutto abbastanza semplice…
A me piace come idea.
In realtà tante classi K* sono wrapper per le medesime Q* ;)
L’unica cosa che non si capisce è dove voglia andare a parare l’articolo,ho letto ottimi commenti ma all’articolo anch’io….e quindi?
Leggevo giusto stamattina su phoronix… beh, l’idea è un po’ azzardata ma di tutto rispetto. Staremo a vedere, io comunque io non vedo male sta cosa.
Io non ne capisco molto di programmazione, ma da profano mi sembrerebbe una buona idea… Si semplificherebbe il lavoro di scrittura delle applicazioni? Sarebbero portabili più facilmente su altre piattaforme? (ormai c’è un porting delle qt per tutto). E le prestazioni, migliorerebbero?
Se si, allora ne varrebbe la pena, è chiaro che magari sarebbe un lavoro molto complicato, ma alla lunga potrebbe portare molti vantaggi…
Ecco, a mio avviso questo è il principale motivo per cui KDE non sfonda! Sempre a rifare tutto da capo e non c’è mai niente di definito e/o definitivo!
Mmmh, completo l’intervento perché non voglio tirarmi addosso le ire di nessuno.
Intendo che a mio avviso dovrebbero prima creare qualcosa di stabile e perfettamente funzionale, in modo che KDE possa essere una valida e funzionale alternativa. Poi possono portare avanti qualsiasi altro discorso, ma devono mantenere sempre i piedi saldi a terra senza fare il passo più lungo della gamba.
Vedo male anche Ubuntu. Ultimamente stanno correndo un po’ troppo e la distribuzione è sempre meno stabile! Così non va bene! Allora preferisco la politica Debian: meglio avere qualcosa di meno ma ben funzionante, che tante chicche ma il sistema in palla.
E’ già tutto stabile e perfettamente funzionante……
In realtà, nel free software tutto è ”non-definitivo”, poi ok ci sono alcune cose che tendono a essere stabili a causa di tempi di rilascio molto lunghi (es: debian, gnome) e altri che hanno ritmi di sviluppo più incalzanti (es: ubuntu, kde). C’è sempre bisogno di qualcuno che tiri il carro dell’innovazione e qualcuno che segua più lentamente e in modo più stabile…
Senza contare che una release abbastanza stabile puó portare anche nuovi sviluppatori: lo usi, ti ci appassioni, trovi qualche piccolo problema e poi cominci a mandare pezze.
Ho usato KDE dalla versione 2.2 fino alla 4.4, circa 9 anni di utilizzo assiduo. Ho partecipato al GSoC con KDE come mentoring organization. E ora? Ora uso GNOME, da quando in KDE hanno deciso che condividere i plasmoidi in rete é piú importante di sistemare i memory leaks, che avere 3 RDBMS (MySQL per Akonadi, Virtuoso per strigi, MySQL embedded per Amarok) é piú importante di consolidare i sistemi di storage.
Certo, potreste anche dirmi “step up or shut up” ma ci sono talmente tante cose su cui dovrei metter mano che preferisco passare su qualcosa di piú conservativo che funziona (per me) qui e ora.
Beh cercando di vedere l’idea in modo razionale direi che:prima di tutto sarebbe un lavoro immane integrare le kdelibs dentro le qt perchè le kdelibs anche se sono scritte in maniera più astratta possibile si basano comunque su dei concetti propri dei sistemi *unix,come i file descriptor ecc e le qt come sappiamo sono multipiattaforma e già ora richiedono un immenso lavoro di manutenzione poichè hanno bug differenti su win,mac,linux,simbyan ecc quindi ingrandire di colpo il codice non è un idea da prendere al volo,detto questo bisogna anche calcolare che nokia magari non vuole farsi carico di tale responsabilità perchè ricordiamoci che è una azienda e come tale fa il suo business,quindi se da un punto di vista del marketing non gli conviene,non lo farà punto e basta e mi pare che di recente abbiano assunto un exCEO della microsoft(ihih) quindi non saprei,tuttavia l’idea è affascinante e darebbe una tale botta di vitalità al software Qt che diventerebbero le librerie multipiattaforma più usate al mondo sicuramente,d’altronde le tecnologie KDE sono cosa buona e son sicuro che molti programmatori su windows apprezzerebbero poter usare qt+phonon+KI/O+magari nepomuk e chissà cos altro,e per la comunità kde questo si tradurrebbe in una grandiosa visibilità per il loro software,ma….come già detto a me sembra fantascienza
Veramente anche le kdelibs sono scritte per essere multipiattaforma e infatti dipendono solo dalle qt, mica da X.org o altro. La prova e’ che KDE funziona anche su windows e su macos, seppur con qualche difficolta’ dovuta principalmente al fatto che il 99% degli utenti e’ su linux.
x la cronaca soprano e mysql sono dipendenze di kde
il 99% di kde funziona benissimo su windows e mac
LOL
Ecco, questa è la supercazzola dell’anno.
Questo signore deve essere ancora sotto i postumi di qualche Oktoberfest a cui ha partecipato. Praticamente vuole completamente snaturalizzare Qt, tanto a lui cosa gliene frega, evidentemente non lo usa al di fuori di KDE.
Pensateci, nemmeno gli sviluppatori GNOME, che sviluppano sia GTK+ che libgnome ed una serie di altri widget extra, si sognerebbero mai di unire queste librerie in un unico progetto.
Prima hanno rovinato KDE, adesso vogliono fare lo stesso con Qt. Spero che Nokia metta un freno alla loro pazzia.
Perche’ “rovinato KDE” ? In cosa ?
ho scritto la stessa cosa nella socialbox,
sono perfettamente d’accordo.
Secondo me Nokia farà ancora di più: li ignorera’.
LOL ma te lo immagini? Gente di KDE che rompe continuamente le scatole a quelli di Qt per includere questa o quella feature XD
A dire il vero questo è proprio quello che dovrebbe succedere in un sistema sano… che poi ci siano dei casi di software/distro (vedi ubuntu, anche se ultimamente meno) che se ne strafregano di portar upstream ok, ma questo non è il modo di migliorare il sistema…
LOL, ma te lo immagini?
Gente di Qt che prende feature da KDE e le reintegra, e un sacco di ex e non ex sviluppatori di KDE assunti da Nokia per sviluppare Qt XD
No aspetta…
ma perchè non vi levate il latte dalla bocca prima di parlare e connettete il cervello? Peraltro, di solito funziona che l’utilizzatore di un framework fa sempre richieste all’upstream.
Si, si, fallo e poi mi dici come va XD
Oddio…se in Kde ho bisogno di qualcosa lo metto in kdelibs non in qt…non credo che le qt siano li in funzione di Kde…servono anche ad altro…
Ehila’ Dcromato, finalmente sei passato a Pollycoke,
ormai nell’altro forum non ci parla piu’ nessuno.
Non sono passato, commento una volta ogni tanto.
E allora commenta piu’ spesso!
Passa anche tu a pollycoke!
GNAM
(bicchiere sull’altro forum, MAH sull’altro ancora)
Prima di dire certe cose e di deridere la gente, non sarebbe meglio leggere il post e qualche commento? Così, giusto da sapere di cosa si sta parlando e dei motivi dietro a questa proposta (che non sono correlati alla birra).
Fino ad ora qui ho letto commenti rispettabilissimi, condivisibili o meno ma rispettabili.
E chi non conosce l’argomento o non è programmatore ha saggiamente e correttamente detto, “non mi esprimo, cosa significa? è una cosa buona o no?”.
Poi invece arrivano commenti come questi dove si apre bocca, pardon lasciare andare le dita sulla tastiera, giusto per il gusto di farlo, il tutto contornato da una sana dose di ignoranza e sproloquio gratuito.
A te non piace KDE? Bene, io me ne faccio una ragione e tu te ne fai una ragione. O non esisterebbero DE diversi.
Perché ti dico questo? Perché il tuo commento non è dettato da una logica conoscenza di ciò che si parla ma da una irrazionale voglia di buttare fango su KDE sol perché non ti piace.
Da cosa deduco questo? Semplicemente perché dovresti sapere che, molti sviluppatori KDE lavorano per Qt, molti non lavorano ma ne sono sponsorizzati, molti lavorano proprio sulle Qt e le Qt attingono a piè pari a KDE. Non a caso molti aspetti di KDE nella storia delle Qt sono sempre stati inclusi nelle librerie.
Inoltre vorrei ricordarti, ma forse non lo sai, che KDE non è più un DE ma un framework, un insieme di librerie dove uno dei suoi progetti è un Desktop Environment.
Cosa vuol dire questo? Che anche se fosse, non significa che includeranno KDE (come tu lo immagini) nelle Qt ma ne condivideranno una libreria fondamentale con modi e maniere da negoziare, sempre se la cosa si farà mai.
@Mourinho
Ti voglio rispondere perché il tuo commento mi ha rallegrato la serata, grazie. Ogni tanto è divertente vedere l’ultimo arrivato dare dell’incompetente agli altri.
Secondo te fare una merge fatta di tanto in tanto su software proveniente da due progetti diversi (cosa che accade molto spesso, anche in GNOME) ha la stessa valenza dell’unire i progetti stessi?
Secondo me no.
Se penso ad un Qt “KDE-oriented” mi vengono i brividi. Ovviamente mi verrebbero anche se pensassi ad un GTK+ “GNOME-oriented”.
PS. L’unica cosa sensata che possono fare è cercare di far dipendere KDE il meno possibile da componenti esterne a Qt. Ma anche in quel caso esisterebbe comunque un “kdelibs”, anche se minimale, perché il progetto ha un obiettivo diverso da quello di Qt.
Non sono Qt “KDE-oriented”. Si parla di integrare alcune parti fondamentali in Qt, cosa che è già in parte avvenuta. Forse questa commistione può suonare male, ma potrebbe risultare meno sgradevole se pensi che dietro alle QT ci sono 130 persone stipendiate che fanno commit a tutto spiano :D
Frafra, quello che dici ha perfettamente senso, ma è già molto diverso da quanto espresso da mr. Schumacher.
Lascia perdere, doveva rallegrarsi la serata e lo ha fatto.
Anzi l’ha ri-allegrata a me confermando quanto ho già espresso nel commento precedente.
Non sa di cosa sta parlando visto che *nell’eventualità remota* non si tratta di fare delle Qt KDE-oriented ma condividere la stessa libreria invece di fare doppio lavoro.
Ma forse non ha nemmeno chiaro che KDE non vuol dire il Desktop, questo ora è solo uno dei progetti.
>Secondo te fare una merge fatta di tanto in tanto su software proveniente da due
>progetti diversi (cosa che accade molto spesso, anche in GNOME) ha la stessa
>valenza dell’unire i progetti stessi?
>Secondo me no.
>
Se fossi stato più attento, sottolineavo che è paradossale dire rovinare KDE (ma rovinare cosa? il Desktop Evinronmet? Non centra niente con questa storia) quando più di cento persone stipendiate da Qt fanno commit da una vita. Vuol dire che sanno quel che fanno.
Quando parli che hanno rovinato KDE a cosa ti riferisci?
Anche io mi chiedevo cosa vuol dire rovinare KDE, dato che si è stabilito che KDE è una comunità _di persone_ -.-
ma….mi sembri che si stia un pò snaturando il discorso principale, lo dico nel modo più ignorante possibile da ultimo arrivato eh…
Non è l’unione di due progetti qualsiasi presi a caso, non è l’unione di un DE con una libreria grafica (come sarebbe tra gnome e gtk+). kdelibs è tecnicamente un “estensione” delle funzionalità di qt per KDE. Quindi non è che siano così aliene rispetto al progetto genitore, anzi in passato, come hanno detto più persone, più parti di kdelibs sono confluite in qt. Quindi non si parla di fondere kde e qt, ma di riunire una estensione di librerie nella libreria madre che continua a prendere funzionalità in ogni caso praticalmente da sempre. Il discorso è molto meno stralunato così
Vedi Darkat, tu dici di essere l’ultimo arrivato ed hai inquadrato la situazione mentre PD questo non l’ha ancora capito!!!
Purtroppo fa il grosso errore di associare le due cose come tra Gnome e le GTK quando invece KDE non è un DE ma un insieme di cose che tra le tante possono *costruire* un DE.
kdelibs ne rappresenta una delle tante parti.
Potevo capire la sua preoccupazione se si trattava di unire il workspace di KDE alla struttura delle Qt ma qui si parla d’altro.
bah mi sono stancato di ripetere le stesse cose
“Ovviamente mi verrebbero [i brividi] anche se pensassi ad un GTK+ “GNOME-oriented”.”
Pronto?
http://live.gnome.org/ProjectRidley
http://live.gnome.org/LibgnomeMustDie
http://library.gnome.org/devel/gio/stable/
Cosa? Il progetto Ridley cerca di far entrare più parti possibili dell’implementazione corrente di libgnome in GTK+ 3.x, non di far sparire libgnome.
Symbian è “morto”, stando a Nokia. Non ne sentirò la mancanza e dovrebbe favorire MeeGo. A me non dispiacerebbe la convergenza… ma, al momento, m’interesso più al caso Unity/Qt (e KDE). Devo tradurmi la digressione di Graesslin dal tedesco.
Symbian non è morto, sei uno di quelli che ha letto una di quelle notizie dei blogger strafatti che hanno confuso l’annullamento del numero di versione del sistema con la cancellazione del sistema stesso? Capisco che sono finlandesi ma il comunicato era in comprensibilissimo inglese
L’importante è che, una volta fatto il merge di KDE in QT, non si proceda in un fork di QT in un ipotetico “KDE-fork”!
non è il merge di KDE con QT ma KDElibs con QT, non è la stessa cosa
Vera la nota di Darkat, comunque consordo con Minkiux… spero non ricapiti quello che è successo con KHTML che è andato avanti fino a kDE 4.4 (compreso) quando da oltre un anno QWebKit lo superava in tutto….
Qualcuno spiega anche a noi, che fino a 5 minuti fa pensavamo che KDE e Qt fossero sinonimi, il significato di questa notizia? per favooooreeeeee
Qt è un toolkit grafico, ovvero una serie di librerie che permette di “disegnare” interfacce grafiche.
KDE SC è un ambiente desktop, ovvero un set di programmi che gestiscono lo sfondo, il menù, la posta, l’audio, ecc, che sfruttano le capacità delle Qt.
KDE SC: “ciao Qt, ci sei?”
QT: “si, dimmi”
KDE SC: “ho bisogno di disegnare una finestra che permetta di cambiare l’ora, fatta in questo modo: […]”
QT: “ok, l’ho appena mostrata all’utente ;)”
Senza offesa ma preferisco correggere.
Qt4 _non_ e’ un toolkit grafico, Gtk+ e’ un toolkit grafico.
Qt4 e’ un Framework C++ completo e modulare. Il toolkit grafico si chiama QtGui4.
Qt4 ha anche altre cose oltre l’interfaccia utente grafica:
– Multimedia
– Network
– Xml
– Animazioni
– Macchine a stati
– etc…
mentre KDELibs e’ un ‘miglioramento’ ( tra parentesi perche’ non sono tanto convinto ) di Qt4,
per integrare funzionalita’ che non sono presenti nel Framework di Nokia.
Funzionalita’ che per adesso il team di KDE deve mantenersi da sole.
( In alcuni casi a Qt sono piaciute le funzionalita’ aggiunte dal team KDE e se le sono assorbite )
Riassumendo.
KDE = Ambiente Desktop
KDE Team = Tipi che sviluppano KDE
KDE Libs = Librerie C++ basate sul framework Qt che sono le fondamenta di KDE
Qt = Framework C++ che e’ la fondamenta di KDE Libs
Il grosso problema di integrazione tra KDE Libs e Qt e’ la gestione non open del workflow di Nokia. In pratica solo pochi eletti possono scrivere codice Qt e fare commit upstream, quelli di KDE per adesso non hanno potere decisionale sulle Qt.
In realtà:
KDE SC = KDE Software Collection = Codice
KDE = Comunità di gente che sviluppa KDE SC
Fai bene a correggere. Sono stato volutamente impreciso. Volevo solo fare notare che i programmi di KDE stanno sopra e le QT sotto, in maniera molto facile e comprensibile. Non volevo addentrarmi nei particolari, dato che mi pare che donpiero non abbia conoscenze in proposito.
Ti ringrazio per l’esauriente spiegazione :)
boh, sempre a disquisire di “massimi sistemi” e intanto ai particolari da mettere a posto non pensa nessuno.
Tantissimi, in KDE, lavorano sulle KDELibs, se queste si alleggerissero o venissero meno, ci sarebbero più ‘ore-sviluppatore’ disponibili anche per i particolari…
Vero, inoltre credo che il maggior vantaggio unificando KDELibs a Qt sarebbe attirare un sacco di sviluppatori Qt ( tipo me ) verso KDE.
Io ad esempio non conosco ( mai utilizzato ) KDELibs, mentre utilizzo molto le Qt, anche in ambito lavorativo.
Vero, e non scordiamoci che la documentazione delle Qt + fatta molto bene (ed è anche possibile trovare dei libri ‘di terze parti’) mentre la documentazione delle KDELibs è molto più ‘casuale’ e non esiste nessun libro da ‘terze parti’, quindi anche cominciando, le Qt sono più semplici delle KDELibs, da imparare ;)
straquoto
e cosa centra questo con l’unificazione di KDELibs con le Qt?
KDELibs è una cosa, il DE è un’altra cosa.
KDELibs non è il DE ma una libreria di cui il DE ne fa uso.
Anzi, al più, come si è detto, si potrebbe riuscire a ricavare più tempo per le “piccolezze” ma questo è solo un plus al discorso.
Non si parla di mettere un DE nelle Qt ma unificare due librerie dove già quella di KDE è l’estensione della Qt.
Per affrontare quest’argomento bisogna tenere ben saldo in testa che il DE di KDE non centra nulla e che bisogna guardare a KDE no rispetto al DE ma a cosa c’è sotto.
KDE non è un Desktop Environment…quest’ultimo ne è solo un suo progetto, il più importante ma è solo un suo progetto!
Come Qt ti permette di sviluppare sfruttando la sua tecnologia, lo stesso fa KDE. Visto che sia Qt che KDE si “scopiazzano” a vicenda e si interscambiano codice Schumacher ha azzardato una proposta che più che altro è un accenno di discussione, se unissimo le parti che più sono simili per evitare questo doppio lavoro? Si potrebbe fare?
Qui si parla di librerie, di infrastrutture non di DE.
Mourinho, per fortuna che qui c’è almeno una persona che sa di cosa parla (insieme a daniele).
Parlando di cose serie, il merge qt4/kdelibs potrebbe portare alcuni effetti molto positivi verso entrambe le parti. Il problema però è che nokia improvvisamente si ritroverebbe a dover gestire ufficialmente una quantità immensa di codice e sinceramente non credo questo possa accadere. Ci vorrebbe una forza lavoro “stipendiata” fin troppo grande, troppo anche per Nokia. Considerando che aumenterà il livello complessivo di righe di codice, aumenteranno per statistica il numero di bugs, casistiche da gestire, documentazione da aggiornare.
Personalmente non credo Nokia abbia la volontà nel fare una cosa del genere. Vedo più vantaggi per KDE che per Nokia :)
beh le qt sono un progetto opensource in piena regola quindi oltre agli spipendiati c’è anche la communità che ci lavorerebbe e quella di KDE è abbastanza grandina. In ogni caso il team di KDE è formato anche da vari sviluppatori di famose distribuzione che potrebbero collaborare benissimo con Nokia per realizzare un progetto che aiuterebbe entrambi. Non sottovalutiamo il potere aziendale di nokia che ha dato uno spintone decisamente grande sia all’opensource che alle qt, infondo le funzionalità di kdelibs sono belle utili: parlando proprio in via futuristica e fantascientifica secondo poter costruire una sorta di nepomuk-strigi per i cellulari sarebbe fantastico e utilissimo e perchè ricominciare da capo quando ci sono quelle librerie che possono offrire fior fior di gioie? sarebbe da valutare in base a cosa realmente Nokia vuole realizzare con le qt
>Mourinho, per fortuna che qui c’è almeno una persona che sa di cosa parla (insieme a daniele).
>
Sarcasmo? Non ti sto provocando ma non ho veramente capito. :-)
Per quanto riguarda il tuo discorso, penso pure io che difficilmente il merge si possa realizzare a meno che non venga affidato il totale controllo della libreria a Nokia (Qt) ma questo prima o poi porterebbe ad un’altra estensione non appena qualche idea funzionale a KDE (non il DE, lo ripeto all’infinito) non sarà recepita.
A meno che Nokia e KDE non sposino in toto la stessa causa (che ripeto ancora non è il DE altrimenti qui si incominciano a dire sciocchezze derivanti dalla stupida guerra Gnome vs KDE SC), cosa che nel breve tempo potrebbe risultare fattibile ma alla lunga non so.
Dopotutto a Nokia sta bene rimanere così, c’ha un pozzo (KDELibs) da cui attingere non appena ne ha di bisogno senza preoccuparsi di gestirlo, ma solamente sovvenzionarlo con donazioni.
Pingback:Nokia. Connecting KDE. | pollycoke :)