Mono és Gtk áttekintés

Programozás

Nem olyan régen rászántam egy napomat és megismerkedtem a .NET csodáival, a C# nyelv rejtelmeivel, ezért szeretném megosztani a tapasztalataimat. Áttekintő jellegű leírást magyar nyelven sajnálatos módon nem találtam, pedig már nem olyan fiatal a terület.

Ha jól emlékszem 4 évvel ezelőtt kaptam egy C# könyvet. Konkrétan a C# mesteri szinten 21 nap alatt. El is kezdtem olvasni, viszont minden oldalon szerepelt az a mondat, hogy: Ez a funkció jelenleg csak a Microsoft .NET megvalósításban érhető el. Mivel már akkor is Linux-ot használtam desktopra, így gyorsan kedvemet szegte. Talán még egy HelloWorld-ot kipróbáltam az 1.0 alatti valamelyik béta Mono-val, viszont gyorsan halottnak könyveltem el a dolgok a Javaval szemben.

Jelenleg a C# nyelv erős szabványosítása miatt, valamit az erős háttérnek, továbbá a két párhuzamos implementációnak köszönhetően, úgy gondolom megállja a helyét. A tervezés és a megvalósítás utolérte, s talán mostanra le is előzte a Java lehetőségeit. Talán még a beágyazott rendszereken, és a mobil készülékeken láthatunk érdekes dolgokat a jövőben.

Feladatnak egy GPS Data logger meghajtóprogramjának megírását választottam. Az eszköz USB-re csatlakozik, egy soros átalakító van benne, ami PL2303-ként jelenik meg a rendszerben. Ezek után erre tudunk rácsatlakozni, és kommunikálni, letölteni a rögzített adatokat.

( trey | 2008. 04. 21., h – 07:34 )

Szakmailag nem tudtam ellenőrizni, mert lövésem sincs a témához, de jó látni, hogy valaki tudja ismeri a HTML-t és vágja, hogy egy cikknek hogyan kell kinéznie. Cikkbeküldők előtt állhat példaként. :)

--
trey @ gépház

( Coornail | 2008. 04. 21., h – 08:22 )

Vaov, nagyon jo cikk. Egesz meghoztad a kedvem a C#hoz, pedig en nagyon ellene voltam.

( ssikiss | 2008. 04. 21., h – 08:54 )

Nem mintha valaha is programoztam volna .Net/C#-al, de én egy másik "struktúrális logikát" preferálok a napi munkámban ill. szabadidőmben programozva (Java, C++).

Én minden változót a (első) használatához leközelebbi helyen és scope-ban vezetek be, inicializálok/példányosítok és paraméterezek fel (ha lehetséges). Amire később/máshol is szükségem van, az úgyis adatmezőként végzi egy osztályban, vagy más helyen, és arról ott kell gondoskodni. A mai fordítók de fejlesztőeszközök is tudnak figyelmeztetni a nem használt vagy használat előtt nem inicializált változókra.

( szabolcs | 2008. 04. 21., h – 08:58 )

Miért jó az, hogy egy programot c# -ban írnak? Főleg azokra a programokra gondolok, amit soha nem is szántak arra, hogy vindózon kívül máson is fusson. Pl. Ati controll center.

A Caesar 4, Microsoft Encarta (2005 utániak) nem indul el .net nélkül. Valamire csak kell neki. Nem tudom, hogy egy játékprogramba minek.

