Qt-s fejlesztés

Fejlesztés

A játékfejlesztés mellett mostanában egyre jobban érdekel a Qt. Éppen azon töröm a fejem, hogy milyen multiplatform alkalmazás fejlesztésbe kellene kezdeni, ami hiánypótló lehetne (Linux, MacOSX és Windows).
Kereskedelmi szoftverre gondolok... CAD, könyvelés, stb.?
Várom az ötleteiteket!

  • 5116 megtekintés

( Yorirou | 2009. 06. 15., h – 21:40 )

Ha alacsony prioritású a projekt, akkor egy kis zsebpénzért a nyáron szívesen beszállnék :) (hétvégi, álmatlan nyári éjszakákra gondolok, mert főmunkaidőben van állásom)

Nincs túlzottan sok Qt-s tapasztalatom, de nagyon gyorsan tanulok (eddig közelebbről az alapok mellett a QtWebKit-et és a Phonon-t néztem meg).

( greenvirag v | 2009. 06. 15., h – 21:43 )

Szerintem egy sakkprogram. Legalabbis szemelyes igenyeim ezt diktaljak. Chattel, buddy listtel, beepitett MI-vel, megnyitas/kozepjatek/vegjatek oktatassal, stb..

Tudom, almok.. De ha valaki egyszer megis belevag, az szoljon, csatlakozok.

( andrasf | 2009. 06. 15., h – 21:47 )

zeneszerkesztő, amihez nem kell ilyenolyan latency-s kernel jack-kel amit sose bírok elindítani :P

ja, és hang is jönne belőle, tehát nem olyan lenne mint a rosegarden meg a muse. az lmms-nél legalább ezt az egyet sikerült elérnem...

Zenei szoftverek terén tényleg elkélne a bővülés.
Viszont van egy-két dolog, amiben nem értem a véleményedet:
a muse és rosegarden egy szekvenszer, nem a hangkeltés a dolga. De vannak plugin hangszerei 8mint ahogyan mondjuk egy Cubase-nek a vst, csak itt nem vst), melyek már tudnak hangot kelteni. Ilyen pldául a fluidsynth nevű sf2 sampler, egész barátian lehet vele dolgozni. De indíthatsz mellette például egy zynaddsubfx-et is, amit hozzárendelhetsz egy midi-porthoz, s máris szól a szinti.
Az lmms már egy más kategória, amolyan reason feeling, ott a cél, hogy egy munkaállomást kapsz, igaz, nem olyan nagy szabadsággal, mint ha magad "kötöd" össze az eszközeidet.

Igazából nekem nagy fájdalmam e tére, hogy az ardour-ban nincs midi támogatás (hiszen ez egy DAW), mert ha lenne, akkor igen komoly (szerintem Cubase szintű) eszköz válhatna belőle.

rosegarden-re gondolsz?

kb max fel ora az egeszet beallitani, es nem kell patchelt kernel, anelkul is megszolal.

ami kell meg neked:
qjckctl, qsynth, fluidsynth sf2 fonts (->package manager)
esetleg egy kis /etc/security/limits.conf audio tweak (->google)
es egy hangkartya, ami kb. mukodik alsa-val

Ha konkret kerdes van, ird meg. Amugy meg googlival egyutt tenyleg max 36 perc.

pl.:
http://buzypi.in/tag/qjackctl/
itt csak a kotogetesnel kell kicsit elmelazni, de sztem bele fogsz jonni :D

( zoner | 2009. 06. 15., h – 22:09 )

Egy normális számlázóprogram nagyon hiányzik linuxról. Ha sikerülne valakinek valami KulcsSzoft szintűt felmutatnia, nálunk az irodában minimum 2 gépről repülne a Windows. Számlázóprogram + Házipénztárért hajlandó vagyok évi 60 000Ft-ot fizetni.

Ha kell, beszállok a fejlesztésbe is, végigcsináltam már néhány Qt tutorialt.

Nekem úgy tűnik, hogy te egyenesen arra születtél, hogy számlázót készíts. A könyvelős háttérből jól készülj fel, az lesz a kulcsa a dolognak, a későbbiekben pedig a naprakészen tartás. A QT ideális lesz ahhoz, hogy windowsra is el tudd adni a cuccot (utána pedig eladhatod a támogatást arra is, hogy linuxosítsd a Szomszéd bt. gépeit). A kritikus pontnak csak a hobbi jellegű időráfordítás tűnik.
Nekem ez tipikusan olyan szoftvernek tűnik, ami nyílt forráskóddal terjeszthető, s a pénz a supportból jön (úgyhogy nem is kell túl testreszabható legyen.)
Ha nem lenne probléma, hogy magam is ritkásan érek rá, akkor szívesen csatlakoznék a fejlesztéshez én is néhány programsor, vagy akár csak kódellenőrzés erejéig, vagy akármi. Lesz munka vele bőven.

"A kritikus pontnak csak a hobbi jellegű időráfordítás tűnik."

A fejlesztés megkezdése esetén nem hobbi jellegű lenne a dolog, hanem céges.

Arra gondoltam, hogy minőségi célként valóban a Kulcs-Soft rendszerét kellene megcélozni (nem a Light verziók, hanem a Plusz), de az ő áraik alá tudnék menni és nem csak Windows, hanem MacOSX és Linux (esetleg később más Qt 4.5-tel rendelkező) platformot is támogatva.
Indulásként pl. a házipénztár kezelő (ki- és bevételi pénztárbizonylatok, stb.) jó ujjgyakorlat lenne.

Ilyen számlázó/könyvelő programoknál ott lehet a bibi, hogy megírni őket csak a feladat egyik (olcsóbb/könnyebb) fele, engedélyeztetni őket a másik...

(Nekem legalábbis úgy rémlik, hogy kell hozzá engedély, a számlázóhoz szinte biztosan...)

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

De ha el sem kezdjuk, akkor nem is kell engedelyeztetni...

Nezd, nem konnyu, persze. De jelenleg a Linuxos piacon akkora a hiany, mint ide Lachaza, szoval belevagni mindenkepp erdemes, aztan majd lehet a apeh-el meg tarsaival kardozni, ha legalabb valami van.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nyilván, de ha már olyan messziről indulunk, hogy videószerkesztő vagy számlázóprogram, akkor az esetleges engedélyeztetési hercehurca (annak minden költségével) erős érv lehet a project ellen (főleg, ha igazából nincs igazi szakmai háttér).

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

Mi nálad a megfelelő szakmai háttér? Úgy érzem - mindenféle nagyképűség vagy éppen álszerénység nélkül -, hogy a szoftverfejlesztői oldalon megvan a megfelelő tapasztalatom. 35 éves vagyok, több mint 15 éves szakmai múlttal. A kórházi laborautomata analizáló szoftverétől, a játékokon át szinte minden területen fejlesztettem már. Édesanyám könyvelő szintén 20+ év szakmai múlttal. Valóban ideálisabb lenne, ha nekem is lenne egy gazdasági informatikusi végzetségem, de nem hiszem, hogy a kettőnk közös munkájával nem lehet a tervezési szakaszban ezt helyettesíteni. Az implementálás során meg ez már nem akkora hátrány. De lehet, hogy nem egyezik a véleményünk...

