Vývojáři KDE diskutují o sloučení knihoven s Qt

Hlavní vývojáři KDE diskutují o možnosti sloučení knihoven KDE s Qt. Motivací je obousměrný prospěch z tohoto kroku. Knihovny KDE přitom mnohdy jen doplňují to, co v Qt zrovna chybí nebo chybělo. Operace by však byla náročná a pokud by se uskutečnila, tak až v nějaké z příštích generací KDE. Více na Phoronixu.

2.11.2010 07:28 | Luboš Doležel (Doli) | Zajímavý projekt

Komentáře

[Marián Kyral]

Jé to zase bude voda na mlýn těm, co neustále tvrdí, že pro běh qt aplikací je potřeba celé KDE (nebo KDE SC?). Teď budou mít konečně částečně pravdu

[kralyk z abclinuxu]

No to snad ne...

[Josef Kufner]

Zachovej klid. Úplně všecko sloučit nemohou. Ale třeba různé vylepšené widgety je blbost udržovat mimo.

[Rezza]

Asi tak - spousta vylepseni kdelibs jsou jen drobne zmeny, ktere ale delaji samotne Qt o hodne lepsim, trebas KIO by byl mazec v Qt a spousta dalsich. Ono se to vlastne i postupne castecne deje to slucovani automaticky - ala Phonon, nez zasahla vyssi moc, teda Nokia.

[kralyk z abclinuxu]

Ale třeba různé vylepšené widgety je blbost udržovat mimo.

Proč? Kdo chce ty vylepšený widgety používat, ať si je stáhne odněkud jinde. Není důvod, proč by měli jít do Qt. Pokud budou v Qt chtít svoje widgety vylepšit, udělají to.

Já teda rozhodně nechci kdelibs-garbage v Qt...

[imploder]

Taky mi připadá lepší, když je to modulární, než jeden velký kolos. Pak se dají knihovny přiložit k aplikaci a dodávat s ní. Řeknete si jako linuxáci: ale fuj, všechny závislosti ať řeší a instaluje z repozitářů balíkovací systém; no jo, ale ve Windowsech nic takového není, tak se to řeší takhle: knihovny se přibalí k aplikaci. Ono je s tím nakonec často míň otravování než v Linuxu i s vymoženostmi balíkovacího systému, v případě že v repozitářích není všechno, co je potřeba.

Ale ne zase nějak extrémně modulární, prostě tak akorát.

[kralyk z abclinuxu]

Na linuxu bych to viděl takhle: Knihovny, které můj program používá, se dají víceméně (fuzzy) rozdělit na dvě skupiny: Ty co jsou běžně používané a ty obskurní, které používá akorát můj program a pak ještě jeden někde v mongolských stepích. Ty první nalinkuju dynamicky, v repo určitě budou. Ty druhé staticky, protože dynamicky by to ničemu nepomohlo, akorát by to mělo overhead.

[imploder]

Kromě toho, že se ušetří místo, má sdílení knihoven i další výhodu: nějaká funkcionalita (zajišťovaná knihovnou) se ve všech aplikacích aktualizuje najednou. Takže je to dobré pro bezpečnost.

Dá linkovat i dynamicky s tím, že .so nebo .dll přibalím k aplikaci. Je to asi lepší v tom, že když se knihovna vyvíjí odděleně od aplikace a vyjde nová verze s opravou např. bezpečnostní chyby, ale jinak kompatibilní se starou, tak ji uživatel může nahradit bez toho, aby si instaloval novou verzi aplikace a autor aplikace o tom ani nemusí vědět. Samozřejmě tohle 99 % běžných lidí nevyužije (už proto, že se v tom nevyznají, ale taky proto, že se nemají čas a náladu se o to zajímat), ale IMHO není špatné takovou možnost mít. Kde to nedává smysl je v případě, že knihovna je speciálně pro tu aplikaci a pro každou novou verzi bude mít ta aplikace aktualizaci.

[kralyk z abclinuxu]

No ve světě open-source je hezké to, že můžu stejnou věc udělat i se statickým linkováním. Prostě program překompiluju oproti nové, ale kompatibilní verzi knihovny

[Mandarinka]

Kromě toho, že se ušetří místo, má sdílení knihoven i další výhodu: nějaká funkcionalita (zajišťovaná knihovnou) se ve všech aplikacích aktualizuje najednou.

Nebo se funkcionalita rozbije ve všech aplikacích najednou :D

[Ivan]

JJ, namatkou me napada, ze treba combobox z KDE3 kterej jsme pouzivali v Tore mnohem lepe resil situaci kdy v nem byly stovky polozek. Mel dole klikatno na "next" a dalsi hodnoty zobrazil v dalsim sloupecku.

[Jardík]

Pokud vím, tak KDE je pod GPL, Qt pod LGPL, tj. 2 nekompatibilní licence. Všichni vývojáři a přispěvatelé do KDE (i dávní) by museli souhlasit s přelicencováním. A aby Qt zase podělali a přelicencovali na GPL, to bych musel někoho nakopat.

[Michal Vyskočil]

Qt pod LGPL

Qt je hlavně pod mrakem dalších licencí, včetně closed-source.

[Saljack]

A není náhodou Qt pod LGPL a GPL viz licence?

[Semo]

Aj keby bolo, tak by to znamenalo, ze by potom existovala obohatena GPL Qt a povodna LGPL Qt. Takze by sa vlastne premenovala kdelibs na gpl-qt a to by bolo vsetko.

[Jardík]

Jenže to kdelibs nemůže (?) protože by s tím museli souhlasit všichni, co tam přispěli. Honem jim jdu poslat nějakej jednořádkovej patch na triviální věc a pak to budu blokovat a sabotovat

[Saljack]

Proč by jako nemohla? GPL a GPL nevím co vidíš za problém.

[Rezza]

Vetsina (mozna vsechny) knihoven je pod LGPL.

[Jardík]

Knihovny KDE jsou pod GPL.

[hanzz]

kdelibs jsou pod lgpl a o ty prave jde

[Rezza]

Aplikace KDE jsou pod GPL.

Pekna a prehledna tabulka

[Jardík]

Aha, tak to se omlouvám, já měl za to, že KDE (knihovny i aplikace) byly a jsou pod GPL.

[pavlix]

Pokud vím, tak zdrojáky KDE byly vždycky pod LGPL.

[Neel]

Byl by mi někdo ochotný vysvětlit, proč je KDE rozděleno na obsáhlé balíky (kdebase, kdelibs,...) místo toho, aby byl napříkrat kwrite aplikace sama o sobě, která by závisela na ostatních KDE knihovnách (asi jak to je všude jinde)?

[Jiri]

V Gentoo to tak je. Máme balík kde-base/kwrite.

[Jardík]

V Arch Linuxu to tak je, v OpenSUSE to tak je, v Mandrivě to tak je, v Ubuntu to tak je ... pokud se např. podíváte do PKGBUILDu Arch Linuxu (obyčejný shell skript), tak zjistíte, jak to kompilovat a mít to taky tak (pokud jde o váš případ).

[Marián Kyral]

V gentoo je takto rozděleno i qt. Největší opruz je, když pak musím kvůli jedné malé aplikaci stahovat celý velký balík, navíc to rozbalení taky není hned.