Ezen a héten történt a KDE táján (augusztus 19.)

Címkék

2007 Google Summer of Code rendezvénye hamarosan a végéhez érkezik. A Step fizikai szimulációs csomagba sok újdonság került be. Több grafikaus játéktéma a KMahjonggban, a KWin4 KShisenben, a KGoldRunnerben és a KJumpingCube-ban. Egy új játékot is fejlesztenek, a KDiplomacyt. A Blitz grafikus könyvtáron fejlesztettek sokat. Az Amarok 2 felületén csiszoltak, illetve a dalszöveg megjelenítő Plasma minialkalmazás is helyet kapott az új verzióban. A Plasmába pedig elkezdtek bekerülni a panelek és a vágólap motor kódjai. Az ODBC adatforrások KControl modulja is kiegészült néhány új funkcióval. A Raptor menü már támogatja az animációt. A KCacheGrind portolva lett a QGraphicsViewhoz. A KOffice már tudja a MusicXML importálási funkciót. A KPixmapCache-ekben már lehet statisztikákat megtekinteni, és ehhez a funkcióhoz elkészült egy alkalmazás is. A KGraphEditor, egy „pont” diagramok szerkesztésére használt alkalmazás került be a KGraphViewerbe. Új architektúrát kapott a KMobileTools. A KTrace neve most már Inspektor.

Akkor most lássuk, hogy mi az e heti „talán ismeretlen” programok listája:

  • Step: egy interaktív fizikai szimulátor. Vele a felhasználó könnyen megszerkesztheti saját kísérletét, olyan elemek használatával mint a részecskék, merev testek, rugók, kötelek, gravitációs- és coulomb erők stb., így könnyebben megértve a fizikát.
  • KShisen: Mahjongghoz hasonló játék; a cél az összes lap eltávolítása.
  • KGoldRunner: akció és rejtvénymegoldás. Keresztül kell futni az útvesztőn, le kell győzni az ellenséget, összegyűjteni az aranyat, majd ezután folytatni a következő szinten.
  • KJumpingCube: egy- vagy kétszemélyes taktikai játék. A pálya olyan négyzeteket tartalmaz, amiken a rajtuk lévő pontok növelhetők. Így több területet lehet szerezni, végül pedig megszerezni a táblát.
  • Raptor:
    Azt hiszem, egy videó erről jóval többet tud mesélni, mint én :)
     
  • MusicXML: egy XML alapú nyílt kottatárolási formátum.
  • KMobileTools: a mobiltelefonok PC-vel való irányíthatóságát teszi lehetővé. Képes a teljes SMS kezelésre, számok tárcsázására, telefonkönyv-kezelésre, telefonállapot monitorozásra. Szépen együtt tud működni a többi KDE-s alkalmazással, így beágyazható a Kontactbe, vagy importálni/exportálni lehet bele/belőle a KAddressBookból. Motorola, Nokia, Siemens, Sony Ericsson és LG telefonokkal tesztelték.

Múlt héten Daniel M. Duley (aka. Mosfet) visszatért a KDE SVN fejlesztéshez. Megkértem Danielt egy újbóli bemutatkozásra, és hogy összegezze a Blitz grafikus könyvtáron végzett munkáját:

Hogyan kerültem vissza KDE fejlesztőnek?
Tulajdonképpen már egy ideje újból aktív vagyok, csak nem csaptam túl nagy zajt, mivel még nem volt mit kiadnom. Ezenkívül sokat beszélek a különböző fejlesztőkkel és már kódolom a saját cuccom leginkább Qt 4-gyel egy ideje.

Hogy kezdődött a Blitz és mit tesz tulajdonképpen?
Amióta egy ideje saját magam programozom, az egyik dolog, amit csinálok, az a KDE 3-as effektek javítása. Ezek eredetileg eléggé hibásak és felületesen kódoltak (legalábbis az, amit én írtam ;-). Így fogtam a régi kódot, újra implementáltam a legtöbb dolgot Qt 4-et használva, de a nulláról.
Néha megtartottam ugyanazokat az algoritmusokat, gyakran újakat használtam, hozzáadtam egy csipetnyi MMX-et itt meg ott. Ilyesféléket csinálok.