Remélem a managelt memóriakezelés jobb, mint java-ban. JEdit-et használok text editornak. 10 rövidke állomány van megnyitva jelenleg. Saját bevallása szerint 50MB-ot foglal (java heap memory). :(

Fapadot kedvelő C/ASM programozóként nekem pl vallási problémáim vannak a ++-szal. Valószínűleg nagyon hasonló, mint amilyen problémája a ++-osoknak van a #-pal. :)

Múltkor beesett egy projekt, soros porton adatot csorgató RFID olvasót kellett mysql-es dolgozói adatbázisból ellenőrizni, beengedni, naplózni. Mondom, tanuljunk valami újat, a C# ránézésre elég ellenszenves, jó lesz vele szívni egy hetet. Aztán nagyjából három órával és 20 sor kóddal később működött az egész. Meggyőzött. (Fő munkaeszközként maradtam a C-nél, de a bemutatkozás kellemes volt.)

(Ehhez még hozzájön, hogy a marketingje szerint ez a C/C++ következő evolúciós fokozata és mást már csak nyugdíjas hobbiprogramozók használnak. Szóval...)

Szerintem sokkal tisztabb a .Net API-ja mint az alap windows-os ami meg Win3.1-es maradvanyokat is tartalmaz. Plusz nem kell figyelni a memoria kezelesre, pointerekre stb, ami nagy konyebbseg tud lenni. Az igazsaghoz hozzatartozik, hogy nem sokat programoztam C++-ban, de amikor .Net utan meglattam a win API-jat, hat a hanyinger kerulgetett.

Egyebkent nekem egyedul a mono, gtk#-al kapcsolatban csak az volt bajom, hogy nem teljes a dokumentacio. Egy TreeView pl. szerintem kicsit tul van bonyolitva, mire minden CellRenderer-t es hasonlot beallitottam eleg szepen megszenvedtem. E

Ehhez muszáj csatlakoznom. Hihetetlenül meggondolatlan dolog volt egy olyan rendszerközeli eszköz elkészítése .NET -el, mint az ATI CCC.

Ráadásul a megvalósítása is egy határ sz*r: nekem egyszerűen nem hajlandó elindulni. (Windows Update-n keresztül rendszeresen frissítem a rendszert és egyébként _minden_ más kifogástalanul működik). Állítólag csak az egyik verziójú .NET framework telepítettsége esetén (vagy csak a három: 1.1, 2.0, 3.5 valamilyen kombinációjában) működik. Nekem nem hajlandó elindulni. Olvastam troubleshooting listákat hiszen rengeteg ember tapasztalja ezt, minden feltétel megfelelő, mégsem.

A főiskolán egyébként C# nyelven kezdjük (és folytatjuk) a programozást. Első félévben objektumorientált programozás bevezetése folyik C#-ban, másodikban pedig Vizuális/eseményvezérelt programozás (kezdetben konzolos "játékok", később Windows Forms-os különféle célú egyszerűbb progik), és Programozási paradigmák és technikák laboron használjuk (interfészek, property-k, objektumok kezelése, függvények, stb), általában mindenki elégedettségére.

Hozzáteszem legutóbbi laboron a Visual C# Express 2005 valamilyen hibát észlelt egy olyan sorban, ami ÜRES volt, így megtagadta a fordítást. Mindenféle trükközésünk ellenére, egy bizonyos tartományban ami vagy üres volt, vagy működő kód volt rajta, (16-18. sor környéke) minden esetben hibával elszállt. Bug, bár a félév korábbi laborjain rendben teljesített.

http://gyuszk.homelinux.org

-- There is never time to do it right, but always time to do it over.

"Ehhez muszáj csatlakoznom. Hihetetlenül meggondolatlan dolog volt egy olyan rendszerközeli eszköz elkészítése .NET -el, mint az ATI CCC."

Az ATI CCC aztán nagyon rendszerközeli. Maximum abban merül ki a rendszerközelisége, hogy maximum a WinAPI -n keresztül matat mélyebre. A driver attól még natív kód.

Ati CCC .Net-be költözése szerintem elég logikus dolog volt annak idején.
Arról ugyanis megfeletkeztetek, hogy ez a költöztetés lehetővé teszi a CCC számára, hogy XP és Vista mint 32 mint 64 bites változatain tudjon futni. Ezzel egy csomó időt spóroltak az Atisok (nem kellet Xp-32, Xp-64, Vista-32 és Vista-64 verziókat külön-külön írni). Valószínűleg tartom, hogy ezért tudtak annó Vistára jóval az NV előtt jól működő driverrel kijönni. (Ezzel egy jelentős kódbázist rendszer függetlenné tehettek, és nagyobb erőkkel lehetett a mindenképp rendszerfüggő driverekre öszpontosítani.)
Egyébként nekem magamnak is az a véleményem, hogy ha nem túl nagy befektetéssel akarunk Xp és Vista, illetve 32 és 64 bites platformokat egyszerre támogatni, akkor jelenleg a DotNet az egyetlen normálisan járható út.

Zavard össze a világot: mosolyogj hétfőn.

Hm..köszi neked és saxusnak a kiigazítást.

Egyébként lehet hogy jó ötlet volt, mégis igen-igen problémásra sikerült megvalósítani. Nem véletlenül használnak sokan Omega-drivert (optimalizált, tweakelt Catalyst), amelyről lecsutkázták a .NET -es CCC-t, és a klasszikust tették vissza (és bővítették ki).

http://gyuszk.homelinux.org

-- There is never time to do it right, but always time to do it over.

( kmARC v | 2008. 04. 21., h – 09:05 )

HUPWikibe postoltad?

megj.: Epp most szorakozgatok a QT-vel C++ alatt (mar itt is atlatom), viszont Java nyelven QT-t programozni maga a mennyorszag (qtjambi). Namost, arra gondoltam viszont, hogy az Ubuntu+Gnome hatalmas eloretorese miatt jo lenne inkabb valami GTK-sat programmirozni - a GTK+C nagyonnagyon nem jon be (pedig ahol lehet a C-t preferalom), a Java+swt kodja meg megintcsak csunya a Qt-hez kepest.

Ez viszont ujra bejon. Qt-s egyszeruseggel (es atlathatoan) lehet felepiteni a feluleteket, es tobbplatformos. Hmm.... :)