Igen, kb arra gondoltam, hogy neked nincs gazdasági-könyvelői gyakorlatod, édesanyádnak meg programfejlesztői gyakorlata. Persze a dolog nem lehetetlen.

Ha én komolyan, profitorientáltan pénzt és céget mögé téve, programfejlesztésbe kezdenék, akkor legalább egy embert összeszednék valahonnan, aki mindkettőhöz ért valamennyit.

Egyébként meg nem tudom... Számlázóhoz bőven elég lehet ennyi tudás. Könyvelő progihoz talán nem. Vagy legalábbis több munka így...

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

Ezzel nem értek egyet.

Sok olyan területen gyűjtöttem már információt az adott terület szakértőjétől, amiről nekem fogalmam sem volt.
Elmondták, hogy minek hogyan kell működnie, elmondták az összefüggéseket, felhívták a figyelmemet esetleges szabályokra.
Lett belőle egy nem csak kockák által értelmezhető specifikáció, és amikor azt mondták, hogy igen, ez jó, akkor meg lett egy projekt, és a végén egy szoftver.

Egy cégben sokféle ember kell, és nem kell, hogy mindenki értsen mindenhez. Persze kellenek emberek, akik legalább megértik amit az egyik csoport mond, és amit a másik, mert ha a programozót eresztettem volna össze mondjuk a gáz brókerrel, vagy mondjuk a teherautó diszpécserrel, akkor tutira egyik nem értette volna, miről beszél a másik :-)

"Persze kellenek emberek, akik legalább megértik amit az egyik csoport mond, és amit a másik, mert ha a programozót eresztettem volna össze mondjuk a gáz brókerrel, vagy mondjuk a teherautó diszpécserrel, akkor tutira egyik nem értette volna, miről beszél a másik"

Pont erre gondoltam. Jó, lehet, hogy a "nincs igazi szakmai háttér" kifejezés erős volt, illetve félreérthető.

Csak hát mit tudunk:
- Adott mash akit nem ismerek, és aki félhobbi projectet keres (én így értettem). Elég sok minden felmerült, köztük a könyvelés is. Ebből nekem azért lejött, hogy a gazd. info. nem lehet a szakmája.

- Adott anyukája aki könyvelő. Itt lehet hogy én voltam rosszhiszemű, de kiindulva a saját nem informatikus ismerőseimből, azt gondolom, hogy közös nyelv hiányában már a fejlesztés első lépései is nehézségekbe ütköznek.

Te is azt mondod, hogy programozót nem eresztesz össze a megrendelővel. Nekem is egy ilyen köztes személy hiányzik.

Persze ez leküzdhető akadály, illetve tévedhetek is, lehet, hogy semmi gondjuk nem lesz egymás megértésével...

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

- Szerintem ez azért túlzás! A tímek azért vannak, hogy kiegészítsék egymást. Nem az ismeretek metszete, hanem az összege számít.
- Szerintem egyszerűbb lett volna beismerni, hogy túlsiklottál azon bejegyzésen, miszerint a mamája könyvelő. Most nem kellene ilyen sánta módon védeni a gyenge lábakon álló sebtiben kreált álláspontodat. Mint ahogy a számlázó program engedélyeztetéssel is hamis infókat hintesz, pedig elég lenne elolvasni az APEH honlapján, hogy milyen követelményeknek kell megfelelnie egy számlázó programnak. De azt sem ismered be, még az után is fenntartod magadnak, hogy mégsem úgy van.
Visszakozni tudni kell! Az ember téved, elnéz, melléfog. Ez azért nem olyan vészes. Ha kitart a bebizonyosodott tévedése mellet az sokkal kínosabb.
Mondom mindezt baráti szándékkel neked.
--
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

"Szerintem ez azért túlzás!"
Szerinted. Szerintem meg nem. Na akkor most mi van?
(Egyébként előző hozzászólásomban már árnyaltam a képet...)

"Szerintem egyszerűbb lett volna beismerni, hogy túlsiklottál azon bejegyzésen, miszerint a mamája könyvelő."
Egyszerűbb lett volna, csak nem így történt.

"számlázó program engedélyeztetéssel is hamis infókat hintesz"
Azt írtam, hogy "Nekem legalábbis úgy rémlik", ez szerintem elég érthetően kifejezi, hogy nem vagyok benne biztos. Többen megírtátok, hogy ez nem így van. Ok.
És? Most minden hozzászóláshoz oda kéne írnom, hogy "Oké, meggyőztetek"?

Sőt még azt is leírtam, hogy "Vagy keverem, vagy változott.", azaz elfogadtam, hogy nem úgy van ahogy emlékeztem.

Tudom, hogy meleg van, pezseg a vét, lehet flame-elni, de mi lenne, ha elolvasnátok amire reagáltok?

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

Na ott aztán jó hideg lenne :-)

São Pauloban vagyok. Itt nem szokott negatívba menni a hőmérséklet, mostanában jó hideg van, ami éjjelenként 4-5 fokot jelent.
Dél tájban, ha süt a nap, jó meleg van, kb. 16-18 fok, de így napnyugta után már bizony pulcsiban didereg az ember a lakásban.
Mert ugye trópus, tehát a házban nincs se fűtés, se szigetelés.

G

"Igen, kb arra gondoltam, hogy neked nincs gazdasági-könyvelői gyakorlatod, édesanyádnak meg programfejlesztői gyakorlata."

Hát, nem tudom. Az a helyzet, hogy az elég kivitelezhetetlen lenne, hogy az adott szoftvert fejlesztő emer(ek) mindig értsen(ek) a másik területhez is. Mondok egy konkrét példát. Sok-sok évvel ezelőtt kórházi laborautomaták kommunikációs protokollját és a beérkező adatok adminisztrációját és kezelését végző szoftver fejlesztésében vettem részt. Konkrétan a gép és a számítógép közötti adatkommunikáció megoldása volt a feladatom. Ha megfelelő végzettségű emberre vártak volna, akkor orvosnak, programozónak és a gép karbantartásához értő szervizesnek egyszerre kellett volna lennem. E helyett volt egy doktórnő, egy a gyártótól kihelyezett szakember és programozóként én. Remek összhangban dolgozott a csapat és megoldottuk a feladatot.
Azóta, ha a magyar kórházak 99%-ban adsz vért, akkor ez a szoftver tartja nyílván, hogy mi a helyzet a szervezetedben. :)

Nem megoldhatatlan dolgok ezek persze.

A te példádban is nyilván könnyebb dolgod lett volna, ha van ismereted a 3 terület mindegyikéből. Pl képzeld el, hogy kapsz egy hasonló feladatot most. Az akkor megszerzett ismereteiddel nyilván könnyebb dolgod lenne, mint akkor volt.

A példa egyébként nem egészen jó, mert két gép összekötésén dolgoztál. Most viszont egy olyan szoftvert kéne írnod, ami a felhasználó munkáját könnyíti meg. Egy olyan felhasználóét aki egészen másképp viszonyul a géphez mint te.