Az eredeti szándékom mindössze az volt, hogy magam használom ezt, amíg az új KDE képkönyvtár, a Quasar elérhető nem lesz. Aztán portoltam a dolgot. De amikor nyilvánvalóvá vált, hogy a Quasar nem lesz elérhető a KDE 4.1-ig, és a régi KDE-s effektek reménytelenül rosszak voltak, javasoltam, hogy használják azokat a szűrőket, amiket eddig készítettem. Így született meg a Blitz. Amint elérhetővé válik a Quasar, megpróbálom elérni, hogy minden Blitz által támogatott dolgot is támogasson, hogy a KDE 4.1-re való átállás olyan könnyű legyen, amennyire csak lehet.

Azon kívül, hogy a Blitz sokkal jobban van megírva, sok újdonságot is felmutat, mint például:

  • MMX smoothscaling
  • MMX-SSE szürke skála és invertálás
  • MMX-SSE Sobel szél
  • MMX-SSE integer convolve
  • MMX-3DNow! lebegőpontos convolve
  • MMX-3dNow! gaussian elmosás
  • Belső HSV és interpoláció
  • Új elmosók és élesítők
  • Jóval hatékonyabb módszerek az olyan dolgokra mint például a szemcsementesítés, kiegyenlítő, normalizáló stb.

Azokon a módszereken, amik már léteztek a KDE-ben, sokat javítottam és láthatóan jobban kell teljesíteniük mind az MMX mind a sima C++ verziót használva. Mindegyiket leteszteltem 8 biten, 32 bites RGB-n és 32 bites RGBA-n és elősokszorosított (premultiplied) képeken (csak ezért kivettem egy szabad napot >:).

Másik dolog, hogy az emberek valószínűleg nem tudják, hogy mennyit gyorsított a Qt a grafikus kezelésén, különösen a QPaintert és a QImage-et használva. Ha körülnézel a Qt forráskód táján (src/gui/painting/), mindenféle nagyon ügyesen megírt MMX/SSE gyorsított dolgot találsz.

Jelenleg a KDE SVN-jében hackelek, veszem sorra a dolgokat, és javítom a régi grafikus kódot. Például most fejeztem be a nagy KIconEffect újraírást, ami jobb teljesítménnyel kell, hogy járjon és néhány hibája is javítva lett az új QT 4-gyel. Kis dolog, de valakinek meg kellett csinálnia, mielőtt a KDE 4 kijön.

Más dolgok, amin dolgozom...
Néhányotok biztosan emlékszik egy öreg KDE-s alkalmazásra, a „Pixie”-re. Célja volt egy nagy teljesítményű képkezelő megvalósítása, ami tonnányi (több ezer) képet képes kezelni könyvtáranként. Hát, dolgozom rajta, és remélem, hogy hamarosan napvilágot lát egy kezdetleges verziója.

Olyan kitűnő képkezelőkkel vagyunk körülvéve mint a Digikam, Krita, KolourPaint és Gwenview, mégis miért csinálom, miért hozom vissza a Pixie-t? Nekem ez főleg csak egy próba az új technikák, felhasználói felületek és ötletek kipróbálására. Alkalom adtán beszélgetek a Gwenview-os Aurelien Gateau-vel és a Kritás Boudewijn Rempttel, ötleteket osztunk meg a kódról stb. Tehát a Pixie nekem csak egy út, hogy újra megszokja a KDE/Qt vonalat és tapasztalatot szerezzek egy ilyen dologgal.
A technológiai oldalon a legnyilvánvalóbb előnyt a Blitznél szereztem eddig (sokat szeretnék még hozzáadni Zack Rusin Quasarjához). De különböző dolgokon is munkálkodom, mint például egy nagy teljesítményű bélyegkép nézegető, ami követi a Qt modell/nézet felépítését és mások is tudják használni:

Minden itt bemutatott anyag csak a korai fejlesztés állapotából való, miközben kísérletezgetek a dolgokkal :P


A Pixie nagy teljesítményű bélyegkép nézegetője

Játszottam a KPartsszal is, és a Pixie már annak hostja, így már bármilyen KDE komponenst be tud tölteni egy fülre, és megfelelően igazítja hozzá a felhasználói felületet.

A Pixie, ahogy egy KParts részt használ

A felhasználói felületnél az ihletet az újabb digitális műholdakon és a kábeltévés vevőkön található felület adta. Megszabadultam az állapotsortól és a forgó fogaskeréktől, és áttetsző takarással helyettesítettem, Csak hogy megtapasztaljam az új ötleteimet a gyakorlatban.


