GUI ale bez gtk/qt (diskuse)

[bubak]

Swing

[hikikomori82]

XUL

[pozortucnak]

xul i swing jsou propojené s gtk...

[Luboš Doležel (Doli)]

Swing ani moc ne, to spíš SWT.

[Espinosa]

Jedna z nekolika implementaci je postavena na Gtk, dalsi jsou Tk a WinGUI. Slibovali i verzi pro Qt/KDE ale nejak nejak zustalo u slibu :(

[qwerty]

XUL je nazavisle, treba na windows se pouziva MFC.

[Radovan Garabík]

ncurses! alebo aspoň slang, či newt (podľa potreby programmer-friendlinessnosti)

[frEon]

+1 za ncurses

[Luboš Doležel (Doli)]

To hlavně není GUI

[merlyn]

To si nemyslím. Umí to dělat okna? Umí. Umí to dělat tlačítka? Umí. Tak jakýpak není GUI.

[Luboš Doležel (Doli)]

omg, Graphical user interface. Ncurses je TUI.

[unknown_]

To je ale slovíčkaření

[Ilfirin]

Hmm, to bych si rád ujasnil. Je textová grafika grafika? Pod text user interface si představuji konzoli čistě, což ncurses apod není (TGUI?)

[unknown_]

No, taky bych si to rád ujasnil. Podle mě problém je ten, že grafický si všichni představujou nad X serverem (asi?). A přitom to o moc víc než ncurses nenabízí.

[Luboš Doležel (Doli)]

A přitom to o moc víc než ncurses nenabízí.

Tak jsme se zasmáli

[unknown_]

Zasmáli, ale neuvedli spletnuvšího se v realitu...

[David Watzke]

To co tvrdíš je nesmysl. Co máš k dispozici třeba v Qt 4 nemůžeš srovnávat s ncurses ani ze srandy, natožpak abys tvrdil, že toho nenabízí moc navíc

[unknown_]

To je sice super, že to říká velký mistr, ale jaksis zapomněl uvést konkrétní příklady.

[David Watzke]

No pokud vynechám framebuffer, tak například v konzoli těžko zobrazíš obrázek. V ncurses si neuděláš vlastní widget, založenej na nějakym původnim, třeba pouze s vlastním paintEventem, mousePressEventem a rozložením. Naprosto vše v ncurses člověk musí řešit sám a sem tam se stane, že to v nějakym terminálu blbne s touhle vlastností a v jinym zase s jinou. Je toho mraky, stačí se podívat na to, co vše Qt nabízí (hlavní třídy). To vše bys samozřejmě věděl, kdybys místo chytračení alespoň jeden z těch toolkitů někdy použil.

Hlavně se obecně těžko dá srovnat konzolová záležitost s GUI v X. V X máš mnohem víc možností, to je ti doufám jasný...

[depka]

to ze nezobrazim v konzoli obrazek je jasne uz s podstaty, a to ze si muzu specializovat zakladni widget a prekryt mu nejake metody je vlastnost objektoveho navrhu, hlavni smysl, rozhrani ktere clovek pozoruje okem a ovlada rukou, je stejny

[David Watzke]

Obojí je pravda. Ovšem nelze tvrdit, že GUI toolkity nemají oproti ncurses moc co nabídnout. Respektive asi jak komu; když si někdo vystačí s jednoduchou grafikou v konzoli, tak prosím, s tím nemám problém, ale to tvrzení stále není (obecně) pravda, a to - jak říkáš - už z podstaty.

[unknown_]

Neřeš je, gujáky

[David Watzke]

Možná tě to překvapí, ale třeba já jsem docela zarytej konzolista a vše co je pro mě efektivnější provést v konzoli, to tak provádím. Přesto jsem vyjádřil nesouhlas, i když jak jsem říkal - ty to co nabízí GUI navíc třeba nevyužiješ, to je možný.

[Josef Kufner]

Ano, provoz ncurses a Qt programů po ssh na gprs je opravdu nesrovnatelný.

[Luboš Doležel (Doli)]

To není slovíčkaření, to jsou zavedené pojmy.

[mirec]

Turbo Vision

[Andrtalec]

+1

[vogo]

vybraly?

Moc dam se zde nevyskytuje, tak se asi nic moc nedozvíš.

[pozortucnak]

díky, opravím to

[Miloslav Ponkrác]

Ty jo, nadpis a hned hrubka jako Brno. Dámy, kterépak GUI byste si vybraly?

Jinak já bych šel po wxWidgets

[pozortucnak]

Ale to je přece gtk...

[Miloslav Ponkrác]

odkdy?

wxWidgets třeba na Windows nemá s gtk společný ani špendlík

[Boris Dušek]

Třeba Cocoa přes GNUStep.

[pozortucnak]

Ehm a to by se realizovalo jak?

[David Jaša]

K čemu je taková anketa dobrá?

[pozortucnak]

Řekněme ze se chci naučit programovat a chci se vyhnout gtk\qt...

[dad]

...se chci naučit programovat ...

to ale nahore nikde nestalo. V tomto pripade prosim skrtnete muj hlas pro fox-toolkit

[Espinosa]

No ja bych se hlavne VYHNUL emocionalmim postojum pri vyberu GUI frameworku. Za vyberem frameworku ma stat racionalni uvaha.

Zasadni kriterium pro adepta je napriklad perspektiva frameworku, ze nez se ho naucim nezahuci v propadlisti dejin. Pripadne jestli s takovou znalosti sezenu praci, nebo pokud zacnu OS projekt, tak sezenu dostatek pripevatelu a pokracovatelu. Obskurdni zastarale knihovny moc zajmu nepritahnou, a treba by to byla skoda, treba by to potopilo jinak zajimavy projekt.

Nebo jeste lepe, pokud se rozhodnete do nejakeho perpektivniho OS projektu prispet, znalost mainstreamovych framewoku bude jen k prospechu, vam i potencialnim uzivatelum.

Pokud opravdu neprogramujete GUI pro nejake hodne specialni zarizeni, kam jeste rozumna implementace Qt/Gtk nedorazila, napr GUI pro digitalni hodinky ;) zvazte rozhodnuti jeste jednou, jinak plati jeste tak Swing/SWT, XUL s WinForms. S takovymi WinForms se taky nestratite, i mimo svet Mona a Linuxu :)

