JavaFX Eclipse kipróba

Kitaláltam hogy beleszagolok a JavaFX-be.

javafx.com a hivatalos kiindulóoldal ahol vannak csilivili demók, de engem a rögvalóság érdekel, úgyhogy utánanézek mit kell letölteni ahhoz hogy én is tudjak ilyen szépségeket programozni. Ezt az oldalt találom, ami azt mondja van SDK, Eclipse plugin és a downloads-okra visz. A Netbeans is támogatja, de nekem most nem az van kéznél.

JavaFX Installálás: Kicsit le voltam már maradva a java verzióval is. Mondja hogy JDK6u13+ kell. Letölti, installálja 5 percig. Felhoz SUN regisztrációs oldalt, de nem kell tölteni. JavaFX install gyorsabb. Alapból Program Files-be akarja installálni (ja mert Windowson vagyok), de átállítom. Nem történtek nagy dolgok szerencsére, megjelent a Start menüben, plusz az install helyen. bin könyvtár, ilyesmik.

Eclipse plugin:
update site: http://javafx.com/downloads/eclipse-plugin/
Verzió: 1.2.0.20090528....
Az ajánlott 3.4.2 ganymede-re installálom néhány másik plugin mellé, mint pl. m2, SVN, WTP, Findbugs.

Sikerül az install. Új projekteknél megjelenik a JavaFX projekt. Néhány prototípusból tudok választani. Fotónézegető, 3D-s polc megjelenítő. A Spring (pattog két labda) példát választom - fordul, működik. Ha az lenne a célom, játszhatnák vele hogy változtatgatom itt ott a kódot, de most nem ez a célom. Lehet új külön JavaFX fájlot létrehozni, megjelenik a JavaFX perspektíva és egy külön Run opció a futtatáshoz.

Viszont nem túl komoly a támogatás.

Jobboldalt van egy Drag and Drop-os komponenskészlet kevés komponenssel, de grafikai szerkesztés nincs, csak bedobja a kódrészt ész nélkül oda ahova viszem az egérrel, akkor is ha szintaktikai hibát eredményez. A context assist működött egy darabig, de rövid használat után elromlott, azóta csak ClassCastException-t hoz fel az IDE újraindítása után is. A javafxdoc hover működik, de nekem nem tetszik a formátuma. Túl nagy betűk, ha böngészőben nézem szerencsétlen az elrendezése. Folyton scrollozni kell le-fel, le-fel, le-fel.

Egy egyszerű Swing-es GUI-t akarok átültetni próbaképpen JavaFX-re, ismerkednék a layout-okkal. Alapkövetelmény lenne, hogy az ablak tartalma némileg intelligensen kövesse az átméretezést. Ez Swing-ben igen egyszerű a BorderLayout vagy a GridBagLayout segítségével. Negatív meglepetés: nagyon gyér a layout támogatás. Ráadásul régebbi verziókhoz képest sokmindent visszavettek. Pl. nem lehet GridBagPanel-ozni. Ráadásul a túl sok változtatás miatt, a net tele van használhatatlan példákkal.

Találok egy ígéretes layout menedzsert, DigLayout néven. Letöltöm a jar-t, hozzáadom a projekthez, de nem reagál rá, nem találja meg az osztályt hiába importálom. No ez már azért kicsit durva, úgyhogy be is rekesztem a kísérletezést.

A nyelv maga az oké. A szintakszis kicsit a JSON-ra hajaz bár semmi köze hozzá. Tetszik a deklaratív megközelítés, és látom hogy sok szépet és jót lehet csinálni vele -és bízom benne hogy egyszer majd fogok is- , de egyelőre a 2-3 órás ízlelgetés után, ebben a formában "nem vettem meg".

Swing GUI trükkök

Éppen Swing-gel tolom. Íme néhány szépség, csak hogy látható legyen, hogy nemcsak a webes GUI készítésnek vannak meg a szépségei.

-A JFileChooser nagyon lassú Java 1.6_02-vel és 1.6_03-mal Windows-on, ha a megnyitott könyvtárban nagy zip fájlok vannak. Van róla bug report is. Több percig is eltarthat, mire megjelenik a dialógus ablak. Addig a hívás blokkolva van. 1.6_01-gyel nem lassú és ahogy nézem az 1.6_04 release notes-jában szerepel hogy javították.