Takarások használta információk közlésére


Még a többi KDE összetevő is tudja használni őket

Még egy véletlenszerű megjegyzés; ha nem felsőszintű ablakokként készíted el a gyorstippeket, kompozit ablakkezelő nélkül tudod őket áttetszővé tenni, így, mindenki gépén működni fog. Hátránya: bele kell, hogy férjen a főablakba :(


Eléggé ronda gyorstipp a főablakot használva

Még egy még véletlenebb megjegyzés; a sokat fejlesztett Qt-s dolgoknak köszönhetően olyan őrült dolgokat tudsz könnyedén megvalósítani mint egy méretezett háttérkép, ami minden felette lévő widgeten látszik. Nem, nem így fog kinézni a program, de azért buli dolog :)


Őrült módon méretezett háttérkép


A kde-look.org oldalról használtam ezt a hátteret, mivel a pók pont olyan jó helyen van, ahol a widgetek találkoznak :)

Jason vanRijn Kasper bemutatja a fejlődést a KPilot
Summer of Code projektjét, a „KPilot bejegyzés alapú szinkronizálásának fejlesztését”:

A KPilot Summer of Code projekt nemsokára zárul, ezen a hétfőn következik be a „tollakat letenni” időpont. Bertjan Broeksema kimagasló munkát végzett, és teljesített minden olyan célkitűzést, amit ígértünk a kiírásnál. A probléma, amivel szembekerültünk, hogy a vezetők sok dolgokat csináltak általánosságban, de mindegyikük kódja ugyanazt tette. Ez nagyban megnehezítette a karbantartást és néhány vezető kevesebbet tud, mint kéne neki – nem említve a túl sok hibával járó duplikált kódot.
(megj.: vezető: a szinkronizálás ún. vezetőkkel (conduit) van megoldva, amik szinkronizálják a tenyérgépek adatait egy asztali alkalmazás adataival. A legtöbb vezető bejegyzés alapú, mivel ellenőrzik, hogy a bejegyzések a tenyérgépen megváltoztak-e (hozzáadás/törlés/változtatás lehetséges), és frissíti az alkalmazást. Eddig mindegyik vezető saját maga végezte a bejegyzések kezelését, ami a hibairtást nehézzé és időigényesség tette – a beküldő)

Tehát az ötlet az volt, hogy az összes bejegyzés alapú vezetőnk közös kódját annyira közössé kell tenni, amennyire csak lehetséges. Ez oda vezet, hogy a vezetőink főleg az adatátalakításokért lesznek felelősek (a PC naptár VCal bejegyzését átalakítani olyanná, ami szinkronizálható egy Palm adatbázis bejegyzéssel), és meg is oldják a fent említett problémákat.

És amíg benne voltunk (plusz amíg átgondoltuk és megterveztük, hogy hogy kéne a KPilotnak működnie), sok energiát fektettünk abba is, hogy annyira megnehezítsük a vezetőinknek a felhasználó adatainak megsemmisítését, amennyire csak lehetséges. Ez olyasféle, amit elővigyázatosan kell beemelni a tervezési folyamatba, mivel egyszerűen nem történhet meg véletlenül. Így néhány olyan döntést hoztunk, ami remélhetőleg oda vezet majd, hogy kevesebb „A KPilot elpusztította a jövőmet” e-mailt kapunk.

Hivatalosan három fő Summer of Code kitűzésünk volt:

1. Sor- és osztálydiagramok

Ebben az évben a Rational Unified Process egy laza értelmezését használtuk a projektünkhöz. Öt hetet töltöttünk el azzal a projekt kezdetén, hogy elkészítsük a célkitűzéseket az elkövetkező munkához, majd lefektessünk néhány sor- és oszlopdiagramot, amik megmutatják, hogy ezek a célok hogyan kapcsolódnak egymáshoz, és hogyan valósíthatóak meg. BOUML-t használtunk az UML diagramjainkhoz (inkább Umbrellót használtam volna, de Bertjannak volt egy kis gondja a Gentooja alatti beüzemeléssel). Mindent egybevéve, úgy érzem, megtaláltuk a megfelelő időbeli egyensúlyt a tervezésre, és maradt elég idő a tervek megvalósítására is.

2. Az elvont bejegyzési keretrendszer implementációja

