GUI programozás linuxban, mivel érdemes kezdeni?

C/C++

Szeretnék programozni tanulni, foleg a multimedia, grafikus alkalmazasok, gui frontendek erdekelnek, ilyen teren van mit hozzatenni meg a linuxhoz.

Teljesen kezdo nem vagyok, regebben programozgattam qbasic-ben, majd pascalban
(legmagasabb szint egy paint szeru gui program volt egerkezelessel, par asm betettel dos alatt).

Nezegettem forumokat, es nem tudom eldonteni hogy C vagy C++ legyen, ami toolkit szinten szimpatikus az a QT, foleg hogy a QT4 minden platformra elerheto GPL szinten (ha a program is az lesz), igazabol ebben szeretnek segitseget kerni hogy melyik legyen. Esetleg a python vagy java-val erdemes meg foglalkozni ilyen teruleteken? (javanak a nativ swing-es feluletet utalom, tehat vmi gtk vagy qt-re raeroltetheto erdekelne csak).

Milyen konyveket ajanlanatok a temaban? (lehetoleg linux specifikusak)

  • 8452 megtekintés

igazabol inkabb a binarissa fordithato nyelvek erdekelnenek sebesseguk miatt c vagy c++, de nem hatarolodom el semmitol. perlrol hallottam, de csak azokat a nyelveket ismerem alap szintem amit fentebb mar irtam, tehat perlt, pythont, c++ -t egyaltalan nem

c-ben tanultam suliban egy szemesztert programozni valaszthato targy kereteben

::powered by Archlinux

a python-t néhány óra alatt el lehet sajátítani. szvsz könyvből tanulni programozi felesleges. abból tanul az ember a lejobban, ha kiindul a hellówörldből, aztán elkezd lassan konvergálni a megoldandó probléma felé. gtk-t cben programozni, meg pfffff... rémálom. nyugodtan kipróbálhatod gtk#/mono párost. hiába menedzselt, nagyon jól karban van tartva, rendkívül jó a support és gyors is...

Tényleg gyorsan lehet tanulni a pythont. Szerintem azért, mert olyanra készítették el, amilyenre én is tenném, azaz megfelel az elvárásaimnak és gondolkodásmódomnak. De egy könyv sose árt. Az is igaz, hogy gépelni kell és próbálkozni, az adja az igazi tudást.
--
unix -- több, mint kód. filozófia.
Life is feudal

( Pontscho | 2007. 01. 14., v – 14:50 )

Ha mar linux, akkor szerintem GTK+C. Szemely szerint en utalom a cpp-t.

---
pontscho / fresh!mindworkz

Pythonhoz ezt "Tanuljunk meg programozni Python nyelven c. könyvének magyar fordítása" illetve ezt "Bevezetés a Pythonba példákkal c. segédletének magyar fordítása", amit letölthetsz innen: http://learnpython.openproject.hu/
Csak ki kell nyomtatni, de nézegetheted PDF-ben vagy OOo formátumban is.

Python!
En 16 evesen kezdtem hozza olvasgatni a pythont (semmit nem tudtam a programozasrol)
Somindent megragadt bennem.
De lealltam vele, mert erettsegi utan jobb lesz komolyabban foglalkozni vele.
Addig is tanulnom kell :S
A python asszem jo valasztas. (sokat nem ertek a programozashoz, de ez tetszett)

-----
Intel1,6Ghz, 512SD, Ubuntu Edgy Eft 6.10

Az a C könyv nem roszz, ajánlom még ezt utána, vagy közben, drágább is jobb is, szerintem. a Pythonról meg a Rashi Gupta Mindenttudó Pythonja mindent elmond amit egy pythonozni vágyó újoncnak tudnia kell, utána meg úgyis csak a levlistet meg a doksikat + referenciakönyveket bújod, de első pythonkönyvnek szerintem ez nagyonjó. Hogy a felmerülő témánál maradjak mégis (mármint GUI linux alatt) ahhoz a mindkettőből el tudsz indulni, a Linux Programozás az a Linux alá készítendő alkalmazások leendő fejlesztőinek készült. Van benne C meg C++ is, mikor mire van szükség, teljes balance. Meg ha jól dereng a GUI-os alkalmazásokat QT-ban oldották meg, bár szerintem a gtk-ról sem érdemes megfeledkezni (de akkor is a curses a legszebb GUI :))

Nem igazán tudok elképzelni GUI programozást OOP nélkül. Lehet, mert a GTK működik C-n, de nem lehet kényelmes. Először én se értettem az OOP-t, de akkor valami ősi Turbo Pascal könyvet olvastam, amiből nem lehetett érteni, mi a lényeg. Viszont anapság szvsz mindenképpen meg kell tanulni és megszokni.

GTK felépítését tekintve OO még, ha C -ben is írták, kövezzenek meg OO hívők, de nekem OO :)
GUI tipikusan olyan eset, ahol van értelme az OO -nak.

(De amíg olyan fordítót használ az ember, ami nem vesz ki ilyen baromságokat pl., hogy meghívsz egy methódust, változó értékhez hozzá adsz 2 -őt argumentummal, az utánna meghív egy másodikat arg-1, az pedig (arg-1)-1 egy másikat, a helyett, hogy a fordításkor, a fordító kiszedné +2 ,-1, -1 -et, hülye példa, de ilyen nagyon OO szemlélettel programozáskor ilyesmik simán ben maradnak.)

------
gentóhuszár

Nem, nem ezt. C-ben még annyira sem lehet OO kódot írni, mint Adaában, hiszen az utóbbiban csomagszinten definiált mindent, nincs valódi osztály - nem igazán OO, bár közelít hozzá. C-ben meg csak adatok és algoritmusok vannak, semmi más.

Valahol meg kellene találnom a két fogalom pontos definícióját, csak nem tudom, hol van ez normálisan leírva...

Nézd meg: C -ben vannak makrók is, meg struktúrák is :)
Egy C++ methodus hívás, sokszor nagyon hasonló, egy olyan függvénynek a hívásához, aminek első argumentuma mutató egy struktúrára.

Egy két fura struktárával és makróval , nagyon C++ szagú dolgot lehet művelni.

Szerinted a nyelv tesz OO -vá valmit?

A mi sulinkban volt olyan akinek vissza lökték a JAVA progiját, mert nem volt kellően OO :)
Csak egy osztályból állt teli static tagokkal, az már eljárás orintált :-D
------
gentóhuszár

Definicó szerint ezek közül valahányat megvalósít egy OO cucc.

C nyelv Nem ojektum orientált nyelvnek definiálódott, nem tartalmaz ilyen nyelvi eszközöket.
De OO szemlélettel igen is lehet programozni benne.

Vess egy pillantást GObject/glib/gtk manualokra, ilyen káronkodások vannak benne:
Object Hierarchy
Implemented Interfaces
Properties

Ha akarod nevezzük csak Object Based szerűnek :), hogy a szent OO szót, ne lehessen együtt említeni az ósdi,elavult szar C -vel :P
------
gentóhuszár

"A mi sulinkban volt olyan akinek vissza lökték a JAVA progiját, mert nem volt kellően OO :)"

Nincsen ebben semmi szokatlan/vicces. Vissza loktek, mert alapveto tervezesi hibat kovetett el, ha a cel egy objektumorientalt program elkeszitese lett volna. Gyanitom, hogy ott arra lettek volna kivancsiak, hogy hogyan tervez es valosit meg egy programot objektumokon keresztul. Lehet Java-ban is procedurlisan programozni (mivel mas nem nagyon johet szoba, felteszem, hogy ezt kovette el az illeto), csak akkor mi a rakert kell ehhez a Java, ha:
- nem el a lehetosegeivel?
- nem mutatkozik meg a munkajaban az, amire egyebkent kivancsiak lettek volna? :-)

Mellesleg - barmennyire is furcsa - a programok proceduralis megvalositasa lassan ki fog kopni a "divatbol". Leginkabb ahhoz tudnam hasonlitani, hogy ezelott 25 evvel meg volt ertelme assembly-ben (jol hallod) megirni egy konyveloprogramot mert megterult, ma mar lassan kernelt sem eri meg proceduralisan, mert jol atgondoltan, objektumorientaltan megirva talan 1-5% overheadje lesz (ha nem gyorsabb, hatekonyabb lesz), de ~tizedannyi hiba lesz benne es ~tizedannyi ember elegendo a megirasahoz/karbantartasahoz. Szamos kernel letezik ma mar amelyet objektumorientaltan irtak. :-)

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

Elvilag java nyelv tudás volt a kérdéses, meg hogy működjön a kód.
A kód működött, és Java -ban is volt írva, mondjuk elég viccesen néztek ki benn a C-ben implementált listák (talán fák is ) átcopyzásai , de futott :)

pl. Linux kernel elég jól strukturált, OO ide vagy oda. (Driver fejlesztői kézikönyvet olvasgattam)

A kernelben vannak ASM kódrészletek is. A sok driverféleség leginkább bit tologatás, semmi komolyabb algoritmussal. Aki azt mondja, hogy írjuk C++/JAVA -ba kernelt/drivert csak ezért, mert akkor már OO nyelvet használtunk és az szuper, az sürgősen forduljon orvoshoz. Ha valahol, akkor a kernelnél nem kéne teljesítményt áldoznunk.
(Ami szerintem így is lassú :) )