Mi a helyzet a teljesitmennyel? Hallottam hireket, miszerint lassabb, mint a Java, stb. Par milliszekundumnyi szamitasi teljesitmeny nem zavarna, inkabb a GUI responsiveness-e erdekel. Hm?

( macat | 2008. 04. 21., h – 09:40 )

jó kis leírás. köszi

Szerintem a sebességgel nincsen probléma, ha a Java-val hasonlítjuk össze.

( triv | 2008. 04. 21., h – 10:26 )

Hali, jo kis kedvcsinalo leiras!
Amugy sajna az a sor, hogy winen is mono kell, h fusson a cucc, eleg kiabrandito.
A gui cuccok miatt tenyleg jo lenne a sharp, de ha kell plusz cuccokat telepiteni, hogy ugyanaz a kod ugyanugy fusson, akkor egy java-t is fel lehet mar csapni, s ott tuti ugy mukodik minden ahogy a masik platformon is.

hat ja az a cel h kompatibilis legyen, de meg akik nagy terjesztoi voltak az egyetemen, azok is csendben megsugtak, h a gui, hat bizony az nem nagyon fog futni mashol:) persze azota gyanitom probaltak fejleszteni a dolgon, de meg el-elcsipek ilyen velemenyeket ittott. Lehet h nem veletlenul tolja az ms a silverlight-ot...ha mar platform fuggetlen gui.

( NagyZ v | 2008. 04. 21., h – 10:38 )

igazabol a gtkt elkene felejteni ugy ahogy van :-)

a .net meg odaver.

bar feladat valogatja; en ugy vagyok most vele, hogy kliens oldali kodot .NET, szerver oldalit meg EE. mondjuk nem webprogramozo vagyok, ugyhogy nem pancsolok weboldalokat, de mondjuk webszervizeket itt tok kenyelmes hasznalni (foleg hogy van ORM); ASP.NET -ben nem tudom mennyire van erre lehetoseg, meg nem akartam sosem irni ott webszervizt.

Így van, a LINQ nem egy perzisztencia réteg, annál jóval több. :)
Keretrendszerbeli, nyelvbeli és fejlesztőeszközbeli támogatás arra, hogy tíz perc alatt megírd (legeneráld) a saját perzisztencia-réteged. Nem mellesleg teljesen elfedve a domain réteg elől, hogy ő most tulajdonképpen adatbázisba, XML-be, memóriabeli szerkezetbe, vagy tetszőleges, adatot stuktúrált módon tárolni képes akármibe dolgozik.

Természetesen a DML utasítások is támogatottak a DataContext osztály SubmitChanges() metódusán keresztül.
LINQ to SQL: Inserting data through Object Model
LINQ to SQL: Update data through Object Model

Ami miatt sok a félreértés a LINQ körül, az az, hogy elég homályos a terminológia. A LINQ-kel egy nagy csomó új nyelvi feature, fejleszőeszköz és egyéb tool támogatás, technológia jött be a .net-be. Ezekre hol gyűjtőnévként használják a LINQ-et, hol csak a új szintaktikát értik alatta, hol meg megint mást, mint én itt föntebb a DLINQ-et (ami kétségtelenül nem egészen helyes, de a hibrid mód topicban nem akartam túlfeszíteni a húrt).

Hát, jó a kérdés. Fejlesztői szemszögből talán az, hogy a (D)LINQ egy alapvetően más programozói modell. Sokkal jobban idomul az OOP-hez, így valószínű a legtöbb fejlesztőnek kényelmesebb használni.
Technikai szempontból nem tudom, mert a típusos dataset alját abszolút nem ismerem (a tetejét se nagyon), valószínű vannak nálam kompetensebbek a kérdés megválaszolására. :)