-Swing komponens konstruktorába továbbra sem érdemes bepakolni a setVisible(true) hívást. Főleg modális dialógus konstruktorába, mert akkor a konstruktor hívása után már nem lehet semmit hozzádrótozni, mivel a setVisible(true); utáni kódrész csak a dialógus lezárása után hívódik meg. Modális dialógust átírni nem modálisra (és visszafelé) eléggé termékeny a hibalehetőségek szempontjából. Különben sem jó ötlet túl sok mindent bepakolni a konstruktorba, ez általános szabály két dolog miatt: 1. Biztos nem lenne hasznos valahol máshol a konstruktorba került inline funkcionalitás egy külön függvényként? 2. Öröklésnél a szuperosztály konstruktorának hívásánál még nincsenek beállítva a leszármazott osztályok mezői. Emiatt konstruktorban nem szerencsés a leszármazott osztályban (felül)definiált metódust hívni, főleg ha az a leszármazott osztály mezőit is használja.

-A JScrollPane-be ágyazott JPanel-eknek van egy rettentően kényelmetlen tulajdonságuk, mégpedig hogy amikor az egérrel görgetjük a külső scrollpane-t és ráfut az egér egy belső panelre, a görgetés hirtelen abbamarad. Erre lehet leleményes workaround-okat csinálni, kérdés hogy melyik Look and Feel-en hogyan működik.

-Look and Feel-eket cserélgetni programfutás közben -bár csábító a lehetőség- nem igazán ajánlatos. Nem mindig sikerül minden úgy ahogy kéne. Nálam néha beragadtak komponensek, azaz a GUI nagy része lecserélődött, de egy-két gomb megmaradt a jól megszokott metál stílusban. Különben -ahogy a JavaPosse-ben megmondták, a Swing Look and Feel-ek kicserélhetősége csak egy elméleti dolog, mert nem skin-ekről, hanem komponensekről van szó. Ha egyik készletben egy komponens így működik másikban meg úgy, az zavart okozhat. Említettek valami okosságot a témában, majd utánanézek. Egyelőre nem találtam meg, csak egy oldalt, ahonnan sokféle L&F letölthető. (JavaPosse 103)

-A JLabel és JButton kényelmetlen tulajdonsága, hogy többsoros szöveget csak HTML tag-ek segítségével tud megjeleníteni. Ez nem is lenne baj, viszont ilyen többsoros szövegnél már nem működik a setEnabled(false). Ajánlanak különféle megoldásokat, de egyik sem nagyon elegáns. Az alapprobléma az, hogy nem mindig elég egyszerűen kiszürkíteni a feliratot, mert némelyik look and feel-ben a bevésett halvány szöveg jelenti a letiltott label-t. Próbáltam azt is, hogy egy JEditorPane-t konfiguráltam úgy, hogy labelnek nézzen ki, de az meg a fókuszt kavarta el az oldalon és ezt nem is tudtam kiküszöbölni a setFocusable-vel és társaival. Végül úgy csináltam meg, hogy HTML-es labelt használtam, aminek setEnabled(false)-nál mondtam egy szürke színt és kész.

-A Swing komponensekhez a setClientProperty()-vel objektumokat lehet rendelni, amit aztán a getClientProperty()-vel vissza lehet olvasni.

-A Swing eseménykezelését továbbra is érdemes tanulmányozni. Legrosszabb megoldás ha egyáltalán nem foglalkozunk vele (eseménykezelőben, pl. actionPerformed semmi új szál, hanem csak az akciókód - ilyenkor hosszabb műveleteknél a GUI úgy néz ki mintha lefagyna), közepesen rossz megoldás ha mindig külön szálat indítunk az eseménykezelőkben. Jó megoldás az invokeAndWait és az invokeLater használata.

-A fest-tel nagyon jól lehet Swing-es GUI-kat tesztelni. Töltögeti a szövegmezőket, nyomogatja a gombokat szorgalmasan ahogy beprogramoztuk, csak legyen beállítva a Swing komponensek neve és legyen úgy görgetve a scrollbar, hogy látszódjon az ablakban amire klikkelni kell. Egyszerre egy klienst lehet tesztelni és jól lefogja az egész desktopot, úgyhogy ilyen jellegű tesztelésnél érdemes újságot, könyvet vagy másik számítógépet kéznél tartani, vagy elmenni kávézni.

-Ezt is beraktam a csőbe, majd valamikor elolvasom: WebCream 6.0 Swing alkalmazásokból AJAX-os webalkalmazásokat csináló medzsik (lásd még: Javaposse 137).

Amíg az embernek nincsenek túl nagy extra igényei egész jól el lehet lenni Swingben. Azonkívül ez még mindig igazán szórakoztató ahhoz képest, mint amikor JSF-ben (GWT-ben, Tapestry-ben vagy akármilyen webes GUI keretrendszerben) kell percenként aknákat kerülgetni.