Attól még, hogy valami úgymond OO, lehet gyors.
És az OO egyáltalán nem garancia biztonságra, nagyon jól képes elrejteni hibát is :)

------
gentóhuszár

"Aki azt mondja, hogy írjuk C++/JAVA -ba kernelt/drivert csak ezért, mert akkor már OO nyelvet használtunk és az szuper, az sürgősen forduljon orvoshoz."

Szerintem OO kernelek fejlesztoi eleg kevesen akadnak akik azert donttek igy: "csak ezért, mert akkor már OO nyelv". Ennel vannak ertelmesebb celok is amelyek orvosi beavatkozas nelkul is eleg konnyen belathatoak:
1. Karbantarthatosag. Nem mindegy,
- hogy ~200MB forraskodot kell kapalni, vagy 20MB-osat
- hogy evente 50 biztonsagi rest kell foltozni, vagy 5-ot

2. Munkamoral. Nem mindegy,
- hogy 2000 nagykepernyos fejlesztot kell egyben tartani, vagy 20-at
- hogy 2000 emberrel kell megertetni/lenyeletni egy-egy uj technologia bevezeteset, vagy 20-al

"Ha valahol, akkor a kernelnél nem kéne teljesítményt áldoznunk."

Ha valahol van ertelme az OO fejlesztesnek, akkor azok az extrem osszetett szoftverek. A mai operacios rendszerek kerneljeire eleg jol passzol egy ilyen megallapitas. :-) Nem mellesleg, hogy ha az normalisan van megirva, nem meglepo, ha jelentos hatasfokjavulast hoz, veszteseg helyett. Lasd pl. az MS Singularity tetsztjeit, FreeBSD, Linux, Windows kerneleket nehany benchmarkban - eleg szep folennyel - csufosan elkalapalta. (valaki ms-berenc dobjon mar egy linket, nem talalom)

Szerk: meg van

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

első benyomás:
hello_world mérte C -ben 8kb és nem, 431,900 byte linux alatt. (-g vel 9Kb)
RSS Size is csak 356Kb. és nem 1,416 Kbyte.
(Többi eredmény mennyire megbízható akkor?)

Koncepciónak nem az OO a lényege.

CIL/MSIL használ mindenütt. Nem használja a processor adta védelmi lehetőségek
nagy részét (Ezzel sporól erőforrást, a Cycle timeknál).
(" memory management hardware on processors for
protection, which suggests the possibility of reevaluating this hardware. In general, many programs only use some of the functionality of memory management hardware.")

Kitíltja natív binárisokat, ami codekek szempontjábol nem jó (Oda kell az asm), valamint Virtualizáció szempontjábol sem tul jó a koncepció.

Kihoz egy csomo dolgot, hogy kevesebb ciklus alatt fut le, (Linux esetében ez kernel verzó és belításoktól is igen csak függ), de azt nem írja le, hogy a koncepció, miatt több ilyenre lenne szükség.

Memória management: Ha processek százai fognak futni a rendszeren, megnézném mit csinál a cucc az 1Gb rammal, ha ugyan olyan funkciókat használ, mint egy desktop user, bár van neki 5 féle gc, az egyik csak jó :) (Lehat váltogatni őket, attól függően mit mérnek :) )

I/O teszt: Nem volt győztes az algoritmusuk, és még az sem derült ki, hogy mennyi prociba ill. memóriába került nekik, ill. a többi OS-nek.

Koncepció igen érdekes, van benne fantázia, idővel kiderül, mit tudnak kihozni belőle, a fenti fikázások ellenére nem vetném el a koncepciót, talán kijöhet belőle valami jó.

------
gentóhuszár

"hello_world mérte C -ben 8kb és nem, 431,900 byte linux alatt."

Osszetett programokrol (kernel) beszeltunk, nem egysorosakrol. Nem a nyelvhez valasztjuk a celokat, hanem a celokhoz a nyelvet/platformot.

"CIL/MSIL használ mindenütt."

...

"Kitíltja natív binárisokat, ami codekek szempontjábol nem jó (Oda kell az asm), valamint Virtualizáció szempontjábol sem tul jó a koncepció."

Ez egy kiserleti operacios rendszer ahol a cel uj programozasi technikak kidolgozasa bonyolult iranyitastechnikai feladatokhoz. Egyelore ne merjuk ossze olyan feladatokkal amelyek eleve nem is voltak celkituzesek. Ha az iranyitastechnikai algoritmusokkal eljutottak egy lepcsofokra ahova szerettek volna, akkor johet a kovetkezo elerendo cel: asm/gepi kod es igy tovabb.

"Memória management: Ha processek százai fognak futni a rendszeren, megnézném mit csinál a cucc az 1Gb rammal, ha ugyan olyan funkciókat használ, mint egy desktop user, bár van neki 5 féle gc, az egyik csak jó :)"

Messze hatekonyabban/gazdasagosabban, mint hagyomanyos memoriakezelessel. (olvasmany: .NET GC manual)

+1: nincs kulon kernelspace/userspace, azaz az alkalmazasok is nagysagrendekkel gyorsabban fognak a memoriahoz hozzaferni.

"I/O teszt: Nem volt győztes az algoritmusuk, és még az sem derült ki, hogy mennyi prociba ill. memóriába került nekik, ill. a többi OS-nek.

Nem neztem meg mielott belinkeltem, lehet, hogy ez nem az benchmark lesz amit en lattam kb. fel eve, de lehet hogy az. Passz. :-)

"Koncepció igen érdekes, van benne fantázia, idővel kiderül, mit tudnak kihozni belőle, a fenti fikázások ellenére nem vetném el a koncepciót, talán kijöhet belőle valami jó."

Egyre jobban uj technologiakra, fejlesztesi modszerekre leszunk rakenyszerulve mindenutt az IT-ben, mert a jelenlegi formaban a szinte vegtelensegig eszkalalodott projektekkel csak assuk a godrot naprol-napra egyre melyebbre.

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

"hello_world mérte C -ben 8kb és nem, 431,900 byte linux alatt."

Osszetett programokrol (kernel) beszeltunk, nem egysorosakrol. Nem a nyelvhez valasztjuk a celokat, hanem a celokhoz a nyelvet/platformot.

Tárgyi tévedés a dokumentációban! Erről szolt ez a bekezdés!

Ha az iranyitastechnikai algoritmusokkal eljutottak egy lepcsofokra ahova szerettek volna, akkor johet a kovetkezo elerendo cel: asm/gepi kod es igy tovabb.

Nem jöhet mert akkor döl a koncepció, és elveszti azon előnyök egy részét amiért létre jött.

Messze hatekonyabban/gazdasagosabban, mint hagyomanyos memoriakezelessel. (olvasmany: .NET GC manual)

Nem minidg, és 5 féle algoritmus van. Miért is? Mert, általánosan minden szempontból jó gc nincs.

Egyre jobban uj technologiakra, fejlesztesi modszerekre leszunk rakenyszerulve mindenutt az IT-ben, mert a jelenlegi formaban a szinte vegtelensegig eszkalalodott projektekkel csak assuk a godrot naprol-napra egyre melyebbre.

Nem a mezei imperatív OO a kivezető út, szvsz. Valamely fordítoprogramos/JIT -es funkcionális (vagy más dekleratív) (pl. Ocaml) nyelv vagy valamely labview szerű visual programming language.. (Persze erősebb optimalizációval)
Itt érdemes lehet kutakodni.

------
gentóhuszár

"Nem jöhet mert akkor döl a koncepció, és elveszti azon előnyök egy részét amiért létre jött."

Nem nem, van itt egy csunya felreertes, ezen a ponton mar tul van a projekt:
"This isn't the CLR. In our world, we compile entire MSIL for the kernel into x86 instructions at installation time."
Az eredeti Galen Hunt-tol - a projekt vezetojetol.

Az az erzesem, hogy alaposan felreerted az egeszet. Javaslom, hogy nezd meg a videokat, minden fenti nyitott kerdesedre benne vannak a valaszok. :-)

Pontos meresi adataik is vannak a hagyomanyos es az uj rendszer teljesitmenyet illetoen - arra keszulj fel, hogy nagyon meg fog valtozni a velemenyed a temaval kapcsolatban. :-)

"Nem minidg, és 5 féle algoritmus van. Miért is? Mert, általánosan minden szempontból jó gc nincs."

Azert, mert jelenleg ennyi van publikusan elerheto. Biztosithatlak afelol, hogy ennel joval tobb letezik. :-)

A fenti projekt egy kimondottan erre a celra keszitett GC-t fog hasznalni, ugyanis szeparalt privilegizalast, utemezest biztonsagosan/megbizhatoan egyik jelenlegi megoldas sem biztosit.

