Názory k článku
Jak na GUI s wxPythonem

wxWidget umi XML formaty (viz. napr. wxPython-demo - v adresari "demo/" si spustte prikaz "python XmlResource.py". Jinak diky za korekci v cestine. Dalsi dil je uz bohuzel odeslany, ale v 3 dilu si dam pozor.

Děkuju za upozornění, bude opraveno a koupím si lepší brýle, abych poznala v od V. (Ne že bych nevěděla, že se to tak nepíše, chyba je v očích, ne v hlavě. :-))

Zdravím.
Umí Boa něco jako XRC nebo Gladí XML? Lze generovat z Boa kód i pro jiné jazyky, že Python?

Jinak si neodpustím ventilovat názor na knihovnu wxWidgets: Pokud nepotřebujete, aby vaše aplikace vypadala nativně na všech běžných desktopových OS, pokud nepotřebujete aby chodila na počítačích Mac, sáhněte raději po pyGTK. Rychlejší vývoj, rychlejší spuštění a především lepší dokumentace.

Boa bohuzel neumi (alespon o tom nevim) generovat kod i pro jine jazyky. Vyber GUI jsem resil, kdyz jsem dostal za ukol napsat rozhrani pro jednu firemni aplikaci o vetsim rozsahu (cca. asi 200 formularu, 30 tiskovych sestav apod. a muselo to byt multiplatformni win - lin - mac).

Qt jsem zkousel - melo napr. problemy s tiskovymi sestavami pod MS Windows, GTK - na Mac OS padalo (pravdepodobne chybna sprava pameti v nativni knihovne). Takze mi zustalo wxWindow a u nej jsem zustal. Jako jeho nevyhodu bych uvedl napr. zobrazovani html - nefunguje podpora CSS, ale tu zase tak casto nepotrebuji a vetsinou se formatovani da obejit pomoci tabulek, akorat musite oprasit opravdu stare HTML a sledovat v dokumentaci podporovane tagy.

Zkušení programátoři wxPython nedoporučují, doporučují PyGTK.

http://www.abclinuxu.cz/forum/show/136766
http://www.abclinuxu.cz/blog/nijel/2006/1/7/116268

Tato ukázka navíc obsahuje extrémně špatný styl tvorby GUI převzatý z Windows. Ta špatnost spočívá v zadávání pevných rozměrů prvků, to je nežádoucí ze dvou důvodů:

1) znemožňuje to kvalitní lokalizaci, resp. při lokalizaci se musí upravovat i kód programu, přitom lokalizátoři neumí obvykle programovat, jen překládají lokalizační soubory. To proto, že třeba přeložený název tlačítka může být delší a do uvedeného rozměru se nemůže vejít. Když se změní, musí se pak přepasat i pozice všech prvků a vlastně celé GUI předělat.

2) znemožňuje to nastavení velikosti písma. To je v době displejů s čím dál vyšším DPI silně nežádoucí. V Linuxu na rozdíl od Windows nikdy nebyl problém si nastavit velikost písma. Ve Windows to (právě kvůli fixním rozměrům) způsobí nefunkčnost řady aplikací.

U GTK se rozměry a pozice nezadávají, používá se kontejnerový způsob skládání prvků, a tyto se automaticky přizpůsobují potřebám. Jestli wxWidgets toto neumí, nemají na Linuxu co dělat. Jestli umí, je tato ukázka příšerným příkladem toho, jak se to nemá dělat.

Takže snažně prosím, uveďte v příštím díle všechno na pravou míru a ukažte správný postup, jak vytvářet GUI aplikace. Neučte prosím lidi tomuto špatnému archaickému stylu, děkuji.

Pod toto se mohu podepsat, fixni rozmery opravdu ne, to je navrat na stromy.

wxPython samozrejme podporuje fixni rozmery widgetu, content managery a taky umoznuje ukotvovani hranic objektu.

Takze bych nekalil vody.

Nejde přece o to, co podporuje wxPython (stejně je ta podpora slabá), ale co autor učí čtenáře. A ten je učí neergonomický archaický fixní layout, který je uživatelům jen pro zlost.