Mivel a célkitűzési dokumentumunk majdhogynem teljes egészében a vezetőink által megkövetelt funkcionalitásra volt kihegyezve, Bertjan elég gyorsan meg tudta írni az alap vezető osztályok kódját. Nagyon kevés tervezési kihívást és hiányt találtunk a kódírási fázisban, amit annak a nagyszabású munkának tudok be, amit a célkitűzési munkánkba és az UML modellekbe fektettünk. Ez ellentmond a tipikus nyílt forrású hackerek felfogásának, miszerint túl sokat tervezünk, de nem kódolunk (úgy értem, a kódolás jó dolog, igaz?). De Bertjan türelmesen dolgozott velem ezen a részen is, és azt hiszem, valóban kiváló minőségű kód került ki kezünk közül. Bertjan írt még néhány sorozat egység tesztet, hogy segítse a kódját tesztelni az alap osztályokon.

3. Egy új vezető megvalósítása, bizonyított elképzelés (proof of concept) szerint

Az elején nem voltunk biztosak, merre tovább: megpróbáljuk-e portolni az egyik létező vezetőt az új alaposztályokba vagy írjunk egy teljesen újat. Ahogyan kiderült, a saját SoC munkánkat a trunk/ mappában végeztünk, ami azt jelenti, hogy nem volt túl stabil a kódbázisunk (még mindig azon dolgozunk, hogy a KPilot stabil legyen), amiről indulhattunk volna. Így eldöntöttük, hogy egy új vezetőt hozunk létre, ami az új alaposztályainkat valósítja meg, ahelyett, hogy a portolásnál és az új rendszerbe illesztésnél ragadtunk volna le. Már régóta szerettem volna, ha létezne egy megoldás a Keyring Palm alkalmazással való szinkronizációra (titkosított, többcélú Palm adatbázis jelszavak, különböző számok, információk stb. tárolására), így elhatároztuk, hogy létrehozunk egy új vezetőt a trunk mappában az új alaposztályok tesztelésére és ellenőrzésére. Éppen most fejezünk be néhány kisebb finomítást rajta, és reméljük, hogy teljesen működni fog a végére, hétfőre.

Tehát összegezve, köszönhetően az idei Google Summer of Code KPilot projektjének, van egy alap vezető keretrendszerünk, ami egy új Keyring vezetőben van megvalósítva. A következő lépéseink ezek lesznek:

  • a démon és a KPilot felhasználó által látható dolgainak stabilizálása
  • a régi vezetők portolásának befejezése az új KDE 4-es API-ra
  • a régi/létező vezetők portolása az új alap bejegyzés keretrendszerre
  • stabilizálás, tesztelés, mosás, szárítás, ismétlés
  • újra megtekinteni az OpenSync keretrendszert (most hogy közös vezető keretrendszerünk van a KPilotben), és megnézni, hogy tudjuk-e módosítani annak könyvtárait az alap szinkronizálási algoritmusok miatt

Inge Wallin ír a Marble új képességeiről (benne a Summer of Code projektről is). A videók Andrew Mansontól származnak:

Valamiért a Marble lett az új generációs KDE alkalmazások zászlóvivője. Grafikus, gyönyörű, gyors és teljes egészében kihasználja a Qt 4-et. Egy figyelemre méltó fejlesztőgárdát kovácsolt össze szinte semmi idő alatt. Érdekes, hogy a Marble két változatban leledzik: egy mint a KDE alkalmazás a KDE-Edu modulban és egy mint csak Qt-s verzió. Tehát folytatva a jó hagyományokat, itt vannak a legfrissebb fejlesztések.

Két napja, ezen a pénteken kiadtuk a 0.4-es verziót. Az új verzió újdonságai között szerepel egy új KDE verzió, beállítható jelmagyarázat, gyorsított sebesség, új térkép típusok, jobb adatsorozatok, részek azonnali letöltése és még több minden. Lásd a kiadási bejelentést az összes részletért.

Marble bemutató videó letöltése (15,3 MB, MPEG)

