Z toho rozboru show a showall vypliva, ze ten toolkit neni moc dobre napsany. Protoze preci by to showall slo napsat uplne stejne, jako kdyz clovek vola show sam. Jestli se to vi a nikdo to neopravi, tak je neco schnileho ve state danskem...
Oficiálně:
The show_all() method recursively shows the widget, and any child widgets.
A právě toto jsem zpozoroval. Strom Widgetů, horní widget zavolaný show_all(), tak se vykreslí a už se jede po stromu směrem dolů.
Což na pomalých/zpomalených strojích je pak vidět.
To je ovšem poměrně unikátní chování. Obvyklé bývá (ještě včera bych napsal že to tak je vždy), že každý prvek zavolá rekurzivně show na své potomky, pak se rozhodne jak sám sebe zobrazí (vypočítá velikosti, pozice apod.) a pak se teprve zobrazí.
Přiznám se, jsem na tenkém ledě. Takhle mi řpišlo, že se to chová, ale samozřejmě máte pravdu, že velikost podprvků musí znát, aby věděl, jak on má být velký.
Asi požádám o odstranění inkriminované věty, nasimuluji superpomalý stroj a zkusím to vypozorovat.
Já myslím, že výchozí chování a parametry snad není nutné psát. To bych je mohl psát všude a jsou widgety, kde jsou těch parametrů kotle. Naopak psát výchozí věci všude mi přijde jako "zbytečné zesložiťování kódu".
Většina knihoven je postavena tak, že nepovinné parametry jsou možnost a ne nutnost.
1) Přeplněný autobus nechávám ujet ;-)
2) Ovšem ani jí to neškodí
No pánové, diskutujete na zajímavé téma, ale na špatném příkladě. Já osobně strhávám za konstrukce typu "IF podmínka THEN RETURN TRUE ELSE RETURN FALSE" docela dost bodů.
Jinak řečeno, mělo tam být něco jako:
def pokus_o_zavreni_okna(self, widget, event):
return not self.smi_skoncit
A máte pravdu, stydím se.
Při psaní jsem zkrátka myšlenkově (ona sekce, "musíme se rozhodnout") na to if myslel, toto je samozřejmě o dost elegantnější.
Jestli delas ucitele, tak si dovedu predstavit, jaka jmena ti prideluji zaci mezi sebou.
Jinymi slovy - pro tebe mozna naprosto zrejme a presne citelne "return not self.smi_skoncit" pro nekoho jineho, kdo se teprve uci programovat je desivou komplikaci a diky temto konstrukcim se tak muze pro zacka stat programovani nocni murou do konce zivota.
Sam sebe neberu jako profesionalniho programatora, ale par jazyku uz jsem za tech vice nez deset let prostridal. Temto konstrukcim se vyhybam, jako cert krizi, protoze po par dnech, kdy dannou funkci nevidim mi vzdy trva dlouho nez prijdu na to, co a v jakem pripade vlastne vracim (nedavno se mi podarilo diky tomuto rozbit docela dost kodu).
A ano je to takhle rychlejsi - ale jestli chci honit rychlost, tak zvolim jako vychozi jazyk c/c++, pokud chci prehlednost a rychlost vyvoje, pak mam Python.
PS Kolik asi casu se usetri... na ukor citelnosti.... zvlast v GUI, kde stejne cekam, nez se vubec hne mys ?
Androide, taky nesnasim, kdyz nekdo napise do jednoho radku celej CAD a udela to v read-only perlu, ale v tomhle pripade je to s tou citelnosti je to pesne na opak. Proc budovat nejaky IFy kolem jedny boolean promenny.
Ovšem je pravda, že je to trochu ná úkor přehlednosti.
Nu nic, pravdu zde mají všichni (a nejméně já :-D ), takže hlasování:
a) dopsat Else větev a nechat return True, return False
b) vrátit znegované smi_skoncit
Nebo za c) můžeš na konec prostě napsat return False, protože to else je tam zbytečné - to bych preferoval já, protože to je technika, která je univerzálnější a je to přehlednější než s else větví.
BTW zase si do toho nenech moc kecat, je to Tvůj článek. ;-)
Vzhledem k tomu, že toto nemá být o Pythonu a referenční příručka mluví o True nebo False, nespecifikoval jsem to. GTK čeká holt pravdu nebo nepravdu a ta, jak víme, může být specifikována více způsoby než jen True/False.
None je nepravda.
Nechtel by jste nekdo napsat radsi serial o tomhle? Urcite se lepe uplatnite kdyz budete umet SWT/RCP nez PyGTK. Kolik nabidek prace vyzaduje tohle? A kdyz to nikdo nevyzaduje, tak proc s tim ztracet cas jenom proto ze je to OSS.
Psat o OSS technologiich je urcite fajn, ale clovek by nemel plytvat svou energii na neco, co nebude pravdepodobne potrebovat. Prakticnost!
To uz je lepsi QT knihovna nez GTK, obcas neco v QT predelavame. Ale fakt nesetkal jsem se s tim ze by nekdo prisel s pozadavkem na predelani aplikace (Py)GTK.
GTK pouzivaji snad jen u SUNu. Je nekde seznam komercniho softu udelaneho v GTK?
Proč vůbec programovat, když v bankách a politice leží peníze "na ulici"?!
Je to taky o tom, že řadu lidí to prostě baví (jestli víte, co to je).
Třeba mne Java (nevím, proč) prostě nebaví. Takže proč bych ji měl dělat? Pro peníze? Tolik mi nikdo dlouhodobě nedá, aby mě to donutilo se na ni vrhnout. (Pro Javu bych viděl moji bariéru odporu někde u 250-300tis.Kč/měsíc). Nebo snad ano? A pokud ano, kolik takových nabídek je? Řekl bych, že míň než těch na GTK. Takže Java pro mne prostě rentabilní není.
To je nejak prehodene. Business poziadavka je vacsinou nieco ako: "napisat UI rozhranie do LDAP" a nie "napisat nieco, to je jedno co, len aby to bolo v PyGTK (Visual basicu, QT, bla bla)". Kto vie PyGTK splaca to v PyGTK, kto vie Visual Basic pouzije Visual Basic. Dolezity je vysledok. Mne Visual Basic nevyhovuje, ako neznaly by som svoj cas skor investoval do ucenia PyGTK.
Vetsina nasich zakazniku si technologie vybira, protoze uz z praxe vi, ze se v aplikaci budou potreba delat zmeny, a kde sezenete matlala v PyGTK? Visual Basic ten snad uz dneska ani neni je jen verze pro .net.
Asi lamerská poznámka, ale sprostě jsem překopíroval text ze závěrečné verze příkladu, abych vyzkoušel, ale python mi tvrdí, že 'module' object has no attribute 'Window'.
Opet dekuji za clanek. Jen bych autora pozadal vyzkouseni:
- Python PEP 08 (jmena trida napriklad PrvniOkno misto prvni_okno). Vytvari to lepe citelne a prenositelne kody.
- pouzivani PrvniOkno(object) - zapina to novy OO engine v Pythonu (resi nektere problemy s MRO a je snad i rychlejsi).
- u PrvniOkno(gtk.Window) si priste pro zavolani __init__ u nadrazene tridy vyzkouset metodu super(), ta kdyz se pouziva konzistetne resi problemy s MRO u objektu a vicenasobnou dedicnosti:
k bodu 3
Ano asi nejlepsi je se kouknout do dokumentace, ale souvisi to s dedicnosti a spravnym poradi volani funkci predku. Nicmene jsme se uz i nekde docetl, ze nespravne pouziti muze byt osemetne.
Osobne doporucji knihu od Alexe Martelli, Python In a Nutshell.