[Bluebear]

Za vyberem frameworku ma stat racionalni uvaha.

Bohužel racionální úvaha je u tak složitého výběru problém; člověk by musel znát všechny, aby se mohl skutečně racionálně rozhodnout. Rovněž je problém posoudit, který framework má budoucnost a který ne

[Espinosa]

Ona ta uvaha zase neni tak slozita. Za trochu te prace a namahy to stoji, rozhodne u rozhodnuti ktere ovlivni vas profesionalni zivot ci "jen" vas project.

Srovnejte si, kolik kvalitnich programu je napsane pro ten ktery framework (jazyk, platformu) a uz dostanete snadno prehlednou mnozinu ne-li primo vysledek. Pak jeste omrknout prekvenci updatu, mrknout na kvalitu a zivost fora, zvazit licenci.

Jasne 100% jistotu vam zadna metoda neda, ale jeden by se mel alespon snazit snizit riziko spatneho rozhodnuti.

Jinymi slovy, pokud se hodlate pustit do nekterych v ankete navrzenych variant, rikujete HODNE. S Qt/KDE/Gtk/Gnome/Swing/SWT/WinForms nemuzete slapnout vedle. Konkterni vyber uz pak zalezi spis na pozadavcich konkretniho projektu ci oblasti kam chcete pronikout (portable devices, enterprise aplikace, desktop tools).

AD perspektiva, framework s dostatecnym poctem aplikaci hned tak nevymizi.

[Miloslav Ponkrác]

Já bych řekl, že ta úvaha složitá celkem je.

Sice první úvaha je, v jakém jazyce to chcete programovat - tím se Vás značně zúží výběr.

Druhá úvaha jsou licence - značně podceňovaný problém. GUI framework pod GPL licencí může způsobit, že si v budoucnu budete rvát vlasy, a budete se muset znovu učit jiný gramework, tentokrát pod svobodnější licencí.

Třetí úvaha jsou vlastnosti frameworku - zda pokrývají vše, co potřebujete. V zásadě jsou frameworky dvojí - herní a pro GUI rozhraní běžných aplikací.

Čtvrtá úvaha je zda framework má verze pro všechny platformy, na kterých chcete participovat.

A konečně můžete si framework napsat i sám, takhle vznikly všechny frameworky, co se tu uvádí.

Třeba s Qt můžete hodně šlápnout vedle - a to licenčně. Máte na krku okovy GPL licence.

Gnome - můžete šplápnout vedle ohledně platforem - například na Windows (velmi rozšířená platforma, zajisté se shodneme) žádné gnome nenajdete.

Kde - viz gnome.

a tak by se dalo pokračovat dále

Šlápnout vedle můžete vždy. Počet kvailtních aplikací nad tím postavených může, ale nemusí být měřítkem kvality, ani použitelnosti daného frameworku. Bral bych to jen jako pomocné vodítko - které ale může zklamat.

