jshot.info

A JShot weblapja ezentul a http://jshot.info cimen erheto el. Felraktam par screencastot, shotot meg eztazt.

Swing, JShot etc

Egy picit el lett hanyagolva az utobbi idoben a blog de itt a nyar - meg amennyi maradt belole - ugyhogy igyekszek irni par postot.

Egy korabbi bejegyezesben mar irtam egy JShot nevezetu ScreenCapture utilityrol. Kicsit felelevenitve ez egy javas screenshot keszito es uploader utility amivel az elkeszitett screenshotot feltolthetjuk az elore beallitott helyre. Tobbfele feltolto plugin van hozza. Pl ftp, http (ami a kepfeltoltes.hu-ra tolti), skype file sender. Az elobbi ketto feltoltes utan megjeleniti es a vagolapra masolja az urlt is. Az egesznek annyi a lenyege hogy ha meg akarjuk mutatni a kepernyo egy reszet vkinek akkor upload es mar pastelhetjuk a linket.

A proginak elkeszult az elso publikus teszt verzioja. Letoltheto egyelore innen.

Feature lista:

• Teljes kepernyo, desktop, aktiv window, taskbar capture. (az utobbi 3 csak jni-vel win alatt)
• Area capture user alatal kivalasztott terulet
• Editalasi es rajzolasi funkciok (alakzatok, szabadkezi, szoveg, copy/cut/paste, radir, floodfill, effektek, rotate, flip, crop, merge, stb)
• Uploader pluginok: ftp/http/skype mindegyikhez kulon profileok hozhatok letre
• Alakzatok tulajdonsagainak allitasa
• Feltoltesek egylepesben systemtrayrol
• Undo/Redo

Ami remlehetoleg meg jon:

• Vmi IPC a tray app es a futo app kozott, az azonos peldanyban valo kep megnyitashoz pl.
• Hotkeyek (keyboard hook jni-vel, nem igerem hogy minden platformra de winre biztos)

Irnek par szot a fejlesztes soran szerzett tapasztalatokrol. A java igazabol nem olyan eros a desktop vonalon ezzel gondolom nem mondtam ujat. Viszont imho meg igyis nagyobb produktivitas erheto el vele mint pl cpp+egy nativ guitoolkit-tel, pusztan a managed kodbol szarmazo elonyok miatt. Az elonyok es hatranyok targyalasanal viszont nem art kulonvalasztani hogy mi az ami a fejlesztesi szempontbol jo vagy rossz illetve a felhasznalonak jo vagy rossz.

User szemszogebol a a swinges alkalmazas csunya es lassu. Legalabbis sokan mondjak. Plusz azontul hogy csunya nagyon elut a kinezete a operendszeren futo nativ alkalmazasoktol. Ez utobbi imho hulyeseg. Vannak eleg latvanyos Look and feel-el is (pl liquid). Az hogy mashogy nez ki mint egy nativ alkalmazas meg nem feltetlen hatrany, sot teljesen szokvanyos. Rengeteg alkalamzas van ami nagy szamban hasznal sajat renderelesu komponenseket, es a userek is szeretik cserelgeni a skineket ha van ra lehetoseguk. Eleg megnezni az official msn klienst win alatt, kb semmi nem emlekeztet belole win32-es widgetekre. Ez a bongeszokre ugyanugy igaz. Az operanal se a Windos Native az alapertelemzett skin hanem valami egeszen csicsas kinezet van defaultbol beallitva. Nem beszelve arrol hogy sokan hasznalnak crossplatformos (pl gtk-s xchat, gimp) programokat, amiknek ugyanugy elut a kinezete az alap widgetektol mint egy swinges progie. Tehat egyaltalan nem lenne problema ez, csak sajnos az alapertelmezett Metal/Ocean laf tenyleg nem olyan tetszetos.