Serial je psany pro naproste laiky a ti se musi od neceho odpichnout. V podstate bude zhruba nasledujici scenar: 1 - zakladni seznameni s Boa konstructorem, 2 - lokalizace a resource soubory, 3 - preklad do binarek (lin i win), 4-6 - neco smysluplnejsiho (navrhuji napr. adresar + sqlite + zaloha a prenos souboru + tisky + napoveda). 1) lokalizaci a resource souborum se budu venovat v pristim dile. Co se tyka pozicovani, jsou zde k dispozici v podstate stejne nastroje jako v GTK + napr. FlexGridSizer. 2) nemate pravdu, projdete si dokumentaci k wxPythonu a demo priklady.

Jeste jako dodatek - pokud jste zvykly na Glade, existuje projekt wxGlade (nezkousel jsem) - muzete se realizovat.

Nekteri zkuseni programatori wxPython nedoporucuji, jini ano, rozhodne nelze hazet vsechny zkusene programatory do jednoho pytle. Ja wxPython pouzivam a naprosto si nemuzu stezovat, jde o vyborny toolkit, ktery je perfektne prenositelny, pouziva nativni widgety (velke plus pri psani programu pro konzervativni zakazniky) a vyborne navrzeny. Samotne wxWindows za sebou maji vice jak trinact let vyvoje.

Nevim jak muzete odsuzovat neco co sam dobre neznate, a wxWindows zrejme moc neznate kdyz si kladete otazku zda podporuji kontejnerove umistovani widgetu. To samozrejme podporuji jiz davno a v dokumentaci je take napsano ze je to jediny doporuceny zpusob tvorby GUI. Neni podle me dobre kydat spinu na neco o cem nic nevim. Jinak s tim ze widgety by se mely povinne umistovat do kontejneru samozrejme souhlasim.

Opet tu padl mytus ze wxWindows maji spatnou dokumentaci. To je nesmysl, wxWindows samozrejme maji zdokumentovane v podstate vsechno co lze, k wxPython se samozrejme dodava demo ktere obsahuje demonstraci kazdeho jednoho widgetu, funkce a jejich vlastnosti.

Na zaver dva postrehy. Nejprve citat Guido van Rossuma (tvurce pythonu).

wxPython is the best and most mature cross-platform GUI toolkit, given a number of constraints. The only reason wxPython isn't the standard Python GUI toolkit is that Tkinter was there first.

