Nový vzhled stránek GNOME.org

Jak bylo slibováno, tak se stalo. Webové stránky pracovního prostředí GNOME byly upraveny, takže jsou o něco přehlednější.

13.10.2007 17:43 | freshmouse | Upozornění

Komentáře

[saly]

Pěkné, pěkné je i Gnome 2.20, škoda že u něj už nejsem ...

[freshmouse]

Co není, může být.

[saly]

Kdepak, já jsem přešel již na KDE(noflame please) kvůli imho jediné vadě na kráse Gnome - rychlosti, dokud se něco neudělá s rychlostí knihoven GTK, tak pravděpodobně Gnome používat nebudu, jinak se těším na KDE4, které mě potěší asi více než Gnome 2.20 ...

[Luk]

S rychlostí knihoven GTK je to tragické. Bohužel se z licenčních důvodů používají v mnoha programech, takže se jim člověk příliš nevyhne

[PMD]

Hele, co všichni mají s tou rychlostí GTK? Zkoušel jsem KDE i GNOME na několika mašinách a připadalo mi to úplně stejný...

[VRtulnikk]

Taky si myslim :) ...samozrejme to nemam podlozene zadnymi merenimi, ale rychlost a odezva mi prijde u obojiho stejne pouzitelna. /...a GTK je navic hezci ;)))/

[PMD]

No já nevim, hezčí nebo ošklivější, sere pes. Každý je prostředí prostě jiný. Ale rychlost odezvy mi přijde prostě stejná. Tak mi neni jasný, proč se vždycky najde někdo, kdo přihodí hlášku o pomalosti GTK, když já nic takovýho dlouhodobě nepozoruju:)

[VRtulnikk]

Vsak ja to myslel jako takove rejpnuti ..proto ty ";)))"

[Luk]

Ono se to měří velice špatně. Nicméně - teď jsem schválně udělal takový mikrotest (samozřejmě neobjektivní ). Postupně jsem spustil (nejdřív vždy třikrát naprázdno a pak teprve naostro) kwrite a gedit. To jsou zhruba srovnatelné programy - kwrite umí o něco málo víc, ale to je jedno. U každého z programů jsem rozbalil levou nabídku z lišty a prošel přes všechny nabídky až vpravo a potom zpět. To celé pětkrát. Celý pokus jsem zopakoval třikrát a výsledky způměroval - tady jsou (reálný čas není příliš podstatný):

kwrite
real    0m24.26s
user    0m1.73s
sys     0m0.31s

gedit
real    0m26.18s
user    0m2.76s
sys     0m0.24s

Tohle mi tedy jako "stejné" nepřijde

[Luk]

Ještě dodám, je to Qt 3.3.8, KDE 3.5.7, GTK2 2.10.13 a GNOME 2.16.0.

[freshmouse]

Doporučuju porovnat s novým GTK a GNOME. Neměřil jsem to, ale subjektivně soudím, že je to (zase) rychlejší.

[Drom]

Gnome 2.18 a 2.20 maji vyreseno nekolik problemu s rychlosti, takze by vysledky mely byt lepsi nez 2.16.

[Drom]

+ hodne taky zalezi na pouzitem tematu a gtk-engine

[Septyk]

A ví někdo jak je na tom s rychlostí třeba murrine oproti jiným?

[Drom]

Myslim, ze dobre, posledni tak pul rok se na tom engine delalo vcetne optimalizaci (ale nevim, co uz bylo vydano).

[Drom]

Dle slov autora murrine zalezi na pouzitych efektech v konkretnim tematu a rozhodne rychlejsi nez ubuntulooks.

#gnome-art @ irc.gnome.org
(15:54:21) Cimi: it depends on the effects
(15:54:39) Cimi: from faster than clearlooks to slower
(15:54:53) Cimi: (but always faster then ubuntulooks)

[PMD]

