Co přináší KDE 4 - (technologie)

3. 7. 2007 | Michal Vyskočil | Recenze | 18540×

Čtvrtá verze prostředí KDE je zcela jistě jedním z nejočekávanějších projektů ve světě open source softwaru. Pojďme se podívat pod kapotu vývoje - první díl minisérie vás seznámí s technologiemi, na kterých bude KDE 4 založené.

Čtvrtá verze prostředí KDE je zcela jistě jedním z nejočekávanějších projektů ve světě open source softwaru. Na abclinuxu jste si už v roce 2005 mohli přečíst článek KDE 4.0 Plasma, který vznikl v době, kdy byly práce v počátcích. A potom Novinky v KDE4.

Co přináší nového?

KDE4 je jednak port celého prostředí na Qt4, ale zároveň i největší "čistka" v knihovnách a přidávání nových technologií v dosavadní historii KDE. Je jich skutečně poměrně dost a často přinášejí zajímavé vlastnosti (respektive by měly umožňovat je přinést). Některé jsou nové, některé KDE pouze integruje v rámci podpory interoperability napříč desktopy (například D-BUS). Některé vznikly přímo v hlavách (a klávesnicích) vývojářů KDE, jiné byly zase adoptovány od těch externích. Nových pojmů je docela dost, takže je dobré si je alespoň ve stručnosti představit.

Qt4

Qt verze 4 je asi nejvýznamnější změnou. Součástí balení této nové generace toolkitu od norské společnosti Trolltech je například:

• Vykreslovací engine Arthur, který přináší podporu OpenGL na všech platformách, podporu Postscriptu, podporu pro X Render Extensions a tak dále. Více viz doc.trolltech.com/4.0/qt4-arthur.html.
• Podpora pro SVG (a CSS), které je vykreslováno pomocí zmíněného systému Arthur.
• Podpora PDF v tiskovém systému Qt.
• Podpora D-BUS (třída QtDBus).
• Integrovaný ECMAScript QtScript a mnohé další.

Prostředí KDE je s toolkitem Qt natolik spjato, že je číslování jeho hlavních verzí stejné jako číslování hlavních verzí Qt. Více informací o novinkách naleznete na http://doc.trolltech.com/4.3/qt4-intro.html.

Plasma

Plasma je koncept spojující panel, plochu a SuperKarambu do jedné aplikace a jednoho API, které mj. umožní vývojářům tvorbu malých widgetů a aplikací (plasmoidy), jež bude možné libovolně umístit na plochu či na panel. Velmi silně používá SVG renderování, takže plasmoidy jsou (na rozdíl od mnoha stávajících systémů) plně vektorové. Ve výše zmíněném článku je Plasma představena pouze jako koncept, ale hlavní vývojář Plasmy Aaron J. Siego v květnu představil současný stav vývoje na KDE Commit Digest, a to včetně ukázkových plasmoidů. Další informace je možno nalézt na domácí stránce projektu plasma.kde.org. Pro zajímavost, ukázková videa naleznete v adresáři media.

Phonon

Phonon je nový multimediální framework. Poskytne jednoduchý a jednoznačný způsob, jak používat různé enginy. V současné době jsou ve vývoji xine, GStreamer, NMM a avKode (následovník aKode). Do budoucna se uvažuje ještě o podpoře enginů MPlayer, DirectShow (pro Windows) a QuickTime (pro MacOS X). Pochopitelně není možné, aby jediné API dokázalo využít možnosti všech stávajících (a budoucích) multimediálních knihoven, takže je Phonon cílen především na aplikace typu přehrávání či streamování videa a jeho účelem je usnadnit vývojářům práci. Na rozdíl od současného stavu, kdy se v každé aplikaci nastavuje použitý engine zvlášť, bude v KDE4 možné volbu provést na jednom místě.

Bývá označován jako náhrada zastaralého aRts, což je zvukový server současných (do 3.x včetně) verzí KDE. Není to technicky zcela přesné označení, protože Phonon je pouze knihovna/API pro práci s multimédii, nikoli zvukový server. Článek The Road to KDE 4: Phonon Makes Multimedia Easier na KDE News se zabývá aktuálním stavem Phononu.

Solid

Solid je nový framework pro sjednocení přístupu k hardwarovým informacím (jako dostupné disky či stav sítě). Trochu se podobá výše uvedenému API Phonon, protože opět nevytváří žádnou novou vrstvu nad stávajícím systémem, pouze nabízí pro vývojáře jednoduché API nad stadardními komponenty, jako je HAL, a opět ponechává nízkoúrovňové věci na specializovaných systémech. Snahou je vytvořit dynamické uživatelské prostředí, které bude reagovat na události, přičemž je zaměřeno především na mobilní hardware (wifi karty, bezdrátová zařízení a podobně). S jeho pomocí bude jednoduché napsat plasmoidy zobrazující dostupnost okolních wifi sítí, podporu pro úložná zařízení nebo správu napájení. Více je představuje článek The Road to KDE 4: Solid Brings Hardware Configuration and Control to KDE na KDE News. Na rozdíl od Plasmy nemá ukázková videa. Libovolný přístup k hardwaru v ukázkách KDE4 má "na svědomí" právě Solid.

Decibel

Decibel je komponentní framework především pro komunikační aplikace. Postaven nad frameworkem Tapioca (ten je zase implementací protokolu telepathy od freedesktop.org) nabízí podporu pro různé komunikační protokoly jako XMPP, Jingle a SIP. S jeho pomocí bude moci libovolná aplikace používat tyto protokoly. Na rozdíl od předešlých komponent není Decibel API, nebo knihovna, ale služba. S její pomocí bude možné jednoduše budovat aplikace používající různé protokoly. Ovšem Decibel se netýká pouze propojení IM a VoIP, ale je možné s jeho pomocí snadno rozšířit textový editor o podporu spolupráce více uživatelů na jednom dokumentu a podobně.

Více je v článcích The Pillars of KDE 4: Decibel a The Pillars of KDE 4: Decibel Definitions and Benefits na KDE News.

Akonadi, KitchenSync - prostě KDE PIM

akonadi je opět server, tentokrát výhradně pro PIM aplikace. Bude se jednat o centrální úložiště pro různé typy aplikací. A z přehledu architektury je zřejmé, že jsou jeho vývojáři velice ambiciózní, protože plánují podporu i pro Gnome centrické Evolution (prostřednictvím Gnome API) nebo soubory ve formátu iCalendar, případně prostřednictvím standardních protokolů Imap a POP3. Technické detaily jsou k dispozici ve slajdech z března tohoto roku. Z nich se například dozvíte, že používá SQL databázi. Trochu více informací naleznete v článku na Developer Journal.