Szvsz, lehet, hogy a vindozt elba.. elrontottak, de nem szabad oket alabecsulni, vagy barmilyen elso hallasra furcsanak hangzo dolgot - barki is mondja - kapasbol visszautasitani. Meg kell hallgatni, megismerni minel tobb dolgot es ha az ember az ismereteknek mar birtokaban van, akkor tud csak tisztan latni es a legjobb tudasa szerint allastfoglalni. Csak igy szulethetnek uj dolgok. :-)

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

This isn't the CLR. In our world, we compile entire MSIL for the kernel into x86 instructions at installation time.

A lényeg, hogy csak MSIL -böl kelettkezett kód futhat rajta, ez hogy JIT Compiler-t lefordítják nativ kódra triviális, másképp nem is működhetne :)
A kernel többi részének lefordításával, értékes másodperceket nyernek a bootolásnál.

nézd meg a videókat, minden fenti nyitott kérdésedre benne vannak a válaszok.

Videó elég rossz minőségű (hang is), nem hallgatom meg, még háttér zajként is csak idegesítene a zizegése. Nem hiszem, hogy voltak olyan kérdéseim, amit megválaszolna, egy zizegőps videó. De, ha végig hallgattad, Miért mérték olyan nagyoknak a linux binárisokat? Talán ezt tekinthetjük implicite kérdésnek a hozzászólásámbol.

Messze hatekonyabban/gazdasagosabban, mint hagyomanyos memoriakezelessel. (olvasmany: .NET GC manual)

Nem minidg, és 5 féle algoritmus van. Miért is? Mert, általánosan minden szempontból jó gc nincs.

Azert, mert jelenleg ennyi van publikusan elerheto. Biztosithatlak afelol, hogy ennel joval tobb letezik. :-)

Te nagyobb singularity és érintett technológia hívő vagy, mint gondoltam.
Szerinted van egy misztikus gc algoritmus, nevezzük isten -nek az egyszerűség kedvéért, ami tökéletes csak titkolják :) Nincs tökéletes gc algorítmus megsúgom, elfogadható kompromisszum van.. (Különösen, ha sátan(expert asm programozó) kódjához viszonyítjuk teljesítményt)
És, ha az értelmezés nem ment volna, arra utaltam, hogy miért is van 5, azért, mert mindnek van hátránya bizonyos szituációkban..

A fenti projekt egy kimondottan erre a celra keszitett GC-t fog hasznalni, ugyanis szeparalt privilegizalast, utemezest biztonsagosan/megbizhatoan egyik jelenlegi megoldas sem biztosit.

Az szerinted még gyorsabbá, teszi gc -t, ha olyan kóddal bővitik, ki a kezelőt ami biztosítja, hogy a szemétből ne lehessen bizalmas adatokat bányászni? (Ez sem kérdés csak egy kérdő jel :) )

Végéhez:
Olvasgattam a doksit.
"Koncepció igen érdekes, van benne fantázia, idővel kiderül, mit tudnak kihozni belőle, a fenti fikázások ellenére nem vetném el a koncepciót, talán kijöhet belőle valami jó." -Ez volt a véleményem.
Nem tudom miből gondolod, hogy leírtam az ötletet. Sőt nekem úgy tűnik, hogy pont az elenkezőjéről szolt a záró gondolatom.

Attól még, hogy látom valaminek a hátrányait is nem jelenti azt, hogy rossznak tartom.
...bla..bla.. Lenne még mondandóm, de úgy látom, write only módban vagy..

------
gentóhuszár

"Te nagyobb singularity és érintett technológia hívő vagy, mint gondoltam."

Nem vagyok fun-ja alapvetoen semminek, igy a singularity-nek sem. Egyszeruen csak nem dugom a fejemet a homokba. Ha van es vannak benne hasznos dolgok akkor nyitottnak kell lenni fele.

"Szerinted van egy misztikus gc algoritmus...

Turul, ne komolytalankodjunk mar... :-)
Nezd meg a videot (3-mas) ott ezekre valaszt kapsz, nem veletlenul adtam a linket.

"Az szerinted még gyorsabbá, teszi gc -t, ha olyan kóddal bővitik, ki a kezelőt ami biztosítja, hogy a szemétből ne lehessen bizalmas adatokat bányászni?"

Ezt nem ertem miert kellett osszemixelni. Ket problema jelentkezett a jelenlegi gc algoritmusnal, az egyik, hogy kiszamithatatlan idokozonkent indult, masik pedig, hogy nem tudtak biztonsagosan elszigetelni az egyes alkalmazasokat, ezert kellett tervezni egy uj GC-t.

"... de úgy látom, write only módban vagy.."

Azert ezt nem illett volna igy... Azok utan, hogy kezsegesen valaszolgatok, linkeket keresgelek.. :-(

Igy pedig kulonosen nem all jol neked:

"Videó elég rossz minőségű (hang is), nem hallgatom meg..."

... mert akkor en azt gondolom, hogy tajekozodas hianyaban nem kene a kerdesben allast foglalni. Tajekozodni kell - egy lehetoseget fentebb biztositottam hozza a video altal - es ha valami megsem vilagos, akkor lehet kerdesek lehetosegevel elni, ill. a temaba kritikakat felvetni. Addig tok felesleges.

PS: Nekem az az erzesem, hogy a beszelgetesunket nem a tema iranti erdeklodesed hajtja...

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

"PS: Nekem az az erzesem, hogy a beszelgetesunket nem a tema iranti erdeklodesed hajtja..."
Vissza fele ugyan ezt erzem. Mivel elmondtam 3 szor, hogy nem rossz az k*. OS , te meg 3 szor probalsz meggyozni rolha, hogy jo amikor en nem mondtam az ellenkezojet.
Ezert vagy write only modban.

Meg vagy gyozodve arrol, hogy en fejemet a homokba dugom, es, hogy olyan maniakus hivoje vagyok valami masnak, hogy el se olvasom. Elolvastam a doksit.
A te videod, miatt tettem fel akkor olyan stuffot ami lejatsza az idiota hang formatumat, aztan beletekertem, akkor nem volt 1 oram recsegest hallgatni.

"Ezt nem ertem miert kellett osszemixelni." De erted.

------
gentóhuszár

"Mivel elmondtam 3 szor, hogy nem rossz az k*. OS"

Tolem akar mondhatnal ra csunyat is, nem vagyok zealotja a temanak - meg altalaban semminek - es nem is errol van szo. Arra proballak ravezetni, hogy ezzel egyidoben megvalaszolt kerdeseket/kritikakat vetsz fel:

1. "Koncepciónak nem az OO a lényege..."

2. "CIL/MSIL használ mindenütt. Nem használja a processor adta védelmi lehetőségek nagy részét..."

3. "Kitíltja natív binárisokat..."

4. "Kihoz egy csomo dolgot, hogy kevesebb ciklus alatt fut le..."

5. "Memória management: Ha processek százai fognak futni a rendszeren, megnézném mit csinál a cucc az 1Gb rammal, ha ugyan olyan funkciókat használ, mint egy desktop user..."

6. "Szerinted van egy misztikus gc algoritmus..."

7. "Attól még, hogy látom valaminek a hátrányait is nem jelenti azt, hogy rossznak tartom."

Tiszta sor, de erdekelne, hogy hogyan lehet valaminek akar az elonyeit vagy hatranyait megitelni feluletes betekintessel? Hat erre proballak ravezetni turul: homalyos ismeretekkel NEM KELL ALLAST FOGLALNI semmiben.

Teged a valaszok nem erdekeltek, viszont tovabbra is kritikakat sorakoztatsz fel egy tema kapcsan amelyeket nem sorolnal fel, ha a valaszokat hajlando lennel megismerni. A videokban a "riporter" ugyanilyen vagy hasonlo jellegu kerdeseket vet fel, a fejlesztok pedig kimerito valaszolokat adnak ra. A beszelgetopartnered meg keresgel is neked hozza linkeket, te pedig a "rossz minosegu felvetel"-re hivatkozva folytatod a butasagok halmozasat. Majd n+1-szer, tapintatosan felhivjak ra a figyelmedet, hogy "ezek megvalaszolt kerdesek, nezd meg a videokat" erre te "halabol" leinditod egy:

"úgy látom, write only módban vagy.." c. megjegyzessel.

Igy inkabb azt javaslom, hogy tenyleg NE nezd meg a videokat, de ha megis raszannad magadat akkor keresgeljel hozza magad linkeket. Reszemrol ennyi.

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

Én kérek elnézést, hogy az általad belinkelt doksikbol is tudok következtetni.
Azért nem kérek elnézést, hogy nem az esetleges előnyöket soroltam, mert doksibol azok is lejöttek.
Meg fogom nézni azt k. videot a közeljövőben, de ha utanna úgy fogom érezni, hogy nem lettem okosabb ill. egyetlen állításomat sem cáfolta meg, nagyon mérges leszek, komoly szitok áradatra számíthatsz.. minimum.

Szerintem a doksi hossza nagyobb, mint a video hanganyagáé, ezért gondoltam, hogy felesleges. Komolyan mondom nagyon mérges leszek, ha tényleg felesleges.

Teljesen biztos vagy benne, hogy a video rengeteg olyan anyagot tartalmaz ami a doksiból nem derült ki (számomra) ?
------
gentóhuszár

"Teljesen biztos vagy benne, hogy a video rengeteg olyan anyagot tartalmaz ami a doksiból nem derült ki (számomra) ?"

Hat ha nem igy volna, akkor ez a thread is lenyegesen rovidebb lett volna. ;-)

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