Tohle podle mě nemá cenu měřit na pikosekundy. Jediný případ, kdy jsem zaznamenal významný rozdíl v odezvě GUI bylo, když jsem zkoušel BeOS:) Jinak mi rozdíly nepřijdou ani dost okem rozpoznatelné, natož aby mi stály za nějaké měření. Z tohohle úhlu pohledu mi přišlo zajímavé, kolika lidem stojí za to neustále opakovat mantru GTK pomalé, GTK pomalé, GTK pomalé... Možná je to nějakým bugem, který se náhodou u mě zatím neprojevil, nebo je to čistě sociologická otázka;) Každopádně mě to zajímá, protože se to často opakované tvrzení rozchází s mou zkušeností.

[Ctirad Feřtr]

Záleží co provozuješ za programy. Pokud je to nějaký editor nebo browser, kde je jenom okno s lištou, pár tlačítky a nic se tam nehýbe, je to v pohodě. Pokud je okno plné elementů co se neustále pohybují (třeba VU metry, tlačítka a posuny "hlavy" v audio aplikacích), je tam řádový rozdíl. U Qt aplikací se všechno normálně plynule hýbe, u GTK to v lepším případě skáče v horším se to pak vyloženě postupně překresluje, jak kdyby se to nějak hrozně složitě renderovalo. Odstrašující příklad viz třeba phasex. Pokud má někdo dvacetijádrový procesor, sto giga paměti a pět vytůněných nvidií ve sli, tak to možná tak nevnímá, ale na starším PC je ten rozdíl opravdu propastný.

[PMD]

Hm, takhle speciální aplikace opravdu neprovozuju. Ale není to spíš tím, že si ty widgety psal autor sám? Nebo bych to možná svedl na Cairo. Ta knihovna opravdu není moc optimalizovaná pro renderování grafiky v reálném čase:)

[anon123]

Sice pacuji v KDE, ale at delam co delam, GNOME mi zatim na vsech pocitacich pripada mnohem rychlejsi.

Navic asi pouzivam vice aplikaci, ktere jedou stejne na GTK.

[saly]

Dle mého názoru je opravdu QT rychlejší než GTK, neskoušel jsem ale poslední verze Gnome/GTK, takže nevím, porovnávám Gnome 2.18 a KDE 3.5.7 ...

[laco]

No, ty stránky jsou fakt lepší. Jo a KDE4 zatím asi moc neboduje.

[freshmouse]

Jasně, používej, co ti vyhovuje. Já jen kdyby náhodou... No nic.

Mimochodem, já mezi rychlostí GTK a Qt nevydím rozdíl. Fakt. Stejně tak GNOME vs. KDE. Uznávám, že GNOME bylo jeden čas pomalé (asi tak 2.8?), ale teď zrychluje velmi.

[Marek 'Maxicom' Zelenka]

nevydím?

[freshmouse]

Ajajaj, to jak na mě přicházelo spaní...

[Petr Tomeš]

Tak to já vidím. :)

[J. M.]

GNOME se může zrychlovat jak chce, ale dokud bude založené na GTK+, bude mu to houby platné. GTK+ je prostě chronicky pomalý toolkit, to se nikdy nezmění. Ten, kdo to není schopen vidět (jako že to je pouhým okem vidět víc než velmi názorně, v porovnání s konkurencí to je velmi žalostný, zdrcující pohled), může sledovat měřič vytížení procesoru, který u triviálních věcí (otevírání menu, přepínání záložek apod.) prostě u GTK+ 2.x vykazuje mnohonásobně vyšší hodnoty než u Qt 3.x, protože GTK+ je prostě neefektivní, špatně napsané (kdyby to tak nebylo, nebylo by tak pomalé).

[Petr Tomeš]

Nějak to moc prožíváte a přeháníte. Kupte si odpovídající HW a bude to dobré.

[Zdenek.Z]

Na některé věci upgrade hardware nestačí. Nemám sice úplně nejnovější stroj (Pentium M @ 1,5 GHz, 1,5 GB RAM, disk 4200 rpm), ale za vykopávku to pořád nepovažuju. Teď jsem provedl test na GTK 2.10 a Qt 3.3.8 (na KDE 3.5.8, Kubuntu 7.10) a jednu z "features", které mě na GTK dost dlouho štvou a kvůli kterým se GTK snažím vyhýbat. File open dialog - najet do /usr/bin/ (nebo jiného adresáře, kde je hodně souborů). Čas v GTK: 40 sekund(!), čas v Qt cca 1 sekunda. A ta optimalizace, o které pořád mluví je kde? Pardon, ale na to, jestli si budu moct otevřít soubor čekat 40 sekund? Jinak bych proti GTK rád nic neměl, ale pomalejší prostě je. A i při vykreslování menu je vidět rozdíl - i když už začíná být nepatrný. Ono se GTK opravdu zlepšuje a optimalizuje, ale ještě má pořád dost co dotahovat.