Úgy gondolom, hogy a legérdekesebb „képesség” a fejlesztett adatsorozatok. Például van egy sorozat műholdképünk 500 m/pixel felbontással. Nyilván ez nem annyira jó, mint a Google Earth-é, de ahhoz elég, hogy nagyon lenyűgöző térképeket készítsünk. Mivel a Marble részlet (tile) alapú, és az összes ilyen adat a KDE-Edu modult túlontúl naggyá tenné, ezért a legnagyobb felbontású részletek egy szerveren tárolódnak, és akkor töltődnek le, amikor szükség van rájuk. Ez eléggé nagy terhelést fog jelenteni a szerverekre nézve, amikor a KDE 4 kijön és néhány millió felhasználó elkezdi használni ezt a tulajdonságot. Jelenleg is beszélgetünk arról, hogy oldjuk meg ezt a problémát.

A 0.4 fejlesztése közben a KDE-n kívülről kaptunk segítséget. Ez vezetett a MaxOS X és a Windows támogatásához.

Még ezzel a szép hosszú „új képességek” listával sem mondhatjuk el, hogy a legtöbb friss fejlesztés bekerült volna a Marble ezen kiadásába. A Summer of Code projekt tanulóiról beszélek most. Tulajdonképpen már készen vannak, de fejlesztéseik nem kerültek be a 0.4-be. A Marble-nek három tanulója van, így a következő hét a következő projektek beépítést fogja jelenteni: sík vetület, GPS támogatás, és a Google Earth KML fájljainak támogatása.

Andrew Manson, a GPS programozó írta:
„A GPS GSoC projekt arra volt hivatott, hogy beépítse a GPS eszköztámogatást és a GPX fájl olvasását és írását. A GPX fájlok olyan fontos adatokat tartalmaznak, mint:

  • sávnyom (trackpoint), amiket általában a GPS eszköz hoz létre, hogy kövesse hol voltál eddig
  • útnyom (waypoint); ezeket a felhasználó maga adja meg
  • útvonalak, amik egy sor útnyomot tartalmaznak

Marble-be beépített GPS videó letöltése (8,1 MB, MPEG)

A GPX fájl nézet egy nagyon egyszerű felület a megnyitott GPX fájlokkal való foglalkozásra, és az engedélyezéséhez a Marble-t az --enableFileView paranccsal kell indítani. A GPS követést a gpsd projekt szolgáltatja, és úgy lehet elérni, ha a Marble-t egy olyan Linux rendszeren fordítják le, ahol van libgps (a gpsd telepítésével elérhető lesz) és a Marble-t az --enableCurrentLocation paranccsal futtatják.”

Ezen képességek legtöbbje természetesen engedélyezve lesz alapból, amint a projekt teljesen integrálásra kerül.

A második projektet, a sík vetület támogatását Carlos Licea készítette.

Sík (2D) vetületű Marble videó letöltése (2,6 MB, MPEG)

Carlos írta:

„A sík vetület nagyon jól fejlődött, bár nem olyan gyorsan, de most már eljutott egy olyan pontra, ahol már egészen használható. Majdnem mindennel végeztünk, amivel a gömbölyű kivetítés rendelkezik: textúrák, helyjelölők, vektorok, távolság mérések.

Ahogyan lenni szokott, néhány feladat elég könnyű volt, amíg a másik ugyanolyan nehéz, megint másikak 90%-át egy ültében meg lehetett írni, míg a maradék 10% keményebb vagy valahogy összetettebb volt, így el kellett gondolkoznom rajta.

Csak hogy egy kis példát mutassak: elgondolkodtál azon valaha is, hogy Ázsia hogyan keresztezi a dátumválasztó vonalat úgy, hogy a kontinens nagy része a Föld egy részén van, míg a maradék a többin? Nos, én azelőtt nem, de most egy kis voodoo mágiát és trükköket kellett alkalmaznom, hogy az a kis falat föld a térkép másik felén helyesen jelenjen meg (a kíváncsiaknak: el kellett különítenem a poligonokat).

Összegezve van néhány dolog, amit meg kell oldanom, mielőtt ez a vetület használható lesz, de hé, a Marble csapat nagyon gyors, szóval nem kell sok idő, hogy kipróbálhasd a »sík vetületet« a »gömbölyű kivetítés« helyett.”

Végül a fehérorosz Murad Tagirov megoldotta a szabvány KML (Keyhole Markup Language) formátum használhatóságát; ezt többek között a Google Maps is használja.

Nem tudtuk őt elérni, hogy mondjon pár szót, de az ő projektje is beépítés alatt áll, egyelőre kevés gonddal.

Az interjú Carlos Liceával, aki a Marble sík vetületén dolgozik, itt olvasható.