"Egy C++ methodus hívás, sokszor nagyon hasonló, egy olyan függvénynek a hívásához, aminek első argumentuma mutató egy struktúrára."

Pont most nézegettem, hogy a D nyelvben lehet ilyet. :)
Vagy fv hívás első paraméterben a "struktúrával" vagy osztály szintű metódust hívsz. Tetszett a rugalmassága.

"Nézd meg: C -ben vannak makrók is, meg struktúrák is :)
Egy C++ methodus hívás, sokszor nagyon hasonló, egy olyan függvénynek a hívásához, aminek első argumentuma mutató egy struktúrára.

Egy két fura struktárával és makróval , nagyon C++ szagú dolgot lehet művelni."

Ahha...
Öröklődés?

Mert az OO-ban nem az a pláne hogy a "structodnak vannak függvényei".
Mert abban igazad van, hogy kicsi a külömbség az "s.f()" és az "f(*s)" hívás között (már csak azért is, mert valójában kb ez fordul).

De az öröklődésnek pont az a lényege, hogy ha egy ősben megvan egy fv, akkor meghívhatod a gyerekre is. Hogy oldod ezt meg C-ben anélkül, hogy újraírnád (még ha csak copy+paste szinten is) a fv-t?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

De az öröklődésnek pont az a lényege, hogy ha egy ősben megvan egy fv, akkor meghívhatod a gyerekre is. Hogy oldod ezt meg C-ben anélkül, hogy újraírnád (még ha csak copy+paste szinten is) a fv-t?

typedef struct
{ ... } a;
typedef struct
{ a x; ... }; b

egy a*-t manipulalo a_call() fv-t is meg tudsz hivni b egy peldanyara, a_call(&bb->x); vagy barmi hasonlo modon.

oke, ez nem u'gy oroklodes, de az ujrairni azert C-ben sem kell ;]

Az öröklést C-ben úgy szokták megoldani, hogy a struktúra első tagja az ős. Tehát ha cast-olod, simán hívhatod az őrse vonatkozó "metódus"-okat. Csak az osztály-hierarchiával kell tisztában lenni.
Nem árt megnézni egy Gtk+ Hello World alkalmazást, mondjuk itt: http://www.gtk.org/tutorial/c39.html#SEC-HELLOWORLD

Többszörös öröklődés, interface-ek, absztrakt metódusok, virtuális függvények?

Win32API-ban is lehet az interfészeket úgy használni C-ben, mintha OO lenne, pedig valójában nem is az...

C-ben programozni objektumorientáltan egyszerűen röhejes. Arra jó a C++, ami ráadásul típusbiztos nyelv (azért az Adához képest sehol sincs, de az más történet). A feladathoz kell választani a nyelvet, nem fordítva.

C++ Virtuális methódus kezelése, kb ugy néz ki ha emlékeim nem csalnak.
hogy minden Virtuális Osztály példánya tartalmaz egy címet egy táblázatra, minden virtuális methódus címe itt van. (tipusonként más-más) táblára mutat. C ben -simán lehet ilyet firkálni.

Többszörös öröklődés necces, de interface megoldható, hasonlóan az eddig elhagzottakhoz.

Abstrakt methódus: minden nem definált methódus, meghívaj káromkodás() fügvényt :) Hatás ugyan az, csak futás időben :)
------
gentóhuszár

a virtuális tábla tényleg így működik. Az őstípus (legfelső) megadja, hogy a tagfüggvényei milyen sorrendben vannak, innentől kezdve az összes származtatottban ugyanaz a sorrend. Ha bővítés van, akkor a tábla végére kerül. Ezért működik az, hogy ha pointer egy alprogram paramétere, akkor a dinamikus típus számít, vagyis a tényleges típus tagfüggvényei hívódnak meg. A fordító ezt előre nem tudhatja, azonban minden típusnak ugyanúgy néz ki a táblázata, ezért elég azt lefordítani a kódban, hogy hanyadik a táblázatban. A ténylegesen meghívott függvény címének megtalálása pedig futási időben történik. Ez nyilván lassabb, mintha a cím azonnal meglenne...

C-ben programozni objektumorientáltan egyszerűen röhejes.
Szerintem inkább ez a kijelentés röhelyes.
Nem tudom, mióta programozol, de elárulom: nem voltak mindig C++ fordítók (pláne nem Java és .NET). Még a 80-as években programoztam pl. Amigán. C++ nak még híre sem volt akkoriban, mégis OO módon kellett rá fejleszteni. Szerinted használható lett vona az API, ha nem OO, csak azért mert a C nem OO nyelv?
GTK+-szal ugyanez a helyzet. Mikor a GIMP fejlesztése elindult, még nem volt normális C++ fordító Linuxon. Ráadásul még normális widget-készlet sem volt. Miért röhelyes szerinted, hogy OO elvek szerint csinálták meg? GUI-t szörnyen nehéz nem objektum orientált elvek alapján programozni, ha nem hiszed, próbáld ki.
Amúgy még ma is adódhat olyan helyzet, hogy nem tudsz OO nyelvet használni egy probléma megoldására. Ilyenkor is kifizetődhet OO elvek követése a gányolás helyett.

"C-ben programozni objektumorientáltan egyszerűen röhejes."

nana. még a linux kernel is használ OO-t, C-ben ugye, pl. a vfs.

"Többszörös öröklődés, interface-ek, absztrakt metódusok, virtuális függvények?"

A java sem támogat többszörös öröklődést, mégis ezzel oktatnak OO-t.

Mondjuk nem kifejezetten az interface-ktől, absztrakt metódusoktól és a többszörös öröklődéstől OO az OO.
Virtuális függvényeket pedig miért ne lenne C-ben egyszerű megoldani? Függvényre mutató pointerekkel a struct-ban.

Az igaz, hogy a feladathoz kell választani a nyelvet, de van amikor a nyelv adott. És az OO nem kötődik annyira a nyelvhez és az implementációhoz, sokkal inkább a program megtervezéséhez.

Nem mondtam, hogy egyszerűbb, sőt nem az.
Csak arra probáltam meg felhívni a figyelmet, hogy a nagy OO mániások elsiklanak gyakran dolgok mellett, de legalább szép a kódjuk :)

Egyébként C++ -nak (És testvéreinek) a kivetelkezelése az ami tetszik. Ami nem is OO dolog. Milyen szar már, 10 függvény hívás van egymásba ágyazva, és te legfelsővel akarod kiiratni a hibát, akkor mind a 10 függvényben ellenőrizd a vissza térési értéket a hívott függvénynek és a szerint térjen vissza hibával tied, elég rossz.
------
gentóhuszár

( hrgy84 | 2007. 01. 14., v – 14:50 )

az új 6-os JRE/JDK már tud GTKLookAndFeel-t...

hat nem tudom, sokan odszkodnak a javas programok hasznalatatol, enis csak vegso esetben hasznalok olyat. mercury pl a legjobb MSN kliens linuxra, de gány az UI a swing miatt, ha valasztom a GTK look 'n feel-t akkor a gtk temak nagy reszet nem tudja atvenni, szal nem az igazni.

::powered by Archlinux

( meditor | 2007. 01. 14., v – 15:09 )

Más-más célú grafikus programokhoz más-más grfikus könyvtár
és más-más nyelv kell. Azaz nagyon pontosan kell
tudni, hogy mit akarsz és utána ahhoz meg kell keresni a
LEGALKALMASABB környezetet. Szerintem.

> Sol omnibus lucet.

Csak nem mindegy milyen úton indul el. Én kb 3/4 évet
kísérleteztem, amig megtaláltam a nekem megfelelő X+motif+C
kombinációt! Rengeteg eszközt kipróbáltam, közben persze
rengeteget tanultam. Ha nincs konkrét célja, akkor nagyon
fontos lenne ugyanazt a feladatot több kombinációban
megoldania. Szerintem...

> Sol omnibus lucet.

( BikMak | 2007. 01. 14., v – 15:25 )

Ha Gui-s dolgokat akarsz programozni, mindenképpen objektum orientált nyelv javallott, mert jobban illeszthetőek a Gui-s problémákhoz.

Java: Én szeretem. A Swinget én se szeretem, de létezik az swt, ami lényegében a gtk+ feature-jeit tudja.

python: egyszerű megtanulni, és a gtk+ programozása egyszerű vele. Gondolom Qt -is adott...

A többit nem próbáltam, ezért nem is kontárkodnék hozzájuk, de ezekkel biztos roppant egyszerű ( hatékony :) )
Egyébként még javasolni szokták még a c# + gtk+, és a c++ + Qt kombókat, a fejlesztőkörnyezetek ( Monodevelop, KDevelop ) miatt.

A linux adottságai miatt mondjuk szinte minden nyelven tudsz minden toolkittel programozni. Van pl Gtk+ pascalhoz :).

------------------------------------------------------
Ha élne, ma ünnepelné halálának huszadik évfordulóját.

