Dotaz: V šem programovat GUI pro linux + windows

[mmartin]

Ahoj. Na toto téma zde bylo napsáno mraky slov. přiznám se, že jsem neměl sílu pročíst všechy. a) otázky byly položeny trochu jinak, napřiklad v čem programovat pro linux, nebo pro kde atp.

Můj dotaz zní trochu jinak. A prosím odpovědi typu v košili, v létě atp nechte v šuplíku děkuji .

Něco jsem už naprogramoval v konsolových aplikacích. Pak jsem pomalu přešel na GUI nejprve v MFC pod win. Pak v C# a nakonec v jave, kde jsem zjistil že je to opravdu velice podobné jako v C#. MS by měl Sunu zaplatit za licence k javě protože to je z venku (uvnitř to bude asi trochu jiné) totální kopie.

Nicméně hledám nějaký pokud možno neinterpretovaný jazyk, ve terém bych mohl tvořit GUI jak pro win tak pro linux.

Omluvám se teď všem Rubyům a Pythonům, ale chtěl bych to tvořit pokud možno v C nebo C++. Pokud mi to někdo nevymluví.

Java i C# jsou sice hezké platformy, ale zdá se mi to jako strašné mrhání systémovými prostředky. Proto jsem se chtěl poohlédnout po něčem jiném. Jak to vidíte vy ?

Jak se dá v C nebo C++ napsat multiplatformní aplikace ? Nebo žeby v jiném jazyce ?

Odpovědi

[Luboš Doležel (Doli)]

Jak se dá v C nebo C++ napsat multiplatformní aplikace ?

Napište to s Qt. Pokud chcete GTK+, použijte třeba GTKmm/Glibmm - tam už si asi budete muset zařídit některé platform specific věci (sahající mimo možnosti jazyka) sám.

[zoul]

To je Ti fakt jedno, jestli budeš psát v Javě, C nebo C++? Nebo chceš zjistit, která technologie by asi tak byla nejlepší, a tu se potom pořádně naučit? GUI programování v Javě a C++ je podle mě mnohem snesitelnější než v C. Přenositelnost Javy je pak další velké plus a já osobně bych už nerad žil bez garbage collectoru :)

Hledáš neinterpretovaný jazyk, protože interpretované považuješ za pomalé? Javu řadíš kam? Tohle je hodně kontroverzní téma, ale Java je většinou srovnatelně rychlá jako C/C++, tedy pokud zrovna nepíšeš nějakou hru a nebojuješ o každý FPS. Swing je maličko bumbrlíček, ale kdyby Ti na tom hodně záleželo, můžeš zkusit SWT.

Kdybys chtěl psát v C++, určitě vyzkoušej QT. Rozhodně bych si ale C++ nevybíral jen proto, že podle Tebe bude rychlejší.

[mmartin]

No. Psal jsem v jave neco jako filemanager. Ve srovnani s vecmi napsanymi v neinterpretovanych jazycich byla moje app asi tak 10x pomalejsi pri nacitani informaci z disku, obzvlaste ze sitovych to bylo markantni atp. Spousteni cele aplikace take 10x pomalejsi. Navic totalni zrout pameti. Zatim co FAR manager zabira se vsemi svymi funkcemi v pameti s bidou 1Mb moje aplikace zabirala 30 jen jsem ji spustil. Kdyz jsem v ni zacal pracovat, zrala klidne i 80. Samosebou je to z velke casti moje chyba, protoze jsem patlal a ne profesionalni programator. Nicmene i tak si nemyslim ze zas tak velky podil na spotrebe zdroju ma ma neschopnost optimalizovat. Spise je to technologii.

Proto jsem chtel zkusit programovat v necem slozitejsim, coz c++ pro mne bez pochyby je, ale zato setrnejsim ke zdrojum. Nelibi se mi totiz moderni trendy ve stylu, pamet roste, vykon pocitace roste, tak budem psat neoptimalizovane.

Nicmene se nebranim myslence psat v jave, pokud mi tu nekdo rekne ze lze opravdu napsat aplikaci, ktera bude alespon trochu srovnatelna s Cckovou app co se tyce zdroju. Budu jen rad, protoze v jave nebo c# je to easy .