a jeden muj postreh: Jestli povazuji nejaky stul tvorby GUI za archaicky, pak je to styl obsazovani handleru na tlacitku OK, stazeni hodnot z formularu, validace hodnot a nasledne nejake akce. Jediny dobry pristup (trosku fasisticke, ale podle me pravdive :-) je navrh s pomoci Model-View-Controller architektury. V tomto smeru se nejvic tesim na Traits/TraitsUI od Enthoughtu (viz http://code.enthought.com/traits/). Bohuzel se orientuji predevsim na Windows verzi a prave svoji distribuci pythonu predelavaji pro verzi 2.4, nicmene toto je cesta kterou bysme se meli pri vyvoji GUI ubirat.

Ja mam s wxPython v linuxu spatne zkusenosti, jenom kompilace toho je komplikovana, vzdy jsem to radsi nakonec vzdal. Balicky nejsou vsude k dispozici. Sirit takovy program mezi beznymi uzivateli je prakticky nemozne. Freeze take neni moc prakticke, coz dokazuje i to, ze zadna takova aplikace pokud vim neexistuje a jastli ano, tak ma nulove rozsireni.

Aplikaci napsanych v PyGTK je oproti tomu velke mnozstvi. Je to standard a prirozena volba pro python.

No pokud třeba chceš podporu unicode (což je podle mě rozumný požadavek), tak si to zkompilovat musíš, protože debiani baličky s touto podporou zkompilované nejsou.

....používá se kontejnerový způsob skládání prvků, a tyto se automaticky přizpůsobují potřebám. ...

jako uzivatel bych rad, aby programatori, kteri psali programy pro nas a pouzili ten "moderni" layout manager, kazdy tyden v pondeli rano nastoupili u nas pred firmu a od kazdeho naseho zamestnance vcetne ukizecek dostali kopanec do zadku, aby si uvedomili, ze nejaky layout manager sice mozna odebere programatorovi praci pro pozadavku atomatickeho zvetsovani oken na obrazovce, ale ergonomie se to nazvat neda.

Vim, ze to bylo ve specifikaci (tedy pozadavek plynuleho zvetsovani/zmensovani), ale zde ma dodavatel povinost upozornit na pozdejsi problemy ohledne ergonomie.

Proto vyzyvam ostatni uzivatele, nenechte se omamit predvadeckama, kde se primitivni okenka pekne zvetsuji, pozadujte ve specifikaci pozdejsi moznost seskupovani prvku podle vasich naroku. Uvidite, jak rychle se koncepce zmeni ....

ergonomie znamena, ze zalomeni textu nejake label se neridi tim, ze se sirka okna vydeli 4 (kdyz je zvolen treba matrix-layout se 4 widgety pro radku) a kazdemu widgetu v radce se priradi ta 1/4. To vypada silene. Obzvaste tehdy, kdy jsou texty ruzne dlouhe. Navic vetsina layoutmanageru nedokaze vyrovnavat napr. zvolene sirky zadavacich elementu (textwidget) a podle toho jak zvolil programator (a za neho to samozrejme rozhodla aplikace) ten pocet zadavanych znaku jsou konce takovych widgetu pod sebou nezarovnane, coz opet odporuje ergonomickym zasadam.

Strucne receno, nejaky vseobecny algoritmus nedokaze designera nahradit. To vubec nemluvim o tom, jakou paseku delaji fonty, ktere nelze zobrazit spojite ale v urcitych skocich a 1/2 vesch nastaveni vede k fontum, kde se meni totalne pomer vysky a tloustky znaku. Ergonometricka katastrofa. Ale co, pani programatori pred tim nemusi sedet 8 hodin denne, zejo.

... vede k fontum, kde se meni totalne pomer vysky a tloustky znaku ...

Ty už to fakt nehul.

S politováním musím říci, že jste vůbec nepochopil to na co reagujete. Vše co uvádíte je samozřejmě špatné, ale netýká se to kontejnerového (dynamického) layoutu, o kterém byla řeč. Jinak řečeno, oni o voze a vy o koze.

U dynamického layoutu o layoutu aplikace nerozhoduje aplikace, ale designer. Ten zadává kde co bude a jak se tyto prvky budou chovat. Podstata věci se skrývá poze v tom, zda prvky mají mít fixní nebo dynamickou velikost. Napříklat designer udělá tlačítko "OK" a nastaví mu fixní velikost. Potom někdo jiný někde jinde a někdy jinfy takovou aplikaci lokalizuje a přeloží "OK" na "Souhlasím" (jedná se třeba o vyjádření souhlasu se smlouvou). Tento text se do tlačítka nevejde a tak se zobrazí pouze "Sou" a konec. U dynamického layoutu se tlačítko roztáhne podle potřeby. A to individuálně podle potřeby každého tlačítka!

Ten samý případ je, když si uživatel zvětší písmo, protože hůř vidí, nebo má notebook s displejem 160 dpi a všechno je u něj 2x menší, než na disleji s 80 dpi. U fixního laoutu máte opět smůlu. Horní polovina každého řádku bude uříznuta. U dynamického se velikost prvků opět přizpůsobí.

Dynamický layout s fonty nemá pranic společného, to jste si popletl s něčím úplně jiným. Jestli je něco neergonomické, tak právě fixní layout. Dobře je to vidět ve windows, kde se zhusta používá (na linuxu naštěstí jen výjimečně a proto je dobře, že čtenáři protestují proti výuce fixního layoutu).

Ve windows se například lze často setkat s mrňavými dialogovými okny, které nejdou zvětšit (všechny rozměry jsou zadány fixně). V nich je pakt selectbox třeba s 50 položkami z kterých jsou vidět 2 až 3. A pak si v tom vybírejte. To je extrémně neergonomické. U běžné linuxové aplikace můžete dialog zvětšit a tím se udělá prostor na natažení selectboxu, takže je v něm vidět podle velikosti obrazovky třeba 10 až 15 položek, to je mnohem lepší.

Designer GUI musí s dinamičností layoutu očítat a správně ho navrhnout a nastavit (zadat výchozí rozměry, maximální a minimální rozměry, váhy a podobně), je to náročnější, než primitivní fixní layout (takže určitě nejde o šetření si práce, jak naznačujete).

V některých GUI toolkitech je tvorba dynamických layoutů jednoduchá a přirozená. Mezi tyto jednoznačně patří GTK, které je v tomto ohledu asi to nejlepší na světě napříč všemi platformami. Je vidět, že ho navrhovali lidé zaměření na grafiku, design a ergonomii. Bohužel ve wxPythonu to není žádná sláva, on koncepčně vychází z Windows, které jsou v tomto směru značně zaostalé a to se přenáší i do modelu wxPython.

Proto prosím příště nemluvte o věcech kterým nerozumíte. Musím pak ztrácet čas odpověďmi, které uvádějí takovéto bludy na pravou míru. A dále se připojuji k hlasům, které doporučují zapomenout na wxPython a používat PyGTK.

jestlize potrebujete dostat na obrazovku urcity pocet elementu a to z duvodu ERGONOMIE, aby uzivatele nemeli na obrazovce 150 okenek a nebo aby nemuseli porad nejaka okna sklapovat a otevirat, tak pak se bez fixniho rozdeleni neobejte.

Zcela zamerne jsem uvedl ve svem prispevku "jednoduche aplikace", ktere je mozno dynamicky realizovat (a uzivatele by se tim nemeli nechat zmast), ale tam, kde je mnozstvi udaju mate tolik elementu, ze vas "gumovym button", ktery by se jednoduse roztahl podle potreby (podle textu) se NEROZTAHNE, protoze nema kam. A jelikoz zadny designer nedokaze predem odhadnout, jake texty kam prijdou , tak pak je design rozhazeny a NEERGONOMICKY.

To, ze nikoho z diskutujicich nenapada, jak to udelat jinak nez dynamickym layoutem, aby se okna aplikaci dala zvetsovat a nebo zmensovat jeste neznamena, ze to nejde.

Jeste jednou, automaty, ktere usnadnuji praci "lokalizatorum" nemohou usporne vyuzit misto na obrazovce a proto se to hodi pouze pro jednoduche aplikace, ktere si mohou dovolit na obrazovce placat mistem. Zkuste si nechat udelat aplikaci, ktera zobrazuje burzovni data s vasim dynamickym layoutem, kazdy burzian vas nakope do zadku. A tim take koncim tu diskuzi, myslel jsem , ze se neco dovim, ale bohuzel jsou zde jen prezentovany odposlouchane a nabiflovane poucky zacinajicihc programatoru bez praktickych zkusenosti.

Já tedy opravdu nechápu, jak někdo může vydávat za ergonomické snahu nahňácat toho na obrazovku co nejvíc a navíc fixně, takže uživatelé s velkou obrazovkou stejně budou mít smůlu :-). Nicméně, ani takové prasárně se dynamický layout nebrání. Prosím honzu, aby zde ukázal screenshot aplikace, o které si myslí, že nejde udělat s dynamickým layoutem.

