Názory k článku
Vyvíjíme multiplatformní programy na Linuxu (1)

Myslím, že příznivci Open Source nikoho kamenovat nebudou. Kamenovat budou příznivci Free Software :)))

Ale jinak pěkné, ač bez dalších dílů v tuhle chvíli nevím skoro nic...a kdyby jen dnešní aplikace netvořily takové příšerné slepence kódu...ne, že bych jim nedůvěřoval, pokud jde o funkčnost. Ale člověk se občas v tom kódu ztrácí :))) (zlatý ST-80 :)

u vetsiny objektovych jazyku dnes plati, ze pokud znas jazyk je to jen maly kousek k tomu zacit programovat. nejdulezitejsi je znat knihovny. ackoli python vubec nezvladam - programuji v jave - tak verim tomu, ze clovek ktery je v py zbehli tomuto kodu lehce porozumi (kdyby to nekdo napsal takhle nejak v jave tak bych to asi chapal:-)

zajimavy clanek... diky

U těch nejlepších se složitost jazyka limitně blíží nule a schopnosti knihovny zase nekonečnu :)

Já to samozřejmě chápu, nic proti tomui nemám, ale přeci jen se cítím mírně pohodlněji v převážně homogenním prostředí (asi to bude deformace, já vím :). Už jen proto, kdybych se snažil narvat to do co nejmenšího objemu. Už vidím, jak třeba embedded aplikaci pro 8MB stroj skládám z komponent v několika jazycích, aby se to tam přád ještě vešlo :)

"Při řešení této problematiky vedly v zákysech Windows, i když nevím, jestli za to přímo mohly."
Tahle věta mi nedává moc smysl.
Jinak je to docela zajímavý, akorát sem teda zvědav na další díly.

Taky mi to chvili trvalo zparsovat, ale veta smysl ma :)
Jakoze Windowsy, neznamo, zda vlastni vinou, zakysavaly vic :)

Já to pochopil tak, že "zakysával" autor při řešení problémů.

Řešil jsem návrh technologií multiplatformního (Linux, Windows) jednoduchého GUI programu, který by šel distribuovat na Windows v binární formě a vše potřebné (pro běh na "holých" windows bez jakýchkoli doinstalovaných knihoven nebo prostředí typu GTK+, Qt, wxWindows, JRE nebo python.exe) šlo přinést na jedné disketě nebo stáhnout po modemu. Na Linuxu by musela fungovat diakritika a přepínání klávesnice (to vylučuje např. FLTK). Nevymyslel jsem nic lepšího, než vytvořit vlastní C++ GUI knihovnu nad Win32API x (Xlib nebo Qt, GTK+, ...) a napsat program nad ní. Jsem zvědavý, jestli autorovo řešení splní mé nároky. Rád se proto nechám poučit o detailech a úskalách převodu z *.py do *.exe.

No ale přesně to, o čem píšeš, dělají wxWidgets (dříve wxWindows). Tj. slouží jako jakási mezivrstva mezi GTK / Win32. Samozřejmě asi obsahují spoustu tříd, které nevyužiješ, na druhou stranu psát si vše sám a znovu - na to je třeba dost času.

Krom toho si myslím, že s modemem jde tahat celkem v pohodě soubor do cca 4 MB. Stáhnutí trvá necelých 20 minut a to je ještě pro většinu uživatelů únosné.

Mimochodem hezky příklad toho, kdy si autor napsal vše úplně od základů, je slovenský "photoshop" pixel32 - http://pixel32.box.sk.

A právě wxWidgets + GTK by si musel uživatel Windows stáhnout, takže to není to, co jsem chtěl. Opravdu mi jde o to, aby to, co se musí tahat na holý a typicky nainstalovaný systém (jak Windows tak Linux) mělo do pár set kB a dokázala to i úplná lama. Na ten pixel32 se podívám.

wxWindows nepotrebuji na woknech GTK. pod pythonem jde samozrejme jeste pouzit TCL/TK. (to je pak jeste mensi).

Tcl/Tk jde pouzit i bez pythonu. Samospustitelny starkit ma kolem 1M a i s aplikaci se vetsinou vejde na disketu.