Mimochodem, nejlepší grafický framework, z hlediska luxusu vývoje grafické aplikace, který jsem kdy viděl poskytoval Power Builder. Samotný Power Builder byl sice shit, který trpěl obrovskou chybovostí, a neuvěřitelnými problémy následkem ignorance firmy Sybase, ale ten princip grafického vývoje byl luxusní. Zažil jsem leccos, prošel jsem v praxi mnoha grafickými frameworky, ale po tomhle se mi fakt stýská. Zatím žádný framework nedosáhl na možnosti frameworku v Power Builderu.

[Espinosa]

Qt je dostupné pod několika licencemi. Není problém si koupit komerční pokud vás "okovy" GPL tolik tíží. Osobně shledávám licenční politiku Qt praktickou. Jak by to bylo s komerčním licencováním programu pro KDE popravdě nevím, ale určitě by se šlo s vývojáři domluvit, kdopak by se bránil penězům ;)

Jak je to s licencováním Gtk/Gnome framewotku nevím, ale existují komerční aplikace (resp. closed source) které Gtk/Gnome používají od boku třeba Acrobat Reader od Adobe, takže to určitě jde.

Qt pro Windows existuje od samého začátku své existence, a dost si na své cross-platformitě zakládá. Dále existují varianty pro Mac, WinCE, Java, Embedded - takže pokrytí platforem přímo luxusní.

Jedna z hlavních featur Kde4 je právě plná podpora Windows. Osobně čekám na Windows verze Digikamu a Kate protože nemám pro ně alternativu na Windows. Release Digikamu je na spadnutí a měla by existovat preview verze.

Gtk/Gnome je na Windows etablovaný už dloho, osobně používám Gimp. Nicméně výkonnost win verze poněkud pokulhává za linuxovou, má svoje problémky, celková integrace do win OS není úplně stoprocentní. Doufám, že KDE4 zvedne laťku :)

Gtk/Gnome má dobré pokrytí i co se týče jazyků - SWT-Gtk pro Javu (Eclipse), GtkSharp pro Mono, binding pro řadu dalších jazyků. Qt/KDE tady jen dotahuje (Jambi pro Javu, Python, Mono mapping - řada těch projektů je čerstvá a nepříliš rozšířená).

Takže co se týče podpory platforem, licence a jazyků mohu jen potvrdit - s Qt,KDE,Gtk,Gnome nemůžete šlápnout vedle.

Napsat si vlastní framework? Tak to by byl ten nejhorší možný nápad. Pokud se vám na nějakém existujícím frameworku nelíbí, a měl by jste takové "cuky" zakládat vlastní, raději se zapojte do vývoje existujícího.

Power Builder je výborný příklad, že i technicky zdařilý framework, se silnou komerční firmou v pozadí není zárukou ničeho. Kamrád byl expert na Power Builder, dost si na tom spálil prsty. Kdeska mu to na CVčku spíš straší a má problémy s hledáním práce.

Pointa je, že porovnávat jen schopnosti samotného frameworku nemá cenu, chce to širší pohled: jak je aktivní komunita (fóra, mail listy), podpora (ani placená není na škodu), dynamika vývoje (řešení bugů, release management) a samozřejmě a hlavně analýza nasazení.

[Ilfirin]

Ono drobná zrada u Qt je, že i ony bindingy jsou zpoplatněné a ne zrovna levné. Například kompinace Qt a PyQt už je poměrné drahý špás (pro neGPL věci).

Jak je to s licencováním Gtk/Gnome framewotku nevím, ale existují komerční aplikace (resp. closed source) které Gtk/Gnome používají od boku třeba Acrobat Reader od Adobe, takže to určitě jde.

(rejp: těch pár vteřin s googlem jste obětovat mohl) LGPL a licenci pokud vím, sdílí i bindingy, takže je možné bezplatně využívat i v uzavřených aplikacích napsané v jakémkoli (téměř) jazyce.

[Bluebear]

K čemu je taková anketa dobrá?

Výsledky a zejména diskuse se mohou hodit více osobám (například mně; taky takovou otázku řeším).

[Kvakor]

To by chtelo blize upresnit, o jaky typ GUI a pro jaky druh aplikaci. Protoze zatimco pro hru staci naprosto primitivni a jednoduche GUI (napr. to, co ma v sobe herni knihovna Allegro), je pro slozitou aplikaci typu textovy editor ci webovy prohlizec treba neco mnohem komplexnejsiho.