Ty linky jsou z letos, stačí se do nich podívat, to jste se nenamáhal, že ne? :-)

Ukázka zde na rootu jednoznačně používá fixní layout. Jestli to wxPython umí i jinak, ostuda padá čistě na hlavu autora článku.

1) U fixního layoutu, který je použit v ukázce článku bude lokalizace bez upravování kódu nemožná. Pravděpodobně jste nepochopil výše uvedenou kritiku. Nebyla to kritika obecná, ale tohoto článku na rootu.

2) Rozumný člověk si samozřejmě velikost písma nastaví svým potřebám. Samozřejmě že jde o systémové nastavení, ne nastavení každé aplikace zvlášť. Ve Windows zvětšení písma u řady aplikací dělá problémy a to právě z důvodu fixního layoutu, který tam aplikace velmi často používají.

Jakej existuje na pyGTK (nejlepsi) rad nastroj?
Muzu zabalit pyGTK aplikaci do jednoho executable souboru, tak aby "behala"
pod Win, Linux, ...?

V pristim dile se tomu budu venovat ;-)

Glade nebo gazpacho, oboji produkuje glade soubory. Obrovska vyhoda je, ze pokud python pouzivate na vytvoreni prototypu aplikace, tak GUI je bezezmeny pouzitelne v ostre implementaci.

Jestli myslite jednu binarku spolecnou pro windows i linux tak ne. Ale pro samotne windows lze pouzit napr. py2exe. V linuxu jsem to neresil, pygtk byva obvykle nainstalovano, takze je to zbytecne az nevhodne, pri mizerne binarni kompatibilite linuxu. Je lepsi vyuzit prirozene multiplatformnosti pythonu.

K vytvareni binarek ve windows pouzivam py2exe (obcas jsou problemy s MS win98 a nizsimi) a pod linux cx_Freeze. V linuxu jsem nejake problemy s binarkou nezaznamenal, naprogramuji to vetsinou na Debianu a bez problemu a dalsich doinstalovavani knihoven pouzivam v Knoppixu, Mandrive a SuSe (v dalsich distribucich jsem to netestoval). Vzhledem k tomu, ze jsem liny vytvaret rucne deb a rpm balicky, tak s uspechem k tomu vyuzivam checkinstall. Jinak s Vami souhlasim, ze nejlepsi je to nechat na pythonu.

