Motorola reaguje na odkoupení Trolltechu (diskuse)

[Jirka]

Když jedno dítě ukradne druhému lízátko, tak to první vyplázne jazyk a začne pokřikovat "A já to stééjně úuúž nééchciíí. Ble ble blé.".

Přesně tohle dělá moje pětiletá neteř.

[freshmouse]

Podle toho článku (celé jsem to ovšem nečetl): "A year ago, we announced that we had founded LiMo (...)" a "As part of its first specification, LiMo specifies GTK (...)". Takže se to zdá logické, ale kdyby Nokia nekoupila Trolltech, tak by asi kolem toho nebyl takový humbuk.

[Jirka]

Já jsem si to nečetl, ale to co jsem napsal bylo první co mně napadlo a nemohl jsem se nepodělit.

[cubas]

Možná už to připravujou delší dobu, ale nepochybuju o tom, že až teď byl důvod začít ten přechod realizovat.

[cubas]

Tak tohle mě pobavilo je to celkem výstižné přirovnání.

[Pavel Půlpán]

Rofl...

[freshmouse]

Jsem rád (jako uživatel GNOME), že i GTK bude nějakým způsobem v telefonech využíváno. Ale je v tom (v mobilních platformách a zařízeních) děsný bordel a situace je nepřehledná.

[Radek Miček]

Jsem rád (jako uživatel GNOME), že i GTK bude nějakým způsobem v telefonech využíváno.

Také jsem rád, především si od toho slibuji, že vývojáři pro mobilní zařízení zapracují na rychlosti a paměťové náročnosti knihovny GTK a dalších, které se tak přiblíží Qt a nebudu pak stále slýchat jak je GTK nenažraná.

[bubak]

tohle bude dost tezky ukol, gtk predbehl uz i Swing

[freshmouse]

Já furt nevím, co máte. Já osobně nevidím mezi rychlostí GTK a Qt žádný rozdíl. A to nemám nijak rychlý počítač.

[Jirka]

Také to tak vidím.

[xm]

Tak to já ho tedy hodně vidím. Na starší počítač jsem sestře nainstaloval XFCE, protože jsem si říkal že je to "lehčí" prostředí (než KDE, které normálně všude používám) a bude tam tedy rychlejší. Dlouho tam nevydrželo, brzo jsem ho nahradil "těžkotonážním" KDE, které tam funguje mnohem rychleji než ono "lehké" XFCE (hlavně odezva GUI, ta tam byla u GTK aplikací přímo tragická).

A všímám si toho i na mém výkonném počítači - GTK aplikace se jeví mnohem líněji, než Qt/KDE aplikace (ale už to není zdaleka tak velký rozdíl, jako na tom pomalejším stroji).

[PMD]

Ono hodně záleží na rozdílu "jeví se" a "je". Někdo třeba pokládá odlišný způsob překreslování GTK za pomalou odezvu:) Já osobně se přidávám k táboru těch, kteří nechápou v čem je vlastně to GTK tak pomalé.

[Jiří Němec]

Tak to se těšte a KDE4. Asi před týdnem jsem nainstaloval 4.0.0 a musím říct, že jsem nic tak živého ještě neviděl.

[Radek Miček]

Radši se budu těšit na další verze GNOME

[Jirka]

Já jsem si nové KDE nainstaloval, ale zdá se mi to oproti mojí 3.5.8 línější. Ale předpokládám, že se to zlepší.

[otula]

+1 nápodobně

[kavol]

kolega to patrně myslel ironicky ...

[Jirka]

Taky mně to napadlo, ale u toho psaného projevu to nejde poznat.

[Radek Miček]

osobně mi nejvíce vadí pomalost knihovny cairo, ale jinak mi to subjektivně přijde též v pohodě

domnívám se však, že vylepšení GTK v oblasti rychlosti a paměťové náročnosti by mohlo sebrat argument odpůrců GTK a navíc by z toho všichni ti, co GTK používájí, jen profitovali

[freshmouse]

domnívám se však, že vylepšení GTK v oblasti rychlosti a paměťové náročnosti by mohlo sebrat argument odpůrců GTK a navíc by z toho všichni ti, co GTK používájí, jen profitovali