[Michal Karas]

Máš v /usr/bin/ hodně dokumentů?

[Luk]

O to přece nejde. Jde o to, že je tam něco shnilého, když to trvá tak dlouho. Možná se to zbytečně překresluje, nebo nevím co...

[freshmouse]

V GTK to rozhodně není 40 sekund a v Qt to rozhodně není jedna sekunda -- minimálně na mém počítači. A to mám 256 MB RAM. Zkoušel jsem to u GTK v GNOME a u Qt v KDE.

[Zdenek.Z]

Tak sem dej svůj výsledek. U mě to je na 2274 souborech v /usr/bin/, fs ext3, konfigurace PC je uvedená výš. Udělal jsem v něčem chybu? GTK file open dialog jsem už zkoušel v průběhu několika let na několika distribucích, různých konfiguracích a vždycky byl naprosto nechutně pomalý a přes půl minuty otvírání (aspoň na mém počítači) trvalo vždycky.

[Martin Böhm]

No, já mám 1GB RAM, procesor Intel Core 2 Duo a stejně to bylo tak 20 sekund, než začal Firefox znovu reagovat. A i kdyby nesnášenlivé KDE zpomalovalo open dialog GNOME, tak je ten rozdíl dost patrný.

[Zdenek.Z]

1) To nepovažuju za moc rozumný argument. Proč něco takového jak Qt dialogu, tak dialogu ve Windows trvá okamžik a GTK skoro minutu?

2) Do /usr/bin/ občas lezu. File open dialog neslouží jen k hledání "dokumentů". Třeba když si chci ve Firefoxu vybrat, jakou aplikací otevřu stahovaný soubor. Jo, můžu to udělat tak, že si ho uložím na disk a pak ho otevřu z shellu, ale je to další zbytečný zdržující krok.

3) Můj /usr/bin není jediný adresář na světě, který má hodně souborů.

[Michal Karas]

Já zase nepovažuji vyumělkovaný extremní případ za dostatečný důvod k zavržení celého toolkitu.

[Martin Böhm]

Na dost velkých vstupních datech se lépe ukáže, jak je Tvá implementace algoritmu rychlá/pomalá. Rozdíl jedné sekundy (který se může projevit třebas v reálném použití ve složce s pár tuctem souborů) by se dal přisoudit chybě měření.

[?]

Co je to "s pár tuctem"?

[Zdenek.Z]

Nezavrhuji celý toolkit. A vyumělkovaný případ to rozhodně není - viz jiné moje příspěvky.

[Michal Karas]

Tak zrovna ten Firefox si dnes už AFAIK umí ty programy odněkud vytáhnout. A pokud si člověk jednou vybere jiný, tak si ho taky zapamatuje.

[Petr Tomeš]

Nemá. Pán chtěl vypadat zajímavě, tak záměrně vybral asi nejhorší příklad pomalosti GTK. V reálném nasazení se však s takovým způsobem práce, kdy by otevíral dokument mei tolika ostatními, asi nesetká. A i pokud ano, tak hledání mu asi nic neříká, takže neumí pracovat efektivně...

[Martin Böhm]

Jak se mi tak zdá, tak GTK používá na načtení a zobrazení seznamu souborů algoritmus, který je v nejhorším případě řádově pomalejší než ten, který je v Qt. Tvrdíš, že v reálném nasazení se s tímto nesetkáme. To je samozřejmě dost dobře možné, protože některé algoritmy se mohou na malém intervalu (řekněme 1-10) souborů jevit rychlejší, než ty, které jsou "správnější" a řádově účinnější v horších případech.

Stručně řečeno: Na hodně malém intervalu je prostě jedno, jestli doba načítání roste s funkcí n nebo n^2 nebo n^3. Otázkou zůstává, kde je ten zlomový bod. Pokud už při 15 souborech by to byla otázka vteřiny, tak už je to podle mého docela velký problém. Spousta lidí má složky o velikosti více než 15 souborů. Pokud jsi tak znalý problematiky GTK, můžeš mi prosím osvětlit následující problémy:

1. Proč přesně trvá načtení většího počtu souborů tak dlouho? Jaká část knihovny za to může? 2. Jakou má použítý algoritmus (resp. jeho implementace) časovou složitost? Při kolika souborech se projeví znatelné zpoždění a kolik toto zpoždění je? 3. Pokud to jde lépe, proč to lépe neudělat?

[Luk]

Na hodně malém intervalu je prostě jedno, jestli doba načítání roste s funkcí n nebo n^2 nebo n^3. Otázkou zůstává, kde je ten zlomový bod.

Osobně tvrdím, že pokud je pro běžné úkoly operační složitost algoritmu n^2 a vyšší, tak je to vždycky špatně. Možná jsem příliš zblbnul z učení doc. Hudce (jehož přednášky jsem vynechával ), ale téměř vždy lze použít algoritmus, který má složitost alespoň n.log(n), přičemž je dostatečně efektivní i pro n blízké nule.

[Martin Böhm]

Rozlišujme mezi pojmy "špatně" a "jedno". Algoritmus může být dobrý a může být špatný, ale někdy to může být taky jedno, že. Tady se pohybujeme dost v rovině spekulací - chtělo by to nějakého vývojáře GTK, aby nám řekl, kdy a proč ke zpomalení dochází.

[J. M.]

Problém toho souborového dialogu je, že je pomalý za všech okolností, a to včetně těch nejjednodušších případů. Nikdy v životě jsem neviděl žádný jiný souborový dialog, který by i prázdný adresář s 0 soubory (!) zobrazoval se znatelným zpožděním. Každý jiný souborový dialog zobrazí i obsah adresáře s desítkami souborů okamžitě, bez sebemenší znatelné prodlevy, GTK+ dialogu znatelně trvá i zobrazení ničeho, nuly. Prostě je to katastrofálně napsaný software.

[Petr Zelenka]

Hmm, to je vlastně zajímavá otázka: Jak dlouho trvá zobrazit "prázdno"? Jak to tak pozoruju, díky vývojářům GTK to lze naměřit už dnes. Dobrá práce, chlapi! ;)

[Deleted [8409]]

lol, dobrá reakce

[Martin Böhm]

Upřímně - a který software není? Kritérií na kvalitu softwaru je mnoho a skutečně schopných a zkušených programátorů zoufale málo Nástroje vznikají jen pro splnění toho či onoho účelu, načež jsou na ně nabalovány tucty nových vlastností, na které původní návrh ani nepomyslel. Nezapomeňme na tucty projektů, po kterých si dneska už nikdo nevzdechne.

A to může být software "špatně" navržen i úmyslně - byl by Novell šťastný, kdyby si Kubuntu nebo Fedora mohly vzít některé moduly z Yastu a bezproblémově je integrovat do svého systému (třeba skrze KControl)? Neřekl bych. Podobně třeba rozhodnutí Sunu použít pro některé projekty "svobodnou licenci", která je ale nekompatibilní s GPL. Rovněž rozhodnutí, které pomůže leda firmě, avšak softwaru ne.

Takhle by se dalo kafrat do nekonečna ... ale stručně řečeno, souhlasím s Vámi, GTK není dobrý pro to, pro co nebyl navržen, a autoři (GNOME) jsou někdy až příliš moc jisti svou pravdou (open dialog, 6-měsíční cyklus apod.), než aby se to v budoucnu nějak změnilo.

[Petr Tomeš]

a autoři (GNOME) jsou někdy až příliš moc jisti svou pravdou (open dialog, 6-měsíční cyklus apod.), než aby se to v budoucnu nějak změnilo.

Zajímavé, že to píše zrovna horlivý účastník projektu (Ubuntu), jehož hlavní představitel oroduje za půlroční cyklus všude, kde může. V poslední době docela dost v tomto směru tlačí třeba na KDE.

[Martin Böhm]

Nene, to píše nevzdělaný negramota, který si i přes své nevzdělání a svou negramotnost udržel schopnost vytvořit si vlastní názor :o)