Ami a lassusagot illeti a startup tenyleg lehetne joval gyorsabb, de ez az ami csak bizonyos alkalmazasoknal fontos. Vannak olyan programok ahol a user elvarja hogy kattintasra azonnal bejojjon. Egy lightweight editor vagy kepnezegeto pl ilyen. Egy screencapture utilitinel is ez az elvaras. Ennek en ugy probaltam megfelelni hogy kulon valasztottam a main appot, es egy a systemtrayen futo kis alkalmazast. Ez memoria hasznalat szemontjabol is kevezobb. Amikor a user ki akarja valasztni a kepernyo egy reszet akkor duplakattint a systrayes ikonra vagy menubol kivalasztja az area capturet. Ekkor bejon egy awt-s ablak rajta egy canvassal ami kirajzolja screenshotot. Azert awt-s mert ezt lehet fullscreenre rakni es eleg gyors ahhoz
hogy azonnal bejojjon. Igy az egesznek olyan hatasa van kb mintha a kepernyon jelone ki a felhasznalo kepreszletet. A kep feltolteset vagy editalasat mar a main app vegzi el. Igy annak startuptimeja adodik hozza a feltoltesi idohoz, amihez kepest a startup mar elhanyagolhato.

Fejlesztesi szempontjabol swing szerintem egy jol felepitett osztalykonyvtar. A komponensek konnyen kiterjeszthtok. Ami elonye hogy ez tenyleg full platformfuggetlen, a komponensek ugyanugy viselkednek es ugyanugy neznek ki mindenhol. Ez a nativ crossplatform guitoolkitekrol altalban nem mondhato el. Viszont alapbol nagyon keves komponens van. Szerintem mar delphi 1.0-ba is tobb volt. Amig ott egy 10 tabos lapozhato widgetre voltak kipakolva, addig az osszes swinges kompi elfer egyetlen JPanelen. Nincs pl calendar, statusbar, datetimepicker. Valamint viszonylag alap dolgokhoz is sokat kell kodolni.

Nem igazan ismerek jol hasznalhato rad gui buildert hozza. Bar a matisse kisebb nagyobb hibai ellenere jol hasznalhato dialogok es static formok megtervezesere.

Ami meg feltunt hogy van par idegesito memoria felszabaditasi hiba ami mar igen regota megvan es sajnos nem nagyon akarjak javitani. Ez abbol adodik hogy a swingben jopar helyen van olyan static referencia ami a sajat komponenseinkre mutathat. A gc az ilyeneket nem fogja tudni felszabaditani, se azokat amikre ez a widget hivatkozik. Megoldas az hogy disposekor kezzel leszedjuk az osszes komponenst rola plusz kulso objectre mutato fieldek nullozzuk. Igy csak az ures widget marad bent a memoriaban a rajta levo stuffok legalabb mar nem. Vagy valami dummy komponenst letrehozunk hogy kiusse a static referencet. Ez nalam jelentkezett a drag and drop-nal hasznalt TransferHandler-ben ahol a SwingDragGestureRecognizer static valtozo hivatkozott a komponemsemre. Persze a kovetkezo muveletkor ezt felulirja egy uj referenciaval, de valami mindig maradni fog benne. JInternalFramnel szinten van memoria felszabaditasi problema. Ha letrehozunk egy framet majd disposeoljuk, nem fogja tudni felszabaditani csak ha csinalunk egy kovetkezot is. A legutolso viszont mindig bent fog maradni a memoriaban. Ami megrosszabb hogy nem csak JInternalFrame-re hanem sima JFram-re is mukodik.

Szoval osszessegeben lenne meg hova fejlodnie a dolognak. De biztos vagyok benne hogy ha SWT-ben vagy .NET-ben csinaltam volna akkor is lenne ehhez hasonlo szivas lista csak mas jellegu problemakkal. Az ember mindig azt szidja amivel eppen dolgozik :)

De attol meg a JShot mukodik - mar amennyira egy developer a sajat alkalmazasat teszteni tudja - minden eszrevetelt szivesen fogadok.