Navíc se v článku The Road to KDE 4: KDE PIM Libraries and Related Technologies můžete dočíst i o dalších připravovaných technologiích, jako je Khalki (pravděpodobné uvedení ve verzi 4.1) pro ukládání kontaktů, zcela přepracovaný KitchenSync (založený na OpenSync) nebo třeba Syndication pro sjednocení přístupu k novinkám v různých formátech (RSS, RDF, Atom, ...). Rovněž se v něm uvádí, že se portace celého KDE PIM uskuteční spíše až ve verzi 4.1.

Kompozitní Kwin

Xgl, Compiz a Beryl jsou hlavní pojmy skloňované loňský rok. Kompozitní desktop je jedněmi odmítán, druhými milován. Buď jak buď, grafický vzhled a efekty pravděpodobně přilákají více lidí než čisté API či revoluční knihovny. Správce oken v prostředí KDE tedy v nové verzi získá různé více či méně užitečné grafické efekty.

Více se dozvíte v rozhovoru s hlavním vývojářem kwin Lubošem Luňákem, případně v jeho blogu na abclinuxu nebo aktivnějším blogu na kdedevelopers.org.

Oxygen

Pro většinu lidí bude (vedle kompozitního kwinu) asi nejvýraznější změnou nové téma Oxygen. Ruší "omalovánkový" styl, který byl doposud jako výchozí, a snaží se vytvářet více realisticky vyhlížející grafiku, přesně v duchu OS X od Apple. Postupuje podle doporučení freedesktop.org, podobně jako konkurenční Tango, takže by je mělo být snadné vzájemně zaměnit. Ikony naleznete na webu projektu oxygen-icons.org.

Následující technologie pocházejí původně z cizích projektů, ale byly do KDE přejaty.

Sonnet

Sonnet je nová knihovna pro kontrolu pravopisu nahrazující kspell2. Mezi poměrně unikátní vlastnosti patří automatická detekce jazyka. Mimo služeb, které nabízí současný kspell2, umí Sonnet kontrolovat gramatiku (ovšem pravděpodobně ne pro české texty, jinak by se uživatel KDE v diskusních fórech poznal tak, že by psal gramaticky správně :-)) a možná by mohl obsahovat i překladatelské pomůcky, slovníky a thesaurus (slovník synonym), případně automatické doplňování slov - a to vše dostupné pro všechny KDE aplikace.

Právě vlastnost automatického rozpoznávání jazyka zaujala vývojáře Strigi, kteří plánují přidat do enginu podporu pro dotazy typu najdi mi všechny dokumenty ve španělštině. Sonnet dokáže rozpoznávat jazyk od přibližně 20 znaků a v zápisku Can your language be detected? je seznam momentálně podporovaných. Pokud někomu chybí podpora právě jeho oblíbeného jazyka (třeba esperanta), měl by kontaktovat autora a nabídnout mu pomoc. Techniky (což je podstatná část čtenářů abclinuxu.cz) bude asi zajímat, že je Sonnet založen na N-Gram-Based Text Categorization, která porovnává n-gramy (n-tice) textu a na základě statistických údajů o popularitě jednotlivých n-gramů v různých jazycích vyhodnotí jazyk. Hezký obrázek funkčního Sonnetu je v zápisku autora Language Detection Works!. Více informací je v článku na linux.com, který obsahuje i přehled všech souvisejících technologií.

Kross

Kross je nový skriptovací engine pro KDE. Původně byl vyvinutý pro KOffice verze 1.5, ale postupně byl začleněn do nových knihoven KDE. Používá jazyky Python, Ruby a KDE JavaScript (kjs). Samotný backend interpretru nezávisí na KDE (používá pouze knihovny z Qt4), takže je možný port na čistě Qt verzi. Více je na domovské stránce kross.dipe.org/.

Strigi

Strigi je indexovací engine pro dokumenty. Tyto enginy slouží pro desktopové vyhledávání, které nehledá jen podle jmen (jako například find, kfind, či slocate), ale i v obsahu souboru. Alternativou pro prostředí Gnome je například Beagle, ale Strigi je napsán v C, což znamená, že je daleko méně náročný než konkurence. To ostatně dokazují i testy, které před časem prováděli zaměstnanci Sunu. Přestože je psán pro KDE4, na jeho knihovnách není závislé, takže je možné jej použít v libovolném desktopovém prostředí. Pro vyhledávání používá knihovnu CLucene.

Nepomuk

Nepomuk (respektive Nepomuk-KDE) je implementace otevřeného standardu (jménem Nepomuk) pro sémantický desktop. Ten neobsahuje pouze hromadu informací, ale i jejich význam a vzájemný vztah. Je založen na standardech RDF a RDS pro popis metadat (původně určeny pro sémantický web) a v této implementaci jsou data přístupná přes D-BUS (což je, mimo třídu KMetaData, výchozí způsob komunikace). Mezi metadata je možné počítat tagy (známá to "novinka" z Web 2.0, se kterou má koncept sémantického desktopu hodně společného) nebo třeba poznámky k daným souborům. Spojení se Strigi a Decibel může užitečnost Nepomuku znásobit.

So long and thanks for all the scripts... D-BUS

Parafrází na Stopařova průvodce začíná poslední novinka v prostředí KDE. Technologie D-BUS je náhradou za dlouho spolehlivě sloužící DCOP. D-BUS byl inspirován právě touto technologií. Změna bohužel způsobí nefunkčnost všech stávajících skriptů, protože žádná vrstva emulující DCOP neexistuje. Více o něm je v článku So long and thanks for all the fish... nebo na domácí stránce projektu dbus.freedesktop.org. D-BUS bude více představen v následujícím díle této minisérie.

Závěr

Další díl se zaměří na změny v aplikacích, které jsou vidět už v současné alfaverzi tohoto prostředí, na porty na ostatní platformy a skriptování v DBUS.

---

Poznámka redakce: autor se rozhodl honorář za článek věnovat na podporu vývoje KDE. Připojte se také :-).

       

Komentáře

[frEon]

to sem zvedav, uz se tesim
jediny ceho se asi i pravem bojim , je ze ovladaci prvky oken (ikonu, menu...) budou zabirat jeste vice mista na obrazovce a tim ubira tomu podstatnymu - datum nad kterymi provadim oprace (treba stranka kterou prohlizim v prohlizeci)

[jiri.b]

