Luboš Luňák odpovídá

7. 12. 2006 | Redakce

Články - Luboš Luňák odpovídá  

Vývojář KDE Luboš Luňák odpovídá na dotazy čtenářů abclinuxu.cz. Patnáct otázek, patnáct odpovědí.

1) Myslím, ze v minulém rozhovoru padla zmínka o tom, ze než zahodit KWin a nahradit ho Compizem, bylo by lepe začlenit akceleraci desktopu primo do KWin. Dočkáme se toho už v KDE4?

Jistě, možná už v KDE 4.0 :). Tedy, i celkem vážně. Z KDE4 dáreček k letošním Vánocům nebude, ještě to bude nějakou dobu trvat a kwin_composite by měl být za pár měsíců už celkem připravený. Vlastně spíš záleží na tom, kdy se začnou řešit drobné problémy a podobně, které se teď ještě víceméně ignorují, svým způsobem je kwin_composite už použitelný i teď. Takže nejspíš se někdy kwin_composite přesune z vlastního SVN branche přímo do KDE4 a bude se připravovat na KDE 4.0 spolu se zbytkem, s vlastnostmi, které tou dobou budou hotové. Už teď jsou nějaké základní věci, teď jsem třeba udělal lupu, nejspíš to nebude mít první poslední jako Beryl, ale na druhou stranu, kdo opravdu potřebuje okno, které shoří?

2) Jak to vypadá s časovým harmonogramem pro KDE 4, resp. protože ho lze očekávat zřejmě nejdříve koncem příštího roku, bude-li ještě KDE 3.6 a co by se v něm mohlo očekávat?

KDE 3.6 plánováno není. Původně ani KDE 3.5 neměla být opravdu další verze, mělo se pracovat na KDE4 a v KDE 3.5 se mělo tak maximálně pracovat na opravách a aplikacích, no a takhle to dopadlo. Mít KDE 3.6 by jen zdrželo KDE4 ještě víc. Ještě bude KDE 3.5.6, zase s opravami a možná pár malými novými vlastnostmi, stejně jako to bylo u všech KDE 3.5.x, možná budou později ještě další 3.5.x verze, ale práce se soustřeďuje na KDE4. Kdy přesně KDE 4.0 bude, opravdu nevím, prostě zhruba tehdy, až bude. Příští rok vypadá jako dobrý odhad :).

3) Někde na webu jsem viděl návrhy na novinky do KDE 4. Zaujala mě myšlenka instalátoru univerzálních tar.gz balíčků, kdy člověk nemusel absolvovat proceduru "./configure" "make" "make install". Chápu, že je to věc ryze kosmetická, ale objeví se tento jakýsi "graficky instalátor" v novém KDE? Pro spoustu "nováčků" v mém okolí by to bylo velice příjemné.

KDE projekt dodává pouze zdrojové kódy, jakékoliv binárky jsou od "nezávislých" poskytovatelů. Krom toho, nevidím důvod, proč zrovna KDE by mělo řešit instalaci, to je věc distribucí (a nebo toho už dostatečného počtu jiných projektů, které se něco takového snaží vytvořit). Ony návrhy na novinky byl nejspíš nějaký seznam, kam si každý mohl plácnout, co ho zrovna napadlo. Na druhou stranu, protože KDE obsahuje to, co pro KDE někdo vytvoří, tak zase to nemůžu úplně vyloučit, ale pochybuji.

4) Měl bych zájem finančně podpořit vývoj KDE/KOffice (které ve verzi 1.6 velice slušně dospělo). Napište, jaké jsou zvyklosti sponzorování.

Na http://kde.org/support/ jsou obecné možnosti podporování KDE. Obvyklou formou finanční podpory je přispění KDE e.V., což je organizace zastřešující KDE pro oficiální účely. Ta potom financuje různé aktivity KDE. KOffice má přímo svou stránku o podpoře na http://koffice.kde.org/support.