PS:Procedury pro zjistovani souboru na disku + zapis informaci do seznamu bylo opsano z velmi tluste a velmi chytre knihy. Takze predpokladam ze to byl nejlepsi zpusob jak to napsat.

[zoul]

No. Psal jsem v jave neco jako filemanager.

Aha, to je problém, k tomu se Java zrovna moc nehodí.

Ve srovnani s vecmi napsanymi v neinterpretovanych jazycich (…)

S tímhle opatrně. Za prvé, výraz „interpretovaný jazyk“ je sám o sobě vachrlatý, protože jazyk je jen specifikace a dá se pro něj napsat interpret i překladač. Za druhé, Java není vyloženě interpretovaný jazyk, ale jazyk překládaný do bajtkódu virtuální mašiny. Velká část toho kódu navíc díky JIT končí v kódu stroje, na kterém VM běží. Za třetí, pomalost správce souborů napsaného v Javě s interpretováním přímo nesouvisí – zpomaluje spíš abstrakce hardwaru, které se člověk v nižších (klidně interpretovaných) jazycích může vyhnout.

Spousteni cele aplikace take 10x pomalejsi.

To je ale kvůli zavádění VM, ne? Druhé spuštění už by mohlo být rychlejší. (Což ale říkám spíš jen do počtu, protože u správce souborů by samozřejmě bylo i to první pomalé spuštění na pendrek.)

Proto jsem chtel zkusit programovat v necem slozitejsim, coz c++ pro mne bez pochyby je, ale zato setrnejsim ke zdrojum. Nelibi se mi totiz moderni trendy ve stylu, pamet roste, vykon pocitace roste, tak budem psat neoptimalizovane.

Tohle je omyl, vážně. Úplně základní programátorská dovednost je umět vybrat technologii, která se pro zadání bude hodit. Když si chci v rychlosti něco spočítat a sáhnu po C++, není to ideální. Když chci napsat správce souborů a sáhnu po Javě, je to velký omyl. Když to pak dře, není to chyba technologie.

Nicmene se nebranim myslence psat v jave, pokud mi tu nekdo rekne ze lze opravdu napsat aplikaci, ktera bude alespon trochu srovnatelna s Cckovou app co se tyce zdroju.

Jistěže jde. Virtuální mašiny se ale člověk nezbaví, takže nesmí čekat, že první spuštění aplikace i s režií startu VM bude lepší než staticky linkovaná céčková binárka. Pro spoustu aplikací na tom ale nesejde, případně výhody Javy převáží.

¶

Jestli chceš psát správce souborů pro Windows i Linux (wtf?), Java pro to ideální není. Jestli chceš psát přenositelnou GUI aplikaci pro Windows i Linux, výhody Javy oproti ostatním řešením můžou být podstatné. Jestli čekáš jednoduchou a správnou odpověď na otázku „V čem psát GUI aplikace pro Windows i Linux?“, nedočkáš se.

[mmartin]

To je ale kvůli zavádění VM, ne? Ano bylo to kvuli tomu.

výhody Javy oproti ostatním řešením můžou být podstatné Nezbyva nez souhlasit. Java nebo C# jsou opravdu pro vetsinu mych potreb vyhodnejsi. Ale mam pocit ze v kazde aplikaci, kterou chci dotahnout do poradneho konce, narazim na hranici VM. Pisu si pro sebe jen takove blbosti, prepocty mernych jednotek, slovniky, generatory hesel atp. Na to si s javou nebo monem vystacim v pohode. Jakmile ma byt ale program spusten na slabsim stroji, nebo hezky pro konzervativce po staru a reknu jim, tady mate 1Mb programek ale musite si kvuli nemu nainstalovat 200mb frameworku tak jsem u nich skoncil , to je za a). A za b) v okamziku kdy se chci prehoupnout do neceho slozitejsiho (jako je filemanaager) nebo neco co pracuje s hardwarem, koncim. Budto to nejde vubec a nebo je to pomale.

Ale co uz, takovy je zkratka zivot .

[cynik]

No nevim jestli ti pomuzu, ale mam par postrehu.