pekne, diky... ja si snad na stara kolena oblibim KDE :) teda ciste v teoreticke rovine :)

gnome je prilis spojeno s linuxem/HAL je fakt peklo; KDE vypada multiplatformeji...

[Yenya]

Tak z článku mi vyplynulo, že na HAL je závislé i KDE. Ostatně nikdo jiný kromě Linuxu neumí v takovéto šíři podporovat dynamicky vznikající a zanikající desktopový HW, takže pokud chce desktopové prostředí tyhle vlastnosti využívat, asi mu nezbude nic jiného než být trochu na Linuxu a HAL závislé.

-Yenya, http://www.fi.muni.cz/~kas/blog/

[kavol]

Tak z článku mi vyplynulo, že na HAL je závislé i KDE.

mě z reálné zkušenosti vyplynulo, že KDE 3.5.x HAL sice umí používat, ale obejde se i bez něj - a nevidím důvod, proč by to v KDE 4 mělo být jinak; jestliže spolu s Qt4 míří za podporou více platforem, těžko se stane závislým na technologii dostupné pouze v jednom systému

[jiri.b]

To je fakt takovy problem mit pouze QT tema bez celyho KDE? ten polymer nic moc jako, ale Scribus vypada fakt desne bez KDE.

[freshmouse]

Já jen doufám, že se začnou víc používat databáze pro ukládání dat. Tím myslím všechny ty hračičky jako záložky ve WWW prohlížeči, pošta, historie konverzací IM a tak. Stejně to k tomu spěje -- třeba všechna ta vyhledávadla: vezmou nějaké soubory, zpracují je a výsledek uloží. Do databáze. Myslím si, že by to ulehčilo třeba hledání: představte si hledání třeba v poště (máte-li třeba desítky tisíc zpráv).

Ač uživatel GNOME (spokojený ), doufal jsem, že KDE 4 by databáze mohlo přinést -- aby se pak nebála další prostředí do toho jít. Nepřineslo, škoda. (Možná jsem ale něco přehlédl, měl bych jít raději chrnět.)

[thingie]

Konkrétní úložiště není zajímavé. Hlavní je aby se k tomu dalo nějak rozumně dostat a aby se vědělo k čemu vlastně se dá dostat. Na druhou stranu je pravda, že kdyby KDE přišlo a řeklo, že se všecko uloží do vestavěného LDAPu, třeba, že by to možná mělo něco do sebe.

[jiri.b]

LDAPu? lol

mimojine je architektura LDAPu navrzena hlavne pro cteni...

[thingie]

To byl jen příklad. LDAP pro tenhle účel pravda úplně to pravé není, ale dalo by se z něho s úspěchem vyjít.

[Michal Vyskočil]

Rozumně dostat - Akonadi, k čemu se vlastně dostat - Nepomuk. Zní to hezky, takže snad to taky bude k něčemu prospěšné, ale to záleží i na vývojářích Gnome a ostatních relevantních aplikací.

[thingie]

No, nevim, třeba u toho akonadi tam mají jedno kolečko a dokumentaci tak celkově jsem tam nepochytil Vůbec tam není napsaný co by tedy třeba v Gnome měli naimplementovat, pokud to budou chtít taky (protože ochotou používat KDE implementaci nikdo kypět nebude). Což teda možná je tím, že to je v raném stádiu vývoje, ale má-li bejt KDE4 za pár měsíců, tak nevjem.

[Michal Vyskočil]

Jasně, to já taky nemyslel, jako rýpnutí do vývojářů Gnome. Ale z těch stránek jsem pochopil, že vývojáři Akonadi chtějí dokonce podporu pro Evolution dopsat sami, či co. Dokumentace není, protože afaik ještě ani není dokončené stabilní API knihoven a o KDE PIM se obecně předpokládá, že bude hotové až ve verzi 4.1.

Jediné, čeho se bojím je, že mnoho z těch nových věcí vypadá ohromně, ale jak bude vypadat jejich reálná implementace?

[thingie]

Nojo, jenže pointa by měla být v tom vymyslet něco obecně použitelného a nejlíp tak obecně, aby si to mohl každý napsat vlastní a nemusel s KDE sdílet ani řádku kódu. Já samozřejmě nevim jaká by k tomu v rámci Gnome byla vůle, ale pokud by něco takového rozumného bylo, pak tu šance určitě jsou. Pokud by v KDE napsali nějakou věc do Evo aby s tím uměla pracovat, není to úplně marná myšlenka, ale taky to určitě není způsob jak to nějak dlouhodobě řešit.

To si myslím taky, když koukám na ty roadmapy.

[jiri.b]

no kdyz to bude maximalne v ncurses tak OK :)

[Espinosa]

Máte na mysli relační databáze? Nejlépe ty SQL relační databáze? ono "databáze", to je široký pojem..

Trochu hlouběji se zajímám o Strigi. To má plugovatelný backend. Nicméně jako default je Lucene backend a ten používá speciální optimalizovaný formát binárních souborů, přístup pomocí mmapu. Pro implementaci reverzních indexů, a na nich vyhledávače obsahu stojí, není relační databáze vhodná. Lze, ale není efektivní.

Autor Katu původně svůj kdysi známý katalog-indexer-vyhledávač trochu zbrkle napsal nad SQL, to bohužel ještě nevěděl o Lucene, když ho poznal, začal ustupovat, bohužel konverzi už nedokončil. Teď tuším spolupracuje s autory Strigiho, takže vlastně dobrá zpráva.

Podobná je problematika pro sémantické informace (Nepomuk), tam mohou jako backend také použít reverzní indexy, takže Lucene.

Já hlavně vyzdvihuji fakt, aby backendy byly plugovatelné, pokud někdo vyvine backend založený na SQL a bude efektivnější, rád ho začnu využívat. Hlavně aby se nemusela měnit ani řádka v aplikacích, o tom je to zastřešení.

[Ctirad Feřtr]

Přinese KDE4 něco nového na poli accessibility s primárním důrazem na zrakově postižené? Před několika měsíci vývojáři vyhrožovali, že nové KDE bude plně ozvučené, ale teď s odstupem času se nezdá, že by na tom někdo zapracoval. V tomhle směru je Gnome na míle daleko a i když mám k principu fungování odečítání pomocí Orcy svoje výhrady, tak faktem je, že to celkem funguje a je to použitelné. QT/KDE apliakce jsou ale bohužel pro odečítač naprosto neviditelné a obávám se, že ani s příchodem KDE4 se to nezmění.

[Michal Vyskočil]