Ahhoz, hogy kényelmes, jól használható, a könyvelő számára logikus programot tervezhess, ismerned kell a könyvelés menetét, az ottani fogalmakat, a normális ügymenetet, a nem normális ügymenetet, stb. Ezen információk kinyerése egy felhasználóból nehéz (igazából ez is egy szakma).

Persze egy számlázó program lehet, hogy nem nagy cucc, (a könyvelő programot komolyabbnak érzem), illetve meg lehet próbálni egy piacon lévő, sokak által kedvelt program "lemásolását".

Ezek mind megoldható dolgok, hajrá. Én csak annyit mondtam, hogy ha erre céget akarnék építeni, nem elégednék meg két szakértővel.

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

"Nem megoldhatatlan dolgok ezek persze."

Semmi nem az. :)

"Pl képzeld el, hogy kapsz egy hasonló feladatot most. Az akkor megszerzett ismereteiddel nyilván könnyebb dolgod lenne, mint akkor volt."

Orvos és szervízes most sem vagyok. Ugyanúgy szükségem lenne a két másik ember munkájára, hiszen a vért ugyanúgy le kell venni, úgyanúgy be kell rakni a centrifugába, ugyanúgy fel kell paraméterezni az autómatát és aztán jöhetek csak én. Ezt hívják csapatmunkának. A "lone wolf-ok" kora lejárt. :)

"Ahhoz, hogy kényelmes, jól használható, a könyvelő számára logikus programot tervezhess, ismerned kell a könyvelés menetét, az ottani fogalmakat, a normális ügymenetet, a nem normális ügymenetet, stb. Ezen információk kinyerése egy felhasználóból nehéz (igazából ez is egy szakma)."

Ezzel megint vitatkoznék. Az első lépés, hogy megnézem, kipróbálom a konkurens termékeket, azok logikai felépítését. A második lépés, hogy ezt a logikai felépítést megbeszélem a könyvelővel, hogy nem néztem-e be valamit. Harmadik lépésben átgondoljuk közösen, hogy lehet-e valamit logikusabban felépíteni a konkurens termékekhez képest. Ötödik lépésben elkészül a design doksi, amiben a teljes program felépítését dokumentáljuk, hogy menet közben visszakereshető legyen bármi, ha valami nem világos, elfelejtődött. Hatodik lépés az implementálás. tovább nem folytatom, mert a többit már kitalálod...

"Persze egy számlázó program lehet, hogy nem nagy cucc, (a könyvelő programot komolyabbnak érzem)"

Ebben egyet értek veled.

"illetve meg lehet próbálni egy piacon lévő, sokak által kedvelt program "lemásolását"."

Mint feljebb leírtam, az alap dolog volt mindig is nálam, hogy megnézzem a konkurencia hogyan csinálja. Nagyon gyakran kihúzott a bajból, hogy nem találtam fel újra a spanyol viaszt. Ettől még ötletelni lehet, de csak ésszerű keretek között. Ha egy felhasználó megszokta, hogy mondjuk Windows-on a KulcsSoft Számla, vagy az EasyInvoice hogyan működnek, akkor miért nehezítsem meg azzal a dolgukat, hogy egy totálisan más paradigmát próbálok rájuk erőltetni. Még akkor is, ha esetleg árban jobb tudok lenni, ugyanazzal a feature listával.

"Ezek mind megoldható dolgok, hajrá. Én csak annyit mondtam, hogy ha erre céget akarnék építeni, nem elégednék meg két szakértővel."

Én sem. Viszont az induláshoz elég. Alapvetően én is a játékfejlesztéssel foglalkozom, azonban első körben összerakok én egy házipénztár és számlázó programot, ami fut mindhárom platformon. Majd ha erre van némi kereslet, akkor jöhet a csapatépítés és a könyviteli, bér és egyéb modulok elkészítése. Lehetőség szerint már "nélkülem".

Illetve komlett megoldásokban gondolkodom. Pl. mondjuk a weblapunkon rendelhető lenne olyan ASUS Eee Top (vagy más modern designnal rendelkező, olcsó, könyvelésre alkalmas gép), amire előtelepítve lenne a rendszerünk Windows vagy Linux környezetben. Illetve ugyanez Mac Minivel/MacBookkal/iMac-kel valamelyik hazai disztributorral szerződve.

"Persze egy számlázó program lehet, hogy nem nagy cucc, (a könyvelő programot komolyabbnak érzem)"

"Ebben egyet értek veled."

Meglepő módon a (kettős) könyvelés maga meglehetősen egyszerű, csak elég sok riport dukál hozzá. Ennél nagyságrendileg bonyolultabb (és főleg jogszabályilag változékonyabb!) a bér-tb-szja téma. Elég csak az őket meghatározó törvények számát és méreteiket összevetni.

Édesanyámnak is az volt a véleménye, hogy a bér modult hagyjuk a végére, mert elég bonyolult lesz. Kettős könyvvitel könnyebb, de azt meg ugye egyre kevesebben használják (alapítványok, egyesületek, stb.), így üzleti szempontból fontosabb az egyszeres könyvvitel kivitelezése.
De ettől függetlenül előbb a házipénztár és a számlázó modul készülne el...

Pont ezert jo, hogy van otthon egy sajat konyveloje, akivel le tudja teszteltetni a programot, hiszen o tud tanacsokat adni, hogy hogyan lenne jo a mindennapi eletben hasznalni. Ezen felul en nem tartanam olyan sikhulyenek a konyveloket a szamitogeppel kapcsolatban, hiszen manapsag mar letezni sem lehet anelkul. Emellett egy konyvelonek amugy is folyamatosan tanulnia kell (a kulonbozo jogszabalyokat, rendelkezeseket, specialis eseteket, etc.), igy az, hogy a szamitogepet is tanulni kell, mar szinte fel sem tunik.

"ismerned kell a könyvelés menetét, az ottani fogalmakat, a normális ügymenetet, a nem normális ügymenetet, stb. Ezen információk kinyerése egy felhasználóból nehéz (igazából ez is egy szakma)."
Akkor igen, ha meg meg is kell nyerned a felhasznalo bizalmat, illetve ossze kell ismerkedjetek. Mas a helyzet, ha az ember egyutt el egy, a szakmajat muvelo emberrel, akitol amugy is nap nap utan hallja a szakszavakat, legfeljebb nem erti, mi mit jelent. Sokkal kozlekenyebbek az emberek egy jo ismerossel, mint egy olyannal, akit meg sosem lattak, azt se tudjak ki fia-borja. Ettol fuggetlen haromtonna turelem szuksegeltetik, mert a konyveles bonyolult valami, de ezen felul komoly akadalyat en nem latom.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Én úgy tudom, hogy az APEH-hel nem kell engedélyeztetni, csak tenni kell egy nyilatkozatot a felhasználó felé, hogy a programod a törvényi előírásoknak mindenben megfelel.

A korábban emlegetett EasyInvoice kapcsán adott az APEH állásfoglalást:

"E-iktatószám: e-113540

Tisztelt Ügyfelünk!