Souhlasím, já jsem samozřejmě nemyslel, že by se nemělo optimalizovat, jen jsem řekl, že mi to subjektivně přijde v pohodě.

[kozzi]

No jo jen jedna vec mi na GTK badi a to pomalost gtktreelistu ci jak se to jmenuje hlavne kdyz clovek otvira slozklu kde je spousta dalsich souboru tak u qt/kde aplikaci se obsah zobrazi behem par vterin radove okolo 5ti u gtk to trva radove 1 minutu

[Radek Miček]

A jste si jist, že je to skutečně tím treeview? Pokud se to stává jen při otvírání složky, ale ne při další práci ve složce, tak bude spíše problém v samotné aplikaci. Pokud se jedná o treeview, neměl by být problém ani při zobrazování desetitisíců položek.

[freshmouse]

Teď jsem si zkusmo otevřel /usr/bin/ v Epiphany (GNOME) a v KBabel (KDE). KBabel se mi zdál rychlejší, ale velmi těsně.

[Kyosuke]

Otvírat složku překladatelským softwarem? Jakpakto? A proč?

[Käyttäjä 11133]

No ony ty *.{po,pot} soubory bývají taky ve složkách

[Kyosuke]

To chápu, ale nepřekládá se v Nautilu blbě?

[freshmouse]

Zkusil jsem prostě standardní dialog pro otevření jakéhokoli souboru nebo adresáře -- a jen KBabel mám z KDE k dispozici. Ono na tom ostatně ani nesejde.

[kozzi]

No tak jsem si ted udelal zbovu porovnani a porovnaval jsem dialog pro ukladani ci otvirani gnome(gtk) vs kde(qt) u gtk to bylo asi 40 sekund mozna neco vic u qt to bylo kolem 1 az 2 sekund. A toto mi nikdo nepopre nevim kde je chyba ale proste je to desne pomaly a stim se neda pracovat. Az to opravi popremyslim o zmene. Krom toho by me zajimalo jak si v epiphany otevrel usr/bin?

[otula]

Také mám zobrazení obsahu složek pomalejší v gtk, ale zas takový rozdíl tam nemám. Zkusil jsem v Huginu zabrouzdat do /usr/bin/ - vzalo to ani ne 3 sekundy, v Keditu to byla asi sekunda.

[kozzi]

Tak ja nevim a kolik mas souboru v /usr/bin?

[otula]

3154

[vladaf]

Potvrzuju, ted jsem to zkousel u sebe open file dialog firefox 2.0.0.11 vs. kate v 3.5.8. Rozdil byl skutecne mnohonasobny asi v takovych radech (nestopoval jsem, ale u gtk vyrazne pres 10s).

[Luboš Doležel (Doli)]

A není to náhodou tím, že u Qt/KDE už ty informace byly nacachované, když to ten GTK+ dialog oddřel?

[kozzi]

Ale houby, spis bych rekl ze to bylo opacne kdyz mu to ten gtk nacetl tak rychle Tad yzadny cachovani nefunguje. At jsem to zkousel vselijak kolikrat sem chtel tak vzdy byl vysledek stejnej gtk bylo rado ze to vubec nacetlo nekdy se to ani nenacetlo

[Luboš Doležel (Doli)]

Poprvé to GTK+ u mě načítalo 45 sekund, pak už to vždy byly sekundy dvě.

[kozzi]

jo tak u me ne neda se nekde treba zapnout to cashovani ?

[kozzi]

no tak kdyz jsem presel s KDE do gnome tak mi to trvalo poprvy kolem 45 sekund a ted uz to trva okolo 12sekun ale furt je to znatelne pomalejsi nez u kde/qt dialogu.

[freshmouse]

Na druhou stranu: kdy jsi naposledy potřeboval otevírat /usr/bin/ pomocí dialogu pro otevírání?

[kozzi]

Prave ze furt. Pokazd ykdyz treba ve firefoxu urcuju cim to otevrit atd, krom toho usr/bin neni muj jedinej adresar kde je vic jak 3000 souboru. Ale tech 12 sekund uz se da prezit ale 3 s by byli lepsi . Krom toho sem na GNOME odkojenej takze jak jsem ted do nej po dlouhe dobe vlezl kvuli testum tak jsem se zase zamiloval

[freshmouse]