Nějaká přednáška o tomto tématu je ohlášena na probíhající aKademy 2007.

[cezz]

Celkom zaujimave citanie su aj tie Sun testy indexovacich engines (motorov? ) akurat mam trosku vyhradu voci kritike memory usage Beagle a JIndex, ktore bezia na VM (Mono a Java), co sice autori spominaju, ale jednoznacne to oznacili ako zapornu vlastnost.. Co je myslim dost diskutabilne. Ale ono to tak asi byva u vsetkych testov. Kazdopadne naozaj zaujimave citanie.

[Michal Vyskočil]

Nějak jsem zapomněl ještě jeden důležitý odkaz - Release Roadmap.

[Ondrej 'SanTiago' Zajicek]

To by me zajimalo, jaky ma smysl delat abstraktni vrstvy (phonon, solid) nad jinymi abstraktnimi vrstvami (gstreamer, HAL). Prijde me, ze jedna vrstva abstrakce je az az.

[vogo]

účel těch dalších vrstev je společná konfigurace (v rámci framworku) a společné rozhraní pro různé frameworky, nebo mi něco uniklo? ;) možná že opravdu neumím číst. BTW dělat přímo s gstreamerem je opruz největší

[vadimo]

A ukážkové LiveCD by sa už nenašlo?

[vadimo]

Tak som niečo našiel. Odkazuje na to priamo kde.org:

http://home.kde.org/~binner/kde-four-live/

[Tomáš Crhonek]

Uz se na to take moc tesim. Hlavne kvuli novym aplikacim. Az vyjde RC, tak ji sem hned hodim.

[Vinicius]

Zni to moc hezky, jsem ale zvedavy na HW naroky. KDE mam od verze 3.2 a s kazdou novou verzi se mi zda subjektivne rychlejsi. Doufam, ze tento trend nebude prerusen.

[mimi.vx]

kde pouzivam od 1.1 ....
subjektivne nejpomalejsi bylo kde2 .... od kde3 se pouze zrychluje

[kavol]

subjektivne nejpomalejsi bylo kde2 .... od kde3 se pouze zrychluje

jak se to vezme ... oproti KDE 1 bylo KDE 2 rozhodně nechutně nenažrané, ale na tehdejších konfiguracích (Celeron 400 MHz 128 MB RAM byl "dělo" se není čemu divit, na druhou stranu je fakt, že na konfiguracích z doby vydání KDE 3 lze docela slušně honit i nejnovější verze; první alfu KDE 4 (hej, neměla by už pomalu vycházet druhá?) jsem si zkompiloval na Duronu 700 MHz, 384 MB RAM, a výkon byl to poslední, s čím by to mělo problémy ...

[J. M.]

Podle mě bude přerušen už kvůli tomu, že KDE 4 je založeno na Qt 4. A Qt 4 je, tak jak jsem jej dosud měl možnost poznat na Linuxu i na Windows, velmi pomalé, až téměř neuvěřitelně oproti Qt 3.

[kavol]

zajímavé, já jsem u Qt4 aplikací nepozoroval, že by běhaly nějak líněji než ty Qt3 ... ani ta alfa KDE 4 se mi nijak neplazila (jak už jsem zmiňoval, Duron 700 MHz, 384 MB RAM) ... bylo by možno specifikovat, kde a jak se ta pomalost dá pozorovat?

[J. M.]

Extrémně pomalé překreslování při změně velikosti dialogu (ještě daleko pomalejší, než je u Xkových GUI normální), velmi pomalé vykreslování dialogů - i jednoduchá dialogová okna se na obrazovku zobrazí se znatelným zpožděním, pomalé přepínání mezi záložkami (na další záložku se přepne až se znatelným zpožděním po kliknutí), pomalé otvírání kombo boxů, které taky měřitelně žere víc výkonu procesoru než u Qt 3... A to všechno i pod Microsoft Windows, kde ten obrovský rozdíl oproti bleskově rychlému nativnímu GUI Microsoftu obzvlášť vynikne.

[Ctirad Feřtr]

Já bych rád někdy viděl to bleskové GUI ve windows o kterém někteří pořád mluví. Jediné, co mi přijde na tom GUI bleskové je rychlost, se kterou jedna zamyšlená aplikace dokáže zablokovat překreslování celého desktopu ;)

A co se týče rychlosti Qt4, tak žádné zpomalení nepozoruju (což se bohužel nedá říct při srovnání Qt a GTK2). Navíc jsem viděl nějaké benchmarky, kde Qt4 trumfovalo v rychlosti Qt3 místy i o desítky procent.

[J. M.]

Já vidím co vidím a na dvou počítačích, na kterých mám Linux a Windows, je rozdíl mezi Qt 3 a Qt 4 srovnatelný s rozdílem mezi GTK+ 1.x a 2.x. Prostě rozdíl generací, rychlý toolkit versus neohrabaný bumbrlíček. A GUI Windows, to je naprosto jiná liga, s tím se v linuxovém světě může rychlostně rovnat tak leda čisté X bez toolkitu, maximálně snad Motif. O pomalosti GUI Windows mají lidé zkreslené představy hlavně kvůli jiným, spodnějším vrstvám OS Windows, ale to GUI samo o sobě je geniálně superrychlé. Já jsem na rychlost GUI hodně velký pes a detailista a tyto rozdíly velmi pozorně sleduji již řadu let.

[J. M.]

Ono je to i logické - se všemi těmi moderními vlastnostmi, které Qt 4.x i GTK+ 2.x nabízejí (Arthur/Cairo, Pango, layouty atd.), není až tak moc divu, že jsou 10-100x pomalejší než GUI Windows. Jenom mě mrzí, že z toho v linuxovém světě není úniku, jsou to prostě "oficiální linuxové toolkty", jiná reálná (použitelná) alternativa k těmto dvěma monstrům není, leda si koupit nový počítač s 4GHz procesorem, na kterém to bude jakž takž přijatelně pomalé.

[Petr Tomeš]

Nepište nesmysly. "leda si koupit nový počítač s 4GHz procesorem, na kterém to bude jakž takž přijatelně pomalé." To je prostě k smíchu. Pokud máte běžný počítač z nižší a střední třídy, který není starší než 4 roky, tak takovou zkušenost nemůžete mít, pracovat s tím lze velmi dobře.

[J. M.]

A kde píšu, že s tím pracovat nelze? Samozřejmě že lze. Ale to, že je to několikanásobně pomalejší než GUI Windows, je prostě fakt.

[Ctirad Feřtr]