A számla, egyszerűsített számla és nyugta adóigazgatási azonosításáról, valamint a nyugta adását biztosító pénztárgép és taxaméter alkalmazásáról szóló 24/1995. (XI. 22.) PM rendelet (a továbbiakban: Rendelet) 1/E. § (1) bekezdése szerint számítástechnikai eszköz útján előállított és papírra nyomtatott számla abban az esetben alkalmas adóigazgatási azonosításra, ha szigorú számadás alá vonása úgy valósul meg, hogy

a) a számla kibocsátására szolgáló számítástechnikai program (a továbbiakban: számlázó program) - a (4)-(6) bekezdésben meghatározott eltérésekkel - kihagyás és ismétlés nélkül, folyamatosan biztosítja a sorszámozást, továbbá

b) a számlapéldányok hiánytalan elszámolása az 1/F. § és az 1/H. § szerint biztosított.

A Rendelet 1/E § (2) bekezdése alapján a számla kibocsátójának a számlázó program olyan dokumentációjával kell rendelkeznie, amely biztosítja a program működésének ellenőrizhetőségét. A dokumentáció tartalmazza a program működésére, használatára vonatkozó részletes leírást, valamint a program készítője által a számla kibocsátójának címzett írásos nyilatkozatát arról, hogy az maradéktalanul megfelel a vonatkozó jogszabályi előírásoknak.

Számítástechnikai eszköz útján előállított és papírra nyomtatott számla abban az esetben alkalmas adóigazgatási azonosításra, ha szigorú számadás alá vonása úgy valósul meg, hogy az azt előállító számlázó program kihagyás és ismétlés nélkül, folyamatosan biztosítja a sorszámozást és a számlapéldányok hiánytalan elszámolása biztosított. Ilyen módon előállított számla esetén biztosítani kell többek között, a program-dokumentációnak a rendelkezésre állását és a program készítőjének a számla kibocsátója részére (a program használójának) címzett írásos nyilatkozatát arról, hogy a program maradéktalanul megfelel a vonatkozó jogszabályi előírásoknak. A számlázó programok előzetes minősítése, vagy véleményezése nem tartozik az állami adóhatóság feladatkörébe.

Üdvözlettel:
Adó- és Pénzügyi Ellenőrzési Hivatal
Közép-magyarországi Regionális Igazgatósága
Tájékoztatási Főosztály"

Az engedélyeztetés tényleg lehetetlen feladat, mert nem kell engedélyeztetni! Valószínűleg a pénztárgépekkel kevered, azt kell engedélyeztetni!
Számlázó program esetében a fejlesztőnek kell nyilatkoznia, hogy a jogszabályoknak megfelelően működik.

--
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

Vagy keverem vagy változott. Az biztos hogy (jó) pár éve konkrét összeget hallottam egy hasonló program esetében. (Hasonló programba belefér a számlázótól a könyvelőig szinte bármi, mert régen volt, és akkor sem érintett...)

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

> jó ujjgyakorlat lenne.

Ujjgyakorlatnak itt egy meredek ötlet:

Az ügyviteli szoftvereknek van két fontos felület típusuk: az adatrögzítés és a jelentéskészítés. Elvileg az adatrögzítő felületeket ki lehetne hagyni, ha a jelentések módosíthatók. A szoftver működhetne úgy, mint valami dokumentum kezeléssel kiegészített WYSIWYG szöveg szerkesztő. Az adatrögzítés úgy történhetne, hogy a felhasználó "lekér" a dokumentum kezelőtől egy valamilyen feltételeknek megfelelő jelentést (jelentés típusra, időszakra, stb. szűrve), majd módosítaná a jelentést (a nyomtatási képen megjelenő tételek módosításával, hozzáadásával, törlésével), hogy pontosan az szerepeljen a jelentésben, aminek kell.

Röviden: létrehozási, szerkesztési lehetőségekkel ellátott Qt based report generator

Asszem egy ilyet elég nehéz dolog lenne megírni, vagyis QT gyakorláshoz pont jó. :-)))

Nem tudom más hogy van vele, de én ha kíváncsi vagyok a cégem havi bevételére, engem az érdekel, hogy mekkora összegben állítottunk ki számlákat az adott hónapban. Attól, hogy átírom ezt a jelentést, szerintem csak a jelentést fogom átírni, nem lesz több vagy épp kevesebb pénz a bankszámlán és vásárlókat sem fog generálni visszamenőleg.

Meg aztán az is érdekes lenne, ha ennek hatására elkezdene számlákat készíteni a program. Valószínűleg le is sittelnének előbb vagy utóbb.

Szóval a leírásod valahogy nekem elég zavarosnak tűnik. Lehet, hogy konkrétan leírhatnád, hogy mondjuk a számlázást hogyan képzelnéd el?

Vessetek egy pillantást a Számlasegédre.
http://sourceforge.net/projects/szamlaseged

Apámnak kellene leváltani a jelenlegi accessben összegányolt számlázóját,
és úgy döntöttem ez lesz a kiindulási alap. Aztán pár nap után a hajam téptem a monotól,
így most írom át Qt-ra. A Qt-s kód még nincs kint a svn-en, még beszélek előtte az eredeti fejlesztővel.

Na nem tudom hol csatlakozzak be a szálba...

A lényeg hogy nekem van egy majdnem kész számlázó-raktárkezelő programom Qt4ben. A napokban kerül éles használatba a második telephelyen, szóval elég készen van, de nem támogatja a könyvelést.

ŐŐŐ mit is akarok ezzel? Nem tudom :) Nem annyira akarom közösségi fejlesztésbe tovább vinni, hogy mindenki az én gányolásaimat nézegesse :) de egyúttal azt is jelezném, hogy nem biztos hogy annyira üres a piac. A http://www.szamlazaslinuxon.hu/ is elég jó cucc, talán az enyém se lesz vérgáz.

Persze senkit nem kívánok eltántorítani semmitől, sőt jó magam is szándékozom közösségi projektekben részt venni, ha végre kicsit lazább lesz a munkarendem. Mondjuk én most archlinuxhoz gondolkozom grafikus front-enden a pacmanhez, ha lesz rá idő meg igény.

( gee v | 2009. 06. 16., k – 00:40 )

Rendes CASE tool van már? Multiplatform...

( dap | 2009. 06. 16., k – 03:54 )

Zárt forrású és/vagy pénzes fejlesztésre gondolsz?

( csortu v | 2009. 06. 16., k – 08:08 )

Egy használható videóvágó programot! Olyat, mint amilyen régen a main actor volt. Vagy olyan, amilyen mostanában a kdenlive szeretne lenni, csak azért működjön! De ne olyan legyen, mint a cinellera, mert nem szeretnék pilótavizsgát a kezeléséhez. Szóval olyan egyszerűt, amivel a kis zsebgépemmel csinált félperces családi videókat összerakhatom egy órás videóvá, berakhatok egyszerű transitionokat és az eredményt ki tudnám rakni mezei avi-ba. Szóval mint a mezítlábas videóvágók win alá (juled vagy mi a szösz). Csak egyszeri felhasználónak valót. Fizetnék is érte, ha lenne ilyen.... (Mondjuk 20-30 dollár körül.)
Csaba