Ve Firefoxu jde nastavit, čím se co bude otevírat, nemusíš pořád lézt do /usr/bin/. Zkus: Nástroje / Předvolby / Obsah / oblast Typy souborů.

[kozzi]

Jo ja vim, jenze ja dost casto experimentuju, tajze si dost casto promazvam nektere veci jako je napriklad ~/.mozilla atd.

[Ctirad Feřtr]

Prave ze furt. Pokazd ykdyz treba ve firefoxu urcuju cim to otevrit atd, krom toho usr/bin neni muj jedinej adresar kde je vic jak 3000 souboru.

Ona ta tragédie spočívá už v tom, že člověk musí vůbec lézt někam do /usr/bin a lovit tam jednu binárku mezi tisícovkou souborů. Takové zvěrstvo má možná svojí logiku ve windows, ale v unixovém systému je to zoufalé mučení uživatele. V KDE/konqueroru na mě prostě vyběhne dialog, kde si buď aplikaci vyberu nebo prostě napíšu do okénka (kde navíc funguje doplňování) třeba "kmplayer" a pokud je taková někde v cestě, tak se spustí. To je ergonomický rozdíl několika tříd.

[Radek Miček]

To je ergonomický rozdíl několika tříd.

To není žádný rozdíl, podobné okénko je k dispozici i v aplikacích pro GNOME.

[David Jaša]

Řeč byla o Firefoxu, který na toto okénko zvysoka ... prdí, i když k dispozici je.

[Radek Miček]

Řeč byla o Firefoxu, který na toto okénko zvysoka ... prdí, i když k dispozici je.

Ano, tím pádem již argument pana Feřtra

V KDE/konqueroru na mě prostě vyběhne dialog...

je naprosto mimo téma. Já na něj reagoval proto, aby to nevypadalo, že GNOME je někde v pravěku.

[Radek]

O to ani tak nejde. Nekde v tech strevech je proste neco spatne, kdyz to jinde jde o poznani rychleji. Kazdopadne jeden cas jsem pouzivat Stratusfs (nebo jak se to jmenovalo), kde jsou vsechny soubory jako linky v jednom adresari, coz ve vysledku kostovalo nejakejch 60.000 souboru v adresari. Pravda je, ze to pouzivat neslo s zadnym dialogem...

[freshmouse]

Souhlasím; jen jsem navrhl řešení pro Kozziho (bez ohledu na rychlost těch dialogů).

[Jirka]

Mně to taky načetl za 13 s ve Firefoxu. V Konqueroru jsem to měl za 1 s a něco. Druhé načtení ale bylo "už" za 4 s.

[J. M.]

Těžko. Už jsem to několikrát psal, ale on je problém je i v tom, že GTK+ neumí ani obsah prázdného adresáře (!) zobrazit okamžitě. I adresář s nula soubory se v souborovém dialogu GTK+ zobrazí se znatelným zpožděním. To je naprostý unikát, světová rarita. Všechny ostatní dialogy (včetně Qt) zobrazí i adresáře s desítkami souborů okamžitě, bez postřehnuteného zpoždění.

[freshmouse]

Firefox bych sem raději netahal. Standardní Firefox má svůj vlastní dialog pro otevírání. Existují sice jakési programy (např. v Ubuntu je to instalované), které mu přidávají standardní dialog otevírání a ukládání z GTK, ale nevím, jak jsou do Firefoxu napasované. raději bych porovnával s nějakou "opravdovou" GTK aplikací.

[Ladicek]

Plus milión, /usr/bin je pro otevírací dialog z GTK neskutečný killer. Ta mrcha dokonce začne načítat seznam souborů i ve chvíli, kdy začnu psát cestu (a třeba mám úplně jasno v tom, jaký program chci vybrat a bylo by pro mne stokrát rychlejší napsat jeho jméno přímo [teď mne napadá, že vlastně nemám tušení, proč píšu i cestu, když mám /usr/bin v PATH ]).

[freshmouse]

Jak tě a Kyosukeho čtu, tak jsem došel k závěru, že možná mluvím o něčem jiném. gtktreelist je ten prvek, co je v "open dialogu"? Nebo něco jiného? Já měl za to, že mluvíš právě o dialogu pro otevření, a proto jsem použil Epiphany a KBabel, kde takový dialog, jako ve většině aplikací, je -- a je jedno, k čemu ty aplikace slouží.