A take jde o to, jestli ma aplikace vypadat pokazde stejne, nebo jestli se ma stazit "zapadnout" do desktopoveho prostredi, kde zrovna bezi (i kdyz prvni pripad jde relativne bezbolestne prevest na druhy tim, ze se umozni skinovani).

Je tu jeste moznost psat aplikaci stylem frontend/backend, kde backend je CLI aplikace a GUI ma na starost pouze komunikovat s backendem a zobrazovat jeho vystup. Vyhodou je, ze backend jde ovladat i bez GUI (pro GUI muze mit specialni protokolol ci rezim, jako treba slave mod u MPlayeru) a tudiz jde pouzit ve skriptech nebo na zpracovani v davkach.

Protoze backend zadne GUI nema, muze byt diky tomu velmi prenositelny. A GUI se klidne muze napsat v nejakem skriptovacim jazyce ("tezkou praci" udela backend, takze rychlost je zde nepodstatna) a nechat na interpreteru, co pouzije na samotne vykreslovani.

[Michal Fecko]

ncurses everywhere!

[David Watzke]

No kdybych nemohl pouzit qt4 a xlib by nestacilo, vykaslal bych se na gui. Stejne to nikdo nepouziva

[Ilfirin]

FLTK2 a jen proto, že je velice podobné GTK (obejití omezení v otázce ). Nebo ty wxWidgets. Oboje má Python binding tak no-problemo.

[pozortucnak]

A jde v tom FLTK2 napsat vzhledově hezkou aplikaci?

[Ilfirin]

screenshoty - www.fltk.org/shots.php

Je to hlavně takové lehčí (ve smyslu velikosti a rychlosti) GTK. Dillo prohlížeč právě kvůli tomu na to přeběhl.

Ale. Jak už ti poradil Espinosa, jsi blbec (pardon), pokud v tom hledáš emoce. Do tohohle odvětví žádné nepatří. Licence/cena a vlastnosti jsou jediné, co hraje roli.

Já jsem osobně měl rád Qt, ale jeho Qvšechno zápis a licence, která mě nutila platit za uzavřené aplikace (pozor! to nekritizuji, prostě to tak je a je to jedno z kritérií rozhodování. Bejt velká firma a Qt milovat, neváhám s koupí) mě nakonec převlála k GTK a zatím spokojenost, umí běžet i na Widnows a na mobilních zařízeních (vím, Qt je v tomhle o trochu dál).

Jaké jsou vlastně ty důvody, že tyto dva toolkity odmítáš?

[pozortucnak]

Kvůli věční rozporům diskuzím flame... GTK je pomalá, QT má blbou licenci...

Asi by byla blbost napsat komerční aplikaci jako frontend/backend s tím že by backend byla ta komerční část a frontend by byla jako open-source napsanaá v QT... doufám že chápete jak to myslím...

[Kvakor]

Asi by byla blbost napsat komerční aplikaci jako frontend/backend s tím že by backend byla ta komerční část a frontend by byla jako open-source napsanaá v QT... doufám že chápete jak to myslím...

Podle mne to zas takova hloupost neni (viz muj prispevek vyse), protoze bezny uzivatel si toho ani nevsimne (kdyz se to dobre udela) a u profesionalu si tim naoak splhnou (napr. dobry backend bude mozne pouzivat ve skriptech a podobne).

Jedina nevyhoda, ze pro urcity typ aplikaci se muze stat komunikace frontend/backend uzkym hrdlem (spis v dusledku latenci nez propustnosti). To jde ale obejit tim, ze backedn nebude samostatny program, ale knihovna - to je metoda casto uzivana closed-source ovladaci, kde je "frontend" (interface vuci jadru) dostupny jako zdrojak (aby ho bylo mozno prelozit vuc aktualnimu jadru), kdezto samotny ovladac je staticka knihovna, resp. nekolik verzi knihovny pro ruzne volby jadra (SMP, HighMem ...), pripadne i achitekturt (i686, k7, amd64 ...).

[pozortucnak]

Mě jde o to jestli lze takto použít QT knihovnu ve close-source aplikacích.

[Ilfirin]

jop, a je to velmi oblíbená metoda

[Miloslav Ponkrác]

Problém je, že musíte navíc řešit API backendu, musíte napsat komunikaci mezi frontendem a backendem, musíte jak na straně frontendu, tak backendu napsat kód, který převádí vnitřní struktury a toky kódů na zvolené API a komunikační protokol, ať se komunikuje čímkoli.

V konečném důsledku je výsledný program složitější a víc se naprogramujete.

I když bude backend jako knihovna, problémy máte stále.

