Dotaz: jaký programovací jazyk+API pro Lin+Win?

[Jirka]

Chtěl bych se trochu více naučit programovat, mým cílem jsou jsou aplikace plné okýnek a formulářů.

Rád bych ale, aby to fungovalo bez velké námahy pod Win stejně jako pod Linuxem. Naučit se nějaký jazyk (cyklus, podmínka apod.) se mi nezdá obtížné, nerad bych ale věnoval svůj čas pronikaní do dvou různých API - třeba MFC pro Win a GTK pro Lin.

Už jsem se domníval, že Java+Swing je to pravé pro mé potřeby, ale po přečtení určité kritiky, si nejsem jist. Mohl byste mi prosím někdo poradit, jaké mám alternativy a případně výhody+nevýhody?

Odpovědi

[mess]

Python + nějaký toolkit (GTK+, Qt, wxWidgets):
+ Netřeba překládat - je to interpretovaný jazyk
+ Jednoduchý jazyk se spoustou vychytávek
- Rychlost - je to interpretovaný jazyk
- Pokud nechceš dělat GPL věci, tak není dobré, že si může každý přečíst zdroják

Pascal + Lazarus:
+ Jede na Win i Lin.
~ Nevím nic bližšího.

C++ a vhodný toolkit (GTK+, Qt, wxWidgets):
+ Rychlost
- Kapku složitější, než Python
- Nutnost program přeložit na každé platformě

Pozn.: Ty 3 toolkity, které jsem jmenoval, jsou jak pro Windows, tak pro Linux.

[kotatko]

Přikláním se k tomu C++. Do nedávna jsem řešil podobný problém.

[laco]

Souhlas s tím C++, ale podle mého je to o dost složitější než Python.

[petris]

Já používám C/C++ a GTK/GTKmm, ale pro C++ bude lepší to QT, já jsem jen líný učit se další API. Přenositelnost celkem bez problémů, wokení binárky překládám na linuxu pomocí mingw.

[Joshimi]

Priklanel bych se k .NET (mono) platforme, muzete si vybrat GTK+ (knihovny gtksharp) nebo QT rozhrani (knihovna Qyoto) (gtk+ i qt4 jsou i pro win platformu upraveny) i kdyz osobne pro vyvoj gui bych to oddelil. Pro Windows - windows forms a pro linux gtk nebo qt.

[ZAH]

Vzhledem předchozím ohnivým diskuzím, jste se základním charakterem vašeho výběru seznámem a to s klady, nebo to co se za klad považuje. Stejně jako se zápory.

Moje osobní zkušenost je, že Java + Swing je mocná zbraň, ale mocné zbraně by neměli používat bez řádného výcviku. On totiž zprasaný základ aplikace se pozná obvykle až na konci. Běží tu dle mého názoru docela korektní diskuze o Bobtnání Linuxu, která se okrajové dotkla JAVY. Většinu názorů bych klidně podepsal. Hlavně ty o nutnosti uvolňovat zdroje ono automatické spoléhání na gc a finalyze se umí vymstít.

Takže jestli je vaším cílem grafická aplikace s dynamickými layouty, případně vícejazyčná, která nasahá na systém a není na závadu určitá reakční doba ( osobně tomu říkám měkkost ) je Java + Swing pro vás dobrá volba.

Upozorňuji, že Swing není jediným grafickým prostředím Javy. Minimálné zajímavým počinem je SWT (pozor je částečně nativní a musí se instalovat podle platforem) na něco jednoduchého postačí někdy i AWT. Dle mého názoru aplikace AWT jsou tak trochu od sekyry, ale což děda byl tesař.

V Javě jde, jako v jiných jazycích, toho psát hodně. Jen prostě, jako jiné jazyky, není univerzálním všelékem. To co je pro jednoho zásadní nevýhoda je pro druhého zásadní přednost. Například dlouhé popisné identifikátory, Osobně oceňuji na Javě spoustu věcí a na spoustu nadávám. Jsem však přesvědčen že jde o zajívavý prakticky použitelný jazyk a proto doporučuji vyzkoušet. Snad je nejprve čtěte učte se snažte se pochopit logiku grafických komponent swingu model, zobrazovač, správce rozvržení atd.Stejně tak jar, classpath classloader. A až pak se pouštějte do rozsáhlejších projektů pomocí nějakých udělátek.