[kozzi]

jj tak to potom jo slo mi taky o ten dialog.

[David Jaša]

To byl bug v nautilu, teď už by se snad neměl projevovat (nevím, mezi osobními daty nemám adresáře s desetitisíci položek a do /usr/share/doc a podobných zákoutí se dostanu výhradně při práci v shellu).

[tsLnox]

+1, naprosto souhlasím... taky to nechápu (ps: už jsem se rozhodl, KDE končí :-P)

[freshmouse]

Jsem rád, že GNOME má o dalšího uživatele víc.

[J. M.]

Já furt nevím, co máte. Já osobně nevidím mezi rychlostí GTK a Qt žádný rozdíl. A to nemám nijak rychlý počítač.

Je třeba rozlišovat mezi verzemi Qt (i GTK+, samozřejmě). Rozdíl v rychlosti mezi GTK+ 2.x a Qt 3.x je obrovský, velmi patrný, to se prostě nedá odkecat. Qt 3.x je daleko rychlejší než GTK+ 2.x. Boužel Qt 4.x je hrozné a v některých ohledech dokonce i pomalejší než GTK+ 2.x (podle některých lidí to je tím, že používá defaultně všude double buffering).

Jinak rozdíl je i mezi GTK+ 2.0-2.6 a GTK+ 2.8 a výš. Od příchodu Caira se toolkit GTK+, který byl už předtím velmi pomalý, ještě velmi zpomalil (proto ho i ti výrobci mobilních telefonů nejdřív vůbec nemohli používat a zůstávali u verze 2.6). Je to velmi vidět např. na přepínání záložek (u GTK+, pokud obsah záložky není jen velmi primitivní, vidím, jak se mi postupně překresluje obsah, postupně vykresluje obsah záložky, prvek po prvku...), stejně tak jako třeba v rychlosti vykreslování dialogů (jsem bez problémů schopen udělat třeba screenshot napůl vykresleného dialogu, do kterého GTK+ postupně pomalu vykresluje jeden spinbutton za druhým, to to trvá, než se to celé zobrazí...) Rovněž rychlost při změně velikosti, to je tradiční evergreen, to je něco, co prostě v GTK+ nikdy, ani za sto let nebude dobré, i přes pokusy vývojářů s tím něco udělat to je prostě pořád líné jak hlemýžď, trhané, neplynulé. V takovém Ubuntu (Gutsy Gibbon, které jsem zkoušel, ale možná to jenom přebrali z upstreamu) to je vyřešené chytře, když ve výchozím nastavení už je prostě vypnutý zobrazovaný obsah okna při změně velikosti. Sice to nahradili efektním průhledným modrým obdéníkem, který mění velikost místo okna, což vypadá hezky, ale je to jenom fikané zamaskování a definitivní uznání toho, že to prostě GTK+ neumí a nikdy nebude umět vykreslovat tak rychle, aby to zvládalo solidně „v real time” (což je pikantní, Microsoft Windows tu umí naprosto dokonale, nádherně hladce strašnou spoustu let i na starých plečkách, GTK+ to nezvládá ani na moderních počítačích). Rovněž v grafických a multimediálních aplikacích, používajících GTK+ to je tragédie, když vidím, jak se mi obrázek vykresluje na obrazuvku postupně po jakýchsi obdélnících (v Qt aplikacích naprosto okamžitě a jednorázově), grafické prvky jako posuvníky nebo třeba výběr barvy s tím barevným kruhem (který se opět vykresluje znatelně pomaleji než v Qt) celé GUI těh programů zpomalují. Atd. atd. Prostě GTK+ je všechno možné, jen ne rychlé, ale to je už spoustu let notoricky známá věc, o které se už napsala šílená kvanta komentářů, článků a tak. Když to vidí a léta si na to stěžuje taková spousta lidí (včetně třeba komerčních výrobců software), tak na tom jistě něco bude.

[xm]

S pomalostí Qt 4 nemohu souhlasit. Co jsem ho tak testoval (nikoliv však KDE 4 aplikace, čistě Qt 4), tak je rychlejší než Qt 3. Extrémně je to vidět třeba u vektorové grafiky (kde Arthur engine z Qt 4 doslova kraluje, Cairo je oproti němu mnohonásobně pomalejší, ten rychlostní rozdíl je přímo gigantický - viz třeba tenhle už trošku starší srovnávací test).