Nedávno jsem řešil backend pro práci s daty. V C++ je to jedna třída s asi 20 metodami, velmi jednoduše a luxusně se sní pracuje. Chyby hlásí výjimkami a data vrací v objektech typu ::std::vector a pod..

Protože však bylo nutné to použít jako univerzální backend, a to pro části psané v C a Visual Basicu, bylo třeba to zapouzdřit do sdílené knihovny s C rozhraním. Výsledek je 87 API funkcí, kde každá API funkce vezme parametry, převede je pomocí konverzních funkcí na objektu, zavolá požadovanou akci, převede vše zpět na C datové typy. A navíc je každá API funkce zabalená do try / catch bloku, který převádí výjimky na chybové kódy a chybové zprávy (které se dají získat přes jinou API funkci). Když jsem se na to díval, tak vlastní výkonný kód je cca 1/3 celého kódu, většina kódu je implementace C API.

Takže zase tak výhodné řešení to být nemusí. Záleží na tom, zda toto rozdělení přinese nějaký výrazný pozitivní efekt. Pokud se má rozdělovat jen proto, aby se obešla licence, myslím je lepší se na daný framework s nevhodnou licencí zvysoka cosi a zvolit jiný framework.

[pozortucnak]

Swig?

[Ilfirin]

Kvůli věční rozporům diskuzím flame... GTK je pomalá, QT má blbou licenci..

Tak tohle by ti mělo být naprosto u ... . Lidi flajmují kvůli všemu, v tom nehledej nic smysluplného. Opravdu se spíš zaměř na to, co potřebuješ (vlastnosti, licence) a s čím se ti bude lépe dělat (projeď si Hello Worldy).

PS.: Flejmující jedinci tvoří s přehledem mizivé procento uživatelů daného software, na to nezapomínej. Skutečné většině uživatel je toolkit ukraden, záleží na funkcionalitě (a alespoň trochu nativním vzhledu).

Přesto ale dík za anketu, donutilo mě to se zamyslet, co bych dělal kdyby ne gtk/qt .

[J. M.]

Flejmujících je skutečně málo, ale těch, kteří si stěžují na pomalost GTK+ a Qt je velmi hodně. 99 procent lidí dnes už totiž neví, co to je flame, je to jedno z nejzneužívanějších a nejdevalvovanějších slov na internetu. Diskuse a kritika opravdu není flame. Flame jsou dlouhé vášnivé rozepře s osobními útoky, nadávkami apod. S tím nemají stížnosti na pomalost toolkitů vůbec nic společného. (Naštěstí éra, kdy jakákoli kritika čehokoli linuxového na ábíčku znepokojovala místní příznivce „klidu na práci“ natolik, že ji automaticky nálepkovali jako flame, už je pár let za zenitem.)

A myslím, že rychlost toolkitu by skutečně měla být jedním ze zásadních kritérií při výběru. To, že většinou není, je dáno hlavně setrvačností, stádností a tím, že spoustu lidí nad tím ani nenapadne uvažovat (protože mají v hlavě to dávno neplatící léta obemmílané klišé, že GUI má nulovou režii a úzké hrdlo jsou ty vlastní výpočty aplikace – to platí ve světě Microsoft Windows, které má extrémně efektivní, rychlé GUI, ale v linuxovém světě rozhodně ne). Zejména složitější multimediální linuxové aplikace pak takovým rozhodnutím trpí, viděl jsem hodně jinak velmi slušných aplikací, které byly totálně zkažné jenom tím, že jejich autor ze zvyku (protože to dělají všichni) vybral GTK+, čímž pádem většina výkonu procesoru byla spotřebována jenom na vykreslení toho GUI, nikoli na vlastní funkce toho programu. Tam je pak evidentní, že s výběrem toolkitu prostě autor šlápl zcela vedle.

Takže v takových případech (kdy se jedná o složitější, dynamičtější GUI, typicky např. ty audio/video sekvencery apod.), bych se opravdu velmi vážně zamýšlel nad něčím jako je FLTK. Jinak u nějakého prográmku s jedním malým okýnkem, které má jedno tlačítko a zobrazuje jeden údaj jako výsledek, je to skutečně jedno, tam by měl zvítězit pragmatismus a mainstream, tedy GTK+ nebo Qt.

[Ilfirin]

Takže v takových případech (kdy se jedná o složitější, dynamičtější GUI, typicky např. ty audio/video sekvencery apod.), bych se opravdu velmi vážně zamýšlel nad něčím jako je FLTK

Ehm. Největší z největších Ardour toto tvrzení zrovna nesplňuje.

