Dotaz: GUI k jadru aplikace C++ - jak ?

[David Sedláček]

Holla :)

Takovy dotaz, ohledne koncepce navrhu programu.. Pisu aplikaci, ktera ve finale je jeden objekt s metodami pro pristup do nej. 

A potrebuji k nemu nejake GUIcko - zvolil jsem kvuli prenositelnosti Win/Lin _Qt_ .

 

Moje predstava -> uz Qt nadstavba si bude jen prohazovat instanci objektu, pristupovat k jeho metodam a slouzit jako I/O .

 

Jaka je bezna praxe, pri "prilepeni" GUI k takovemu objektu aplikace? Je to vubec takhle v praxi realizovano??

Odpovědi

[tom]

udelejte si knihovnu

[Pilgrim]

No tak na tohle by Ti asi kazdy dal jinou odpoved. Zaryty GNU /Linuxak Ti asi odpovi tim, ze filozoficky nejcistsi je udelat jadro a GUI jako dva samostatne programy (delame jednu vec a dekame ji dobre), ktere spolu budou komunikovat  - command line, signaly, nebo co komu zrovna sedi (ted je v Qt tusim popularni pouzivat DBus, i kdyz nevim, uz to mozna nahradili zas necim jinym) .

Padla tu uz samostatna knihovna (IMO zalezi jak je to cele velke), v jednodussich pripadech by asi stacilo pouzit

#ifdef

 a dalsich zpusobu by se dalo najit jeste asi dost...

Nemyslim si, ze existuje "jedno univerzalni" reseni (pokud se nepohybujes jenom v jedne platforme)..

 

[Josef Kufner]

Jojo,... ono tohle hodně závisí na povaze aplikace. Někde se hodí client-server, někde je lepší udělat knihovnu, jinde se hodí načítat gui jako modul pomocí dlopen(), ... Možností je spousta.

Co ten program vlastně bude dělat?

[David Watzke]

Zaryty GNU /Linuxak Ti asi odpovi tim, ze filozoficky nejcistsi je udelat jadro a GUI jako dva samostatne programy (delame jednu vec a dekame ji dobre)

No zrovna GUI programy, který volaj CLI utility nejsou nic moc úžasnýho, mnohem lepší je IMO udělat knihovnu, kterou pak bude používat CLI i GUI aplikace.

[Josef Kufner]

Nooo... treba smplayer a grip jsou velice povedené

[Limoto]

Zrovna ten SMPlayer by ale mohl být ještě mnohem lepší...

[Luboš Doležel (Doli)]

Stejně se to chová divně. Člověk něco změní a už to musí restartovat podproces, všechno znovu načítat atd. atd.

[David Watzke]

Jo, SMPlayer je super, ale to jak je řešený to vestavění MPlayeru, to je prostě opruz, mnohem lepší by bylo, kdyby dali dokupy libmplayer.

[stativ]

Zrovna smplayer je příklad jak by to děláno být nemělo. To, že to funguje dobře je skoro zázrak. Bohužel všechny pokusy udělat nějakou libmplayer zatím skončily nezdarem.

[vencas]

Osobně bych udělal tenký wrapper toho přístupového objektu přes boost::python a GUI napsal v pythonu. Záleží ale na jaký jazyk jste zvyklý a jak moc těžkotonáží to GUI bude (třeba openGL grafika a tak).

[Luboš Doležel (Doli)]

A k programu tak nabalíte dvě velké závislosti: Boost a Python. To není moc elegantní.

[vencas]

Podle toho, jak je výpočetní jádro velké, tak to nemusí vadit. Rozhodně bych to upřednostnil před psaním GUI v c++; ale jak řečeno, věc osobní preference.

[Luboš Doležel (Doli)]

Když se podívám, jak je "obtížné" dělat GUI v C++ například v Qt 4, tak to vadí snad vždycky. Boost+Python je zde naprosto zbytečná zátěž pro hardware, zbytečné nabalování dalších vrstev a zbytečné riskování dalších bugů v různých mezivrstvách.

[David Sedláček]

2ALL:  Diky za Vase nazory.

Jadro aplikace je v podstate program pro terminal s cteckou carovych kodu, ktery komunikuje ze SQL serverem.

 

GUI by pak melo zvladnout zobrazit par seznamu, tlacitka ala odepsat/pripsat.. C++ lesson :)

 

Zkusim tedy vyrobit knihovnu a pak ji prilinkovat ke GUI. Je videt, ze mnoho z vas u ma nejake zkusenosti s timto problemem, podle toho, co pisete :). Nemate nejaky dobry priklad?

[depka]

gui tedy bude pouze komunikovat ze sql serverem?

[David Sedláček]

GUI by melo komunikovat s C++ aplikaci, az ta samotna komunikuje se SQL ..

[David Sedláček]

Nakonec volim variantu s knihovnou - zda se to jako nejelegantnejsi varianta.