Ale netýká se to jen vektorové grafiky, ale i spousty dalších věcí. Qt 4 je IMHO obrovským krokem kupředu. Jinak defaultně zapnutý double-buffering považuji v dnešní době za klad.

Co se týče té pomalosti Qt 4 na některých systémech, pokud vím byl to snad jen problém NVidia (nebo ATI?) proprietárních ovladačů, nikoliv problém Qt. Jestli už je to v nových verzích ovladačů napraveno netuším, ale v posledních NVidia ovladačích bylo nějaké obrovské zrychlení XRender akcelerace, tak snad ano.

[J. M.]

Mohlo by to být i tím, používám NVIDIA ovladač v Linuxu, ale bohužel i na jiném počítači s MS Windows a ATI kartou bylo Qt 4. hodně pomalé. Rychlejší než 3.x může být maximálně v té vektorové grafice, ale celkově to GUI, ty widgety, ty dialogy a tak, rychlejší nebudou, už kvůli tomu, že je to nová generace, složitější technologie (podobně jako GTK+ 2.x je o kus dál než 1.x, proto je o tolik pomalejší). Režie je vyšší. Stačí se třeba dívat na vytížení procesoru - i takové triciální věci jako otevření combo boxu v Qt 4.x žere několikanásobně víc výkonu procesoru než v Qt 3.x. A pomalost Qt 4.x není jen moje zkušenost.

[Käyttäjä 11133]

- i takové triciální věci jako otevření combo boxu v Qt 4.x žere několikanásobně víc výkonu procesoru než v Qt 3.x. A pomalost Qt 4.x není jen moje zkušenost.

To je pokus o co? Jak moc mi nějaká operace zatěžuje procesor je mi upřímně úplně jedno. Model:

Můžeme buďto vykonávat činnost 1s při zatížení CPU na 100%, nebo 2s při zátěži 50%. Co je pro nás jakožto pro někoho, kdo čeká na dokončení činnosti lepší? Aby činnost běžela na 50%, nebo na 100%?

[J. M.]

To je vyvrácení toho, že Qt 4.x je rychlejší než Qt 3.x, na konkrétním příkladu (tedy 4.x není rychlejší alepoň v určitých věcech, ale je jich mnohem víc než to menu, to byl jen jednoduchý příklad). Na otevření menu měly všechny testované toolkity jednu sekundu (všechny to stihly v limitu, tedy žádné prodloužení na dvě sekundy se nekonalo). Když je průměrné vytížení procesoru za tu jednu sekundu u jednoho toolkitu vyšší než u druhého, je to pro mě signál, že na otevření menu ten první spotřebovává víc cyklů procesoru než ten druhý, tudíž je v otevírání menu pomalejší a dejme tomu za deset sekund by to menu nezvládl po sobě otevřít tolikrát jako ten druhý (a to se dá i změřit, zbenchmarkovat, pro GTK+ je k dispozici gtkperf). Zkrátka, Qt nespotřebovává víc cyklů procesoru proto, že by ty operace prováděl rychleji, ale prostě proto, že má větší režii a je pomalejší (protože složitější).

[J. M.]

A pro ty, kterým „to je jedno”, jestli je při otevření menu vytížení procesoru 0 procent nebo 10 procent – ono to je vidět i pouhým okem. Qt 3.x to zvládne otevřít s nulovým vytížením procesoru a je to viditelně bleskové, okamžité. GTK+ na to spotřebuje 2-10 procent a už je pouhým okem vidět, jak se tomu nechce. Totéž Qt 4.x (byť možná o něco méně, v závislosti na okolnostech). To tedy k tomu, jestli to je nebo není jedno – vnímavému člověku to není jedno, protože to vidí a cítí, většina lidí si toho ale nevšímá (to je taky důvod, proč někteří lidé tvrdí, že s rychlostí třeba GTK+ nemají problém – není to proto, že by se ta pomalost na jejich počítači neprojevovala, ale prostě si jí jen nevšímají, mají horší postřeh, navíc jsou na to zvyklí).

[Käyttäjä 11133]