Ke zbytku víceméně souhlas, akorát já té honbě za rychlostí nepřikládám takovou váhu a její dopady (Nepřišlo mi, že by VLC, SMplayer apod. měli s rychlostí toolkitu problémy) také nevidím tak katastrofální. Nicméně pomalejší než MS Windows GUI je to rozhodně.

[J. M.]

Právě Ardour je jeden z těch smutných případů, které na to doplácejí. Starý Ardour se postavil na GTK+ 1.x, které bylo řádově rychlejší než GTK+ 2.x (asi tak jako rozdíl mezi Windows 98 a Vista). Tehdy nikoho nenapadlo uvažovat, co bude potom. Bohužel pak už ze zákonu setrvačnosti bylo jasné, že když přijde GTK+ 2.x, samozřejmě na něj i aplikace časem „upgraduje“. Což byla velká škoda, od té doby je pro mě Ardour prakticky mrtvý, protože s GTK+ 2.x žere jeho GUI snad dvacetkrát víc výkonu procesoru jenom na triviality jako vykreslení času v hlavním okně apod. Jenom taková prkotina sežere dvacetkrát víc výkonu procesoru než realtime audio efekty, což je opravdu velmi, velmi absurdní. Ostatně, o tom, jak GUI Ardouru po přechodu na GTK+ 2.x zlenivělo, tady psal už před lety Ctirad Feřtr, který se hodně vyzná... Takže z mého pohledu to byla jasná chyba v úsudku, moc rád bych viděl něco jako Ardour ve FLTK.

[pozortucnak]

Hádám že TK bude ještě řádově pomalejší než GTK

[J. M.]

Jestli myslíš Tk (ne TK), ten už sice vídám málokdy, ale to je kategorie bleskurychlých, primitivních toolkitů z dekád minulých. To je lehké jak pírko, GTK+ 2.x je oproti tomu obří komplex atomových elektráren. Teď si třeba pro představu prohlížím idle, pythonové IDE udělané v Tk... No to to sviští jako kdybych na svém počítači spouštěl MS DOS z 80. let minulého století... Mnoho, mnoho, mnohonásobně rychlejší než GTK+.

Já jsem ale psal o FLTK, ten nemá s Tk nic společného (kromě rychlosti).

[pozortucnak]

No já jse myslel že je pomalé kvůli vazbě na tcl...

[J. M.]

No, teorie je jedna věc (navíc se dá se používat i s jinými jazyky např. tím Pythonem, u kterého je to pořád jeho „vestavěné„ GUI, které se k němu přibaluje), ale ten toolkit sám o sobě je hodně jednoduchý, v podstatě archaický (i když se pořád vyvíjí) a tím pádem ta rychlost u běžných aplikací je opravdu o dekádu jinde než u GTK+ (zmiňovaný rozdíl Windows 98 vs. Vista), které má všechny ty monstróznosti jako GObject, Pango, Cairo, pokročilé skinování atd., které jej sice možnostmi staví do jiné ligy, do třetího milénia, ale tím pádem i úplně jiné váhové kategorie. Navíc je GTK+ velmi mizerně, neefektivně napsáno (jsou jiné toolkity, které jsou při obdobné funkčnosti v mnoha ohledech mnohem rychlejší, v rychlosti vykreslování, překreslování, jednotlivých widgetů i celkově, obecně, např. při změně velikosti, věcech jako jsou velké množství položek v menu, souborové dialogy, ale i rychlosti těch kreslících knihoven – Arthur z Qt 4 je daleko rychlejší než Cairo atd.), takže to je opravdu z těch běžných toolkitů jedna z nejpomalejších věcí, co člověk může použít. Prostě GTK+ je toolkit, který se používá kvůli všemu možnému jen ne kvůli rychlosti. To je nejslabší vlastnost GTK+, kterou lidé jenom laskavě trpí nebo tolerují, protože uznávají jiné, praktické výhody, zejména tu rozšířenost a všudypřítomnost na linuxových a podobných systémech, na rozdíl od lehčích a rychlejších, ale mnohem exotičtějších toolkitů.

[petr_p]

Věděl byste o toolkitu, který by zvládal pravolevý text a dosazování glyphů z jiných fontů a zároveň byl rychlejší než GTK+?

Co mám zkušenosti, tak to zvládá pouze GTK+ s pangem a pak Qt4. Qt3 má problémy se substitucí, Tk neumí pravolevý text. Ostatní toolkity ani jedno nebo zavaří X server při hledání fontu.

[Ilfirin]