Kdyz jsem zacal psat nekdy pred 8 rokama prvni GUI tak jsem vybral jako jazyk C a jako toolkit gtk. Duvodem bylo, ze se me nechtelo moc ucit C++ a prave prenositelnost. Plain X (Athenu) jsem zavrhoval protoze uz tehdy mela vazne retro vzhled a nebyl jsem si jistej jestli by ji nasi uzivatele zvladli pouzivat. Nicemne uz jednoduche pokusy jasne ukazaly, ze gtk je viditelne narocnejsi nez X.

Ten program jsem pak jeste prepisoval asi 3x. Hruza, poprve to bylo proto, ze pri povyseni gtk z verze 1.0 na 1.2 odmitalo spoustet suid binarky, takze jsem navic jeste kolem toho musel prepsat kompletne architekturu zbytku baliku. Byl to krok spravnym smerem, nicmene pak uz me gtk jen zdrzovalo, protoze kazde dalsi povyseni znamenalo prepsat pulku programu diky zmenam v API. Hlavne (a to tak je dodnes) neni poradne vyreseno pouzivani grafiky, takze ke gtk musite prihodit ruzne gdkpixbufry atd. Aplikace se dodnes pouziva pod starym gtk. Dotazem v konferenci me bylo receno, ze stare gtk (<2.0) se bude udrzovat, ovsem je to uplne jiny toolkit nez nove gtk.

Takze jsem casem na psani v GTK zanevrel a pri dalsim "bodu obratu" kdy jsem se rozhodoval o toolkitu pro C++, ale tentokrat s vetsi vyberem mezi Qt,Gtk v C++ a wxWidgets. Qt jsem vyloucil rovnou kvuli filozofii (tvori to jedna firma, co se stane, az se neco stane), licenci (tehdy jeste nebyla pod GPL, mozna neni ani ted, i kdyz je licence liberalnejsi) a proto, ze se me z Qt aplikacema tezko pracuje a nelibi se me. Naopak ma Qt pekne propracovane API, takze to vyuziva moznosti C++ dokonale a ciste. Gtk v C++ jsem zavrhnul kvuli tomu, ze jsem zase cekal zmeny API (to jsem asi trefil). Pokud vim o dalsich toolitech tak uz jsou o hodne mimo, vetsinou nemaji ani zdaleka takove moznosti a hlavne jsou ve vyvoji (coz znamena zmeny API).

Takze jsem zacal pracovat s wxWindows, ktere se prejmenovali na wxWidgets. Duvodem byla hlavne prenositelnost a to, ze jsem ocekaval, ze zmeny v API Gtk za me budou filtrovat vyvojari wx. Po asi dvou letech pouzivani se me zda, ze to byla dobra volba. Zacal jsem v pythonu, protoze jsem podlehl tomu, ze v pythonu se snadno a rychle programuje. Coz je sice pravda, tehdy jsem neco jednoducheho vyrobil behem tydne. Nicmene pak jsem udelal jeste jeden pokus a ani v C++ to nebylo pomalejsi, spis naopak. Prakticky v tom tedy neni zadny rozdil. Pokud jde o rychlost pak python pochopiltene dele startuje, za behu uz se rozdily nedaji poznat vyjma pripadu, ze pocitac musi swapovat, pak je pochopitelne python mnohonasobne pomalejsi. To je pro me dost dulezite kriterium, protoze mam ridici system a ten ocekavam, ze budou lidi provozovat na spise starsich strojich, na noteboocich atd. Navic to znamena, ze clovek si muze na takovou sunku nainstalovat jen par knihoven a nemusi mit tisice dodatecnych modulu atd.

Pokud jde o programovani v C, C++ nebo pythonu, tak mezi C a C++ je vyrazny rozdil v predevsim v jednoduzsim programovani a dodatecne stabilite, navic v C++ se me zda, ze se da mnohem jednoduzsej pochopit struktrura toolkitu a tim padem to rychlej a bez chyb napsat. Doporucil bych spise C++. Mezi C++ a pythonem nevidim z hlediska programatora zadny praticky rozdil. Javu a Mono jsem nezkousel, nemam na to pocitac.

[cynik]

Jeste doplnek.

Pokud jde o rychlost a systemove zdroje, je jednoznacne C podstatne rychlejsi nez C++, program mensi atd. Beru to jako dan za to, ze je ten program s vetsi jistotou spolehlivejsi.