Zatížení 0% znamená, že se žádné menu nevykreslí. Nebo mi chceš říct, že Qt3 funguje nějakým kouzlem? --> Existuje nějaká hranice měřitelnosti, pokud se množství spotřebovaných cyklů za jednotku času dostane pod tuto prahovou hodnotu způsobí to tu situaci, že se bude zdát, jako by operace nezatěžovala procesor. A tak pokud navrhnu algoritmus tak aby spotřebovával méně cyklů (za jednotku času) než je tato prahová hodnota podaří se mi uživatele, který by chtěl provádět benchmark oklamat a podle jeho hloupého benchmarku se mu bude zdát, jak je jeho vykreslování rychlé, protože přece nespotřebovává "žádný" strojový čas. A přitom to vykreslení trvalo několikanásobnou dobu, než vykreslení za situace kdy jsem všechno udělal co nejdříve to bylo možné a množství spotřebovaných cyklů tak stouplo nad hranici měřitelnosti.

Už víš, proč je tvůj "benchmark" i ničem a zatížení procesoru mě vůbec netankuje?

[J. M.]

Ne.

Zatížení 0 procent neznamená, že se nic nevykreslí, znamená zatížení méně než jedno procento (nebo méně než půl procenta). Meřiče vytížení zpravidla neukazují údaje v desetinných číslech, ale zaokrouhlené na celá čísla.

Autoři toolkitů jistě nepíšou algoritmy na otevření menu tak, aby oklamali uživatele, kteří dělají benchmark. Prostě GTK+ 2.x i Qt 4.x spotřebují několikanásobně více cyklů procesoru na otevření položky menu (i mnoha dalších věcí) než Qt 3.x (nebo třeba microsoftí GUI, i jiné toolkity jako Fox atd.) A protože to, co vidím na vlastní oči a co jako uživatel cítím při používání toho GUI (a postřeh mám velmi dobrý) naprosto koreluje s tím, co mi ukazuje „benchmark” (Qt 3.x je bleskurychlé, GTK+ 2.x i Qt 4.x viditelně váhají – kdybys měl pravdu v tom, že ten toolkit žere víc výkonu procesoru proto, aby to bylo rychlejší, muselo by to mít ten efekt, což rozhodně nemá), je pro mě závěr jasný: GTK+ 2.x i Qt 4.x jsou pomalejší než Qt 3.x. Můžeš teoreticky spekulovat jak a čím chceš, ale mě nepřesvědčíš.

[J. M.]

Dám ještě jeden příklad, aby to bylo jasnější. Mám v dialogu tři záložky. Když se přepnu z první na druhou, u Qt 3.x je vytížení procesoru 0 procent a přepnutí je naprosto okamžité, dokonale bleskové. U staršího GTK+ 2.0-2.6 bylo vytížení procesoru 1-3 procenta a přepnutí bylo téměř okamžité. U GTK+ 2.8 a novějšího je vytížení třeba 8-10 procent a přepnutí už je viditelně pomalé, trhané, vidím, jak se postupně vykreslují widgety do druhé záložky, jeden po druhém. U Qt 4.x je vytížení 10-30 procent a do druhé záložky se to přepne až po (více či méně dlouhé) pauze (GTK+ 2.x začne obsah okamžitě postupně vykreslovat a chvíli mu trvá, než to dokončí, Qt 4.x si chvíli počká a pak jej tam vykreslí najednou). Když chci projíždět všechny záložky (třeba kolečkem myši nebo klávesovou zkratkou) jak nejrychleji to jde, v Qt 3.x je můžu bleskově prosvištět třeba tempem 20 záložek za sekundu (všechny se v tom fofru stihnout vyobrazit), u GTK+ ještě jakž takž, s větším vytížením procesoru, místy trhaně, ale dá se to, u Qt 4.x už zobrazím tak záložku za sekundu, je to slideshow.

Já prostě vytížení procesoru neignoruji, protože to je v těchto věcech velmi směrodatný ukazatel.

[xm]

Takhle pomalé jak tu popisujete rozhodně Qt 4 normálně není, v mých testech (a obecně dle mých zkušeností) tomu tak nikdy nebylo. Nebude u vás opravdu problém s ovladači grafické karty?

[J. M.]