Nagyon jok a KDE-s cuccok, tenyleg - a KDE usereknek. Ha viszont valami mast hasznalsz, nem biztos, hogy szeretnel egy haromnegyed KDE-t felrakni csak azert, mert 1 azaz egy darab programot akarsz hasznalni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem, nem. En hasznalnek Qt-s programot, de KDE-set nem, ugyanis az a memoriambol is elfoglal egy jokora darabot, nem csak a winyombol. Foleg, hogy nagyon keves KDE-s programot hasznalok (a 0 az nagyon keves).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

lezsögezem, nem kötekedni szeretnék, és kde4linugzfanboy sem vagyok.
megmértem egy gnome-on és kde-n indított amarok közti különbséget. 20mb volt. gnome-on 60mb körül fogyasztott a memóriából, kde4 alatt 40mb többlet volt a memóriában. Ez önmagában soknak tekinthető, és engem is zavartak ezek a dolgok még jó néhány évvel ezelőtt, amikor 320mb memórám volt mindenféle összekukázott sdramokból. De most, hogy 1,2gb ramom van (ne mondja nekem valaki, hogy az átlag ennél kevesebb, sőt...) és (sajnos) a firefoxnak egy puszta tab is többet eszik ennél, nem hiszem hogy bármiféle komoly jelentősége lenne desktop felhasználáson. Lehetnek helyzetek, amikor ez még számít, de meglehetősen ritka esetként tudom elképzelni, hogy pont az a 20mb hiányzik még bármihez.

Nem azt mondom, hogy valaki használja a kde-t merazjó', (vagy fordítva), csak nem tudom megérteni hogy egy jó alkalmazást miért kell csak azért elvetni mert más DE-hez igazodik. és ezért azt mondani, hogy linuxon kevés szoftver van. És ha mondja hogy de hát ott a Kxy, hát az nem jó, mert "zabálja" a memóriát, meg nem olyanok megnyitási/mentési dialógusok, meg még randa is.

Bocsi a kiborulásért, tudom ezek közül sokat te nem említettél. Csak olyan sok helyen tapasztaltam már, hogy ezzel nyavajognak, és egyáltalán nem tartom nyomós érvnek.

Szerintem a kino használható erre is, de nem erre való. DVre van kihegyezve, nagyon helyesen. Viszont a kis kézikamerámmal lekapott vacak minőségű videót importnál konvertálja DV-be, aminek szerintem semmi értelme. Ráadásul nekem hiányzik belőle a kép/hang sávmegjelenítő szerkesztési mód, elég körülményes két videó közé betenni egy szimpla cross-fading átmenetet is, az meg már csak hab a tortán, hogy nálam instabil is.... Ennyi erőből már mencoderrel trükközök, az előbb megvan, és betonstabil is. Szóval ezért mondom, hogy valami "csak leülök mellé, aztán összekattintgatom a videóm" szerű program hiánypótló lenne. Egy elég jó összefoglaló a témában itt, a meglévő programok kritikájával. Jól látható, hogy ez egy üres piaci szegmens, pedig igény úgy tűnik, volna....
Csaba

( hrgy84 | 2009. 06. 16., k – 10:01 )

Egy normalis kepbizgato progit. Ne legyen olyan pilotavizsgas, mint a Gimp, de legalabb tudjon annyit, mint az IrfanView (foleg a batch muveletek lennenek jok). Nem lenne rossz, ha valamilyen szinten scriptelheto lenne. Ja, es legyen valami normalis, attekintheto GUI hozza.
Nem lenne rossz olyasmi megoldas, mint a Windows 7-ben elterjedo ribbonok - ha lehet valasztani a normal megjelenites kozott is, vagy fentre kerulne egy rendes menurendszer is. Qt-ban teljesen mindegy, hanyfele modon lehet egy fuggvenyt meghivni a GUI-rol, szoval ezzel a reszevel sok gond nem hiszem, hogy lesz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha jól tudom, akkor elméletileg licenszet kellene végy ahhoz, hogy pénzért adhasd a programodat. (Pontosabban "commercial license" nélkül csak úgy terjesztheted, hogy mellékeled a forrást, és feljogosítod a vásárlókat, hogy azt kezdjenek vele, amit akarnak - szóval elméletileg mindig lehetne valaki, aki tőled vásárolta, s olcsóbban adja, mint te magad.) De lehet, hogy nem tudom jól.
[szerk]Sőt, valószínű. LGPL.

Kritának legfeljebb az elrendezése megszokottabb kicsit, mint a GIMP-nek, amúgy hasonlóan bonyolult. (Amúgy van egy pár dolog, amit a Krita tud és a GIMP nem.) Viszont a "legalabb tudjon annyit" az IrfanView-ra vonatkozott, és nem a GIMP-re, úgyhogy gondolom, képnézegető-képmódosítgató kéne (egyszerű, Paint-nél nem sokkal többet tudó rajzolónak ott a KolourPaint). Ilyennek viszont a Gvenview és a Digikam jön a képbe.

Akkor kell fizetni, ha a Qt forrását is módosítani szeretnéd, oly módon, h a módosításaidat nem adod ki opensource. Ha csak zárt forrású szoftverben szeretnéd használni a Qt-t, azt nyugodtan megteheted. Ez az LGPL lényege.

(Valami olyasmi kikötés is van az LPGLben, h olyan verziót is szolgáltatnod kell a usereknek, amit a Qt újabb verzióval újra lehet linkelni, ami gyakorlatilag azt jelenti, h dinamikusan linkelt változatot is elérhetővé kell tenned.)

"ami gyakorlatilag azt jelenti, h dinamikusan linkelt változatot is elérhetővé kell tenned"

Ez az egyszerűbb megoldás, de semmi akadálya a statikus linkelésnek és a .o(bj) fájlok közzétételének.

(Nem is kell közzé tenni, elég, ha kérésre biztosítod...)

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

Tényleg van ilyen az LPGL-ben, hogy lehetővé kell tenni a user számára, hogy tudja használni a library-k frisebb verzióját.

De mi van akkor, ha az általad mellékelt object fájlokból az újabb Qt libekkel nem szerkeszthető össze a program mert változott az Qt API felületében valami? Akkor ez az LPGL megsértése?

A Qt LPGL-ben van amúgy egy LPGL_EXCEPTION cucc amiben ez van:

As a special exception to the GNU Lesser General Public License
version 2.1, the object code form of a "work that uses the Library"
may incorporate material from a header file that is part of the
Library. You may distribute such object code under terms of your
choice, provided that the incorporated material (i) does not exceed
more than 5% of the total size of the Library; and (ii) is limited to
numerical parameters, data structure layouts, accessors, macros,
inline functions and templates.

Én ezt még a mai napig nem tudtam értelmezni (érteni értem, értelmezni nem tudom), hogy pontosan mire is vonatkozik az 5% és hogy fogja ezt a Nokia ellenőrizni.

Nem vagyok jogi szakértő, de ha a lib binárisan nem kompatibilis az előző verzióval, akkor logikusan nem várható el, hogy biztosítsd a működést...

(Qt egyébként kompatibilis (ha nem, akkor az bug).)

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