Zdravim,

1) je krapytek zvlastni, kdyz autor basni o tom, jak je Boa a python a wx zalezitosti uz k dostani v baliccich a sam pote ukazuje screenshoty z windows verze onoho... :-))) (ale to jsem si jen nemistne rypnul)

2) btw. dost zvlastni bylo kdyz jsem chtel aby mi v okynku preskakoval focus v editboxech (tak jak byvaji lidi z woken zvykli) a uspokojive mi to chodilo jen na Windows - v Linuxu mi tam ta udalost o stisku tabulatoru proste nikdy nedorazila. Divne....

1 - To je bohuzel pravda, mel jsem zhavarovan notebook a nezbylo mi nic jineho, nez ty screenshoty udelat z MS Windows ktery jsem mel k dispozici.

2 - fokus v editboxech na linuxu funguje, budu se tomu venovat zhruba ve 4-5 dile.

No nezlob se!
To není argument a pro šiřitele jiného "evangelia" (sic!) ani omluva.
Nazvěme to diletanstvím a odfláknutím práce.

Bohužel, na rootu už jsem si tak trochu zvyknul.

Mozna me utlucete, ale na neco takoveho bych vzal Swing. Davno uz neplati ze je pomaly, v JSE 1.5 a 1.6 se udelalo opravdu hodne prace. Navic 1.6 ma ted nativni rozhrani pro GTK, win a mac. V novych verzich mi prijde Swing stejne rychly jako GTK. A clovek si muze vybrat z nekolika "klikatek", at uz NetBeans a jejich Matisse, nebo Jigloo pro Eclipsu nebo Ideu.

A zpakovat vse vcetne virtualni masiny jde take, ale daleko lepsi je webstart.
http://www.excelsior-usa.com/jet.html?post=jlsig

neutluceme, ja naprosto souhlasim :)

On je swig pro python? Jestli ne, tak je to nepatricna poznamka, protoze java nesnese s pythonem srovnani.

Ale Python není jen CPython, nýbrž i Jython :-) Jinak ti co chtějí SWT jsou na tom ještě lépe, kromě Jythonu můžou využít i PySWT.

Jo, ale to zpakovani jde jenom za tezky prachy.

Programovací jazyk a GUI knihovna jsou možná multiplatformní, ale rozhodně nejsou pod GPL.

Mimochodem pro zobrazeni HTML je celkem zajímavý projekt wxmozilla.

Jo, máte pravdu není to GPL :-))

The wxWindows Licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWidgets, and also those producing proprietary software.

BOA momentálně trpí zásadní vadou - už asi rok vývoj stojí. To je zlé. Začíná ho nahrazovat asi SPE - Stani's Python Editor ale ten ní zase tak integrovaný s GUI designerem (SPE používá wxGlade).

Staci nahlednout do mailing-listu:

From: Riaan Booysen
Re: current status
2006-06-13 13:36

Hi Zlatko,

Zlatko Matic wrote:
> Hello.
>
> I'm new to this e-mail list.
> Is this project (Boa) still actively developed? I ask this because I see
> that new version has not been released for a long time...

Yes, Boa is moving forward again. I hope there will be CVS release
in a few weeks with a few new features, most notably improved sizer
support.

Cheers,
Riaan.

Což ovšem neodporuje výše napsanému...

Me kdysi wxPython mirne vypekl. Prenasel jsem neco z Widli na Linux a wxGTK2 tehdy bylo jeste naprosto nestabilni (jakkoli GTK2 existovalo uz docela dlouho) a wxGTK1 neprechroustalo unicode retezce.