Samozřejmě může být. Např. na starším notebooku s vestavěnou grafikou SiS se mi zdálo rychlejší (což ale neznamená že nějak moc rychlé) než na mém (teoreticky) rychlejším desktopu s NVIDIÍ. Ale vzhledem k tomu, že ani na počítači s MS Windows a kartou ATI (kde obzvlášť vynikne rozdíl oproti neuvěřitelně superrychlému GUI Microsoftu, kdyby nic jiného, aspoň za rychlost GUI by někdo z Microsoftu měl dostal nobelovku) to nebyla žádná sláva (v některých ohledech spíš dost hrůza, ale vývojáři Trolltechu snad postupně na výkonu v sérii 4.x pracují, bohužel jsem ještě nezkoušel 4.4 s těmi „alien widgets”, na to jsem dost zvědav), počítám, že Qt 4.x opravdu není obecně moc rychlý toolkit, i kdyby můj linuxový počátač byla anomálie.

[Käyttäjä 11133]

Já se tě taky nesnažím přesvědčit o tom, že je Qt4 rychlejší než Qt3, ale pouze o tom, že tvůj argument s vytížením procesoru je stupidní.

Zatížení 0 procent neznamená, že se nic nevykreslí, znamená zatížení méně než jedno procento (nebo méně než půl procenta).

To jsem taky sporem dokázal hned v prvních větách svého komentáře. O to mi taky šlo, že existuje určitá mez při které tvá měřící metoda nic nedetekuje.

[otula]

Ale Marku… Pokud budu tvrdit, že pírko je lehčí než pětikilové závaží, a budu to dokazovat na váze, která pod půl kila ukazuje nulu, také mi řekneš, že mé měřicí metody jsou na nic, protože nejsem schopen to pírko zvážit?
Také čtu velmi skepticky všechna radostná zvolání, že Qt4 je rychlejší než Qt3, protože mé pocity z Qt4 aplikací jsou velmi špatné - vždy říkám, že mi připadají malátné.

[otula]

Ještě bych měl jeden postřeh, který ale (patrně) nesouvisí přímo s Qt4. Že některé aplikace pro Qt4 jsou prostě katastrofálně nenažrané. Třeba MuseScore, v němž se reálně vůbc nedá pracovat. I to projíždění menu je utrpení. A třeba QStarDict versus klasický StarDict - vyhledání hesla ve Stardictu se mi projeví zatížením procesoru do 3 procent. Vyhledání hesla v QStarDictu šplhá na 70 % :-/

[J. M.]

To bude tím ovladačem grafické karty.

[ivan]

Komercni vyrobci SW uprednostnuji jeste jedno kriterium. A to je rychlost vyvoje a potazmo celkove naklady. Pamatuju si, ze kdyz jsem programoval a pouzival GTK 1.2, tak mi vsichni tvrdili, ze QT je desne pomaly protoze je napsany v C++. Zatimco GTK ma sice objektovy model, ale diky tomu, ze si objekty musi resit programator sam, je GTK mnohem rychlejsi. Na GTK je videt, ze je nekdy lepsi nechat problemy na kompilatoru a ze neni potreba aby programatori ve vsem stourali. Takze bych dodal, ze QT vede i v dokumentaci a rychlosti vyvoje.

[Radek Miček]

Takze bych dodal, ze QT vede i v dokumentaci a rychlosti vyvoje.

A na to, ze Qt vede v rychlosti vyvoje, jste prisel jak? Pro jaky programovaci jazyk ma vase tvrzeni platit?

[trekker.dk]

No když se mluví o rychlosti vývoje, tak bych si tipnul, že tvrzení má platit pro ten programovací jazyk, ve kterém je Qt vyvíjeno,

[David Jaša]

Popisované problémy jsem naposled zaznamenal na starém počítači s 256 MB RAM a Celeronem 850 přiškrceným 5/8 prázdných cyklů. Dlužno dodat, že Qt 3 na tom bylo pouze o poznání lépe.

[Robo]

Jsem rád (jako uživatel GNOME), že i GTK bude nějakým způsobem v telefonech využíváno. Ale je v tom (v mobilních platformách a zařízeních) děsný bordel a situace je nepřehledná.

GTK sa uz vyuziva v platformach OpenMoko a Maemo

[freshmouse]