( Dacr (nem ellenőrzött) | 2009. 06. 16., k – 15:58 )

Jó pár építész van az ismerőseim közt, akik azért nem váltanak linuxra, mert nincs igazán jó CAD.

( NPeete | 2009. 06. 16., k – 17:10 )

Én is pont ilyesmin gondolkoztam, viszont abszolút kezdő vagyok, nekiállnék én valamit csinálni, csak semmi elképzelésem sincs. Ráérős szabadidőm (egyelőre) van, bár tudásom nem sok...

( f0xhu v | 2009. 06. 16., k – 17:31 )

+1 nekem is kellene tanulni valamit :)

Bár van ötletem, csak a rutin+évek+idő hiányzik a megvalósításhoz,
meg igazából elég szűk és anyagiakban sem bővelkedő piacot céloz meg...

A céges meg egyelőre üzleti titok :P

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

( gee v | 2009. 06. 16., k – 19:01 )

Mivel már (túl) hosszú ideje munkát keresek, szabadidővel teli a padlás.

Szívesen beszállok egy ilyen programozós projektbe, főleg, ha esetleg egy kis zsebpénz is jönne belőle.

C++ gyakorlatom van kb. 8 év

G

( viktor.bruder | 2009. 06. 17., sze – 12:26 )

Egy jól használható kottázó/kotta szerkesztő program. A Canorus egyelőre hiányos: pl. a hajlításokat nem lehet vele normálisan bevinni.

A Lilypond sokat tud, és nagyon profi kottaképet csinál, amihez már nagyon kevés kézi korrekció kell, csak hát tanulni kell.

Viszont jó a dokumentációja.

És a hátrányok nagy része kiváltható megfelelő editor támogatással:

Pl. ha Qt4 akkor:

http://www.frescobaldi.org/index.html

pdf preview + point-and-click (a pdf elemek és a lilypond forráskód szövegpoziciói közti megfeleltetés) + alapvető elemek beszúrása ikonnal stb...

Nem a profi kottázók közé tartozik, de a Rosegarden szekvenszerben van kotta lehetőség, s ha a midi-sáv végére akasztasz mondjuk egy plugin-hangszert, akkor le tudja játszani. Nézd meg, hátha használható céljaidra.
Gitártanulás esetén pedig a TuxGuitar lehet még jó szoftver számodra.

( leviske | 2009. 06. 18., cs – 14:30 )

Lehet, hogy hülye ötlet, de nekem pl Linux alól legjobban egy Windows Live Messenger 9 funkcionalitású üzenetküldő hiányzik.

Ha esetleg sikerülne egy gazdag funkciólistával és ízléses design-al rendelkező üzenetküldőt fabrikálnod, ami esetleg még a többi üzenetküldő szolgáltatással is kompatibilis volna, arra szerintem nem csak én volnék vevő. És nem hiszem, hogy sokakat zavarna, ha bele lenne csempészve némi reklám, hiszen a WLM-ben is van a 8.0 óta.

A kisebb játékaitok demóját is elérhetővé tehetnétek benne cloud-ból, vagy kiegészítőként letölthetők volnának. Így jó esély van rá, hogy többen is vennék a teljes változatokat. Esetleg, ha van multiplayer játékra alkalmas művetek, az még jobb.

Egy minőségibb üzenetküldővel szerintem akármelyik platformon megállhatnátok a helyeteket, mivel konkrétan csak a WLM-el és a Skype-al kell megküzdenetek komolyabban, ami az alábbiak meglétével nem volna nehéz:

- Beállítások mentése egy központi szerveren (ez lassan általános minden üzenetküldő esetében), így nem kéne újra beállítgatni a csoportok neveit, a partnerek neveit, a saját hátteret, vagy a beállított témát, a beállított skint és persze az avatart.
- Fizetős szolgáltatásként lehetne hasonló módon telefonálni, mint a Skype esetében, azzal a különbséggel, hogy esetetekben javasolnám, hogy lépjetek szövetségre a T-System-el, hogy lehessen az Ő feltöltőkártyáikkal is fizetni. Így megkapnátok a megfelelő nyilvánosságot, úgyis jól jönne nekik egy olyan "szövetséges", mint Ti, hisz az Androidra is kellenek majd komolyabb játékok, amikért érdemes lesz fizetni és miután az Android meg (tudtommal) Linux alapú... :) És persze az általam említett üzenetküldőt is lehetne portolni Android mobilra és netbook-ra.
- HD képes videóbeszélgetés [Az esetleges mobil és netbook portból ezt a funkciót érdemes volna kivenni, vagy butítani.]
- Kiforrott konferenciabeszélgetés

Fiataloknak (ezt még rám is lehet talán mondani) lényeges ficsörök:
- Az iGoogle-höz hasonló interaktív, de nem zavaró témák, vagy helyettük szabadon válaszható hátterek, amiket hasonlóan kezelne, mint a WLM9.
- Skinek sem ártanak, főként, ha multiplatform lesz. Bár amúgy sem árt, mert az emberek szeretik személyre szabni a gyakran használt progiaikat.
- Beépített, de kikapcsolható "Messenger Plus!"-éra hajazó szolgáltatáslista.
- Hasonlóan egyszerű kiegészítő kezelés, mint a Firefox-ban. [A kiegészítőknek Ti is nyithatnátok egy oldalt, mint a Mozilla, és ebben az esetben is akárki küldhetne be fejlesztéseket és mint említettem, ide becsempészhetnétek egykét játékdemót]
- Cloud-on keresztül megoldott fájlküldés (ha akarok valakinek küldeni egy képet, akkor felküldöm a kis tárhelyemre -ha fenn van az illető akinek küldeném, ha nincs- és utána az adott embernek csak megjelenne, hogy szántam neki valamit és Ő eldönthetné, hogy letölti-e. Esetleg egy víruskereső előbb végigfuthatna a fájlokon, így megelőzve az esetleges féregfertőzések futótűzszerű fejlődését)

Ez csak nagy vonalakban ennyi, ha tetszik az ötlet, akkor még beszélhetünk részletesebben, meg gondolom nektek is vannak saját ötleteitek ugyebár... bele tudjátok őket szőni. :)

Tudom, hogy ez nem konkrétan kereskedelmi szoftver, ahogy kérted, de amennyi pénz betudna jönni a reklámokon keresztül, plusz egy esetleges T-System-es szerződésen keresztül... Szerintem nem járnátok rosszul. Arról nem is beszélve, hogy komolyabb elterjedés esetén komoly reklámot csinálhatnátok egyes játékaitoknak. És miután lenne lehetőség feltölteni az egyenleget (fentebb említettem), arra alapozva lehetne később piacteret is létrehozni, ahol ugyanúgy lehetőség nyílna a játékaitoknak egy nagyobb vásárlókör megkaparintására.

Én még nem vagyok fejlesztő (bár ebbe az irányba akarok majd továbbtanulni), így nem nagyon tudnám megvalósítani és ki tudja, hogy 3-4 év múlva is ennyire "egyszerű" lesz-e a helyzet, hisz Linux-ra és MacOSX-re alig van normális üzenetküldő, a Windows-on is csak a WLM örvend osztatlan sikernek.