PyGTK je sice docela hezke, ale na Windows ma GTK dost nevyhod: 1) je to docela velke (mala aplikace zabalena pomoci py2exe po orezani GTK na minimum ma po zabaleni asi 3,5 MiB); 2) misto jednoho DLLka je to milion ruznych souburku; 3) neexistuje oficialni JEDEN instalator GTK pro Widle, resp. co je horsi spousta GTK veci pro Widle (namatkou GTK#, Gnumeric) si taha vlastni a cpou ho do cesty (PATH); 4) horsi podpora vlaken; 5) chce to pouzit napr. win32all pro souborovy dialogy nebot s temi od GTK by uzivatele cloveka asi umlatili :-)

2) me hodne, ciste osobni preference; 3) neexistuje :-) na gtk.org jsou jenom binarky pro kazdou knihovnu zvlast. neoficialni instalatory pak existujou minimalne dva; Gnumeric ani GTK# se me neptal jestli chci GTK+ instalovat; 4) viz PyGTK FAQ 21.3, netvrdim, ze nejde pouzivat vlakna, ale pokud nekdo vyviji na linuxu tak na to musi dopredu myslet, aby pak nemusel aplikaci upravovat

2) Tak to je potom irelevantní

3) Existuje oficiální port gtk na win32 s oficiálním instalátorem.

To že si některé aplikace GTK k sobě přibalují je stará známá bolest windows (dll hell), kdy aplikace přibalují všemožné knihovny. Jestli je pak instalují i když v systému jsou, je to chyba těch aplikací, ne GTK. Z osobní zkušenosti mohu říct, že chodu GTK aplikací to ani v nejmenším nebrání. Gaim se vás zeptá, jestli chcete GTK instalovat, Gimp GTK s sebou dokonce ani netahá.

4) Jestli chcete používat v aplikaci thready, vždy na to musíte dopředu myslet, jinak kvůli tomu budete aplikaci upraovat.

2) LOL, tak pro me urcite ne :-)
3) oficialni port existuje, oficialni instalator nikoli (nebo mi reknete, kde je na gtk.org umisten). to, ze si aplikace bali svoje GTK neni bolest Windows a akorat to zminovane DLL hell vytvari
4) ano, ale ma-li aplikace fungovat i pod Windows, pak nelze pouzit nejjednodussi zpusob prace s vlakny v GTK+

2) pro vás ne, ale je to subjektivní a imho zcestný názor

Třeba pro záplatování je lepší vyměnit jeden soubor o velikosti 50 KB, než soubor o velikosti 10 MB, čím víc souborů, tím větší pravděpodobnost menší záplaty.

Nebo při vytváření portabilní apliace třeba na flash disku nebo při použití freeze/py2exe je dobré minimalizovat její velikost, tedy odbourat všechno nepotřebné. Když máte všechno v jednom souboru, musíte to tahat všechno s sebou, i když 90 % toho nepotřebujete. Čím víc souborů, tím více zbytečností se můžete zbavit.

3) oficiální port existuje, odkaz na něj je na gtk.org a na tomto oficiálním portu je odkaz na stažení GTK

4) To je zase FUD. Moje aplikace thready používají (jak jinak u GUI, že?) a práce s thready je stejně jednoduchá. Vyzkoušejte si to prosím před šířením těchto nepodložených pomluv. Aplikace vyvíjím na střídačku ve windows i linuxu (i jednu a tu samou, u kterého počítače zakotvím, u toho zakotvím), běhají ve windows i v linuxu bez sebemenších problémů.

Při vývoji multiplatformní aplikace je potřeba dávat na rozdíly mezi systémy, například že mmap funguje jinak ve windows jinak v linuxu, že ve windows jsou jiné konce řádků než v linuxu, že v cestách jsou jiné oddělovače mezer, že threadi mají mírně odlišný model, všechno to jsou snadno řešitelné maličkosti a nic z toho nehovoří proti používání GTK, které je, a to zdůrazňuji, bezproblémové.

2) ano je to můj čistě subjektivní názor a nikdy jsem netvrdil nic jiného

3) žádný oficiální instalátor se na gtk.org nenachází. to těžko popřete

4) Tedy jednak si nejsem jist, že víte co je FUD a jednak neumíte číst. Já někde píšu, že nelze použít GTK+ ve Windows s vlákny? Nepíšu. Já někde píšu, že nelze napsat práci s vlákny, který funguje jak pod Windows tak pod Linuxem? Nepíšu. Vy jste si prostě vymyslela virtuálního odpůrce GTK+, který tvrdí věci, které jsem nikdy nenapsal a proti němu bojujete.

2) No, ale vydávat čistě subjektivní názor za objektivní nedostatek GTK, to je trochu silné kafe, ne? Zvláště když jde o tak, podle mě, nesmyslný požadavek. Jako programátoři bychom měli vědět, že je z řady důvodů lepší mít více kratších funkcí, než jednu obří a to se týká i rozdělení knihovny do souborů.