Jak bylo řečeno. Program psaný s wxWidgets lze na Linuxu slinkovat s Gtk+ nebo Motif. Na Windows jako nativní Win32API aplikaci a na Macu jako nativní kdovíCoSeTamPoužívá. Navíc je k dispozici i celkem pěkný klikací editor (wxGlade). Má spoustu nedostatků, ale asi nic lepšího v této kategorii není (Java je jiná kategorie). Více viz http://wxwidgets.org/

jeste se musi jit na kafe, kdyz se v wxwidgets pod windows ma natahnout 10000 elementu do List-Controlu? Umi listcontrol pod unixem justify_right/left u list-controlu pro jednotlive sloupce?, je mozno kdyz....?, umi..?,

strelim ted od boku, s wx jsem delal jen chvili pod pythonem (lin & win):

Q: jeste se musi jit na kafe, kdyz se v wxwidgets pod windows ma natahnout 10000 elementu do List-Controlu?
A: ve wxLC_REPORT rezimu neni problem pouzit wxLC_VIRTUAL. pokud se snazite nacitat 10k polozek do icon-view, asi mate hodne zvlastni aplikaci

Q: Umi listcontrol pod unixem justify_right/left u list-controlu pro jednotlive sloupce?
A: "pod unixem" znamena pod wxGTK, wxMotif, nebo snad pripadne wxX11? pod wxGTK umi.

Q: je mozno kdyz....?
A: ano

Q: umi..?
A: 42

Cool, ty mas doma Hlubinu mysleni? Pujcis? :-D

muj tip: GCJ + SWT + UPX

