Struktura command-line programu pro snadne pridani GUI

[uiii]

Cau chtel bych se zeptat jestli neznate nejaky clanky, nebo mi aspon poradit, jak vytvaret (strukturovat) program (bez GUI) tak aby se casem dalo snadno doprogramovat GUI. Nejlepe tak aby nebylo nutne zasahovat, pripadne co nejmene, do jiz hotovych zdrojaku. Mozna je to blby dotaz, ale s programovanim GUI zatim nemam moc zkusenosti a rad bych uz program zacal tvorit driv nez se to programovani gui naucim, s tim ze by ta verze bez gui byla normalne pouzitelna (delal bych to na linuxu, takze proste command-line program, kterej bude mit casem gui). Chtel bych to psat v C++ a to GUI by bylo nejspise Qt. Dik moc za jakykoli rady. Uiii
_________________
Twitter

[rezna]

co treba to napsat tak ze s programem komunikujes zpravami (v linuxu treba signaly) tedy proste nejake API.

a k tomuto API si udelas klienta v konzoli a v GUI.

tzn. potrebujes tridu Aplikace ktera navenek vystavi metody a eventy a bude uvnitr fungovat nezavisle na tom kdo ji vola.

a na toto API navazes tridu klienta - kterou poprve zimplementujes v cmd-line - textove prikazy prevedes na volani API - a podruhe v Qt - zpravy od GUI prvku prevedes na API volani

[OndraSej]

Nez se pustime do nejakych rad, bylo by dobre rict, co vlastne ten program bude delat. A pripadne naznacit jak...

Command-line programy jde delat dvemi zpusoby... bud jde o program, ktery dela nejakou jednorazovou akci (jako treba vetsina unixovych nastroju - z commandline si precte co ma udelat, ze stdin precte data a na stdout zapise data).
Nebo to muze byt program, ktery ze stdin cte nejake prikazy, ty pak interpretuje a vysledky zapisuje na stdout.

Oba pristupy se trochu lisi, nicmene jedna vec je asi spolecna pro oba: vlastni funkcnost aplikace bys mel co nejvic oddelit od vstupu a vystupu. Tj. nejlepe ji celou nacpat do samostatne tridy/trid a pak jenom podle toho, co se deje na vstupu volat metody teto tridy. Pokud to udelas dusledne, pak pak stejny pristup budes moct pouzit i s GUI (postup prace bude ulozeny porad v te tve tride, akorat ty metody nebudes volat ve chvili, kdy uzivatel zada prikaz, ale ve chvili, kdy klikne na polozku v menu).

Tj. abych to shrnul - mel bys svuj program rozdelit do dvou co nejvic oddelenych casti:
1. dela ty "uzitecne" veci. Pocita, pracuje se soubory, proste to, co jo ukolem programu
2. se stara o uzivatele - cte z commandline a ze vstupu co by se melo stat a preklada to do formatu vhodneho pro funkce/metody z casti 1. O moc vic nez parsovani vstupu a formatovani vystupu by ale tato cast delat nemela.

rezna> Pouzivat eventy na command-line je myslim trochu zbytecne, volani funkci celkem staci. A unixove signaly na toto jsou mozna jeste mene vhodne, protoze signal == jedine cislo, navic vetsina jich ma presne dany vyznam v systemu. A krome toho signaly prerusuji bezny tok kodu a tak podobne. Kdyz uz, tak lepsi varianta by byl nejaky server na bazi socketu nebo sdilene pameti, ale pro naprostou vetsinu pouziti jde o zbytecne slozite zalezitosti (zvlast kdyz jde o program delajici jedinou vec).
_________________
http://trionteam.net

[Quiark]

No já se pokusím nějak lidsky popsat to, co tady radí rezna.

Jde o to, mít v samotném ovládacím rozhraní (které bude buď GUI nebo commandline) co nejmíň kódu. V podstatě by měl jen spouštět dané metody na třídě, která sama a nezávisle na uživatelském rozhraní vykoná to, co má dělat a případně tomu uživatelskému rozhraní vrátí nějaký výsledek, který pak bude příslušným způsobem zobrazen.

Příklad - vyhodnocovač výrazů/kalkulačka. Uživatelské rozhraní bude umět číst vzorec jako text. Když ho přečte, pošle ho vyhodnocovači, ten udělá, co má a pošle zpátky výsledek už. rozhraní a ten ho zobrazí buď do konzole, do GUI, nebo třeba na webu.
_________________
Mám strach

[uiii]

Hele dik moc. To oddeleni gui a api, to je dobra vec. Ostatne je to asi jedinej rozumnej zpusob, predtim sem nad tim zas tolik nepremyslel, ale takhle to bude jiste nejlepsi. Jinak ten program nebude jednorazovej, bude to neco ve smyslu slovniku a zkousece slovicek, proste pro vyuku ciziho jazyka. Takze to api bude ruzne komunikovat s databazi, vytvaret ruzny statistiky a tak podobne. Jako v tom command-linu to asi zas tak pouzitelny nebude, ale chtel bych na tom pracovat driv nez se poradne dostanu k tomu gui. Takze ste mi pomohli, dik .
_________________
Twitter

[rezna]

OT: to porad jeste pises ten program na jedno odpoledne ktery jsi zacal resit v breznu tu - http://www.ceske-hry.cz/forum/viewtopic.php?p=7994 ?

[uiii]

no problem je spis v tom, ze na tom programu sem jeste nezacal delat
_________________
Twitter

[uiii]

Když teda vytvořim nějaké to API a vytvořím z něj dynamickou knihovnu, tak ho pak budu moci využít při vytváření jiného progamu, třeba i v jiném jazyce? Třeba kdybych chtěl vytvořit alternativu té aplikace pro mobil (že bych nemusel to celé API přepisovat do javy)?
_________________
Twitter

[Augi]

Dynamické knihovny jsou přímo stvořeny pro potenciální využití v jiných programech. Jestli je to v C++ nebo Delphi je celkem jedno (akorát je třeba si pohlídat např. konvence pro volání funkcí). Nativní dynamické knihovny je možné využívat i z managed prostředí (.NET, Java).

[Marek]

Akorát teda to DLL na mobilu asi nerozjede, musel by to přepsat do té javy / .netu.
_________________
AMD Open Source Graphics Driver Developer

[Augi]

Jojo, to mi přišlo jako samozřejmost

[uiii]

Ok, tak v tom mobilu to asi nepude no, ale jen tak pro zajimavost, jina moznost nez to prepsat do javy teda neni?
_________________
Twitter

[OndraSej]

Hodne zalezi na typu mobilu (Symbian, WM, vlastni system, uplne bez systemu...). Pro nektere se programuje jen v Jave, pro jine jde pouzit C/C++ a WinAPI, pro jine je to zas neco jineho...

Dalsi vec je, ze mobily pouzivaji uplne jine procesory nez PC a DLL zkompilovanou pro PC (s Windows) NELZE prenest na uplne jiny typ hardware a cekat, ze tam bude fungovat (teda jsou drobne vyjimky, ale v tomhle pripade jsou irelevantni).
_________________
http://trionteam.net

[uiii]

hmm to je pravda no... tak to zatim nebudu resit... az to bude aktualni tak to nak prokutam a nakonec to asi stejne prepisu do javy
_________________
Twitter

[posila]

Jestli to chces prepisovat nakonec do Javy, tak navrhuju napsat to v Jave a pak (pokud to bude treba) to prepsat do C++.