Přiznám se, že jsem barbar a z tohoto pohledu jsem na to nikdy nekoukal (vteřina sem, vteřina tam). Díky za zajímavé info, někdy si budu muset splácat nějaký GTK2/FLTK2 benchmark.

PS.: Jestli je to opravdu tak špatné, tak doufám, že s tím něco udělá GTK3 (jednou, možná ...).

[J. M.]

Ano, benchmark! To bych moc rád viděl. Já ta čísla střílím od boku, ale benchmark by s tím pohnul, ten se dá brát vážně.

[Josef Kufner]

Za benchmark se přimlouvám. Chtělo by to srovnání nějakých jednoduchých programů v Gtk, Qt, toho co je v anketě a Xaw3D (je v tom napsané např. gv). Pro každý toolkit by měl napsat někdo, kdo ho ovládá, program v nativním jazyce toolkitu a pak z toho uděláme velikánský koláč a co ho bude mít největší kus je žrout

[J. M.]

To by bylo taky nejlepší řešení toho „jednou, možná...“ Když lidé houfně píšou v diskusích, že je GTK+ pomalé, s vývojáři GTK+ to ani nehne (za celé ty roky s tím neudělali prakticky nic, kromě každoročního dalšího drastického zpomalování). Ale když někdo udělá seriózní benchmark, který se pokud možno publikuje (nebo odkaz na něj) na nějakém významnějším serveru, to je podle mě ta nejlepší věc, co může se stavem věcí pohnout. Rozkřikne se to, proslaví se to, už to nikdo nebude moct bagatelizovat, pro vývojáře jednotlivých toolkitů to bude výrazná motivace zlepšit to, kde jejich produkt zaostává oproti konkurenci. Zářná budoucnost s rychlejším linuxovým GUI pro všechny bude na dosah.

Například, za jak dlouho GTK+ vykreslí do okna 100 (1000, 10000...) spin buttonů, a za jak dlouho FLTK? Srovnání s Win API/MFC (ne s tou superpomalou imitací ve Wine!) by pak bylo třešinkou na dortu.

[dvh]

Ja som asi pred 2 mesiacmi robil benchmark rychlosti gui. Vytvorenie 936 buttonov v mriezke 36x26 na okne. Meral som rychlost generovania a potom rychlost prekreslenia po navrate z minimalizacie. Tu su vysledky:

Toolkit  Vytvorenie  PrekresleniePoMinimalizacii
GTK1      7.2s       0.4s
GTK2     17.0s       2.8s
XUL       2.5s       1.5s
STK       1.2s       0.4s

[J. M.]

Díky! Zajímavé. Ale mohl bys to prosím zopakovat se spin buttonem? Ten je podle mých zkušeností (na mém počítači) v GTK+ neuvěřitelně pomalý, několikanásobně pomalejší ve vykreslení než všechny ostatní GTK+ widgety (a hrozně viditelně zpomaluje všechny dialogy a záložky, ve kterých se vyskytuje, což mi strašně moc vadí). Dokonce jsem si taky spíchl takový benchmark (srovnávající jen rychlost vykreslení jednotlivých widgetů GTK+), který mi to potvrzuje. Takže kdyby to někdo seriózně předložil vývojářům GTK+, jsem přesvědčen, že by popátrali po příčině.

[J. M.]

Teď jsem to u sebe znovu zkoušel, a jen pro představu – rozdíl v rychlosti mezi vykreslováním záložek se spinbuttony (gtk_spin_button_new_with_range)a s obyčejnými tlačítky (gtk_button_new_with_label) byl více než desetinásobný (obsah záložek s buttony se vykresloval desetkrát rychleji než se spinbuttony).

[pozortucnak]

Není XUL v Linuxu náhodou děláno pomocí gtk? Jestli se nemýlím tak XUM jsou například songbird nebo samotný firefox...

[J. M.]

Ne, a proto paradoxně např. ačkoli obcně to XUL GUI je (v té linuxové verzi; windowsová je samozřejmě mnohem rychlejší) ještě několikanásobně línější než GTK+ GUI, některé věci se paradoxně vykreslují ruchleji než v GTK+. Klasicky ty spinbuttony, o kterých pořád píšu – překreslování v dialogových oknech při přepínání záložek se spinbuttony je rychlejší v tom Firefoxu než ve skutečném GTK+ GUI. Firefoxí XUL na Linuxu GTK+ imituje, ale není tro GTK+. Z GTK+ používá pár částí jako souborové dialogy a aktuální motiv vzhledu, kterým pak vykresluje ta svoje okna, nabídky, dialogy a tak, čímž vzniká dojem, že to je GTK+ aplikace.