( BaT | 2008. 04. 21., h – 12:01 )

Hmm, felkerül a megtanulandó dolgok listájára. :) Jelenleg a java szerepel előkelő helyen még ezen a listán, és ahogy a kommentek alapján olvasom, a kettőnek programozási szempontból sok köze van egymáshoz.

( emberk | 2008. 04. 21., h – 15:24 )

Tapasztaltabbaktól kérdezem, hogy ez a programnyelv mennyire alkalmas prociigényes matematikai prblémák megoldására? (Nem akarok indíg mindent 2*írni, mert grafikus felületet is kell produkálnom, és az win/lin esetén totál más)

Proci igényes matematikai prblémák megoldására szerintem a legjobb, ha a legalacsonyabb szinten programozod le. Szerintem nem is kellene az egész programot alacsony szintű programozási nyelven megírni, elég ha csak azt a programrész írod meg ami a matematikai számolásért felelős. Szerintem.

sly @ w3m.hu

C-ben szoktam írni (diffegyneletmegoldás meg egyebek asm-ben kicsit túl sok időt emésztenének fel, míg megírom jól. Addigra a C-kód rég végez mire megírom asmben, tény hogy gyorsabb, de rohadtul nem éri meg, max 20%-tot tapasztaltam eddig). Mert az eredmény cask 1-2 alkalmommal kell nem fut a pogram állandóan évekig.....

Nem tudom, mire gondolsz? Nyelvi támogatás annyi van, amennyi egy általános célú programnyelvtől elvárható: alapműveletek, a Math osztályon keresztül trigonometrikus, logaritmikus, kerekítési, stb függvények.
A sebesség témája: fordításkor IL kódot generál a fordító, ami futtatáskor on the fly lefordul natívra, onnantól az fut, így sebességben szintén kb. azt hozza, amit a többi általános célú nyelv.
Így első blikkre egy dolog lehet necces: a GC. Ha sok temporális objektumot csinálsz, amit aztán hamar eldobsz, akkor érdemes lehet olyan nyelvet választani, ahol te tudod kontrollálni a memória-felszabadítást.

Nem használtam, ezért írtam, hogy állítólag. Mivel rémlik, hogy valahol valaki nagyon szidta.

Erről a régebbi qt frontendről meg nem hallottam. Ettől függetlenül, mivel valószínűleg nagy szívás átírni wxWidgets-ről egy alkalmazást QT4-re, talán van valami oka az átállásnak.

> A QT-t nem ismerem, mert nem vagyok milliomos.

LOL. Ez kicsit demagog igy, nem gondolod? :)

Az osszes milliomos viszont ismeri. A golf- es yacht-klubok tulajdonkepp a trolltech hetvegi szorakoztatokozpontjai.

Szoval attol, hogy nem csinalhatsz vele nemcsak GPL-es appokat, meg lehet tanulmanyozni, sot eleg sok pelda talalhato hozza a neten, szoval - ha egy internetelerest, es a villanyszamlat ki tudod fizetni, akkor akar - ismerheted a QT-t.

( turul16 v | 2008. 04. 21., h – 21:38 )

Ha a MonoDevelop-al gui hegesztes nem ment, glade -vel is eleg egyszeru es nagyszeru dolgot lehet muvelni.
pl [Widget] -moge erdemes benezni :)

( kbalint v | 2008. 04. 22., k – 02:36 )

wow, nagyon jó cikk, köszönjük!
én 4 éve tolom a C# + .net világot magam előtt igaz webes projektekkel, a desktop-dolgokat csak windows service-k formájában ismerem (jó, összesakkoztam már pár gui alkalmazást is VS-ben), de a GTK cuccoktól mindig is féltem egy kicsit, egy kis projektnél C-ben már játszottam vele, de megőszültem tőle :D

Viszont most felnyitottad a szemem, amint időm engedi megnézem és megpróbálom ismét - én is OS X alatt szeretek dolgozni, hátha vissza tudok térni teljesen.... (bár a MonoDevelop még a webes fejlesztést khm. fogalmazzunk úgy nem nagyon támogatja [auto code-snipps, intelisence-mockup etc..])

~ubuntu, os x~

bár annyit még hozzátennék, hogy ha a nagy Gnome-evangélista szája íze szerint (Miguel) mennek a dolgok akkor én a következőt látom a linux-desktop jövőjének:

C# mint Gnome default language, GTK (Moonlight mint widgets) mint GUI, Cairo alapon... kihagytam valamit?:)

~ubuntu, os x~