5) Asi sa opýtam úplne mimo, ale bude/je Cairo integrované do KDE?

Není a minimálně zatím to ani moc nedává smysl. Qt má vlastní grafický engine (Qt4 má nový, nazvaný Arthur), takže nepotřebuje tuhle funkcionalitu z nějaké jiné knihovny. Navíc, vzhledem k tomu, že v současné době Arthur převyšuje Cairo v kvalitách (jako třeba rychlosti), tak by použití Cairo vlastně vedlo ke zhoršení. A i tak by pořád musela zůstat alespoň část Qt kódu, konkrétně API, protože to by Trolltechu rozhodně neprošlo nechat používat vývojáře přímo API Cairo. Jednoduše řečeno, zatím použití Cairo by vůbec nestálo za to. Jestli to jednou za to stát bude, tak se Cairo může stát dalším backendem pro Arthur.

6) Ako napreduje konvergencia a integrácia desktopových prostredí? Na čo sa môžeme tešiť v budúcom roku? Sú už nejaké "hmatateľné" výsledky projektu Portland? Na čo sa máme tešiť?

Jediným hmatatelným výsledkem projektu Portland je zatím vydání verze 1.0 xdg-utils. S tím těšením bych to bohužel tak moc raději nepřeháněl, jde to celkem pomalu. Takovéhle věci povětšinou nestojí tak vysoko na stupnici důležitosti a málokdo zajde dál než za nadšené očekávání toho, až to tedy bude.

7) Na GNOME fóre sa objavila požiadavka lepšej integrácie desktopu s používateľskými dátami, napr. mailovou schránkou, spamfiltrom, adresárom, PIM a podobne, takže by teoreticky používateľ mohol kedykoľvek zmeniť aplikáciu, a dáta by putovali s ním (bez potreby bolestivých importov, exportov, nastavovaní apod.). Uvažuje sa o niečom podobnom v KDE, prípadne nebodaj už sa na tom pracuje v koordinácii s GNOME komunitou, aby vznikol jednotný štandard? V konečnom dôsledku by to prinieslo nielen väčšiu slobodu v zmene aplikácie, keď mi súčasná prestala vyhovovať, ale dokonca aj v zmene desktopu.

Pro KDE4 se pro KDEPIM pracuje na technologii zvané Akonadi, což by mělo tohle řešit. Akonadi má být nezávislé na KDE (a tím použitelné i pro GNOME), co vím, tak GNOME vývojáři byli přizváni, ale jaký je přesný stav, nevím.

8) Bude akcelerácia v novom KWin pre KDE4 rýchlejšia a efektívnejšia, ako je tomu napr. v projekte Beryl či Compiz? Bude tu kompatibilita medzi témami s projektom Beryl či Compiz? Do akej miery bude KWin konfigurovateľné (aké nastavenia budu k dispozícii pre používateľa)? Bude KWin dostupný v testovacej verzii ešte pred príchodom KDE4?

Žádná akcelerace není :). To je zavádějící název, jestli to něco je, tak spíš decelerovaný desktop (a nemá to nic společného s tou zeleninou). Kompozitní desktop je víceméně navíc přidaný jeden krok při vykreslování, takže alespoň pro současný desktop to nemůže být rychlejší. Akcelerované je ono vykreslování, takže je tyto efekty možno udělat rychleji než bylo doteď (resp. je vůbec možné je udělat), některé věci by po přepsání pro kompozitní desktop mohly být i skutečně rychlejší, ale obecně kompozitní desktop přidává nové vlastnosti, ne novou rychlost.

Co se týká kompatibility, opravdu nevím. Velmi pravděpodobně bude alespoň základní kompatibilita mezi kompozitními správci, stejně jako je teď mezi správci oken (tj. window managery, jak říkáme my latiníci). Sdílení čehokoliv víc je otázka, na kterou odpověď je nejspíš "pokud to bude stát za to", což si myslím, že nejspíš nebude. Pokud se nepletu, tak už ani teď nejsou Compiz a Beryl úplně 100% kompatibilní, a to mezi sebou nemají žádné zásadní rozdíly v architektuře, jakou má vůči nim KWin.