ja osobne mam wxWidgets dost nerad, IMHO osklivy API a`la MFC, problemy rozchodit to s GTK 2, widgety maji defaultne bordery, coz vypada hnusne kdyz je takovejch widgetu par do sebe vnorenejch a je nutny je odstranovat, ale aby na vsech platformach zustal aspon jeden atp.

nejlepsi je mit dobre rozdelenou aplikaci a mit GUI napsany dvakrat, tomu se nic nevyrovna

FOX Toolkit

Bohužel nevyhovuje. Qt ve verzi 3.x jsou pro Windows pod nějakou Trolltech licencí, která je jak správně tušíte, za penízky. Ale Qt 4 by snad měla být GPL i pro Windows pro GPL aplikace.

Citace:

Qt for Windows will be available under both a commercial license and the open source GPL license starting with the next major production release of Qt, version 4.0, which is expected in the second quarter of 2005. With the GPL availability of Qt for Windows, Trolltech will offer dual licensing of Qt on all supported platforms.


Zbytek na http://www.trolltech.com/newsroom/announcements/00000192.html

Už aby to bylo :-)

Omlouvám se tady to být nemělo, to mělo být k tomu příspěvku níž o Qt. Nový root je nepřehledný, obvzvláště tedy ty diskuze.

Nikoliv. Nastavte na Linuxu anglickou klávesnici, spusťte program ve Fox toolkitu, napište 'abc', přepněte na českou a napište 'ťuťuťuťutínek ďábel Úchyl'. Podle mě se vám to nepovede.

mate s tim fox-toolkitem zkusenosti na trochu hlubsi urovni? Jak je to s rychlosti u velkych aplikaci, kdyz mate velmi mnoho tech handleru na event-funkce - je pravda ze toolkit hleda ty funkce pres hash a kdyz je treba nekolik 1000 volani nejakych eventu, jestli to neni pomale?

Mám s FOX Toolkitem jen povrchní zkušenost. Staticky slinkovaný jednoduchý program je opravdu velmi malý. Ale jak už jsem psal blbl mi (pouze na Linuxu) český vstup např. do edlajn u znaků vyžadující dvojí ťuknutí do klávesnice (ď ť ň...). Jak se chová prostředí v (jakémkoli smyslu) náročnějších projektech bohužel nevím.

Tedy nerozumim presne tomu, proc treba Qt-cka nevyhovuji? Je nejaky problem krome vysledneho exe souboru jeste "poslat" uzivateli nejake dll-ko?

Qt nevyhovuje, protože ho není možno zdarma použít v closed source projektech. A ceny Qt jsou IMHO vysoké...

Tak cena je jiste duvod. Nicmene se muzeme tesit, ze ve seruhem ctvrtleti se licence Qt pro Widle zmeni. Snad...
Ale na moji otazku ohledne dll-ek to neodpovida...

Opravdu FLTK neumožňuje přepínání klávesnice? Já se to marně nějak snažím rozchodit. Mám to vzdát? :-( Ve win diakritika funguje. V Linuxu nemůžu napsat například ď nebo ň. Zvláštní je, že to ale jde překopírovat přes schránku. Tedy font je v pořádku, zobrazit to jde. Jen je problém s klávesnicí abych to napsal.

Čau,
pěkný článek! Dobře napsaný, se zajímavým obsahem. Těším se na další díly a nešetři detaily a všemi zkušenostmi, které jsi během vývoje tvé apliace nabyl (převod z ".py" na spustitelný soubor by mě fakt zajímal).

Jirka

Diky za zajimavy clanek a namet. Taky bych vas rad poprosil, abyste se v ramci moznosti podelil o vsechny mozne zkusenosti a detaily.
Moc se tesim na dalsi dily.

Děkuji za skvělý článek. Pseudokód Pythonu lze pokud vím snadno dekompilovat, čili uložení v binárním souboru je spíš symbolické - kdo se ke zdrojáku chce dostat, dostane se. Ale o to nejde.

Rozhodně je legitimní dělat closed source pro Linux. Těším se na pokračování.

Taky se pripojuji k probrani pytoexe

py2exe

Příznivci Smalltalku se mohou mimo jiné začít poohlížet po projektu wxSqueak

http://www.comtalk.net/Squeak/86
http://homepage.mac.com/rgayvert/wxsqueak.html

Zatím je sice dostupná jen verze pro Windows a MacOS (na linuxovou VM si budeme muset ještě nějakou chvíli počkat), nicméně již nyní se nachází v použitelném stavu a na dalších verzích se usilovně pracuje.

Příznivci Ruby mohou využít wxRuby, TCL/TK, FOX nebo i qtRuby :-))) No flamewar, hlavní je, že skriptovací jazyky mají budoucnost.

Tohle je podpásovka, protože Squeak si sebou primárně nosí celé vlastní binárně přenositelné grafické rozhraní a podpora externích GUI toolkitů je jen třešnička na dortu. A označit Smalltalk za skriptovací jazyk je, mírně řečeno, silně zavádějící. Ale flámoval bych kvůli tomu nerad.

Nad titulkem článku jsem zajásal, po přečtení mám pocit, že bude řešit pouze výsek ze skutečného rozsahu problému. Pro nový projekt lze jistě zvolit jazyk Python, v reálném světě však převládají projekty, do nichž již byly vloženy desíky, stovky člověkoroků.

Nejlepší multiplatformní nástroj, který jsem zatím našel, jsou wxWidgets, to však neznamená, že fungují bez problémů - můj seznam záludností, podivností a chyb ve wxWindgets už má dost stránek.

Nesmírně bych uvítal článek o binární přenositenosti mezi Linuxovými platformami. Například projekt v C++ sestavený na SuSe 9.2 nelze použít ani na SuSe 9.1. Knihovny stdc++ a libgcc můžete sice přilinkovat staticky, ale pro libc není statické linkování řešením, takže při instalaci na cílový systém nastane problém s verzí GLIBC. Kompilovat projekt se starší verzí libc také moc nejde, protože si s ní nerozumí crt1.o. Zkoumal někdo tento problém?

...Nejlepší multiplatformní nástroj, který jsem zatím našel, jsou wxWidgets...

je to pravda, ze jestlize musite napsat nejaky novy widget, ktery nemuzete odvodit ze stavajicich trid, tak ze musite kvuli multiplatformite napsat odpovidajici kusy software v gtk+ a v mfc. Jestlize ano, tak pak je ten tool nesmyslny pro _skutecne_ vyvojare, protoze by mel prave aplikacniho programatora drzet v patricne vzdalenosti od gtk+/mfc specialit, nebo?

S MFC nemají wxWidgets nic společného. Při vývoji nových tříd záleží na tom, zda se s požadavky vejdete do toho, co nabízejí obecné abstrakce pro "okno", "událost" atd. Pokud ano, pak programujete pouze ve WX API. Pokud ne, pak musíte klesnout k WIN API, GTK2 API atd. U mně druhý případ nastal jen zcela výjimečně, třeba když mi nevyhovovala koncepce tooltipů ve wxWidgets.

No právě proto, že je problematika psaní multiplatformních aplikací tak obsáhlá, jsem hned v anotaci upozornil na to, o čem to bude. Hlavním cílem je natrknout vývojáře, kteří se rozhodují o psaní nového projektu, aby použili nástroje a postupy, které zajistí snadnou portaci. Bohužel mám pocit, že alespoň u nás to rozhodně není samozřejmostí.

(Ne)přenositelnost mezi Linuxy je podle mě jedna z největších nevýhodl Linuxu. Podle mě se na to moc nemyslelo, protože ke všemu jsou přeci zdrojáky a není problém program na každé platformě zkompilovat. Když pak ale přijde na komerční projekty (např. Oracle a pod.), tak aby člověk měl jen jednu z mála doporučených distribucí. Věřím, že se to časem zlepší.

"... může být instalován i bez práv roota"

S tim chown a chmod pak preji bez roota hodne stesti. ;-)

Jinak clanek podle me muze mit smysl jen tehdy, kdyz nebude svazovan s konkretnim jazykem.
V populaci nelze predpokladat nijak zvyseny pocet sebemrskacu, kteri si zvoli pro napsani hry python. ;-) Z tohoto pohledu byl pekny priklad ten s /var/games, skaredy priklad je ten s temi seredne dlouhymi radky na zjisteni dom. adresare uzivatele.

S tim chown je to samozrejme vytrzene z kontextu, jak to je udelane presne bude asi v nekterem z pristich dilu. K tomu pythonu - jasne, ze na Python nejsou lide (v CR) prilis zvykli, ovsem je to tak jednoduchy jazyk, ze se v nem daji pekne ukazat obecne principy. A to i s tim zjistovanim domovskeho adresare - stejne se na to vola win32 api a ta bude stejna i v C++ nebo v cemkoliv jinem.

V čem byste psal hru, když ne v Pythonu?
Pygame je opravdu výborná knihovna, snadno použitelná a velmi nápomocná.
Časově nejnáročnější operací je výkreslování a to provádí SDL na nižších vrstvách.

Pokuď se píšete hry s mnoha levely, dialogy, animacemi, stejně se nevyhnete použití nějakého skriptovacího jazyka pro popis levelů. Vím o použití zabudovaného Pythonu, Lua, Lispu, Ruby.

U me python odpadl hned na startu diky vyuziti 2D layoutu. Zlaty zavorky.

nebylo by mozne pouzit pro zjisteni domovskeho adresare na linuxu:
blabla = os.environ['HOME'] + "/.myApp"

Jistě. Na všech pořádných OS to tak jde. Na parodiích se musí používat složitější postupy. No a v článku je snad dost jasně napsáno, že kvůli parodii se tam dělají ty opičky.

už se těším na další díl

nejak mi unika duvod, prc by si mela hra ukladat sva data jinam nez do ~/.myapp/ - muzete mi to nekdo vysvetlit? prece kdy ji bude chtit uzivat vice uzivatelu, nebude user a chtit vyuzivat cokoliv zapsane userem b, ne?

Prave ze jo. Jako priklad jsem uvedl tabulku se skore. Presne takhle to dela docela dost her.

OK, diky. Stejne bych tam radsi videl (volitelne, samozrejme) nejakej inet server, kdyz uz se chci porovnavat s jinejma uzivatelama, tak proc jenom u me na stroji, ze. A kdyz neni server dostupny, tak holt nekam do $HOME. Ale to je jenom muj nazor.