To je ale blbost. Mám doma dva stroje, z toho jeden notebook, sotva do GHz (z toho notebook většinu času běží na úsporných ~700MHz) s 512MB RAM a v práci teď nově E6700 s 2GB RAM. Na všem Gentoo s KDE a při běžné práci fakt nevidím žádný rozdíl, co by stál za řeč. Na všech třech se mi pracuje výborně a svižně. To bohužel nemůžu říct v případě, když zasednu k windows. Pokud je to průměrná kancelářská mašina (pořád ale nejmíň o generaci lepší než to, co mám doma), připadá mi, že všechno plave a pořád na něco čekám. U nových mašin s tím dá pracovat, ale že by to bylo rychlejší (notabeno řádově) než KDE, to mi tedy fakt nepřipadá.

[J. M.]

To čekání u Windows, o kterém pořád lidi píšou, není způsobeno tou GUI vrstvou, jak jsem se marně snažil dodat. To je věc jádra, správy paměti, scheduleru (když jeden program vytíží na 100% procesor, nedá se s jinými programy moc pracovat - to NENÍ chyba výkonu toho GUI) a tak. Píšu o tom samotném GUI. A to napsal Microsoft sakramentsky efektivně. Ostatně stačí si porovnat vytížení CPU při řadě různých úkonů. Např. v GNOME mi jenom přejetí myší přes tlačítko správce oken vytíží procesor k 70 procentům, v MS Windows samozřejmě u všech takových triviálních akcí, kde je v Linuxu procesor vytížen na desítky procent, ukazuje CPU měřič konstantní nulu.

[Jirka]

Teď jsem si empiricky ověřil, že v KDE přejetí přes tlačítko okna na panelu zvýší load o 8% oproti normálu. Naproti tomu při zběsilém přesouvání je load na obou systémech 100%. Ale to, že Windows XP (tedy žádné vykreslování GUI pomocí GPU) ukazují při akcích s GUI konstantní 0, mi připadá divné. Nic není napsáno tak efektivně aby se při provádění toho kódu nepoužíval procesor.

[thingie]

Tak, ty X eventy projít musí. Něco to stojí, ale jen maličko. Jo, pokud někdo bude lítat myší sem a tam, tak to asi nějaký load vygeneruje, ale koho to žere. Na zuřivé šoupání myší nepotřebujete počítač, si kupte jenom tu myš a blbněte si jak chcete. Ve Windows to bude podobný.

[J. M.]

Mluvil jsem o Metacity, ne o tlačítku na panelu Kickeru. Nicméně takových konkrétních příkladů a srovnání jsou spousty a prakticky vždy je ta režie v GUI Microsoft Windows nižší, byť ne vždy tak drasticky jako v tom příkladu s Metacity.

A ano, konstantní nula není ani ve všech případech ve Windows, někdy procesor vyletí i na 2 procenta. Ale zatímco třeba při otevření kontextového menu v GTK+ vyletí CPU až na 10% (a to i v MS Windows), microsoftí GUI to, jako spoustu jiných zvládá na nule (což dokonce zvládalo i Qt 3, na rozdíl od Qt 4. které už v těchto ohledech "dohnalo" GTK+ 2.x). Stejně tak třeba přejíždění myší přes záložky - ten efekt, kdy se záožka, nad níž je myš, zvýrazní, u Qt vezme tak 15% CPU u Qt3, u GTK+ klidně i přes těch 70% s tím, že zaostává za pohybem myši a nestíhá, u MS Windows samozřejmě nula procent, v MS Windows je režie GUI naprosto minimální. Nebo hlavní aplikační menu a pohyb v něm, držení klávesy s autorepeatem v nějakém dialogu/okně/textovém políčku. (v linuxových GUI 10-20%, v MS Windows 0%), atd. atd. A netřeba ani měřit vytížení CPU, aby člověka praštil do očí ten obrovský rozdíl rychlosti při změně velikosti okna, to trhané překreslování v Linuxu a absolutně hladké ve Windows. Já jsem pozorováním těchto věcí strávil stovky hodin a celé roky a vím, že to tak prostě je.

[Olsen]

Proto zásadně vypínám zobrazování obsahu okna při tažení a zvětšování - to vytíží naplno i Athlon 64 (zkrátka jakýkoliv procesor) - jak na win98,2000,xp,xfce,gnome,kde3... Jinak souhlasím, že ačkoliv je gui na 2Ghz A64 dosti svižné, určitě žere o hodně víc prostředků, než windowxové, ale to je asi i otázka grafických ovladačů, gdi je ve windows asi taky pěkně ústrojně zaintegrované, zatímco windows má všechny možné systémy dost nezávislé (X, jádro)...

[Robert Krátký]

Proto zásadně vypínám zobrazování obsahu okna při tažení a zvětšování - to vytíží naplno i Athlon 64 (zkrátka jakýkoliv procesor)

Ne proto, že je to nepraktické, protože není vidět, co leží pod přetahovaným oknem?

[Olsen]

No, ono na notebooku je důležitější ta úspora.

[Ctirad Feřtr]

To čekání u Windows, o kterém pořád lidi píšou, není způsobeno tou GUI vrstvou, jak jsem se marně snažil dodat.

Mě je ale úplně jedno, čím je to způsobeno. Prostě se mi to nijak super rychlé nepřijde (spíš naopak) a především, dělá se mi to v tom blbě a basta. Já mám počítač na práci a tu potřebuju dělat rychle pohodlně a efektivně. To mi Linux s KDE 100% splňuje. Kdyby ne, nepoužíval bych ho, nejsem sebemrskač. Zabývat se takovýma hovadinama, jestli se při otevření okna ukáže v nějakém pochybném ukazateli zátěže CPU (jejichž údaje jsou navíc napříč platformama naprosto neporovnatelné) 8 nebo 3, fakt nehodlám.

[Jirka]

V čem to měříte? U mě trvá na notebooku Pentium M 1,73 GHz s 1 GiB RAM (první) rozbalení menu Accessories (a téměř každého, které má více jak jednu položku) subjektivně stejnou dobu jako v KDE. Pak mám taky Celeron 1,2 GHz s 512 MiB RAM a tam funguje KDE docela svižně. Věřte mi, že kdyby to bylo tak pomalé jak uvádíte, tak bych s tím nepracoval. Tam to ale nemám jak porovnat s Windows. Windows mám doma jen na tom notebooku. Další počítač je Duron 1,2 GHz a tam také vše sviští bez problémů a s Windows stále pracuji velice často a nějaké svižnější reakce oproti Linuxovým desktopům nepozoruji. Anžto si každá druhá aplikace pro Windows sebou táhne svůj vlastní toolkit a samotné Windows také používají různé verze komponent (u dialogů je to nejzřetelnější) na různých místech. Takže bych rád znal benchmark, kterým měříte. Pokud je to subjektivní (což by ten uváděný interval 10-100x naznačoval) tak to neberu jako argument.

