Luboš Luňák odpovídá

7. 12. 2006 | Redakce | Rozhovory | 5969×

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í.

       

Komentáře

[xkesh]

kdo opravdu potřebuje okno, které shoří?

Reklama!

[Semo]

Neexistuje žádný standardní způsob uživatelských preferencí u MIME typů

Nebol prave na to vymysleny subor /etc/mailcap? Nie ze by som si robil iluzie o mnozstve programov, ktore to respektuju, ale nejakym "standardom" to asi je.

[m;)]

v /etc asi nebudu uzivatelske preferencie, ale systemove .. na uzivatelske je $HOME

[Zdenek]

ad 15. Tady se neco rodi.

[Daniel Kvasnička ml.]

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.

Pritom tohle je jedna z nejvetsich prekazek rozsireni Linuxu na desktopu. Porad se soustredit na "featurky" a kaslat na integraci je obrovska chyba.

[Ripper]

|

[Sandik]

Ahoj Danieli, máš krásnou patičku. Mám chuť jí obšlehnout do mého deníčku. Smím? ;o)

[Aleš Kapica]

11)..aplikace typu snímání obrazovky do OGG Theora..

Vyber si..

[msk]

Ja by som este dodal, ze planujem napisat nieco v qt, mozno priamo kde, co by vyuzivalo recordmydesktop. Trosku sa o tom diskutovalo tu, ale teraz na to nemam moc cas. Kostra je hotova, dokonca to funguje, ale odladene to teda ani zdaleka nie je. Ak sa niekto chce k vyvoju pridat, dajte vediet.

[kreten]

hele já te mužu podpořit jenom finančně, protože potřebnými programátorskými znalostmi nedisponuji... Takže jestli máš o podpoření zájem tak se ozvy.

[msk]

Myslim, ze skor trpim nedostatkom casu. Ale pokusim sa to nejak este tento rok dostat do alpha stadia a mozno spravit debilianovsky balik.

[kreten]

Mno už se teším. třebas bychti mohl udělat betatestera.

[neaktivni]

git?

[...............23]

recordmydesktop má ale bohužiaľ jednu zásadnú chybu, že nefunguje nahrávanie OpenGL okien (skús si to napr. na glxgears), pokiaľ nezapneš nejaké nastavenie s ktorým to ale zas bude hrozne pomalé

[Aleš Kapica]

xvidcap nahrává i akcelerovaná okna - nahrává totiž vše z X serveru. Opravdu nechápu proč vymýšlet již vymyšlené, místo zdokonalení a vylepšení vymyšleného. Námitky že xvidcap má GUI v GTK neberu, protože jej lze spouštět i z konzole a kdo chce, může si GUI v QT dodělat, pokud na to má.

[msk]

Co je presne to, co robim ja teraz. Recordmydesktop sa bude spustat ako zvlast proces z toho gui, takze zmenit to na cokolvek, co sa da zavolat a pomocou sigterm stopnut, nebude problem.

[...............23]

Heh, no kukol som ho, ale zistil som že pri nahrávaní fullscreen (1152x864) je na mojom PC (Athlon 1200, 512ram, FX5500) úplne nepoužiteľný. A neviem ako xvidcap, ale recordmydekstop vyzerá byť dosť živý projekt (súdiac podľa news)

[Aleš Kapica]

Myslíte jako že to video bude tím pádem komprimovat svižněji, jo? Naivko.

[...............23]

Huh ? Nechápem. Dá sa niekde v xvidcape vypnúť kompresia on-the-fly ? Neviem jak to robí recordmydesktop (asi nezachytáva celé obrazovky ale len zmeny), ale pri vypnutej kompresii počas nahrávania (defaultný nastavenie) to až tak moc miesta na disku nežere, a ešte je to aj rýchle. Na malú oblasť sa samozrejme môže aj v rmd zapnúť full shots, a potom to nahráva aj akcelerované okná. Však skús a uvidíš, alebo sa spýtaj autora

[j3nda]

"Chceš to? Tak si to naprogramuj, dokumentace je tamhle" už je víceméně pryč.

tak toto me mirne obveselilo
byl bych rad, kdyby tato doba mela znovu-zrozeni
[precejenom by si nekteri pokrocilejsi uzivatele meli uvedomit, ze FSF se bez programatoru a ruznych hackeru a stouralu neobejde a je potreba prejit pomyslnou caru: spotrebovatel/prispevovatel]