[Zdenek.Z]

Pán nechtěl vypadat zajímavě. Pán chtěl jen poukázat na to, že jsou i situace, kdy jsou ostatní toolkity ne nepatrně, ale brutálně rychlejší než GTK. Ano, pán vybral nejhorší případ, který z GTK zná. Ale udělal to proto, že v reálném nasazení se s takovým způsobem práce _setká_. Viz příspěvěk o kouek výše: http://www.abclinuxu.cz/zpravicky/show/196651#33 (případ s Firefoxem). No, jediné řešení, jak to pán může dělat efektivněj je a) nepoužívat Firefox b) nahradit v něm GTK File open dialog (existuje sice nějaký hack, jak ho nahradit Qt dialogem, ale posledně když jsem to zkoušel, tak to občas Firefox shodilo - nevím kde byla chyba) c) vytvořit si tam zbytečný mezikrok s ukládáním souboru a jeho opětovným hledáním ve filemanageru/shellu/...

Jinak se domnívám, že i průměrný uživatel se s tím může setkat poměrně snadno. Třeba používá GNOME a zjistí, že na prohlížení PDF/obrázků/ODT/ZIP archivů/jánevimčeho se mu víc líbí jiný než defaultní prohlížeč (Evince/OO.o/...). Tak si po kliknutí na soubor dá Open with other ... začne lézt do adresáře se svým programem (xpdf) a ono se mu to na 40 sekund sekne. Řekl bych, že většina uživatelů po 20 sekundách sačne nadávat a uvažovat o zabití Firefoxu. Je tohle (chtít si vybrat program, kterým budu otvírat daný typ soborů) tak strašně nereálné použití? Tenhle příklad dávám proto, že prostě občas mám potřebu tuto činnost provést a v tu chvíli na GTK nadávám opravdu hodně.

Nechci hanit GTK stylem "je to úplně na prd, nepoužívejte to". Jsou věci, které se mi na GTK líbí, ale tady se předpokládám bude jednat o použití algoritmu s příliš vysokou složitostí, což novým hardwarem prostě nespravím. A Vy tu argumentujete stylem "opravovat to není potřeba, při mém stylu práce se s tím nesetkám" (asi jako když Linus tvrdí, že suspend-to-disk je na prd, protože on používá suspend-to-ram).

Ale jo, možná chci jen vypadat zajímavě.

[Petr Tomeš]

Pán nechtěl vypadat zajímavě.

Dobrá, to jsem trochu přehnal, omlouvám se Vám. Určitě by bylo lepší, kdyby to fungovalo rychleji. Všechny by to potěšilo.

Pán chtěl jen poukázat na to, že jsou i situace, kdy jsou ostatní toolkity ne nepatrně, ale brutálně rychlejší než GTK. Ano, pán vybral nejhorší případ, který z GTK zná. Ale udělal to proto, že v reálném nasazení se s takovým způsobem práce _setká_.

Dobře tedy. Pak jste tedy asi jediný, koho znám, že takto potřebuje pracovat. Ostatní lidé toto nepozorzují, případně si daný soubor vyhledají.

Jinak se domnívám, že i průměrný uživatel se s tím může setkat poměrně snadno. Třeba používá GNOME a zjistí, že na prohlížení PDF/obrázků/ODT/ZIP archivů/jánevimčeho se mu víc líbí jiný než defaultní prohlížeč (Evince/OO.o/...). Tak si po kliknutí na soubor dá Open with other ... začne lézt do adresáře se svým programem (xpdf) a ono se mu to na 40 sekund sekne.

A proč by to proboha takto blbě dělal? Ledaže by používal nějakou stupidní distribuci, která mu snižuje komfort a produktivitu práce. Stačí na to přece kliknout pravým tlačítkem a zvolit Otevřít s "XPDF" (openSUSE 10.3 - GNOME).

[Zdenek.Z]

Dobře tedy. Pak jste tedy asi jediný, koho znám, že takto potřebuje pracovat. Ostatní lidé toto nepozorzují, případně si daný soubor vyhledají.