[Jan Martinek]

... A GUI Windows, to je naprosto jiná liga, s tím se v linuxovém světě může rychlostně rovnat tak leda čisté X bez toolkitu, maximálně snad Motif. O pomalosti GUI Windows mají lidé zkreslené představy hlavně kvůli jiným, spodnějším vrstvám OS Windows, ale to GUI samo o sobě je geniálně superrychlé. Já jsem na rychlost GUI hodně velký pes a detailista a tyto rozdíly velmi pozorně sleduji již řadu let.

Stoprocentně s tebou souhlasím. Těch příčin, proč je GUI windows tak zatraceně rychlé, je docela hodně, takže se těžko zjišťuje čím to vlastně je.
Ale nejhorší, co lze dělat je zastírat to, nepřiznat si to, lhát si sám sobě a utěšovat se tím, že windows mají své chyby. Chtělo by to spíš sprostě okopírovat dobré myšlenky.
Jako první krok bych chtěl vidět benchmark - něco jako gtkperf, ale pro win32.

[J. M.]

+1

[Ctirad Feřtr]

Ale nejhorší, co lze dělat je zastírat to, nepřiznat si to, lhát si sám sobě a utěšovat se tím, že windows mají své chyby.

Mluvte za sebe. Mě se pracuje několikanásobě líp na linuxu a to i přes to, že mám prehistorický počítač, na kterém bych si mohl v XP tak akorát posouvat okny. Žádný problém s rychlostí tedy fakt nemám a už vůbec nemám potřebu si nic nalhávat ani se utěšovat. Pokud to tak děláte vy, doporučuju změnit platformu.

[zenek]

Vy jste to imho nepochopil. On netvrdil, že Windows jsou super, protože má GUI nízkou režii. Říkal, že Windows mají na GUI nízkou režii a když si budeme zastírat, že tomu tak u GTK a Qt není, tak ničeho nedosáhneme. Naopak je lepší si to přiznat a snažit se na tom zapracovat...

[thingie]

Ono tomu tak opravdu ale nejspíš není.

[J. M.]

To je ale to, co zenek píše - že tomu tak není, tedy že u těch linuxových GUI není nízká režie. Což je fakt, který nepopírá nikdo, kdo má o těchto věcech aspoň trochu seriózní ponětí. Za ta léta jsem neviděl ani jednoho člověka, který se v těchto věcech orientuje, aby napsal, že linuxová GUI mají nižší režii než GUI Windows. Všechno, včetně benchmarků, hovoří o opaku, tedy že rychlejší je GUI Windows. Bohužel je typické, že s lidmi jako jsou v této diskusi se o tom vůbec nelze bavit, protože veškeré zmínky o tom, že GTK+ a Qt mají problémy s rychlostí neustále berou jako útok na Linux a i přes opakované upozornění že tady není řeč o tom, jestli je Linux oproti Windows super systém pořád melou o tom, že je Linux oproti Windows super a na neustále marně opakovaná upozornění že tady je řeč o jediné konkrétní jednotlivosti - tedy o rozdílu rychlostí GTK+/Qt versus GUI vrstva Windows a ne o něčem jiném (a ať se prosím vyvarují neustálého stáčení tématu na svatou válku Linux versus Windows) neustále melou o té koze místo toho vozu. Já např. řeknu, že Qt 4 je pomalejší než GUI Windows. Načež jsem označen za blbce a lháře, který šíří hlouposti, a vyzván k tomu, abych uvedl příklad v čem asi. Tak řeknu v čem asi - třeba v rychlosti překreslování při změně velikosti. Načež už jsem odpálkován jenom tím, že si mám vypnout zobrazování obsahu okna při změně velikosti a problém je vyřešen. Tomu už se musím jenom smát - ne jenom kvůli tomu potěmkinovskému "řešení" (typickému zastírání problému, o čemž tu právě byla řeč) a tomu, že to je zvláštní tiché přiznání toho, že jsem měl pravdu, aniž by se mi omluvili za to, že mě označovali za blbce a lháře, ale hlavně kvůli tomu, že to je přesně to, co jsem čekal, protože ve všech diskusích co jsem za ta léta viděl, všichni podobní zaslepenci neschopní diskutovat reagovali přesně stejně - člověka, který řekl, že je GUI v Linuxu pomalé, označili za lháře a blba, a když jim to konkrétně doložil třeba na té pomalé mizerné změně velikosti (což je v linuxových GUI oproti Windows naprosto nepopiratelný propadák, to prostě nejde okecat), vždycky to odbydou tím, že kdo má zapnuté zobrazování obsahu okna při změně velikosti, je blb. Ale ono je to s tím blbem jinak. A i nejen z toho důvodu, že ve světě Windows měla tato volba (vypnutí zobrazování obsahu) výkonnostní smysl naposledy tak mezi Windows 3.x a 95, v posledních 10-12 letech je to k smíchu.

[Petr Tomeš]

Napsal jste: "Jenom mě mrzí, že z toho v linuxovém světě není úniku, jsou to prostě "oficiální linuxové toolkty", jiná reálná (použitelná) alternativa k těmto dvěma monstrům není, leda si koupit nový počítač s 4GHz procesorem, na kterém to bude jakž takž přijatelně pomalé." A to je s prominutím krávovina jak mraky a naprosto směšná.

[thingie]

Já nevím jakou režii pro GUI mají Windows. Vím, že X Window systém a věci jako GTK+ a Qt mají režii přiměřenou. Zlepšit by jistě bylo co, jsou tu detaily i některé principiální věci na kterých by se dalo něco získat. Ale obecně to je poměrně rychlé a použitelné. Což je the fakt.

A rovněž si troufám tvrdit, že principiálně na tom windows nemohou být o moc líp (nemusí platit pro některé konkrétní případy, ale celkově), protože co dělá Linuxové GUI musí ony dělat taky.

Blabla. Ten tón co tu kritizuješ je tvůj tón.

Jo, a doufám, že nemáš pocit, že by ,,Což je fakt, který nepopírá nikdo, kdo má o těchto věcech aspoň trochu seriózní ponětí.`` bylo něco co by mohlo aspoň vzdáleně připomínat argument.

Čísla, popisy, údaje. Ne žvásty.