[mmartin]

Diky za tip. Odpoved byla vycerpavajici. Urcite testnu C++ s wx. Uvidime co to umi.

Zkusim se mrknout a zjistit taky situaci kolem gtk (nemylim-li se je v tom napsany gimp) a QT4. Prozmenu v tom ted prepsali KDEcka a je uz GPL. Uvidiem co se od jednotlivych platform bude dat ocekavat.

[David Jaša]

Pokud jde o rychlost pak python pochopiltene dele startuje, za behu uz se rozdily nedaji poznat vyjma pripadu, ze pocitac musi swapovat, pak je pochopitelne python mnohonasobne pomalejsi.

Potvrzuji, rozdíl v rychlosti běžného programu v pythonu a C/C++ poznám jen pokud se ten pythoní musí vyhrabávat ze swapu.

jednoduzsej

Dnes už píšeme mnohem jednodušeji než ve spřežkách.

[Petr Mach]

Od GTK 2.0 je GTK stále kompatibilní, tedy až do současné verze 2.10.14. GDK je součástí GTK, takže poznámce o GDK pixbuferech nerozumím. GDK je low level knihovna pro primitivní GUI operace na které staví GTK, což je vlastně sada widgetů.

S wxWidgets mám špatné zkušenosti jako uživatel, protože většina programů postavených na wxWidgets je podivná, má potíže s fonty a tak.

[anyd]

Pokud chces psat desktopove aplikace, tak bych uprednostnoval mono nez javu.

rozhodne dneska bych uz nepsal v C (GTK), cas je velice draha vec, aby se s ni takhle plytvalo.

[springer]

...rozhodne dneska bych uz nepsal v C (GTK), cas je velice draha vec ...

nezlobte se na me, ale obcas to musi byt, a proto ta otazka: kolik stoji auto?

[R]

Moje stoji asi tak 5 hodin - od osmej, co som nim isiel :P

[springer]

opravdovy programator (skutecne opravdovy) pouziva fox-toolkit.

[Jiří Němec]

Pokud vám nevadí licence GPL, tak je QT a C++ pro vás asi nejlepší. Pro firemní použití pokud zákazník nesmí dostat zdrojáky je QT asi stejně drahé jako podobné řešení třeba od Borlandu. V tomhle by na tom bylo GTK lépe, ale zas byste musel psat v C a GTK je pouze grafický toolkit. QT má proti tomu vlastní řešení na všechno možné jako třeba databáze, sítě, xml, OpenGL...

[Luboš Doležel (Doli)]

Kvůli GTK+ by nemusel psát v C, je tu i GTKmm. Je to sice další balík knihoven navíc, ale pořád někdy lepší, než to plácat v lowlevel GTK+.

[depka]

Pokud mate skusenosti s MFC tak wxWidgets bude asi nejlepsi volba

[HS]

Ad. otazka : V pohode, ale potrebuje to dodrzet standardy jazyka, nikoliv tvorit podle toho, co kompilator vezme.

Jinak zalezi co chces tvorit. konzolove aplikace jsou v pohode, horsi je to s grafickymi aplikacemi, tam vetsinou multiplatformost krachne. Co se tyka javy, tam jsem jeste neslyzel, ze by nekdo mel problem s multiplatformosti. Sam vetsinou tvorim graficke aplikace aplety, ale jsou tu i dalsi tridy, ktere by ti vice vyhovovali. V C++ je to problem, ale kdyz najdes vhodne vyvojove protredi, jses zavodou. V C si musis odrit grafiku sam. Je to sice pracnejsi, ale o to mene komplikaci pri multiplatformosti. Jinak na multiplatformost C# bych nesazel. Prece jenom je to produkt Microsoftu, hlavniho tvurce ruznych multiplatformich problemu.

[Bubak]

WX by nemusela byt spatna volba, ale muzes take mrknout na C++ toolkity Fox-toolkit nebo FLTK, pokud netrvas na systemovem look&feel (jak se to rekne cesky?). U Fox-toolkitu je to sice v planu, ale az na poslednim miste. Nicmene ho pouzivam na ruzne mensi veci a nemam s nim problem.