Kompozitní KWin má v současné době vlastní SVN branch kwin_composite a testovací verze jsou dostupné zhruba stejně jako KDE4, tj. přelož-si-sám. Pokud někdo udělá testovací binárky KDE4, je možné, že udělá postupem času i pro kwin_composite, je v plánu někdy později začít dělat nějaké pomocí openSUSE build service. Do té doby, pokud se někomu to nechce překládat a vidět, že to toho stejně tak moc zatím neumí, tak asi zbývá jen sledovat, jestli se v mém blogu neobjeví nějaký nový obrázek. Konfigurovatelnost bude klasicky ve stylu KDE, ano, ale zase ne až v tom šíleném rozsahu, jako to má Beryl.

9) Půjde nadále KDE svou vlastní cestou ovládání a rozšiřování GUI, nebo se chce přibližovat MS systémům? Stále tvrdím, že Windows neumí s okny pracovat tak dobře jako KDE (i GNOME), tak doufám, že to vydrží.

Musím se přiznat, že tahle otázka mě trochu mate :) . KDE vypadá tak, jak si vývojáři KDE myslí, že vypadá nejlépe (což, pravda, občas dopadne všelijak :) ). Pro KDE4 jsou v plánu nějaké usability změny, ale rozhodně pořád je plán být KDE a ne něco jiného.

10) Četl jsem, že KDE 4 bude běhat mimojiné i pod Windows, myslí se tím celé KDE, nebo jen některé programy? Jak se bude KDE integrovat do Windows - bude i port KWinu, nebo správa oken zůstane klasická jako ve Windows?

Programy. Nevidím moc smysl v portování desktopu KDE pro Windows, navíc ani nevím, jestli je to vůbec možné (třeba KWin nemůže fungovat bez X11).

11) Strašně se mi líbí KDE, jak se snaží komplexně řešit desktop. Zajímalo by mě, jestli v novém KDE přibude aplikace typu snímání obrazovky do OGG Theora. Dále mě zajímá, jak by bylo možné integrovat do Konqueroru podporu prohlížení nějakých CAD formátů, třebas dxf, adt. Bylo by to zajímavé z hlediska použití KDE pro konstrukční firmy.

O aplikaci na snímání obrazovky nevím, také by se mi hodila na kwin_composite ;). Podpora pro další formáty do (nejen) Konqueroru samozřejmě jde. Pro samotné prohlížení by se musela vytvořit nová komponenta pro KParts, pro metainfo by byl potřeba nový KFileMetaInfo plugin a pro náhledy ThumbCreator plugin.

12) Bude konečně možné zřetězení kio_slaves, tak abych si mohl otevřít ZIP archiv zabalený v TAR archivu, nebo otevřít ZIP archiv na sdíleném samba disku, smb://xxxx/yyyy.zip#cosi.doc?A ještě příjemnějším překvapením by byla integrace s FUSE. Kio_slaves by pak bylo možné volat i z ne-KDE aplikací, což v současné době dělá problémy. Například si otevřete ZIP v Konqueroru, kliknete na ODT soubor, ale OpenOffice.org ho nedokáže otevřít, protože zadanému URL zip://xxx/yyyy.odf prostě nerozumí. Nebylo by výhodnější používat pro všechny archivy jeden kio_slave? Nechystá se užší spolupráce s Krusaderem? Jejich krarc kio_slave podporuje zápis do vícero druhů archivu než standardní kio_slaves (tar, zip) v KDE.