No, co pozoruji já, tak dost uživatelů když klikne ve webovém prohlížeči na nějaký třeba zip soubor, a prohlížeč se jich zeptá, jestli chtějí soubor otevřít v aplikaci XYZ nebo ho uložit, tak používá volbu Otevřít (pokud si soubor nechtějí uložit na pozdější použití).

A proč by to proboha takto blbě dělal? Ledaže by používal nějakou stupidní distribuci, která mu snižuje komfort a produktivitu práce. Stačí na to přece kliknout pravým tlačítkem a zvolit Otevřít s "XPDF" (openSUSE 10.3 - GNOME).

Tak jste nepochopil, jak to myslím. Nemluvím o souborovém manažeru. Mluvím o webovém prohlížeči. Tam jsem si nevšimnul, že by se tyto akce přidávaly do kontextového menu (kromě Konqueroru). Ani ve Firefoxu, ani v Opeře to, co popisujete, nejde. Ani v Kubuntu, ani ve Fedoře. openSUSE tu od včerejška už nemám, tak to nemůžu vyzkoušet, ale pochybuji, že by měli svoje webové prohlížeče takhle upravené.

Jinak -- samozřejmě, dá se použití file dialogu na takovéhle účely obejít. Ale já bych radši viděl problém vyřešený, než ho jen nějak obcházet.

[Petr Tomeš]

Tak to možná ano, nepochopili jsme se.

[Zdenek.Z]

OK. Jen tak mimochodem, právě mě napadla další (IMHO ne zas až tak neobvyklá) situace, kdy lezu do adresáře s velkým množstvím souborů. Mám staženou nějakou referenční příručku jazyka / tutoriál apod. v HTML podobě. Třeba referenční příručka k PHP, kterou tu mám má 6138 souborů, tedy ještě 2.5x víc než /usr/bin/. Pokud chci otevřít nějaký její soubor a browser už mám otevřený, tak si vytvořím nový tab a dám File-Open (pokud nechci psát cestu ručně). (Teda, teď už se této cestě ve Firefoxu vyhýbám a volím jinou. Ale tahle mi přijde nejlogičtější.)

[Martin Böhm]

Nejdřív jsem nevěřil, ale zkusil jsem a je to tak. A to mám ještě novější stroj (nejaktuálnější Apple MacBook). Tipnul bych si, že zastánce GTK namítne, že 90% z těch 90% běžných uživatelů neotevírá takto naplněný adresář, ale pro mne je to zajímavý úkaz.

Ačkoli do problematiky GTK/GNOME zas tolik nevidím, domnívám se, že tady nějaká menší vylepšení, která by se za půlroční vývojový cyklus GNOME stihla, nijak nepomohou. Ten problém bude ležet někde v použitých algoritmech a jejich složitosti. To jest můj odhad, pokud někdo má přesnější údaje, rád budu osvícen :o)

V tom bude mít KDE4 (Qt4) výhodu nad GNOME 2.X (GTK 2.X) - vývojáři měli možnost překopat vnitřek prostředí a odstranit všechny "háčky", respektive špatná řešení, která se během opravování chyb a přidávání menších vlastností ve větvi KDE 3.X nakupily. Bohužel, GTK/GNOME 3 se neplánuje a menší vylepšení, která se za půlrok stihnou, budou jen přidávat GNOME na váze.

<nebezpečnýnázor>GTK je typickým úkazem knihovny, která "nakynula", protože se začala používat jinak, než k čemu byla původně navržena (The Gimp Toolkit). Rozšířila se, protože měla svobodnější licenci než konkurence, a dnes je držena při životě (kromě historických důvodů), neboť její licence je "méně svobodnou" než konkurence. ("Svobodnou" podle interpretace Richarda Stallmana).</nebezpečnýnázor>

[Petr Tomeš]

Bohužel, GTK/GNOME 3 se neplánuje

Nikoliv bohužel, ale naštěstí.

[Mark]

Ale niečo by s tým chlapci mohli urobiť. Prečo je napríklad print dialog skoro v každej aplikácii iný? Prečo nie je všade rovnaký?

[Drom]

Nutno podotknout, ze Ubuntu patchuje gnome oproti oficialnim zdrojakum, myslim, ze to _muze_ ovlivnit vykon, nevim detaily.

[kapy]