Ízlések és pofonok. Én Windowson is az aMSN-t használom, azt is csak azért, hogy a gyerekeim napközben a szünetben elérjenek. Nem győzöm letiltani azt a sok krix-kraxot, amit az MSN kiegészítések miatt a lányom küld. Az meg kifejezetten idegesít, amikor a lányom gépén kicserél egyes szavakat képecskékre.
Könyörgöm ez egy kommunikációs szoftver! Tudok írni-olvasni, beszélgetni, sőt még web-kamerázni is, mi kell ennél több?
Amúgy meg inkább a Skype-ot használom.
De ha neked ez tetszik használd!

UI: Nem hiszem, hogy mash-t rá tudod beszélni, hogy "hasznos" program helyet MSN-klónt írjon.
--
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

Nem MSN klónról írtam... De miután feltételezem, hogy erre az oldalra kevés értelmezési problémákkal küzdő emberke jár, feltételezem, hogy talán az első mondatot, ha elolvastad...

"Amúgy meg inkább a Skype-ot használom."
Ennek megemlítése is erre utal...

Azt is pont megemlítettem, hogy a "sok krix-kraxot" le lehetne egy gombnyomással tiltani.

Az tény, hogy ízlések és pofonok, de számomra erősen kérdéses, hogy az aMSN esetében lehet-e ízlésről beszélni. A Skype-al meg az a gond, hogy Linux alatt nem mondanám teljesértékűnek. Elég rég nem is jelent meg új változata.

Én végigolvastam, és én is egészen úgy értettem, hogy igazából egy MSN-klónról írsz, olyan változtatásokkal, ami által annál sokkal jobban megfelelne az ízlésednek.
Ha egészen biztos vagy az elképzelésedben, akkor érdemes bérelned egy-két(-x) embert s felméretni, megterveztetni és kiviteleztetni a dolgot. De a leírt víziód alapján én személy szerint óvatosságra intenélek.

Irtó sok funkció, ami a usernek két kattintás, a háttérben néhány hónapnyi emberóra munkát igényel. Videótovábbítás, fájlok cloudban tárolása például. Vagy egy ízléses felhasználói felület. Amit meg is kell tervezni, hogy milyen funkcionalitásra kell képes legyen: melyik modul mit csinál, hogyan fér a többihez, ilyesmi.

Szerzői jogokra én nem gondoltam, de videótovábbításnál nem apró részlet a codec sem.

Az MSN-klónszerű az benne, hogy
- onnan indulsz ki, és nagyjából bekezdésenként visszautalsz rá
- nem érződik az a forradalmi új ötlet, ami más alapokra helyezné a dolgot, mint a meglévő instant messengereknél
- nem írtad bele az én IM-es szívem fájdalmát: nem látszik karakterenként a gépelés, mint a unix talk-nál =)

6030999+Yorirou: Igen, jobban belegondolva abban igazatok van, hogy nem kevés munka volna (bár nem tudtam, hogy több év lenne).

Yorirou: Igen, ebben is igazad van... nem igazán gondoltam át, hogy mekkora szerverparkra lenne szükség, bár ha a T-Systemmel megtudnának egyezni, akkor nem feltétlen lenne ez a legnagyobb akadály. Eleinte úgysem 1milliárt user-t kéne kiszolgálnia, ha pedig szép lassan erősebbnek bizonyulna a konkurenseinél, akkor T-éknek is megérné belefektetni. Bár az is igaz, hogy amennyiben már az egészet a T-System szponzorálná, akkor mash-éknek nem igazán jönne már be annyi pénz, ha egyáltalán kapnának részesedést. Innentől meg már tényleg egyszerűbb, ha nekik írok. :D

6030999: A felhasználói felülettel nem hiszem, hogy gondjuk lenne, hiszen játékfejlesztők...

Az MSN-re szerintem annyira sokszor nem utaltam vissza, mint amekkora piaci fölénnyel rendelkezik. Egy WLM9.0 sajátosságot említettem komolyabban meg, az a háttér kezelése, de az meg annyira nem lényeg... Egyszerűen csak jópofának tartom, hogy amit beállítok háttér, az lesz az üzenőablakom háttere is annál, akinek írok. Ezt is csak amiatt említettem meg, mert az iGoogle-ben tetszik, hogy napszak, vagy időjárás szerint változnak a témák és ez az ötlet szvsz jól mutatna egy üzenetküldőben is, de ez nem akkora lényeg...

A másik MSN sajátosság, ami helyett nem írhattam volna más programot, az a reklám, amivel csak arra akartam utalni, hogy önmagában is tud egy ilyen szoftver nekik pénzt termelni (miután említette, hogy nemáll szándékában freeware programra pazarolni az idejét, amiben valahol igazat adok neki, lévén, hogy valamiből élni is kell)

Ha lenne rá időm, pénzem, energiám, akkor nagyon szívesen beszállnék akár nyílt forrású fejlesztésekbe is, de egyelőre még nem jártam az űrben és nincs saját Linux distro-m. Ha ezeket letudtam, akkor nekiesem ígérem. :)

Az MSN csak Magyarországon ennyire népszerű. Ha nem csal a memóriám, akkor USA-ban alig használják. Ott inkább Skype, meg Yahoo megy. De lehet, hogy rosszul emlékszem.

Ahhoz, hogy a T-Systems szponzorálja a dolgot, ahhoz valami nagyon meggyőző dolgora van szükség.

Amire szvsz igény lenne, az valami durván titkosított protokoll, de arra meg előbb-utóbb a titkosszolgálatok be fognak szólni (lásd skype), ha elkezd elterjedni.

Viszont egy alap IM klienst + szervert összedobni jó kis Qt/C++ gyakorlat lehet. Funprojectnek is nagyon jó :)

Ezekre a funkciókra lennék kiváncsi. Ami egy IM szoftvernél számíthat szerintem: szöveges chat, telefonálás, videotelefonálás, valami offline üzenethagyási lehetőség. A többi csicsa.

(OFF: miért kell átvenni a marketingesektől a "generáció" újszerű használatát? Számtechben eleinte a szgépgenerációkra használták, amikből mostanáig 4 vagy 5 volt. Mostanában meg félévente megjelenő major verziókat is generációnak mondják. Ez nem csak neked szól.)

Néhány hete megjelent Windowson, a Skypeban, hogy van új verzió. Én meg letöltöttem és telepítettem. Aztán még egy hét után is azon gondolkodtam, hogy downgradelek. Igazán új dolgok nem jöttek vele csak míg korábban aránylag részletes info jelent meg a partnerekről, az avatar mindenképpen, addig ezt minden esetre jobklikk-helyi_menü-info kiválasztásával lehet előcsalni. egyenként és mindig csak egy látszik.
De olyan sokat azt (mármint a Skype-ot) sem használom, tehát hagytam a fenébe.
Lehet, hogy öreg vagyok, de nekem elég ha üzenetet tudok váltani és néha beszélgetni, a kamera sem igényem. De mondom a hiba nálam lehet én egy telefonnal is "csak" telefonálni akarok, mondjuk a telefonkönyv az jó dolog és egy ideje már az ébresztő órát is használom, de ennél többet nem várok tőle. Van a mobiomban egy gyenge kamera is, de 2-3 próba képen kívül mást még nem fényképeztem vele. Játékokklal meg főleg nem játszok mobilon.
Szóval az MSN még ha újabban Windows Live Messengernek is hívják egy csomó fölösleges kacat, és csak minimális hasznos funkcionalitás.
De nem vagyunk egyformák. Ha valakinek az kell hát használja! Abban reménykedek a gyerekeim (főleg a 16 éves lányom az érintett, a 13 éves fiam mást használ üzenetküldésre) előbb utóbb kinövik.
--
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

