Portál AbcLinuxu, 4. prosince 2025 14:34
maximalizaci pak skoro nikdo nedela krizkem, ale dvojklikem na ram okna...Neverím, že väčšina ľudí vie aspoň to, že také niečo funguje (takže pochybujem, že väčšina ľudí to tak robí).
Hmmmmmmm - ako pre koho. Pre mna to je:
KDE -> MacOS X -> Windows Vista -> Windows 7 -> ........................................................... -> Gnome
Takze bud taky laskavy a nezovseobecnuj!
Proc tohleto vsichni tvrdi, kdyz jim musi byt naprosto jasne, ze to bude procesorove i pametove narocnejsi? To se netyka jen Gnome, na druhe strane barikady jsou mozna jeste vetsi srandisti s QT4 a KDE4.
Opravdu se to dá velmi rozumně používat. Nejvíc mě překvapují ty na 100 % funkční a plynulé 3D efekty bez měřitelného dopadu na spotřebu stroje.
Tady bych se zastal Qt4. Ten toolkit jde pustit bez vetsich potizi i na mobilu s 350Mhz ARMem, ale na tak obrovskou knihovnu s tolika funkcema je to rychly skoro uzasne.P5esně tak. Qt4 je dost dobře výkonově vyladěná.
file /usr/bin* zvládlo rychleji. Ale mám pocit, že neustále rýpání opravdu k něčemu vede, protože teď se to načítá postupně a řadí (to v minulosti nebylo, ne?). Ne jako že by mi to snad k něčemu bylo dobré, ale asi vývojáře toho dialogu furt nebaví poslouchat to fňukání.
Už to, jak se na obrazovce objeví, je viditelně pomalejší než u konkurence. Samozřejmě záleží na (výkonu) hardwaru, pokud má někdo nadupaný stroj, ta hrubá síla hodně nedostatků GTK+ (a jiných) zakryje. Stejně tak s kompozitním správcem oken je spousta artefaktů neviditelných (postupné načítání obsahu dialogu, místo toho to prostě vychrstne celé okno, třeba se zpožděním). U mě je to ale viditelné jasně. Jiné souborové dialogy se objeví okamžitě, u GTK+ je viditelná prodleva. Nejdřív se objeví kostra okna, do něj se postupně, dodatečně vykreslují jednotlivé sekce toho dialogu, postranní panel (místa), tlačítková cesta nahoře a samozřejmě výběr souborů. To chvíli trvá. Další věc je procházení mezi adresáři. To je taky suverénně nejpomalejší ze všech souborových dialogů. Nejznámější věc je to, jak dlouho trvá načtení obsahu adresáře s mnoha soubory. Méně známé je to, že to je pomalé za všech okolností. I do prakticky prázdného adresáře se to přepne s viditelným zpožděním. To nikde jinde neexistuje. Třeba Qt dialog se i do adresáře s větším množstvím souborů přepne okamžitě, bez postřehnutelné prodlevy. Rovněž rolování je citelně pomalejší než u konkurence, např. na mém (ano, ne zrovna moderním) počítači často prostě posuvník při rolování v tom dialogu nestíhá následovat myš, i u adresářů s pár soubory. To v Qt dialogu neexistuje, ani u velkých adresářů.
Obrovský rozdíl je taky mezi starším souborovým dialogem z GTK+ 2.x (tím jednoduchým, hnusným, bez ikon a panelu s umístěními) a tím současným. Ten starý byl (a pořád je, i v současném GTK+) naprosto bleskový a srovnatelný s konkurencí. Ten nový je prostě řádově pomalejší, mnohem línější v reakcích. Nevím, jestli je to těmi ikonami. Například když použiju téma ikon, obsahující vektorové ikony, pak je ten dialog přímo úděsně pomalý (na jiné věci to přitom nemá vliv, jen na ten souborový dialog). S bitmapovými ikonami je to mnohem rychlejší, ale pořád pomalé. A pamatuji si, že jsem si i v "pomalém" Pythonu během chvilky napsal panel pro výběr souborů s ikonami (tedy podobný tomu novém GTK+ dialogu), který byl stejně rychlý jako ten starý GTK+ dialog bez ikon. Takže ačkoli GTK+ je celkově pomalé, tohle není ani tak primárně problém GTK+, jako toho dialogu, který je prostě špatně napsaný.
Další nedostatek - ne tak zásadní: dialog nikde nenabízí aktuální cestu v textové podobě.
Až půjde v tom dialogu cokoliv normálně vybrat a bude v něm přístupná kromě tlačítek cesta i v textové podobě, pak se dá bavit o tom, co komu vyhovuje. Teď je GTK open dialog z hlediska použitelnosti ve stavu "je to rozbité" a žádný flame na tom nic nezmění. Změní to jedině programátoři.
Další nedostatek - ne tak zásadní: dialog nikde nenabízí aktuální cestu v textové podobě.CTRL+L?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.