A három legfőbb os-en igen.
Linux/Unix, OSX, Windows(NT*)

A Mercurisokat kérdezd :) (én arra voksolok, hogy azért, mert nem a jre része)

------------------------------------------------------
Ha élne, ma ünnepelné halálának huszadik évfordulóját.

( tr3w v | 2007. 01. 14., v – 15:26 )

Haladjunk sorban:
GTK - C
Qt - C++

Tehát ha a C++-t nem ismered, és nem is akarod megtanulni, akkor a Qt kiesik.

Én mindenképp ajánlanám egy Objektum Orientált programozási nyelv megtanulását, már csak azért is, mert GUI már eleve ilyen gondolkozást igényel. (A GTK-t is szokták objektum orientáltnak csúfolni, de csak szemléletében ilyen.)

Elterjedt OO nyelv, ami natív kódot produkál csak egy van: a C++.
De marha nehéz egy kezdőnek. Ez tény.
Megtanulása sok-sok időt és káromkodást igényel.
És akkor még hol van a GUI...

Én a helyedben vagy szoktatnám a C++ gondolatához magam, vagy feladnám a natív kódra vágyást, és megtanulnám a Java-t vagy a C#-ot.
Python (én is szeretem), Perl eléggé periféria.

(C# elég jó nyelv, én csak win alatt használtam (WindowForms), de a GTK# is biztos jó.)

Ha véletlen C++, akkor a bőség zavara lép fel:

wxWidgets
Régi-régi cross-platform lib, bár kissé fapados mai szemmel. Előnye, hogy (alap esetben) nativ, azaz fordíthatunk vele GTk-ra, Qt-re, Winre, és a progi tökéletesen beleillik a környezetbe, használja a theme-t, stb.

Qt
Modern lib (főleg a 4). Mindent tud mi szem szájnak ingere.
Hátránya, hogy qt, azaz win alatt nem lesz XP theme (bár lehet, hogy van rá megoldás), és a Gnome-osok sem fognak szeretni.

GTKmm (G*mm)
GTK, Glib, stb feletti C++-os lib.
Használható, de nem jó. Qt sokkal átgondoltabb.
Elvileg cross platform, gyakorlatilag win alatt nem tudtam static-nak fordítani, a dll-ek meg önmagukban vagy 60 Mb-t foglalnak. Nem túl előnyös egy 100 k-s programhoz :).
Illetve volt egy kis gixer a fájlnév kezeléssel, a @-ot tartalmazó könyvtárakat nem szerette.

Ezeket használtam már.
Ultimate++-ról sok jót hallok, cross platform, hátránya, hogy felülete nem natív.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ultimate++-ról sok jót hallok, cross platform, hátránya, hogy felülete nem natív.
A helyzet, hogy ez a "hátrány" részben mostanában szűnik meg. Windows-on már régóta natív theming engine-eket használ, Linuxon néhány hete pedig már GTK theming engine rajzolja a felületet. Persze lehet használni az eddigi beépített felületrajzolót is egy flag átbillentésével. Ez egyébként leginkább WinXP alapértelmezett felületére hasonlít.
Ultimate++ nagy előnye a többi cuccal szemben, hogy a licence BSD.
Programozási (C++) szempontból pedig a library egy álom a többi ismertebb dologgal összehasonlítva.
Nekem pl. tetszik, hogy new operátort és malloc-ot soha nem kell használni az átgondolt tervezés miatt, így sem delete, sem free(), sem garbage collector nem kell.

Hmm, ezt jó tudni, lehet, hogy ránézek megint...

A new-tól meg nem kell félni, nem bánt. :)
Normális GUI libben meg a delete-et sem használja az ember, mivel (majdnem) minden widgetnek van egy szülője, ami kilépéskor gondoskodik a gyermekek felszabadításáról.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Nem arról van szó, hogy félni kell a new-tól, hanem arról, hogy egészen más olyan szemlélettel dolgozni, hogy pl. egy ablak osztály normál member-e az összes rajta található vezérlő. Nem mutatók, amiknek a konstruktorban adsz értéket (new) és nem is olyan lebegő valamik, amiket név szerint kell megkerestetni a GUI-kezelővel.

A felülettervező egy C++ template-osztályt hoz létre, amivel bármiből (ablak, "panel") tudsz egy konkrét vezérlőt létrehozni. Így leírva bonyolultan hangzik, de a példák alapján nagyon egyszerű megérteni.
A lényeg, hogy minden tartozik valahova. A C++ egyszerű alap memőriakezelését kell használni, nincs szükség semmilyen mágiára. És az eredmény: minden felesleges sallangtól mentes forráskód.

Régebben dolgoztam én is eleget ilyen (azóta már ósdivá vált) dolgokkal, mint VCL, WXWidgets, GTK+, Gtkmm. Ha elkezded Ultimate++-t használni, szerintem rájösz, miért elavultak ezek.

Amúgy mióta Ultimate++-szal dolgozom, kezd az az érzésem lenni, hogy a mostanában annyi helyen (Java, .NET) erőltetett garbage collector, nem más, mint egy béna workaround egy csomó fajta tervezési hibára. Valójában semmi szükség nincs rá.

Egyébként biztos, hogy OOP elveket én inkább Ultimate++-on keresztül oktatnék, mint Javán, mert a Javával szemben Ultimate++ helyes OOP tervezésre is szoktat, azon túl, hogy lényegesen egyszerűbb dolgozni vele, mint Javával.

Jah, ha már tervezés:
Smartwinről is hallottam ódákat zengeni ezzel kapcsolatban. Igaz, ez csak wines, és nem is lesz más...

Egyébként nem kell meggyőznöd az Ultimate jóságáról.
Csak azt akartam mondani, hogy nem olyan nehéz memory leak mentes programot írni, főleg, ha megfelelően ismerjük a libeket amiket használunk. (Feltéve, hogy a lib leak mentes :) )

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Pythonnak saját bytekódja van, futtatáskor fordít, majd futtat.
A CPython nem JIT-es. (CPython az eredeti C-s implementáció.)
Psyco nem egészen JIT, de az eredmény szempontjából mindegy. Elég gyors, de még mindig marha lassú a natív kódhoz képest.

IronPython viszont CLI-re fordít, mono futtatja, elvileg gyors kell legyen.

Meg van vmi Java bytecode-ra fordító cucc is.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ez tök jó, de mi van, ha a szerencsétlen user témát váltott?
Na itt bukik minden nem natív GUI lib.

Ebből a szempontból kb csak a wxWidgets a megoldás jelen pillanatban...

(Meg a Java SWT).

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( apal v | 2007. 01. 14., v – 15:34 )

Javallom a GTK + C kombinaciot. A GTK felepitese elegge egyszeru, konnyen meg lehet tanulni.

Egy hatranya van, hogy egy egyszerubb valamit is tobb utasitasbol kell osszepakolni (pl. ha csinalsz egy input-mezo"t, ami egy ege'sz sza'mot ke'r be, akkor az 5-6 gtk-hivas (letrehozas + inicializalas + elhelyeze's + visszajelze's definialasa + la'thato'va' te'tel), ezenfelul 1-2 sajat callback megirasa (ami szinten kb. 3-4 soros). Mondjuk a callback fv-t utana az osszes tobbi input-mezo"nel fel tudod hasznalni egyazegyben. De ami a hatrany az elony is lehet, ha komplexebb dolgokat csinalsz (pl. van ke't input-mezo"d, ege'sz sza'mokat ke'rnek be es azt szeretne'd, hogy legyen egy ke't mezo"ben levo" sza'm mondjuk osszege legyen kisebb mint mondjuk 100, akkor a fenti tucatnyi sort +1 sorral kell kiegeszitened, es jo lesz).

Ezenfelul viszonylag jol dokumentalt, sok peldaval, egy teljesen sablonos felepitessel rendelkezik. Raadasul a gtk1.2 es a gtk2 ugyanaz az api (csak mas lib-eket linkelsz be vele, persze a gtk2 tobbet tud).

A gtk1.2-nek, noha fapadosnak meg elavultnak tunik, van egy marha nagy elonye a gtk2-vel es a QT-val szemben is: nativ X-en keresztul, lassabb halozaton (pl. 512k adsl) is teljesen hasznalhato' marad. Ta'voli fejleszte'sne'l ez kulonosen hasznos...:]

A.

Nekem viszonylag bonyolultabb, 1.2-re fejlesztett programot sikerult szoszerint leforditani 2.0-s ala' is, csak az -I/usr/include/...-t es a -lgtk-t kellett lecserelni a gtk2-es megfelelo"ire. Vilagos, a gtk2-es az joval tobbet tud (forditva tehat nem megy, mert elegge valoszinu, hogy beleteszel valamit, ami csak gtk2 alatt van). Csak arra akartam celozni ha valami miatt valaki a gtk1.2-est tanulja meg eloszor/arra fejlesz barmi ok miatt is (mert az gyorsabb / atlathatobb / jobb peldakat talal hozza / stb.), akkor azzal nem veszit semmit, ha elobbutobb gtk2-esre a'llna a't.

A.

( totya | 2007. 01. 14., v – 15:43 )

Én a Qt és C++ párost ajánlom. A C++ érdemes egyébként is megtanulni. A kezdet nem egyszerű, de aztán nagyon fogod élvezni. A Qt4 meg egyszerűen zseniális.

( turul16 v | 2007. 01. 14., v – 16:30 )

MonoDevelop + GTKSharp + C# kényelmes.

De gvim + Glade + C se kutya.

http://glade.gnome.org/screenshots.html -el egyszerűbb, több féle képpen is, lehet vele guit -hegeszteni.

Tud C/C++ kódot generálni a glade-2.
Vagy egy program által bolvasható , xml filet (.glade), ami megkönyíti az ember fiának a dolgát.

Ha az anjuta nevű IDE-t használod, válaszd a libglade 2.0 Project tipust.
Az egyből készít egy műkködő példát. Ilyenkor glade-2 GUI build funkcióját ne használd, csak .glade filet mentsd.
------
gentóhuszár

Öszintén?

MonoDevelop még gyerek.
mono nem tul gyors. (C-hez viszonyítva; nagy terhelésnek kitett szerver progit, nem írnék hozzá,vagy video codec-et,de főleg GUI-t használó, keveset számoló alkalmazásokat, leginkább ebben írnám most)
MonoDoc még hiányos. (De más is használja, ugyan ezeket az osztályokat, úgyhogy van doksi a neten)

Ezek ellenére nagy jövőt jósolok neki, fejlődik és érdemes kipróbálni.

Én írtam, vele GTK -t meg XML - hálózatot használó progit, elég kényelmes volt a bepített gui szerkesztő, TreeView inicilizálásához, kell némi kódot behegeszteni, (Oszlopok tipusa,Neve ..etc)

C#, mint nyelv nem rossz.
Hiányzott vim szerű szerkesztés nekem :)