( Winter | 2009. 06. 18., cs – 15:31 )

Esetleg egy grafikus Dreamweaver-szerű webfejlesztői környezet.

Bye Bye Nyuszifül

Igazabol az csak egy resze a dolognak, hogy keves a fejleszto.

Az eredeti KDevelop ket modulra bomlott, a KDevelop programra, es egy KDevPlatform nevu osztott konyvtarra, amit a kulonbozo fejlesztoeszkozok kozosen hasznalt kodjanak hoztak letre. Az eredeti gond az volt, hogy egy csomo minden ujra fel lett talalva a KDevelop-ban es a Quanta-ban, aminek igazabol sok ertelme nem nagyon volt.

En meg ugy tudom, jelenleg a Quanta fejlesztoi arra (is) varnak, hogy a KDevPlatform fejlesztese kisse lenyugodjon, hogy elkezdhessenek dolgozni a Quanta4-en.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ja, rájöttek, hogy minek mindent újraírni, majd KDevPlatform alapokon, modulárisan megoldják.

Ami teljesen jó is lenne, csakhogy a KDevPlatform nem nagyon akaródzik elkészülni, és így ők sem tudják alapul venni.

Ezóta sztem nem sok előrelépés volt: http://www.kdedevelopers.org/node/3448

A levlista szinte kihalva, az SVN _elvileg_ lefordul, de nem tekintik használható dolognak jelenleg.

Ez nem igaz. A KDevPlatform nagyonis fejlodik, rengeteg SVN commit van folyamatosan.

Ami a hasznalhatosagot illeti: azt mondtak a fiuk, hogy meg kiadni nem lehet, mint stabil cuccot, azonban azt sehol se olvastam, hogy ne lenne hasznalhato, sot. A #kdevelop -on egyre tobb kerdes jon KDev4-gyel kapcsolatban, ami igen erosen arra utal, hogy emberek folyamatosan ternek at - holott definiáltan nem befejezett cuccrol beszelunk. Annyira nem lehet pocsek...

Megint mas kerdes, hogy a mainstream KDE developerek mit minek tekintetnek. Ha jol hiszem, azert nincs meg hasznalhato termeknek tekintve, mert a KDevelop3 kepessegeinek egy resze meg hianyzik, plusz a nyelvi supportok kozul is meg csak a C/C++ van kesz meg a PHP.

Ami a levlistat illeti: hat tenyleg nem egy forgalmas valami, de a KDE developerek egy resze a kommunikaciohoz inkabb IRC-et hasznal, mint levlistat, az csak azert van, hogy legyen +1 kommunikacios csatorna.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nincsenek. Ha arra gondolsz, hogy orzik a 4.2 kompatibilitast, az azert van, mert a KDevPlatform trunk mindig a legutolso stable-hoz nezve kompatibilis. De ugy tudom, hogy ha van valami hack, ami kellett az eggyel elozo verziohoz, es egyebekben nem valtozott, akkor elvben lefordul regebbi KDE-vel is a platform.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Annak ellenére sem kapkodják el. Ha belegondolsz, lassan másfél éve jelent meg a 4.0, és a KDE-fejlesztők már jóval az előtt tudták, hogy kb mi fogja őket várni. Olyan portok készültek el 4.2-ig, mint Amarok, digiKam, Krusader... amik egyéltalán nem kis hobby-projectek.

Ezek után azért szerintem mindenképp lemaradás, hogy az egyik alap-komponens még mindig csak beta fázisban van, pedig nagy szükség lenne rá (rendes KDeveloppal a többi program portolása is kézenfekvőbb lenne, nem kéne a régivel/külső stuff-okkal bohóckodni)

Hasonlóan nem értem a K3b késlekedését, pedig az "csak" egy frontend, mások ennyi idő alatt 2x újraírtak nagyobb progikat. Igaz, náluk csak néhány fejlesztő dolgozik aktívan.

Sokaknak meg nem sikerult rendesen atterni a KDE4-re programilag. Rengeteg program ugy van most a KDE-ben, hogy a KDE3 support libet porgeti ezerrel. Ilyen peldaul a JuK is, meg jonehany regebbi KDE-s program. Ezek igaz, hogy eleg aprok, de van egy par beluluk - es ezeket is portolni kell.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( mash | 2009. 08. 28., p – 05:47 )

Na, megszületett a döntés és nem nagyon tudtam "messze esni a fámtól". :)
Egy SCUMM szerű kattintgatós kalandjáték fejlesztő környezetet fogunk létrehozni, amivel Monkey Island szerű 2D-s kalandjátékokat tudunk csinálni. A rendzser Qt-tal fog készülni, a script nyelve pedig a LUA lesz. A tervek szerint futni fog Linux-on, MacOSX-en és Windows-on. Az editorokból "kiköpött" végeredmény az alábbi platformokon lesz futtatható.

Phase1:
- Windows
- iPhone

Phase2:
- Linux
- MacOSX
- Nintendo Wii
- Sony PSP

Phase3:
- Xbox360
- Sony PS3
- Nintendo DS
- Flash

Az egész folyamat automatizált lesz. Az editorból kinyomott kód egy VM szerű környezetben fog futni minden platformon, lehetőleg módosítás nélkül.

Szóval ez lenne a cél. Szép nagy feladat. Induláskor zárt forráskód, aztán lehet, hogy később megnyitjuk GPL alatt.

Pedig már a "legfontosabb", a név is megvan! ;)
Tádádádám-tádádádám!

MACK® - Multiplatform Adventure Construction Kit®
MACK ED® - Multiplatform Adventure Construction Kit Editor®
MACK VM® - Multiplatform Adventure Construction Kit Virtual Machine®

Már le is védettem.
Remélem nem ázunk el vele! XD

Valami olyasmit képzeltem el megvalósítani, hogy az editorban futna a játék és közben valós időben lehetne scriptelni Python vagy LUA segítségével, a változások pedig azonnal látszanak a végeredményen is anélkül, hogy újra kellene indítani/fordítani a projectet.
Ezt az egészet úgy, hogy non-modal window-kat lehetne szétpakolgatni több monitoros rendszereken és nem fix felbontással dolgozna, hanem 4:3-as képarányban az adott platform default felbontásához igazítaná a játék felbontását. Pl. Windowson, Linuxon és MacOSX-en a játékok 1024x768-ban futnának, Wii-n 640x480-ban, míg iPhone-on 480x320-ra, vertikálisan kissé torzítva.