Nechápu, buď je něco špatně, nebo je to v GTK+ 2.12 a potažmo v Gnome 2.20 opraveno. V /usr/bin mám asi 1960 souborů, a dám-li ve Epiphany nebo Firefoxu otevřít soubor a vybírám z /usr/bin (zobrazeny jsou všechny soubory), tak to trvá asi 1,5 sekundy.

Konfiguraci mám prakticky shodnou, Intel Pentium M Dothan@1.5GHz, 1GB RAM, disk 5400 rpm.

[Luk]

Tak jsem to schválně změřil - načtení souborů v /usr/bin do dialogu pro otevření souboru. Vždy to bylo "za horka", tedy po předchozím provedení, aby se neprojevil vliv pomalosti disku. Výsledky jsou následující:

Firefox 2.0.0.6    39,7 s
Opera 9.23          3,5 s
KWrite             neměřitelné

Neobejde se to bez komentářů. Adresář obsahuje 2722 souborů. Firefox používá otevírací dialog GTK2, Opera používá dialog Qt, KWrite dialog KDE. Zatímco dialogy GTK2 a Qt nejdřív vše načtou a teprve pak zobrazí, dialog KDE funguje úplně jinak. Načítá, současně již průběžně zobrazuje (při první otevření to celé proběhne tak do 2-3 sekund) a pak ještě dále na pozadí načítá podrobné informace, což trvá dalších cca 15 sekund, kdy lze ovšem už normálně vybírat soubory (podrobnosti k souborům ve viewportu se načtou vždy před zobrazením).

Zřejmě je tam také nějaká vnitřní cache, protože při následujícím otevření téhož adresáře toto se okamžitě zobrazí obsah (s podrobnostmi k dispocici) a nic už se znovu nenačítá (asi se jen přečte seznam souborů a provede aktualizace).

Verze knihoven: GTK 2.12.0, Qt 3.3.8, KDE 3.5.7

[frdrx]

GNONME se zrychluje, a DMSN je to hodně patrné zlepšování se. Je co zlepšovat i mimo GTK+. Pravda, GTK+ je proti Qt trochu pozadu, ale co na tom? Dokud je to rychlejší než já a nezdržuje mě to, tak ať si je to klidně pomalé. Jsou důležitější věci než nějaká relativní rychlost překreslování, ikdyž bylo by fajn, kdyby s tím někdo něco udělal. Konkurence snad popostrčí vývoj GTK tak aby dotáhlo náskok.

[PMD]

A jéje. Fundamentalista;) Na čem to prosímtě zkoušíš? Zatížení CPU při otevírání menu?????

[Deleted [8409]]

Nejhorší je, že Gtk+ začíná být pomalinku závislé i na dalších neoptimalizovaných knihovnách jako je třeba cairo. Věřím, že autoři by chtěli optimalizovat, ale bojím se, že prostě neví jak, jinak by to dávno udělali.

Asi tak před rokem jsem četl článek, který psali nějací programátoři, co portovali Gtk na nějaké nové mini-zařízení a použili právě Gtk (asi licence). Jediný problém byla rychlost a tehdy museli použít silnější procesor aby to GUI běželo v únosné rychlosti, což je podle mě katastrofa ( v prvních testech trvalo načtení "prázdné" aplikace kolem 4 sekund, po výměně procesoru 2 sekundy, což je i tak strašné)

No flame, v Gtk knihovně je prostě chyba už v designu a ani sebelepší programátor žádný zázrak neudělá. Jediná záchrana pro tuto knihovnu je to obrovské množství programů, které ji využívá.

[Lu-Tze]

Už to sem nepiš, pane prezidente. 14 zpráviček z toho tři tyhle. Však to je vo ničem. Nebo ne?

[freshmouse]

Nerozumím. Jakých 14 a 3?

[freshmouse]

14 už chápu.

O ničem je asi všechno, co napíšu.

[MiK[3]Zz]

Copyright © 2005-2007 The GNOME Project.
Optimised for standards. Hosted by Red Hat.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.gnome.org%2F

Je to naozaj smiesne :)

[Drom]

Nikdy nevahejte reportovat chybu...

http://bugzilla.gnome.org/show_bug.cgi?id=486822