[hikikomori82]

Prave som vyskusal spinbuttony a mas pravdu. Buttony alebo checkboxy asi 17s s tym ze sa 17s nic a potom sa naraz vykreslia. Spinbuttony sa vykresluju okamzite ale vo vlnach. Spolu 45s. Najprv 2 horizontalne ciarky v prvej vlne ktora trva 30s, potom nasleduju 2 vertikalne ciary ktore sa vykresluju asi 10s, zvysnych 5s sa vykresluje finalny obraz ale paradoxne odzadu. Prekreslenie po minimalizacii nejakych 7s. Wow.

[J. M.]

Ano, přesně, to postupné vykreslování - když je v dialogu víc spinbuttonů, je to tak pomalé, že jsem bez problémů schopen zachytit screenshot toho napůl vykresleného dialogu! Další zajímavá věc je, že Qt 4 s tím svým novým gtkstyle enginem, který vykresluje widgety jako GTK+ (tedy Qt s vzhledem GTK+), ty GTK+ spinbuttony vykresluje jako Qt, tedy chvíli počká a pak je tam dá okamžitě. A asi je nějak cachuje, protože pak při dalším přepnutí na tu záložku není žádná pauza, jsou tam okamžitě, zatímco u GTK+ se při každém dalším přepnutí záložky na tu, která obsahuje spinbuttony, znovu a znovu ty spinbuttony v ní postupně pomalu vykreslují. takže paradoxně „GTK+ pod Qt“ je o hodně rychlejší než samotné GTK+ (tedy v tomto ohledu, v jiných zase pomalejší).

Já na jednu stranu chápu, že vykreslit spin button, s těmi šipečkami vpravo, je zákonitě náročnější (a tudíž pomalejší) než vykreslit třeba obyčejný textový boxík, ale i tak mi ten rozdíl přijde příliš drastický. Nešlo by to nějak nahlásit vývojářům GTK+? Třeba i s tím benchmarkem, zdrojovým kódem k němu, nebo prostě jenom to nějak seriózně popsat... Fakt to je věc, která podle mých zkušeností v posledních letech nejvíc vizuálně zpomaluje GTK+, nejvíc kazí dojem, takže by stálo za to se tomu podívat na zoubek.

[hikikomori82]

Příloha:

• cairo_benchmark.PNG (5874 bytů)

V prilohe je moj benchmark rychlosti vykreslovania buttonu pomocou kniznice CAIRO. Cele okno (tych 936 buttonov) vykresli za cca 3s (pri vychdzom vzhlade tlacitka).

Tiez som spravil test spineditu vo win32 na winXP, tam to ide 10s. Samotne kreslenie 936 spineditov (ak ich dam len vykreslit na okno, bez komponentov) je okamzite cize tych 10s nerobi grafika ale kod toolkitu, na linuxe to bude asi podobne.

[Vinicius]

Při výběru bych v úvahu vzal také existenci či neexistenci GUI návrháře. A taky možnost načítat GUI z XML souborů, aby se při úplně každé změně GUI nemusel znovu kompilovat program. Při neexistenci IDE pro danou kombinaci GUI knihovny a jazyka se to hodí.

[YYY]

tk rulez

[Kafař obecný]

Swing?

[Deleted [8409]]

Nečetl jsem to tady úplně celé, ale myšlenka napsat vlastní toolkit mě nenechá spat už tak 3 roky. Po této době mám celkem jasno o tom, jak by takový toolkit měl vypadat (API) a na sourceforge mám počíteční implementaci některých částí.

Jedná se o tento projekt: http://sourceforge.net/projects/wdesktop/ Koukněte kdyžtak jen do SVN, ty downloady jsou zastaralé (mnoho se změnilo).

Jestli má někdo podobný názor jako já, nemám problém se spojit a vyvíjet společně. Zatím mám jen příznivce, ale ne reálné vývojáře, kteří by pravidelně přispívali.

Zatím dělám na grafické knihovně FOG, kterou mám i jako diplomovou práci. Bude to hlavní kreslící nástroj pro GUI, který bude umět zrychlit kreslení použitím více vláken (na multicore) a speciálních instrukcí SSE2, MMX (na x86/x64).

Knihovna byla dřív napsaná ve stylu C/C++, ale nyní je konečná filozofie udělat z ní pure C++ (ale bez výjimek a STL, za tím si stojím).

Chtěl bych o tom někdy něco napsat, ale časově na tom nejsem moc dobře v poslední době:(

[pozortucnak]

Funguje v gtk1.x vyhlazování písmen? A co je na GTK1.X špatného?