------
gentóhuszár

Örülök, hogy felhoztad. Igen az MSDN sok esetben használható, de azért rengeteg gond van vele. Sajnos nem tudom pontosan idézni, de volt olyan, hogy kerestem egy osztályt és amit találtam az nem leírás volt, hanem inkább marketing szöveg :)
A kedvencem e mellé, hogy beállítod, hogy csak a c# nyelvre specifikus dolgokat mutassa, na ez 10-ből 8-szor megy a maradék 2 esetben jön a vb.net vagy managed c++.
Mono-hoz tapasztalataim szerint konzol téren (using System.Console;) teljesen ugyanúgy lehet az objektumokat használni, de biztos, hogy van olyan dolog amit nem ugyanúgy valósítottak meg.

( _Franko_ v | 2007. 01. 14., v – 16:29 )

Ha GUI kell, és nem csak Linux, akkor Java-t ajánlok... reklámszagú de ajánlom a http://www.javaforum.hu alatt a cikkeknél a Java Suli-t, ami GUI készítésröl szól.

( f0xhu v | 2007. 01. 14., v – 16:57 )

Ha qt, akkor qt... abbol is a 4-es verzio, mivel a 3.x sorozat EOL-ja 2007. julius 1., így nyilvan a 4es meno mostanaban, van hozza nehany nyelvi binding,

- Qt/Jambi->java (Trolltech altal fejlesztett cucc)
- pyQt->python
- Qt# - mono
- Qt ruby,

de ha C++-t tanulsz akkor azzal a legegyszerubb nyilvan.

Dokumentacioja IMHO az egyik legjobb, van csomo jo tutorial, segitokesz levlista, C++ GUI programming with Qt 4 konyv (bar, ha megvan a 3-as ahhoz kepest a 4 nem sok ujat ir, plane, hogy csomo ujdonsag kerult a 4.2-be, ami persze a konyv utan joval jelent meg..) + hasznos eszkozok.

Ami talan hianyzik az egy jo keresztplatformos IDE hozza, bar mintha olvastam volna valami eclipse plugin probalkozasrol...

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( zoli78 | 2007. 01. 14., v – 18:55 )

Ha nem tudod, hogy mi a különbség a C, C++ és a Java között, akkor azt ajánlom, hogy ne ess neki egyből GUI-t programozni, hanem vagy tanulj meg programozni, vagy csak a kezelőfelület megtervezéssel foglalkozz és állj össze valakivel, aki tud programozni.
QBaseic + dos asm nagy gyenge háttér ahhoz, hogy minőségi C++-os GUI-kat csinálj!

Akkor:
- Bjourne Stroustrup: A C++ programozási nyelv
- szoftvertechnológia és UML könyvek
- gyakorlati C++ és Unix/BSD/Linux programozási könyvek
- GCC és binutils leírások
- Ha szimpi a KDE, akkor: QT docs, tutorials, KDE docs, tutorials, QT Designer, KDevelop
- Ezek sem ártalmas dolgok: Doxygen, Subversion, Trac, ...
- meg ezek sem: GDB, DDD, electric fence, ...

Ezek megismerése és rutinszerű használata önerőből legalább egy év.

És -mivel sok nyitott kérdésed lesz, ha olvasod a könyveket-, sok-sok próba program írása és elemzése nagyon hasznos lesz. Én is ilyen kis próba programokkal vizsgálgattam olyan dolgokat, amelyek a könyvekből kimaradtak.
--
unix -- több, mint kód. filozófia.
Life is feudal

( n0gabor | 2007. 01. 14., v – 21:13 )

akkor összefoglalva:

1)sok hozzaszolast irtatok, igazabol semmivel sem lettem okosabb hogy akkor most kezdokent mit tanuljak eloszor, C, C++, C#, Python?

annyit vágtam le hogy GUI-s dolgokhoz inkabb Oo nyelvet, tehat Python vagy C#/C++, illetve sokak szerint Oo szemlelet elsajatitasaban megakadalyozhat ha vki elotte nagyon elmerult es legyokerezett C-ben.

ahogy latom GUI teren mindegyikbol van valasztek.
-Pythonhoz tudom hogy van pygtk, pyqt, stb
-Qt (ami nekem a kedvencem mint felhasznalo) ugye C++-t igenyel, es sokan eleg profinak es kiforrottnak, jol dokumentaltnak, es crossplatformnak tartjak, emellett van mellé jo IDE
-C-hez is felsoroltatok egy tonnányi

Amit tuti elkezdek tanulni a Python, mert nagyon sokan szeretik, GUI frontendekhez eleg alkalmas scripteleshez. Mellette kéne valami de nem tudtam donteni a sok kulonfele hozzaszolas alapjan

2) Kene valami jo konyv, plz ajaljatok Pytonhoz, C és társaihoz
(lehetoleg libriben hogy ellojem az ajandekutalvanyomat:D )
::powered by Archlinux

http://learnpython.openproject.hu/
Az itt található könyv magyar fordítása nagyon jó. Itt ragadnám meg az alkalmat hogy reklámozzam és köszönetet mondjak a fordítónak: Daróczy Péter
Sokat tanultam ebből a könyvből.
A könyv címe: Gérard Swinnen : Tanuljunk meg programozni Python nyelven

"Gérard Swinnen könyve pedagógiailag átgondolt, rendkívül logikus bevezetés a Python programozási nyelvbe. Viszonylag kis terjedelme ellenére számos alkalmazási területre ad rálátást a példaprogramok és alapos elemzésük segítségével. A könyv szerves részét képezik a példák, illetve a külön is letölthető működő példaprogramok."

( bocs | 2007. 01. 14., v – 21:32 )

Javaslat: komoly és/vagy pénzes projektre Qt4.

Qt4 előnyök:
- valódi multiplatformos. Ez kimondva egyszerűen hangzik, de a gui készletek 99%-a itt vérzik el. Amikor egy cégnél hosszú távra befektetnek, ez komoly szempont lehet. És persze Neked is jó, mert egy környezetet megtanulva 2 platformon leszel profi.
- nagy teljesítményű. Ha például telecomm/képfeldolgozás/HPC/custom szerver területen (vagyis a profi ligában) akarsz labdába rúgni, akkor python és társai, interpreteres dolgok felejtősek!
- full source-ot kapsz, bele tudsz turkálni ott ahol kell.
- eléggé fejlett a 4-es verzió, tehát sok minden megtalálható benne (jó GUI, networking, OpenGL, thread-ek stb)
- fejlődik, rendszeresen jönnek ki új dolgok, jó az irány, a trolltech a bevételeit úgy látszik normális, értelmes tervezők megfizetésére fordítja, ezért úgy tűnik, hogy van jövője

Qt4 hátrányok:
- hordozza magán a régi örökséget: a c++ lehetőségeinek csak töredékét meri kihasználni, ezért csúnya trükközésekre kényszerül (külső preprocesszáló tool-ok kellenek a használatához)
- az event kezelése kissé túlbonyolútott, vagy 15 egymásba skatulyázott függvényhívások keresztül jut el oda az esemény ahova kell. Ez teljesítményben nem nagy gond, de azért nem elegáns. CSerébe viszont az eventek küldözgetése forrás kód szinten egyszerű, és elég rugalmas.
- kemény pénzbe kerül. (Ezért viszont kapsz kvázi garantált továbbfejlődést)

