Vlákno názorů k článku Jak na GUI s wxPythonem od Adam - 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...
-
Adam (neregistrovaný)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. -
anonymníDěkuji Adamovi za jeho příspěvek. Přišel jsem z Win a takové finesy, o kterých píše, jsou utajeny. Prakticky od DOSu mám návyk na obrazovku skládat boxy, co se jich vejde. A pak se plácám, když mi něco vyteče....
Nad podobným chováním jsem vůbec nepřemýšlel, že by mohlo chodit.
Prosím, lidé, kteří něco umíte, pište tutoriály.
V Javě jsem vyvíjel aplikaci, jednoduchou databázi. A nikde jsem nenašel popis, jak z okna zavolat okno a jak mu předat parametry. (Při vyplňování formuláře je třeba do číselníku zadat novou položku).
Spousta seriálů se věnuje základům, ale návod, jak efektivně pracovat s dokumentací javy a jak tam něco najít nikde.
Stejně tak mi chybí návody na NetBeans a Eclipse - ne jen technický a marketingový popis, ale zkušenosti uživatele. Něco nakousl Roman Pichlík, ale...
Takže seriál jak napsat databázovou aplikaci pomocí Eclipse, odladit a připravit k distribuci by pro mne měl cenu 1000Kč placeného obsahu.
Co na to autoři, provozovatelé portálů a ostatní informačně hladoví?
Michal -
anonymník tym oknam v jave: http://csis.pace.edu/~bergin/mvc/mvcgui.html - v skratke, data v okne (model), samotne okna (view) a logika (controller) su oddelene. ked chces, aby jedno okno vedelo o druhom, daj tomu prvemu parameter triedy typu jframe (triedy okna) a nasetuj ho na to druhe okno.
k databazam: su rozne pluginy do eclipse, ale vacsinou iba na preview tabuliek alebo generovanie xml pre hibernate... bud pouzi jdbc (http://www.onjava.com/pub/a/onjava/excerpt/javaentnut_2/index1.html), alebo lepsie hibernate, toplink. nebudes mat potom sql kod priamo naplatany v jave, ale budes mat objektove mapovanie. to je na dlhsie studium. pozri si toto: http://www.oracle.com/technology/oramag/webcolumns/2003/techarticles/pepperdine_TopLink.html -
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.
-
ava (neregistrovaný)
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.
-
Onyx (neregistrovaný)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. -
honza (neregistrovaný)....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 .... -
anonymníCo je to za hovadinu, prosímtě? Nejedná se o žádný "moderní" layout manager. Jedná se poctivou tvorbu GUI, která je třeba v GTK od jeho počátku přirozená. Na ergonomii to ničemu neubírá, právě naopak. Stačí se podívat na libovolnou GTK aplikaci. Jestli je neergonomická, pak to není z důvodu kontejnerového layoutu. Proto vyzyvam ostatni uzivatele, nenechte se omamit predvadeckama, kde se primitivni okenka pekne zvetsuji Pane boze, co to je za FUD? Týká se to libovolné GTK aplikace, a to nejsou žádná primitivní okénka. Seskupování prvků je možné jakékoli, dynamické GUI v tom neklade žádné překážky. Uvidite, jak rychle se koncepce zmeni .... Tak schválně, nějaký příklad, ať si uděláme jasno.
-
anonymníCo je to za hovadinu, prosímtě? Nejedná se o žádný "moderní" layout manager. Jedná se poctivou tvorbu GUI, která je třeba v GTK od jeho počátku přirozená. Na ergonomii to ničemu neubírá, právě naopak. Stačí se podívat na libovolnou GTK aplikaci. Jestli je neergonomická, pak to není z důvodu kontejnerového layoutu.
Proto vyzyvam ostatni uzivatele, nenechte se omamit predvadeckama, kde se primitivni okenka pekne zvetsuji
Pane boze, co to je za FUD? Týká se to libovolné GTK aplikace, a to nejsou žádná primitivní okénka. Seskupování prvků je možné jakékoli, dynamické GUI v tom neklade žádné překážky.
Uvidite, jak rychle se koncepce zmeni ....
Tak schválně, nějaký příklad, ať si uděláme jasno. -
honza (neregistrovaný)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. -
Lena (neregistrovaný)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. -
honza (neregistrovaný)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. -
anonymníBez fixniho layoutu se obejdu vzdy. To ze nevite o cem je rec, ze nechapete jak to udelat neznamena ze to nejde. Fixni layout je prekonany, nezadouci a neergonomicky.
Obavam se, ze jste ustrnul v dobe pred 15 lety a na zaklade vasich nesmyslnych tvrzeni (o velikosti tlacitek, fontech) se domnivam, ze vubec netusite, co je to dynamicky layout. -
Petr Mach (neregistrovaný)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.
-
Jakožto překladatel a lokalizátor uživatelských rozhraní si recipročně s radostí zamlouvám přednostní právo nakopat do zadku v pondělí ráno Honzu, protože bych mu nepřál problémy, jaké mi v práci působí fixní layout některých lokalizovaných aplikací a kolik mi přidělává neplaceného času, nehledě na to, jaké patvary mě nutí fixní layout produkovat v případě, že nemám možnost ho v průběhu lokalizace změnit. Automatický layout je i pro Honzovo dobro, i když mu to možná ještě nedochází.
-
anonymníNeviem kde na to chodite, ale tie linky musia byt poriadne stare. Nejaka archaicka verzia skutocne pouzivala rozmery a pozicie widgetov, ale to je uz davno deprecated. Vsetko dnes funguje systemom kontajnerov, vid. wx.Sizer a odvodene triedy.
1) Lokalizacia funguje uplne v pohode BEZ upravovania kodu. Skuste v dokumentacii hladat heslo 'internationalization'.
2) Velkost pisma a font sa urcite da nastavit, ale rozumny clovek to nepouziva. Standardne sa pouziva aktualna tema. Funguje mi to tak vo Windows aj v KDE. O Gnome ani najmenej nepochybujem. Kto chce, moze si samozrejme vsetko naskinovat sam, nastavit fonty, velkosti ... -
Lena (neregistrovaný)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í.