Já vím. (OpenMoko je navíc myslím i HW, nemýlím-li se.)

[cezz]

OpenMoko je navíc myslím i HW, nemýlím-li se.

Mylis HW je Neo1973. Inak prave na tomto HW je paradoxne momentalne viac usable Qtopia..

Osobne vsak GTK fandim viac.

[Jony]

Já bych byl spíš překvapenej, kdyby Motorola ve svých "linuxových telefonech" linux nepoužívala

[xHire]

Také mě to už při prvním přečtení zprávičky prásklo do očí.

Ale škoda, že se o jejích linuxových telefonech moc nemluví... (tedy alespoň já o nich moc neslýchám)

[xm]

Jako bych to u zprávičky o odkoupení Trolltechu firmou Nokia neříkal, moje obavy se vyplnily Ty řeči že stejně chtěli od QTopie ustoupit jsou jen PR žvásty, Nokia je tu hlavní důvod. A to samé bude následovat u dalších japonských a čínských výrobců mobilů, které QTopiu využívali (případně měli v plánu využívat) - nebudou přeci závislí na platformě vlastněné konkurencí. Tohle znamená smrt QTopie, je to obrovská škoda, byla to velmi dobře propracovaná a slibná platforma

[kerala]

Spíš si myslím, že bude hodně záviset na rozhodnutí Nokie, zda bude nabízet knihovny Qt a Qtopia dalším stranám. Kdyby nenabízela, tak mnoho projektů asi zanikne, včetně KDE. Podle mě je lepší aby knihovny rozvíjel silný majitel, který ledacos může protlačit. Kdyby platforma JAVA nebo .NET nebyla vyvíjena SUNem nebo MS, tak by jistě již skončily na smetišti počítačů.

[Luboš Doležel (Doli)]

KDE by samozřejmě nezaniklo, vždyť je kód pod GPL a pokud by přecejenom došlu k průšvihu, je podepsaná smlouva, která by zaručila uvolnení posledního kódu pod BSD.

[Kyosuke]

Otázka je, jestli to jednou neshoří na něčem úplně jiném...

[xm]

Tohle mě taky děsí, Nokia se opravdu silně snaží prosadit softwarové patenty v EU. Z tohodle pohledu není o nic menším zlem, než třeba Microsoft.

[Jirka]

Tak tohle: "ep1348155 Menu item selection" mně opravdu pobavilo. A hned potom rozbrečelo.

[trekker.dk]

To je přesně důvod, proč jsou softwarové patenty naprosto nesmyslné - neslouží k ochraně toho, kdo investoval nemalé částky do vývoje, ale k boji s potenciální konkurencí od menších firem, které takhle lze zničit jenom tím, že je dáš k soudu.

[Michal Kubeček]

Škoda že tam momentálně nefungují odkazy na detaily. Docela by mne zajímalo, co se skrývá třeba pod "Content Transfer". Zní to docela děsivě...

[Jirka]

Jsou tam i horší, např. "Keyboard".

[Jan Molič]

Kdo mi zaručí, že firmička XY nebude jednou koupena mojí konkurencí? A když bude a já proto přejdu k jiné firmičce XY, kdo mi pak zaručí, že nebude taky koupena mojí konkurencí? ...? Nemyslím si, že je v dnešní době tolik podstatné, kdo co vyvíjí. Někomu prostě platím za vývoj. Tohle není problém QT, tady jde o běžné konkurenční chování. I kdyby Trolltech nebyl vlastněn Nokií, vždy budou firmy, které se už z podstaty budou snažit o vlastní řešení, a pokud možno nekompatibilní - sázejí na to, že právě to jejich nakonec prorazí. Podívám-li se do minulosti, tenhle přístup bohužel neshledávám dobrým, často totiž vítězí horší řešení. A QT pod Nokií? Motorola má prostředky na to, aby dala dohromady sto programátorů a udělala si vlastní klon QT, kdyby se Nokia rozhodla uzavřít kód nebo nebyla licenční politika výhodná. Jak je vidět, tohle problém není a vlastní řešení chystají už dávno - už z principu.

[Laoc]

Oni nechystají vlastní řešení, oni jen chystají přechod ke konkurenčnímu GTK+.

[Martin]

A kdo se směje? Android! Hurá!