Nem olyan komoly vagy óccsó projektre? nem igazán tudom.

Nagyon jól összefoglaltad mit nem szeretek a Qt-ben. :)

Én azt vártam a 4-től, hogy kidobják ezt a sok régi vackot (külső toolok, macro trükközések, stb.), de nem tették meg. Gondolom a minél nagyobb kompatibilitás miatt.

Nincs mit tenniük, csak úgy mint a többi régi Lib (wxWidgets, stb) már akkor kezdtek fejlődni, mikor még C++ szabvány se volt, nemhogy szabványkövető fordító.

Nagy előny az újaknak, hogy használhatnak minden feature-t (ld Ultimate++).

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( n0gabor | 2007. 01. 14., v – 22:57 )

Tehát akkor milyen könyvet vegyek linuxos python, C, C++ v. C# programozáshoz?:)

::powered by Archlinux

( n0gabor | 2007. 01. 15., h – 01:03 )

talaltam par konyvet online libriben:

LINUX PROGRAMOZÁS (BÁNYÁSZ GÁBOR - LEVENDOVSZKY TIHAMÉR)

PROGRAMOZÁS C NYELVEN (Pere László)
UNIX - GNU/LINUX

A C++ PROGRAMOZÁSI NYELV I-II.
STROUSTRUP, BJARNE
ez vmi nagyon durva 1800 oldal, ára is elég borsos.

OBJEKTUM-ORIENTÁLT C++
BENKŐ TIBORNÉ - POPPE ANDRÁS

C++ ZSEBKÖNYV
DEPASQUALE, PETER J.

PROGRAMOZZUNK C++ NYELVEN
AZ ANSI C++ TANKÖNYVE (CD MELLÉKLETTEL)
TÓTH BERTALAN

melyiket erdemes?

::powered by Archlinux

Meg annyit a Python mellett, hogy az is bytecode-ot forgat es az fut az interpreterben, a java/jvm -hez hasonlatosan.
Valamint a python forrasokbol is van lehetoseg eloallitani bytecode-ot bar pont a GUI-s resznel (TKinter) vannak problemak a Freeze-vel. A forditasrol info: http://www.python.org/doc/faq/programming.html#how-can-i-create-a-stand…

Freeze: http://wiki.python.org/moin/Freeze

Egy masik project a freeze-re epul de egyszerubben hasznalhato kezdoknek / haladoknak is;) / : http://www.python.net/crew/atuining/cx_Freeze/

bzg

C++-hoz a STROUSTRUP könyv a Biblia. Egyrészt, mert a szerző a C++ egyik tervezője, másrészt mert (majdnem) minden benne van amit a nyelvről és az STL-ről tudni érdemes.

De:
"Felhasználói szint: közép-haladó/profi
Könyvtípus: Kézikönyv/referencia"

Tehát kötelező, de ha nem írtál sosem OO programot, akkor talán ne ezzel kezd.

"OBJEKTUM-ORIENTÁLT C++
BENKŐ TIBORNÉ - POPPE ANDRÁS"
Olyan kis egyszerű, olvasmányos (én ezzel kezdtem), de végtlenül elavult. Kerülendő.

"PROGRAMOZZUNK C++ NYELVEN
AZ ANSI C++ TANKÖNYVE (CD MELLÉKLETTEL)
TÓTH BERTALAN"
Sosem láttam, de a tartalomjegyzék alapján nem tűnik rossznak.
Ha nem erős az angolod, akkor jó választás.
Ha jó az angolod, akkor talán olcsóbb egy jó netes tutorial és a Stroustrup könyv (, ami kötelező).

Ja, és említettem, hogy a Stroustrup könyv kötelező?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

LINUX PROGRAMOZÁS (BÁNYÁSZ GÁBOR) - csak ajánlani tudom, rengeteget lehet belőle tanulni. Sajnos 2003 óta nem készült új kiadás, így néhány helyen elavult, de man pagekkel kombinálva verhetetlen.
PROGRAMOZÁS C NYELVEN (PERE LÁSZLÓ) - őt vettem meg először... Nem rossz könyv, de az előző bőven kiváltja.

( sibidiba | 2007. 01. 15., h – 01:54 )

A Qt nekem nagyon nem jött be, a multiplatform ellenére szvsz. a többlépéses fordítás teljesen felesleges, és csak falramászok attól, hogy elrejti előlem a C++-t.

A dokumentációja persze csillagos hatos.

( pete | 2007. 01. 15., h – 11:05 )

erdemes megnezned fltk es wxWidgets-et. Mindketto lightweight, legalabbis konnyebb a QT-nal, afaik gpl-esek. Az fltk az amolyan "freedom-project"-nek tunik, a wxnek tobb eves (evtizedes) multja van. ha az fltk-t vagod, jo esellyel tudsz dolgozni pl. a dillo-n (most abandonalja a ket fofejleszto a projektet)...

a wxWidgets-et sok advancedebb programozo szidja (nemtom miert), az fltk meg nem annyira tetszik megmondom oszinten.

(Dillo meg egyaltalan nem erdekel, nem szeretem az ilyen "lightweight" program filozofiat linuxon hogy a program kiforratlansagat meg anti felhasznalobaratsagat probaljak pozitiv ervkent beallitani. nem azert van A64-em hogy MWM meg xterm fusson a gepen 256 szinben. Dolgozzon csak alám, legyen nekem kényelmes, és legyen opera vagy firefox:) )

::powered by Archlinux

( black (nem ellenőrzött) | 2007. 01. 15., h – 21:16 )

Hali !

Azt írtad, hogy most tanulsz programozni. Ebben az esetben nem látom egészen megalapozottnak, hogy "kapásból" elveted a java/swing használatát. Én évek óta használom, szerintem az egyik legjobban kidolgozott, átdondolt, jól dokumetált technológia. Elosztott alkalmazások kliens oldali felületére ideális (pl. teljes körű, egyszerűen használható CORBA). A java web start pedig az egyik legtutibb dolog, amit valaha láttam (alkalmazás futtatása telepítés nélkül. Melyik másik techológia tudja ezt?).

Mindezek mellett nem kell vesződnöd a memóriakezeléssel, fejállományokkal, linkeléssel. Én a mostani munkahelyemen c++-ban programozok szerver oldalon, és leglább kétszer olyan hosszú a fejlesztési idő, mint javaban. Persze, ha mazohista vagy, akkor szerintem GTK+. Motifot nem ajánlom, abba bele lehet rokkanni... (persze nagyon gyors).

Ja, és kezdésnek szerintem Emacs, vagy Vim kezrlését is meg kellene tanulni. GUI feljesztőt csak akkor használj, ha már penge vagy a kódolásban (akkor meg már azért nem fogsz :)))

nem azt mondtam hogy szar, hanem hogy nem tetszik az hogy nem nagyon integralodik bele az adott kornyezet widgeteibe, (1.6 os javaval javult a helyzet GTK tema egesz jo, fontok is antialiased-ek lettek). persze lehet hogy eddig en hasznaltam eddig fostalicska javas programokat. azureus pl kivetel, de ha jol tudom az nem is swing.

kerdes: akkor micsoda?:)

::powered by Archlinux

az már tetszik:)

ahogy olvastam csak ez meg az wxwidgets az igazi nativ GUI (bar ugye linuxnal nincs ilyen, es hol vagyok meg attol hogy crossplatform meg minden)

kurvajo mert megvan a kedv (meg a konyv) a C++hoz is, python-hoz is JAVA hoz is, de sztem egyszerre az egyik is boven sok lenne...majd agyalok meg rajta hogy melyik legyen.

::powered by Archlinux

Natív GUI alatt azt értem, hogy a lib nem maga rajzolja ki a különböző elemeket (gombok, stb.), hanem az adott rendszerben található toolkitet használja.

Azaz pl wxWidgetsnél GTK-t Qt-t vagy MFC-t.
Megvan az a hátránya, hogy a lib fejlesztőinek többször kell dolgozni, és több kódot kell karbantartani, szemben azzal a megoldással, hogy csak egy alap rajzeszköztárat implementálnak platformfüggően, és utána a rajzolás maga platformfüggetlen.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

OFF

Mindezek mellett nem kell vesződnöd a memóriakezeléssel, ...

Bocsánat, ezzel vitatkoznék. Java-ban elvileg nincs is mód vesződni a memóriakezeléssel, mert a primitív típusokon kívül minden referencia. Azonban ebből, meg abból, hogy a garbage collector csak viszonylag ritkán fut, lehetnek szopások. Egyik szopás rögtön az új objektum létrehozása, mert az lassú. Aztán emiatt a sok objektumot létrehozó (rosszul megírt) algoritmusok eleve lassan futnak. Illetve a legnagyobb szopás, hogy rosszul megírt algoritmus (esetleg több szálon több ilyen együtt) képes elfogyasztani a rendelkezésre álló RAM-ot, ha gyorsabban hoz létre új objektumokat, mint ahogy a régieket a garbage collector kivághatná. Magyarul Java-ban a "new"-t csak ritkán szabad használni, és sűrűn lefutó rutinokban igyekezni kell a régi objektumokat újra hasznosítani. (Ami megint szopás, mert statikus objektumokkal nem lehet "thread-safe" módon programozni.)