GTK se skládá z několika knihoven, glib, gdk, atk, pango a to celé zastřešuje gtk. Imho je toto rozdělení velmi rozumné. Dále jsou součástí gtk lokalizační překlady, každý jazyk má svůj soubor s překlady. Snadno tak můžete smazat třeba čínštinu o které víte že ji nebudete potřebovat a nebo dokonce všechno kromě češtiny a angličtiny, podle účelu použití aplikace. Opravdu nechápu, proč byste tohle všechno chtěl mít v jednom souboru, vždyť to přináší samé nevýhody.

3) Imho je rozdíl mezi původním tvrzení oficiální instalátor neexistuje a tímto novým tvrzením, existuje, ale nenachází se na gtk.org. V podstatě jste už odsouhlasil, že existuje a to gtk.org uvádíte, jan abyste si zachoval tvář.

4) Vy píšete, že ve windows je horší podpora vláken. Ale to není pravda, není horší, je jen jiná, protože windows s vlákny zachází jinak, je to vysvětelno v tom FAQu. Nijak vás to neomezuje psát aplikace s vlákny a uvádět to jako důvod proč GTK nepoužívat pod windows je neopodstatněné, takže se nedivím, že takové tvrzení vzbuzuje odpor :-).

2) já nic takového ale nedělám. já jsem popsal objektivně jednu vlastnost GTK+ s tím, že pro mě představuje nevýhodu. naprosto nikomu necpu, že to má být nevýhoda i pro něj. předpokládám, že každý člověk má svou vlastní hlavu a dokáže se sám rozhodnout jestli mu to vadí nebo ne.

3) a co je podle vás teda oficiální instalátor? Já si to představuju tak, že přijdu na oficiální stránky knihovny a odtamtud si ho stáhnu. A ktery z tech existujicich je podle vas ten oficialni? Ten Simoncicuv? Ale ten zase nabizi pouze runtime, ne SDKcko. Takze to ma byt instalator od gladewin32.sf.net (ktery nabizi balicky pro runtime i SDKcko)? Ale treba oficialni GTK FAQ dodnes zminuje instalator Dropline, ktery uz zanikl. Je tedy snad on tim oficialnim?

4) tak ja myslim, ze mohu rict, ze je horsi, protoze neumoznuje ten nejjednodussi zpusob prace s vlakny, ktery je jinak v GTK k dispozici. Pro Pythonisty to nastesti FAQ PyGTK popisuje, jak to lze obejit, ale treba ceckari to v GTK FAQu vubec nenajdou jenom v dokumentaci o GDK zminku "With the Win32 backend, GDK calls should not be attempted from multiple threads at all."

No ja myslim, ze silny zaludek chce hlavne cpat ostatnim lidem, co maji povazovat za vyhodu ci nevyhodu, za horsi ci lepsi apod. Ja si myslim, ze lide maji svou vlastni hlavu a dovedou si to zhodnotit samy. Ja jsem napsal, co mne konkretne na GTK+ pod Win vadi a nechapu, co je na tom spatneho. To ze ruzni lide maji ruzne pozadavky a stejne veci hodnoti ruzne je snad normalni.

OK, chapejte tedy vsechny me prispevky jako ciste subjektivni nazory, priste to radsi zvlast zduraznim, aby nedoslo k omylu.

V GUI toolkitech byl před pár lety strašný chaos, který do značné míry přetrvává dodnes. Probíhal přerod GTK1 na GTK2, knihovna Qt byla taky celkem v plenkách, dost programů používalo Tkinter, wx a výjimkou nebyly ani aplikace pouze s xlib. Naštěstí už to postupně krystalizuje a teď se uvidí, jestli zvítězí Qt nebo GTK nebo spolu budou nějak koexistovat. Obě jsou velmi dobré a je mezi nimi drsná konkurence. Dvě knihovny se dají ještě tolerovat - musí být záloha, když se jeden projekt sesype. Ale když je jich víc? To už není svoboda výběru, to už je bordel, tříštění lidského úsilí, brzda vývoje a plýtvání pamětí. Proto mě irituje, když někdo v dnešní době propaguje takové nedodělky jako je WxWidgets (nebo nedejbože Tkinkter), které by už dávno měly skončit na propadlišti dějin. Je jasné, že WxWidgets umře. Jde jen o to, za jak dlouho to bude. Podívejte se na Changelog u nejnovější verze: WxWidgets se stále ještě vyhrabává z dětských nemocí. Používá se (ve srovnání s GTK či Qt) zcela minimálně, proti GTK nemá vůbec _žádnou_ výhodu a pro nové projekty je to naprosto nevhodná knihovna.