Nevím. Řetězení kioslaves je KDE bug #73821, má docela dost hlasů, ale to nemění moc na tom, že to někdo prostě musí naprogramovat, aby se to stalo skutečností. Nahrazení kioslaves pomocí FUSE není možné, protože FUSE nevyhovuje všem požadavkům (je třeba jen pro Linux a FreeBSD myslím), viz KDE bug #75324, spolupráce by možná mohla být, ale nevím, jak by to bylo technicky, a opět, někdo by to musel považovat za tak důležité, aby to napsal. Konkrétně v tomhle příkladu s OpenOffice.org je ale problém v tom, že OOo rozumí některým URL, ale ne tomuhle. Kdyby existoval standardní způsob, jak zjistit, které druhy URL aplikace podporuje, KDE by ostatní URL řešilo pomocí dočasných souborů, stejně jako už se to děje pro aplikace, které URL neumí žádné.

Co se týká spolupráce s Krusaderem, myslím, že ta otázka je v spíš nepochopení situace. KDE projekt není nějaká magická bytost, která kdesi tajuplně vytváří software, je to skupina lidí, kteří se rozhodli ke KDE připojit a vytvářejí ho. Cokoliv v KDE se stane tak, že se někdo rozhodne na tom pracovat, připojí se ke KDE a vytvoří to, nijak magicky se to samo od sebe neudělá. Jediný způsob, jak může KDE spolupracovat s Krusaderem, je ten, že Krusader bude spolupracovat s KDE. Jak by se měl kioslave z Krusadera dostat do KDE jinak, než že jeho vývojáři (Krusadera) ho dají do KDE a budou se o něj starat?

Ze stejného důvodu jsou i některé další moje odpovědi tady "nevím, někdo to musí udělat". Ano, bylo by moc hezké mít v KDE řetězení kioslaves, aplikaci pro snímání obrazovky, standardy na tohleto nebo tamhleto a tak dále, ale jen chtít to samo o sobě nestačí. Bohužel je to tak. Obzvlášť v dnešní době, kdy počty uživatelů znatelně převyšují počty vývojářů a doba "Chceš to? Tak si to naprogramuj, dokumentace je tamhle" už je víceméně pryč.

13) Chcem sa spýtať, či sa plánuje nejaká zmena k lepšiemu v oblasti inštalovania nových štýlov a okenných dekorácií. Súčasný stav je dosť neintuitívny, kedže treba stiahnuť zdrojové kódy a prekompilovať ich.

Styly a dekorace jsou programy (resp. pluginy) jako každý jiný. I programy je třeba stáhnout a překompilovat. Nebo, samozřejmě, se stejně jako u jiných programů dají použít připravené balíčky, takže je prostě potřeba sehnat balíček. Možností by bylo i kdyby existovaly styl a dekorace, které by měly vzhled měnitelný jen pomocí pixmap, ale o ničem takovém nevím.

14) V KDE 4 nebude DCOP, nahradí jej DBUS. Mám ve svém programu kód, v němž DCOP využívám. Chtěl bych vědět, zda můj skript bude fungovat v KDE 4, nebo jak to provést bez DCOP (progress bar např.).

Sám od sebe fungovat nebude, když nebude žádný DCOP. Možnost je přepsat skript tak, aby místo nástroje dcop používal qdbus, většina volání má jen změněný zápis podle pravidel DBUSu, třeba z dcop konsole-3443 konsole setFullScreen true se stane qdbus org.kde.konsole-3443 /Konsole setFullScreen true. Je ale celkem možné, že někdo napíše wrapper skripty podporující starý zápis.

15) Používám KDE a mám definovány asociace k souborům podle svých představ. Problém nastane v případě, že použiji program z GNOME. Např. otevřu Evolution a pro přílohu typu obrázek mi nabídne uložení na disk. Proč mě to nutí editovat MIME typy znovu pro GNOME? Bude toto chování nějak sjednoceno?

Neexistuje žádný standardní způsob uživatelských preferencí u MIME typů, je jen standard pro určení MIME typů a jaké z nich které aplikace podporují, ale uživatelská nastavení si dělá každý sám. Nevím o žádných konkrétních plánech na sjednocení.