Amint olvashattad múlt héten, a Kalzium szerzője, Carsten Niehaus egy tucat funkciót távolított el, amik már benne voltak a KDE 3-as változatban. Az ok az, hogy Carstennek nincs elég ideje a programra, hogy az összes maradék hibát javítsa.

Ez egyfajta felhívás is, hogy segíts a Kalzium karbantartásában. Ha érdekel a program fejlesztése, és portolnál néhány maradék képességet vagy újakat adnál hozzá, írj a Kalzium levelező listájára. Köszönet érte.

Statisztikák:

Beküldések: 2547 db történt 234 fejlesztőtől, 6323 sor módosításával és 1198 új fájl hozzáadásával.
Nyitott hibák: 14204
Nyitott kérések: 12945
Megnyitott hibák: 160 az utóbbi 7 napban.
Bezárt hibák: 122 az elmúlt 7 napban.

Beküldési statisztikák:
/trunk/KDE 1064
/trunk/l10n-kde4 390
/trunk/koffice 208
/trunk/playground 186
/branches/work 160
/branches/stable 88
/trunk/extragear 77
/trunk/www 76
/branches/extragear 72
/trunk/kdesupport 67

Nyelvi statisztikák:
Svéd: 100.00%
Portugál: 99.96%
Spanyol: 93.88%
...
Magyar: 37.89% (egy héttel ezelőtt: 37.79%)

További információk és rengeteg statisztika megtekinthető az e heti KDE Commit Digest weblapján.

Hozzászólások

Jó volt olvasni, van egy csomó érdekesség.

De vajon mindenképp muszáj lefordítani az angol kifejezéseket magyarra?
Olyasmire gondolok, mint mondjuk a vezetők, meg a proof of concept (ami egyébként nem is azt jelenti, hogy bizonyított elképzelés, hanem inkább az elképzelés bizonyítása... De míg angolul egyértelmű, magyarul nem is tudom, mi lenne jó körülírása. Talán az elképzelés bizonyítására (bemutatására) született példa?), meg hasonlók.

Én a WinCE eszközök szinkronizálását várom már nagyon. Valamikor régen azt olvastam, hogy a KDE4-ben teljesen újraalkotott szinkronizálás lesz majd, és állítólag ez majd működik is.
Nagyon kéne :-)

G

Megnéztem. A leírás szerint ez mobiltelefonokhoz való cucc.

Én meg WinCE konnektorral PocketPC-t (palmtopot) próbálnék szinkronizálni.
Vannak ilyenek, hogy raki (synce-kde), meg kitchensiync, meg volt valami harmadik, az talán nem KDE-s, nem emlékszem.

A háromból kettő semmit nem csinált, (azt hiszem, a nem KDE-s működött, csak a KDEPIM adatbázisokról fogalma nem volt) a raki azt, amit a windows kb. 1 perc alatt leszinkronizált, azt leszinkronizálta kb. 45 perc alatt, és amikor elért a 100%-hoz, akkor crash. Crash után mintha a szinkronizálás nem is történt volna, adatok nem kerültek át egyikről a másikra.

Amikor utánaolvastam, akkor egy teljesen újraírt szinkronizációs keretrendszert igértek KDE4-re.

G

És mit használtál, melyik programot?

Átment a Kontact-ból a todo lista, a naptár, és az addressbook?

Egyébként amikor feladtam, ezt a cikket találtam, és most erre várok, mint a messiásra: http://dot.kde.org/1131568739/

Ami nem működött, azt bejelentettem, de a hibakövető rendszerekben még bottal se piszkálták meg a hibajegyeket. :-(

G

Mindig élvezettel olvasom eme beszámolókat. Sok infó, lelkiismeretesen összeállított anyagok.

Köszönet érte, csak így tovább!

--
[Random Topical Haiku] (Slashdot.org) I've Got A Cool Site. What The Fuck? So Much Traffic! Now My Server's Down

király összefoglalók, csak így tovább.

Nagyoj szép munka ez a tájékoztató. Köszönöm szépen.
PS: A miért így vagy úgy fordítottad megjegyzések szerintem csak stílus és szokás kérdése, ne adj rá túl sokat! Az érthetőség a lnyeg, az meg tiszta és érthető.

Köszönjük a beszámolót! Csak így tovább! :)

Mar csak egy dizajnert kell keresniuk.

---
pontscho / fresh!mindworkz