Tohle je nesmysl. Qt je hezky, ale pro komercni ucely za tezky $$$. GTK+ je pekny a zadarmo, ale Widloidni verze neni uplne dokonala (viz me vyhrady v jinem komentari). Kdo vyviji primarne pro Windows tomu asi nic jineho nez zustat u wx nezbyde.

To je FUD. GTK ve windows nemá žádné problémy, PyGTK rovněž ne. Všechny mé GUI aplikace používají GTK a jsou primárně používány na Windows. Jediný problém GTK na windows je ten, že není součástí Windows a musí se nainstalovat. To je ale problém všech toolkitů, které nejsou od Microsoftu.

Tak FUD to urcite neni, to ze vy je nevidite neznamena, ze nevadi nikomu.

FUD to je. Já GTK při vývoji na windows používám už léta. Odmítam kategoricky vaše tvrzení, že to nejde nebo je to spojeno s problémy, není.

Já někde tvrdím, že to nejde?!? To jsou mi novinky. Možná to chce pozorněji číst. A věci, které mi na GTK+ pod Windows vadí jsem konkrétně popsal. To, že vám nevadí neznamená, že jiným vadit nemusí.

Úplně každá existující technologie má své výhody a nevýhody a tvrdit o něčem, že má jen výhody a žádné nevýhody je IMHO strkání hlavy do písku.

Aha, takže už to mám chápat tak, že má GTK konečně podporu tisku?! Přece jenom, na Windows se těžko bude instalovat něco jako gnome-print!

Bohužel, díky (ne)podpoře tisku pro mě GTK absolutně neexistuje, i když se v něm (občas!) píše dobře. Zvykl jsem si na wxWidgets, přece jen je to malinko objektovější než GTK a hlavně dobře navržené (ale tím samozřejmě netvrdím, že GTK není!). Spousta věcí se mi tam líbí, pár věcí ne, ale to už je u všeho. A až přidají do GTK tu podporu tisku, možná o něm začnu uvažovat. Teď... bohužel...

Tvrdíš, že pro všechny problémy ve windows je jejich průnik s GTK prázdná množina?

V čem se mi nejlépe píšou okení aplikace, tak je:
java: swing
c a python: gtk
c++ : qt.

S gtk jsem ani na Windows nikdy neměl žádný problém, to ale neznamená, že neexistují. I pro to teď volím raději wx, přestože se mi zdaleka nelíbí tolik, jako gtk.

Dle mého názoru záleží výběr toolkitu (u tak dobrých jako je qt, gtk, wx) čistě jen a pouze na programátorovi. Uživatel většinou ani nepozná (pokud okýnko vypadá podobně jako ostatní), co daný program pohání. Při použití py2exe nebo cx_freeze BFU (Bloody Fool User - přeloženo do češtiny: běžný uživatel Microsoft Windows) ani nepozná, že narazil na program napsaný v Krajtě.

doporucujem vsetkym vyskusat si aj PyQt pre Qt4
... uz je to nejaky piatok co s tym pracujem a je to fakt dobra vec

btw. asi by nebolo odveci vytvorit nejake porovnanie PyGtk, PyQt a wxPython. Viem ze take zrovnania po nete su, ale skoro vsetko s PyQt3, ktore spolu s Qt3 neni free pre win32 - co u ludi dost straca body

PyQt4 je ve stabilni verzi venku pomerne mlada viz. http://www.riverbankcomputing.co.uk/pyqt/, takze jsem ji nestihl jeste otestovat. V Qt3 jsem napr. pod win narazil na par pro me zasadnich problemu a proto ji zavrhnul (testoval jsem komercni verzi).

Mohl byste být prosím konkrétnější?

docela dobra diskuze nad tematem "Hello World!", ale zase na druhou stranu se clovek alespon neco dozvi. Otazka zni, jetli k tomu ucelu by nemel slouzit ten clanek ;)

Zdravím autora a všechny čtenáře!

Tento článek a celý seriál mě nesmírně potěšil, jednak proto, že jsem dlouhodobým vývojářem–uživatelem wxPythonu, a jednak proto, že jsem dlouhodobým vývojářem–uživatelem Boa Constructoru☺