Mondjuk GUI-ban tényleg nem kell vesződnöd a memóriakezeléssel, mert ott minden "ritkán" történik.

( develru | 2007. 01. 20., szo – 21:50 )

Na akkor egy két félreértést tiszáznék:

"A szemléletmód alapvetően arra épül, hogy a világ sok folyamata leírható egymástól függetlenül létező, jól elkülöníthető egységek (az objektumok) együttmőködéseként, melynek során ezen egységek egymásnak különböző szolgáltatásokat nyújtanak."

elvek:
-egységbezárás
-öröklődés
-polimorfizmus
-újrafelhsaználhatóság
-láthatóság
-perzisztencia

Ha valamelyik elv hiányzik, az nem 'igazán' objektum orientált. /Mi ezt így tanítjuk :)/ Kihangsúlyoznám, hogy az OO egy szemléletmód, attól, hogy valaki Javaban programozik mág nem boztos, hogy OO-tan.

Akinek nem tetszenek a Java alkalmazások linux alatt az nézzen meg pár képet itt:
-http://rityi.tvn.hu/Pic/1.jpg
-http://rityi.tvn.hu/Pic/2.jpg
-http://rityi.tvn.hu/Pic/3.jpg
-http://rityi.tvn.hu/Pic/4.jpg
-http://rityi.tvn.hu/Pic/5.jpg

Nem azt akarom ezzel mondani, hogy ez nagyon szépre sikerült, csak azt, hogy Javaval igenis lehet tetszetős alkalmazásokat készíteni. (Megj.: A karakterkódolásból fakadó hiba ki lett javítva, csak lusta vagyok újabb képeket csinálni.)

-----------------------------------------
A lehetetlen csak a lusta ember kifogása!

"elvek:
-egységbezárás
-öröklődés
-polimorfizmus
-újrafelhsaználhatóság
-láthatóság
-perzisztencia"

Erről van szó...

És ha lehet, senki ne jöjjön azzal, hogy mondent meg lehet írni asm-ben (C-ben) is jó?!

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Nem tudom mit értesz az alatt, hogy ocsmány? A 2. nekem se tetszik, de az főleg felhasználói kérésre lett így kialakítva. A 4-edikkel kapcsolatban leírhatnád, hogy hogyan csináltal volna meg, mert nem a legszebb az tény, de nincs is ötletem, hogy mit csinálhattunk volna másképp.
A 3. és az 5.-en ki lettek már javítva a betük, csak valamiért a Linux UTF kódolását nem vette be ...

ui.: az építő kritikákat szívesen fogadom!
-----------------------------------------
A lehetetlen csak a lusta ember kifogása!

Általános szabály, hogy a beviteli mezők bal oldala egy vonalban van a jobb áttekinthetőság kedvéért. Ezt egy GridLayout-tal simán el lehet érni, még küzdeni se kell különösképpen vele.
A OK-típusú gombokat jobboldalra szokás rakni, mert a legtöbben automatice ott keresik (dialógus-effektus).
Az adatbázisban való mozgást segítő gombok nem a legjobbak a navigáláshoz, mert idő, mire a végefelé lévő rekordot megtalálsz. olyan 20 rekord felett nem érdemes alkalmazni, inkább valamilyen listanézetet.

Egyelőre ennyi.

( gthomas | 2007. 01. 21., v – 06:48 )

Ha szép és egyszerű, de nagyszerű nyelvet akarsz, akkor Python.
Lehet hozzá GTK-t (pyGTK), Qt-t (PyQt), FLTK-t, wxWidgets-et (wxPython) párosítani mint GUI. Amúgy a wxWidgets-et is figyelmedbe ajánlom: Windows, Mac és Linux platformon is létezik, és mindenütt a NATÍV felületet adja (Windows alatt Windows, Linux alatt GTK)!
(Persze vannak, akik szerint a "legnagyobb közös osztó" miatt nem használható, de szvsz jól hordozható, és nem is olyan szűk az a "legnagyobb közös osztó").
GT

( onthefloor | 2007. 01. 26., p – 23:45 )

Huhh latom sok hozzaszolas van :) nem tudom hogy olvasod e meg, de ahogy olvasgattam sokan tanacsoltak neked a GTK t, en is a GTK tanacsalom inkabb,
ha meg nem programoztal gtk ban akkor inkabb php-gtk val kezdj , hogy megertsd
aztan majd kesobb http://glade.gnome.org/ Glade-t ha hasznalod megrajozlja neked a kodokat, es sok tutorial es examples is talalhato a gtk rol
http://www.linuxheadquarters.com/howto/programming/gtk_examples/index.s…
http://www.gtk.org/tutorial/
De lenyegeben te tudod mire van szukseged :)

( noss | 2007. 01. 27., szo – 15:30 )

ha kezdő vagy és gyorsan, nyűg nélkül szeretnél szép eredményeket elérni, akkor mindenképp a python-t ajánlom. rengeteg graf. felület létezik hozzá, platformfüggetlen, könnyen/gyorsan tanulható.

van hozzá ingyenesen letölthető könyv magyarul (!), ami végigvezet a programozás alapjain is:
Gérard Swinnen : Tanuljunk meg programozni Python nyelven
bővebb infó

ha ezt már kened vágod és mélyebbre szintre akarsz süllyedni a programozás rejtelmeiben, biztos alappal kezdhetsz neki a C-nek. ráadásul a későbbiekben összehangolhatod a python+C kódjaidat, így egyensúlyba kerül a python gyors fejlesztési sebessége a kritikus (erősen sebességigényes) területeken a C gyors futásával. a libri utalványból meg vehetsz egy izgalmas regényt ;)

ismerem a pythont egy ideje, és épp abban alkotok. A behúzása egy eget verő baromság. Ha a szóközt meg a tabot összecserélem => nem müxik. Ha épp úgy döntök, hogy a 100 soros kódomban lévő függvényeket berakom egy osztályba, akkor egyesével végig kell nyálazni a sorokat, hogy még mindig jó-e a behúzás. Miért nem lehetett kitalálni egy blokk szerkezetet... Könnyű hibázni benne.

segít a következetesség. :)

"Miért nem lehetett kitalálni egy blokk szerkezetet..."
a behúzás az pont maga a blokk szerkezet megtestesülése.
nem tudom, lehet-e külön karakter a blokkolásra, de egy py-hoz való editorral/ide-vel biztosan könnyebben menne. ha meg több egybefüggő sort 'alakítassz át', akkor a behúzást is lehet egyszerre növelni az érintett sorokon.

"Könnyű hibázni benne."
addig jó --főleg egy kezdő számára--, míg ezeket a könnyű hibákat könnyű javítani is. azér egy C-s hibát nem hinném, h könnyebben lehet javítani.

"""de egy py-hoz való editorral/ide-vel biztosan könnyebben menne. ha meg több egybefüggő sort 'alakítassz át', akkor a behúzást is lehet egyszerre növelni az érintett sorokon."""

No, igen, emacs tudja. Csak konzolban sosem tudom, hogy hogy csaljam elő a menüt, vagy épp hogy nézzem meg a billentyűkombókat (kellett nekem ssh-n keresztül szerkesztenem).

"""a behúzás az pont maga a blokk szerkezet megtestesülése."""

Hát ez az... Más nyelveken konvencióból van behúzás, de a fordító nem igényli, és még van begin/end jelölés is, esetleg kapcsoszárójellel - ez utóbbi sem az igazi, de már egész használható (legalább keveset kell gépelni :))

a 'behúzás ~ blokk szerkezet' konvencióját a python egész egyszerűen ráderölteti :)
cserébe kapsz ajándékokat (átláthatóbb, olvashatóbb kód, kevesebb gépelés), de ha ez neked nem fekszik, akkor
(ahelyett h elküldenélek melegebb éghajlatot kedvelő programnyelvek felé)
ajánlok egy kisegítő/kompromisszumos megoldást:
írj egy egyszerűbb előértelmezőt/konvertert, ami a { } blokkjaidat átalakítja behúzásos blokkokra!

Nyilván _direkt_ így találták ki a blokk szerkezetet.
Valójában begin-end, vagy {-}-es nyelvre fordítóprogramot még könnyebb is írni.

"függvényeket berakom egy osztályba, akkor egyesével végig kell nyálazni a sorokat"
Ez egyrészt csak egy gomb egy normális szerkesztőben, másrészt meg én akkor is megteszem, a C-ben, C++-ban fejlesztek (nem normális szerkesztőben).
Jó dolog a lustaság, csak ha 2 nap mulva ránézel az osztályodra, nem fogod tudni hol az eleje, meg a vége.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( n0gabor | 2007. 01. 27., szo – 16:14 )

koszi a hozzaszolasokat, elkezdtem pythont, Gérard Swinnen könyv 1/3-ánál járok, tenyleg konnyen, gyorsan tanulhato.

bar kicsit gaz pdf-be bujni a konyveket, foleg a referenciakat, kene vmi konyv hozza papir formatumban

::powered by Archlinux