[Radek Miček]

Zdravím,

vaše otázka je docela častá, nicméně nejlépe si odpovíte asi vy sám, až si různé knihovny sám vyzkoušíte.

Já vám pouze mohu nabídnout svůj subjektivní pohled na věc, doufám, že vám alespoň k něčemu bude.

Já osobně preferuji knihovnu GTK, aplikace napsané v GTK běží hladce jak ve Windows tak v Linuxu. GTK preferuji především proto, že vývojáři této knihovny si udržují pořádek ve zdrojových kódech, knihovna má docela dobrou dokumentaci i architekturu.

Moje náklonnost ke knihovně GTK je ale možná dána tím, že preferuji jazyk C před jazykem C++.

Mám-li se vyjádřit i k ostatním knihovnám, tak knihovna Qt mi přijde příliš nafouklá - obsahuje sice více funkčnosti než GTK, ovšem otázka je, zda-li tu funkčnost navíc chcete používat - jsou tam i třídy, které nemají nic společného s GUI a i třídy, které mají něco společného s GUI, ale příliš se nevyužívají. Dále se mi na Qt nelíbí mechanismus signálů a slotů.

Ale na druhou stranu je knihovna Qt z hlediska návrhu také docela dobře vystavěna, ale IMHO není už tak intuitivní jako GTK. To, co by knihovna GTK mohla knihovně Qt závidět je vysoce kvalitní dokumentace.

Menší knihovny jako FOX Toolkit a FLTK jsou zase většinou vyvýjeny malou hrstkou vývojářů a člověk nikdy neví, zda-li se vývoj nezastaví - proto bych si rozmyslel, zda-li se vyplatí je používat.

Radek

[frm]

...Menší knihovny jako FOX Toolkit a FLTK jsou zase většinou vyvýjeny malou hrstkou vývojářů a člověk nikdy neví, zda-li se vývoj nezastaví ...

jaky vyvoj myslite, nove widgety, nebo opravu chyb ....

jak udelate napr. v Qt nebo GTK upravy na table widgetu, aby jste mohl zobrazovat treba nejaky obsahly text mezi jednotlivymi radky? Uz jste zkusil, aby to vyvojari pro vas udelali, vzali do vyvojoveho planu? Reknou vam, ze to delat nebudou => a vyvoj se zastavil ...

[Radek Miček]

Měl jsem na mysli především opravy chyb a udržování knihoven ve funkčním stavu, i v nových verzích operačních systémů - např. když se trochu změní API, tak aby knihovna dále fungovala

jak udelate napr. v Qt nebo GTK upravy na table widgetu, aby jste mohl zobrazovat treba nejaky obsahly text mezi jednotlivymi radky? Uz jste zkusil, aby to vyvojari pro vas udelali, vzali do vyvojoveho planu? Reknou vam, ze to delat nebudou => a vyvoj se zastavil ...

Ano, pokud to berete takhle, tak se skutečně vývoj zastavil, ale to platí i u těch menších knihoven - to by pak knihovny asi pěkně rostly, když by autoři implementovali funkčnost na přání.

IMHO všechny knihovny jež jsem jmenoval mají funkčnost (alespoň pro mne) dostatečnou, já jsem spokojen a stačí mi jen, aby to chodilo. Proto se osobně raději spolehnu na knihovny, které jsou více používané - tam je alespoň větší šance, že se případné chyby/nefunkčnosti pokusí někdo odstranit, i kdyby stávající autoři na tuto činnost rezignovali.

Radek

[Jirka]

Díky všem, zkusím si pro začátek hrát s Pythonem a GTK, přesedlat v případě potřeby na C++ s GTK snad nebude takový problém.

S swingem už jsem si něco zkoušel, je to hezké, škoda jen, že neexistuje nějakej sw, kterej by vyslednej bytekod překousal ještě do binárního kodu dané platformy, včetně nahrazení napodobených grafických prvků těmi nativními pro danou platformu. To by pak byl můj jazyk snů:)