[Josef Kufner]

Jo, v tomhle máš pravdu. Gtk je nechutně líné. Qt je na tom o hodně lépe. Oproti windowsímu GUI jsou pomalé oba toolkity. Ono kdyby jsme měli v Linuxu X server součástí jádra jako je tomu ve Windows, tak by to s rychlostí vypadalo daleko líp (ale nestojí to za to). A co se týče diskutujících, to máš pravdu taky.

[Gryffus]

+1

[trekker.dk]

Co je mi platná nízká režie, když při rozbalování něčeho velkého rarem trvá několik vteřin, než se zminimalizuje okno a zobrazí plocha pod ním? Kolik má to které GUI režie je v porovnání s tím, jak dlouho co trvá, bezcenný údaj.

[Deleted [8409]]

Vy porovnáváte program, pokud vím tak tady šlo čistě o implementaci GUI, kterou má Windows prostě lepší.

Nejsem příznivce Windows, ale o implementaci GUI se zabývám už nějaký ten pátek a ve Windows je to podle mého názoru propracovanější (implementace). Nemusíme přesouvat nebo roztahovat okna jak šílení, stačí napsat jednoduchý test, který vytvoří double buffer okna, do kterého bude možné kreslit (přímý přístup do paměti). I takto banální případ, který jsem zmínil je ve Windows několikanásobně rychlejší (beru v úvahu samozřejmě i XShm).

Nové Qt4 používá pro všechny widgety právě double-buffer. Na jednu stranu je opravdu rychlejší překreslování oken (při pohybu atd, protože není třeba vykreslovat prvky znovu), ale rychlost změny veliskosti (a tím pádem i double-bufferu) je otřesná.

Ovšem na druhou stranu, když jsem použil pár fíglů, tak jsem docílil v X Window System stejnou rychlost jako ve Windows - někdy o tom napíšu určitě blog, ale nyní stále vyvíjím;)

Pokud by nějaké programátory v C++ zajímal jiný toolkit než Qt nebo Gtk+, může mi napsat, ale stále se nejedná o bohaté řešení...

[JS]

Ja si take myslim, ze GUI Windows je rychlejsi (lepe receno bylo pred Vistou) nez GNOME a KDE. Vysvetleni je podle me vcelku proste - rychlost a nenazranost software zalezi na dobe, v ktere vznikl. Windows GUI vzniklo v 2. polovine 90. let, tudiz, aby se dalo pouzivat, muselo byt rychlejsi nez KDE a GNOME, ktere vznikly o nejakych 5 let pozdeji.

Pokud mi neverite, a jste vyvojari, uvedomte si sami, jake delate kompromisy behem navrhu, a jak ty kompromisy ovlivnuji rychlost a velikost vysledku. Napr. dneska se vsude vyzaduje Unicode, nejsou povolena zadna arbitrarni omezeni typu max. 255 urcitych objektu, jestli se pouziva pole nebo seznam se neresi atd. Bajt po bajtu, aniz si to uvedomite, sezerete spousta pameti a procesoru.

[Petr Tomeš]

To jsem chtěl původně také připsat. Pokud to ten pán myslí opravdu seriozně, tak ať srovnává současné KDE a GNOME a konkrétní distribuci s konkrétní edicí Windows Vista (tzn. systém a GUI ze současnosti), kde bylo GUI výrazně změněno a vyjmuto z jádra pokud vím, a ne že bude srovnávat nesrovnatelné věci, tzn. například to, že Windows XP technologicky odpovídá roku 2001, a házet o tom abstraktní čísla a tvrzení typu stokrát pomalejší/rychlejší. Ať napíše svou konkrétní zkušenost s konkrétními produkty a nastavením. Úplně nejvhodnější by asi bylo porovnávat výchozí stav. A ten je jasný. Na mém notebooku většina zkoušených současných distribucí startuje, vypíná se, reaguje rychleji, spotřebovává více než dvakrát méně RAM, má více a lepších a přizpůsobivějších efektů s mnohonásobně nižšími nároky než Vista Business - a to je to, co mě jako běžného uživatele zajímá při práci s počítačem.

[thingie]

Více než dvakrát méně, muhehe, dlouhý život relativismu :-]

[Petr Tomeš]

Toto a podobná spojení se běžně používají jak v češtině, tak v angličtině i jiných jazycích. Nechtěl jsem psát třikrát/několikanásobně, protože by to nebylo pravda. Zvolil jsem to jako jinou možnost pro dvakrát až třikrát méně, protože v jistých situacích by to mohlo dosáhnout třeba i třikrát méně (i menších hodnot).

[thingie]

Nemyslím, že by mě fakt, že se to běžně používá mohl nějak omezovat v tom, že se tomu budu smát

[Petr Tomeš]

Smějete se logickému a racionálnímu trzení? Neutekl jste odněkud? :) Představte si to na obdobném modelovém případu pro snazší uědomění a pochopení: Více než dvakrát menší = menší, a to více než dvojnásobně.

[thingie]

Více než dvakrát menší... Více| než dvakrát menší
více než dvakrát| menší A není jediný důvod proč by mělo spíše platit to či ono krom toho že je to běžné. Což je slabé

[Petr Tomeš]

Jistě že je. To, že tomu nerozumíte, je věc jiná. http://www.ujc.cas.cz/poradna/odpo.html#carkanez

[Deleted [8409]]

no můžete srovnat Windows XP s linuxovou distribucí z roku 2001. Jsem zvědav, jestli na tom linux bude v rychlosti GUI líp - říkám že nebude;)

[Petr Tomeš]

Nebude, ale bude lepší v jiných věcech. A relevantní je současnost a budoucnost, Linux z roku 2001 dnes již nikdo používat nemusí a většinou by ani neměl, kdežto Windows XP stále dostane s novým počítačem.

[avip]

Tak jsem si to tady pročetl... a je roztomilé, jak obě strany tohoto "flame" zapomněly na zdánlivou maličkost - a sice že kromě 3D akcelerace existuje i velice přehlížená 2D akcelerace.

A Windows využívají 2D akceleraci téměř "do bezvědomí", z toho také vznikají tak časté grafické artefakty (proto také Windows obsahují klikátko pro snížení úrovně akcelerace, ono je tam z velmi dobrých důvodů). Linuxová GUI si od plné 2D akcelerace udržují jistý odstup, což je zas lepší z hlediska kompatibility aplikací (ale používají ji, to byste si vážně všimli, kdyby ne, na straně druhé, na identickém HW s identickým nastavením a v rámci možností i ovladači pro VGA pod Linuxem stačím překreslování okna potřehnout, pod Windows XP ne, ovšem nijak výrazně mne to neptrápí, Linux mi to vynahrazuje mnohem hladším chodem celého systému).