[ZAH]

Bytecode je právě proto, aby nemusel být nativní překlad na platformy. Potřebujete li snadnou přenositelnost Javového programu, vytvoří se .jar soubor (je to v podstatě zip), který se dá přímo bez další instalace spouštět na včem co má nainstalovanou Javu.

[Jirka]

To vím, ale kdybych měl možnost volby, vzdát se za určitých okolností přenositelnosti a dostat za to nativní rozhraní spolu s rychlejším během programu pro jednu konkrétní platformu... to by pak nemělo chybu. Chtěl bych přenositelnost - měl bych bytecode+jar, potřeboval bych to uzpůsobit pro jednu platformu - prohnal bych to nějakým programem, kterej by to překopal do nativního kodu s nativním rozhraním.

[Vinicius]

Swing ale podporuje zmenu look and feel, takze muze vypadat tak jak potrebujete, tedy pod Windows jako prvky poskytovane Windows a pod Linuxem jako GTK+. Nadto Java pouziva technologii Hotspot, tudiz casti bytecodu se prekladaji a casti interpretuji, je to tak,ze nekdy lze beh programu urychlit prekladem, nektere optimalizace zase zvladnou pouze interprety..,, protoze maji prehled o interpretovanem bytecodu.
JAR archivy jsou velmi dobry zpusob distribuce programu. O vyhodach garbage collectoru uz ani nemluvim, samozrejme gc se zabyva jen spravou pameti, jestli vas program 1000000x otevre nejaky soubor, tak to dopadne vzdycky spatne.

Pouzitim poslednich verzi GTK+/GTKmm odstrihnete uzivatele MS-Windows 98 a starsich, coz je ale jen potencialni nevyhoda. Ale nevim o zadnem IDE pro GTK+/GTKmm, ktere by dobre integrovalo navrhovani GUI a psani kodu.

[ZAH]

S javou 1.6 odstřihnete uživate W98 asi taky .

[Vinicius]

Docela urcite. No ale Windows 98 jsou prece jenom uz vyslouzily system Pokud pujde vysledny program v jave prelozit s parametrem -target 1.5, tak bude mit i uzivatel Windows 98 vyhrano.

[jan.xxx]

I tato možnost existuje. GCJ umí vytvořit z jar i nativní aplikaci, ale ... Toho ale je tam hodně. Další možností je komerční Excelsior JET. Dělal jsem s tím 3 roky nazpět nějaké testy a líbilo se mi to. http://www.excelsior-usa.com/

[Filip Jirsák]

Otázka je, co se tím přeložením do nativního kódu získá. Zvlášť když běžné JVM dnes kritické části překládají do nativního kódu za běhu. Kritické části za vás v asm gcj stejně nenapíše, a pro ostatní je podle mne rozdíl mezi nativním kódem (který vyleze z překladače) a virtuálním strojem s bytekódem nepodstatný.

[jan.xxx]

To nechám na autorovi (třeba odzkouší a uvidí). Já jsem překlad použil pro konverzní (ne GUI) program a ten rozdíl v čase mi ve výsledku nestál za námahu okolo. Java má své kouzlo, stejně jako C++ či Python, ...

[rich]

tcl/tk - přenositelné, snadné na naučení a ani nepotřebuje další "toolkity"

[petr]

Jednoznačně doporučuji Javu se Swingem. Jestli to má být opravdu bohatý, tak to postavte na NetBeans Platformě.

Hodně štěstí!

[ZAH]

Vzhledem k ohlasu diskuze si dovoluji k pomlouvaní uvolnit mini aplikaci pro vypis a řazeni PSČ v tabulce. Jako ukázku možností reakce javy na podnět a změny vzhledu dle prostředí. Jde o seznam českých PSČ asi 3 000 položek,které jsou uloženy v XML souboru ten je při spuštění analyzován a vytvořen paměťový TableModel. Je realizováno řazení v tabulce filtry však ne.

http://www.zah.cz/download/PostCodes.jar zdrojový kód http://www.zah.cz/download/PostCodes.zip

Program se spouští nemáte li asociaci java -jar PostCodes.jar