Takže není pravda, že i ve Windows vše počítá CPU, zatraceně velký kus práce tam odvádí VGA s 2D akcelerací.

Na straně druhé je definitivně pravda, že by se mělo srovnávat srovnatelné, t.j. současná GUI Linuxu s Win Vista - a tam to porovnání pro Windows nijak skvěle nevychází. Spíš naopak. Ale to by asi bylo na jinou diskuzi.

[Deleted [8409]]

Když srovnáte rychlost implementace GUI (WinAPI, nemyslim vrstvy typu .NET), tak na tom Windows vždycky bude líp, je to způsobeno už jen komunikací mezi X serverem a aplikací.

[thingie]

To je relativně maličko. Ve Windows se to taky musí nějak jistě někam předat, sama apliace kreslit určitě nemůže.

[Deleted [8409]]

Neřekl jsem, že je to způsobeno jen tím, ale říkám že i tento fakt brzdí. Na procesoru 2GHz je to poznat samozřejmě méně než na 500MHz. Mám linux na starém počítači, kde je Duron 800MHz a stařičká GK a ve srovnání s WinXP je překreslování a vše kolem GUI o dost pomalejší (v linuxu).

[tdx]

A tohle je KDE4 podle Everalda...

Desktop

Firefox

OpenOffice.org

[mess]

Ty první 2 jsou pěkné, ale ty OOo se mi nelíbí. Hlavně ty obludné ikonky.

[Milan Vít]

A takhle podle Nevím Koho (soubory mockup-nn.png)

[Standa]

Tyhle screeny jsou hrozne. Ty ikony jsou tragicke, okraje jen ubiraji prostor na praci atd. Doufam ze se KDE4 nezvrhnou do preskinovani, ale ze opravdu pujdou se zmenami zasadne dal, jak je naznaceno v clanku. A skin MacOS muze mit davno kazdy, to neni pokrok.

Standa

[pj]

+1 gui kde4 na screenshotech je skutecne hrozne, ikony blee :( jsem velmi zvedavy na finalni stav, ale taky zacinam mit cim dal vetsi obavu :-\

[trekker.dk]

Já nevim, proč se všichni děsíte, jak vypadá nové KDE, vždyť to učitě půjde nastavit jinak.

[frEon]

jo tak ted sem si prohlid ty screeny (ty officialni) poradne a zacinam mit docela strach. teda abych byl presny, rec bude o dolphinu.
co se mi fakt nelibi je to, ze jeho ovladaci prvky (menu ikony a tak) zabiraji o 24px vice mista. co je fakt hnus je ten vysokej okraj nad menu k dekoraci okna. to hnusny prazny misto.
dalsi vec, ktera ho prome cini o 100% mene pouzitelnym nez konquror je ze mi dolphin nedovoluje cestu kam se chci dostat napsat. musim se proklikat jak naka mys (neni nad to kdyz staci pouzivat kombinaci prvni pismeno adresare, sipka dolu. podle me je to omnoho lepsi nez koukat na ikony, chvili hledat tu kterou potrebuju, klik, pak zase hledat atd...).

[pard]

Ja zmacknu ctrl l a muzu psat cestu
naopak se neumim dostat klavesnici na bookmarky a taky mi jednourovnove bookmarky prijdou neprehledne

[frEon]

Ja zmacknu ctrl l a muzu psat cestu

tak to mi spadnul kamen ze srdce

[Josef Kufner]

No, ale pak nefunguje entr...

[error414]

Ale dovoluje, ted jsem to vzykousel, je to jen o nastaveni

[neurol23]

pokud vim, tak novy tema dekoraci oken pro kde4 jeste neni vytvoreny a velikost ikon se diky svg da libovolne menit, takze obavy imho nejsou na miste

[abr]

Plastik vladne, misto novych skinu mohli polecit ty hnusne fonty.

[tdx]

Hnusné fonty? To má být co? Fonty ala MacOS X? Není co léčit. Chce to jen umět nastavit si, co se vám líbí, když nedáváte default nastavení ve své distribuci. Já osobně bych zvracel při delší práci s fonty "vylepšenými" ClearType (a to i na LCD monitoru), používám naopak tohle nastavení.

BTW, na nesmyslné generalizace odrážející subjektivní vkus některých přispěvatelů nemá smysl reagovat. I vizuálně to bude jednoznačně posun k lepšímu. A pokud bude většina věcí vektorová, smysl některých nářků nad velikostí toho či onoho mi nějak uniká. A ano, počítá se i se zobrazováním velmi malých velikostí ikon.

[frEon]

jojo, vypada to hezky, ale vsimnete si prosim kolik zbytecnyho mista na obrazovce zabira rezie, kolik mista je tu vyplacano na nic. dyt se na 1280x1024 dva dolphini poradne nevejdou, a kolik mista zabira na obrazovce prace s pouhejma deviti adresarema....
podle me je kazdej pixel drahej.

[freshmouse]

Sesmolil jsem kratší článek, kde "porovnávám" GNOME 2 a KDE 4 (fakt jen ve zkratce, je to spíš takový přehled).

[JoHnY]

Jestli se na neco v KDE4 tesim, tak je to velkem uklid ovladanich prvku an panylku. Vsimli jste si, ze nektery bary jsou tedka uz zaplneny tak nejak prazdnejsi a hezci?

Trsoku si rejpnu do GNOME: Proc pacholci nepridaj nejaky ty konfigurace, kdyz KDE team zvladne uklidit neskutecnej bordel a hnuj co byl v KDE3? No nic, jsem clovek kterej vladne chaosu, takze davam prednost kdyz mam 3 roletky co potrebuju a 20 roletek co nepotrebuju, nez abych mel jen 4 roletky a z toho nepotreboval 1 ;)))

PS: pokud se preportuje KDE4 pod winXP aby to opravdu fungovalo, tak poslu KDE teamu penize. Konecne totiz budu moc mit v obou systemech poradny GUI. (jen bych nedelal port pro vistu, treba by ji este lidi zacali kupovat a to prece nechceme :)))

[noname265]

Až vyjde KDE4 tak si chci koupit notebook....a jestli mi něco zbyde tak to pošlu na KDE ať je port nebo neni....

[faugusztin]

Pod Windows sa kdesktop portovat nebude. Iba kdelibs + aplikacie, ktore ma vyznam mat pod Windows.