Eclipse és az OSX

Az elmúlt időszakban egy kicsit összejöttek a Java-fejlesztéssel kapcsolódó dolgaim. A keretrendszer, amibe éppen fejlesztek, nemrég esett át egy elég durva refactoringon (hogy Eclipse-projekt révén a csomagnevek megfeleljenek az Eclipse elnevezési konvencióinak), és akkor közben megtették még azt is, hogy a legfrissebb változat már csak 6-os Javaval fut.

Ezzel önmagában nem is lenne baj, hiszen ez egy research projekt, nem érdemes régi technológia felett fejleszteni. Szerencsére az Apple nemrég kiadta a Java környezetének hatos változatát (igen, az Apple, és igen, csak most), annak idején már telepítettem is, de valahogy használatba nem került még. Sebaj, az Eclipse futása közben is lehet Java-t váltani. Szal beteszem az új verziót a futtatási konfigurációba, és a puskaport szárazon tartva reménykedek.

Az elmúlt időszakban egy kicsit összejöttek a Java-fejlesztéssel kapcsolódó dolgaim. A keretrendszer, amibe éppen fejlesztek, nemrég esett át egy elég durva refactoringon (hogy Eclipse-projekt révén a csomagnevek megfeleljenek az Eclipse elnevezési konvencióinak), és akkor közben megtették még azt is, hogy a legfrissebb változat már csak 6-os Javaval fut.

Ezzel önmagában nem is lenne baj, hiszen ez egy research projekt, nem érdemes régi technológia felett fejleszteni. Szerencsére az Apple nemrég kiadta a Java környezetének hatos változatát (igen, az Apple, és igen, csak most), annak idején már telepítettem is, de valahogy használatba nem került még. Sebaj, az Eclipse futása közben is lehet Java-t váltani. Szal beteszem az új verziót a futtatási konfigurációba, és a puskaport szárazon tartva reménykedek.

Nincs szerencsém: brutális bundle not found kivételeket kaptam, és a hiányzó bundle-ök az eclipse alap moduljai voltak. Kicsit utánaolvasgatva a témákat kiderült, hogy az a gond, hogy az Apple Java 6 megoldása csak Intel-alapú gépen fut, és ott is csak 64 biten. Pontosabban nem is ez a probléma, hanem az, hogy az SWT a Carbon GUI könyvtárat használva jeleníti meg az Eclipse GUI-t. És az Apple döntésének megfelelően a Carbon nincs meg 64 biten, csak 32-n. Azaz ebből az irányból per pillanat nincs győzelem. Fényt mindössze annyi jelent az alagút végén, hogy az SWT-sek megkezdték a Cocoa portot, és az Adobe is biztosított erre a célra egy mérnököt (az Eclipse-technológiára alapozva fejlesztőkörnyezetet akarnak építeni az ismereteim szerint). A Cocoa-port jelenlegi állása szerint csak 32 bites APIt használ a rendszer, de remélhetőleg ez hamarosan változni fog. Talán a 3.5-re meglesz.

De addig is kellene egy megoldás, mert dolgoznom kéne. Egyik ötlet, ami segíthetne, az az Eclipse on Swing projekt lehetne. A céljuk az, hogy az SWT platformfüggő hívásait Swing-alapúra cseréli. Nagyon szép, csak sajnos még az SWT 3.2-es változatánál vannak lemaradva, ami nekem nem felel meg, ugyanis a keretrendszer legalább a 3.3-as Eclipse-et igényli, ugyancsak ez a helyzet a Subversive SVN pluginnel is. Azért kipróbáltam, nem indul be vele az Eclipse Ganymede…

Másik megoldás egy másik JVM lenne, ami nem igényli a 64 bitet. Van is egy ilyen, ami a találó Soylatte névre hallgat. Feltelepítem, beállítom Eclipse JVM-nek. De ekkor kiderül, hogy itt meg az a gond, hogy X11-et használna grafikus felületként, ahogyan meg nem lehet behívni az SWT számára a Carbont…

A helyzet siralmas… Háromféle, egymástól drasztikusan eltérő megoldást kipróbálva jutottam el oda, hogy per pillanat Eclipse pluginfejlesztést nem lehet OSX-en Java 6-on végezni. Siralmas, hogy ezért kénytelen vagyok egy virtuális gépen futó Windows-t használni. Majd figyelem a változásokat, és szükség szerint alátolok valamit a rendszernek. Addig is a remény hal meg utoljára – a sör meg először…

Programok összehangolása OSX alatt

Megvan már egy ideje, hogy Mac-et használok. A múltkor is, amikor ismét próbálkoztam a Windows-zal (lásd a cikket a Macre telepítéséről), már erőteljesen érzékelhető volt a különbség. Az, hogy a Mac működik, a Windows meg nem.

A helyzet még durvább, ha azt is figyelembe vesszük, hogy az Apple segített azoknak, akiknek egy egyszerű szolgáltatás hiányzik egy programból. Nekem például az iTunesszal volt egy-két problémám.

Több rendszer még több programját kipróbáltam korábban, és mivel az a szokásom, hogy szinte állandóan zenét hallgatok, szeretem időnként megnézni, hogy áll a zenelejátszás. Ugyanakkor az ellen sincs kifogásom, ha ehhez nem kell túl sokat kattintgatnom, stb.

Megvan már egy ideje, hogy Mac-et használok. A múltkor is, amikor ismét próbálkoztam a Windows-zal (lásd a cikket a Macre telepítéséről), már erőteljesen érzékelhető volt a különbség. Az, hogy a Mac működik, a Windows meg nem.

A helyzet még durvább, ha azt is figyelembe vesszük, hogy az Apple segített azoknak, akiknek egy egyszerű szolgáltatás hiányzik egy programból. Nekem például az iTunesszal volt egy-két problémám.

Több rendszer még több programját kipróbáltam korábban, és mivel az a szokásom, hogy szinte állandóan zenét hallgatok, szeretem időnként megnézni, hogy áll a zenelejátszás. Ugyanakkor az ellen sincs kifogásom, ha ehhez nem kell túl sokat kattintgatnom, stb.

Windows-on a Winampnál, Linuxon az Amaroknál elég volt a kis ikonjára ráhúzni az egeret, és rögtön kaptam egy feliratot arról, hogy mit játszik éppen, esetleg még arról is kaptam információt, hogy mennyi ideig játssza még az aktuális számot. Nem is beszélve arról, hogy mindkét program képes rá, hogy számváltáskor dobjon egy üzenetet, és ez rövid ideig jelenjen meg, majd automatikusan tűnjön el.

Na, az iTunes ezekre önmagában nem képes. Nincs egységes notification interfész az OSX-be integrálva, más kérdés, hogy helyette van a kvázi-szabványos, nyílt forrású notification-program, a Growl. Amennyire látom, egyre több OSX-es alkalmazásfejlesztő foglalkozik azzal, hogy Growl értesítéseket használjon, köztük kereskedelmi termékek is. Nem lepődnék meg, ha idővel az Apple saját szoftverei is elkezdenék használni.

De addig is, amíg ez nem következik be, a Growl fejlesztői elkészítettéka saját Growl-pluginjeiket a legtöbb alkalmazáshoz: az iChathez, az iTuneshoz és több máshoz is. Az iTunes-plugin pontosan arra képes, hogy üzenjen, ha új szám kezdődik.

Ezzel félig megvagyunk, a másik problémára csak trükkösebb megoldás képzelhető el. Ugyanis ezt még nem igazán csinálták meg korábban. De azért egy magamfajta kockafejnek ez azért nem jelentett igazi kihívást – pláne, hogy a megoldás nagyjából már megvolt a weben is. Sajnos egy jó ideje, hogy megtaláltam, akkor is nehezen, így nem tudom megmondani a forrását a megoldásnak, de ha megtalálom, utólag is be fogom illeszteni. Addig is névtelenül tisztelem meg azzal, hogy felhívom a közönség figyelmét, hogy a megoldás elve nem az enyém.

Tehát, a megoldás lényege az volt, hogy írni kell egy Applescript scriptet (szóismétlés ruley 🙂 ), ami értesíti a Growlt az aktuális szám adatairól, majd ehhez be kell állítani egy gyorsbillentyűt globális triggerként.

A globális trigger relatíve egyszerű eset volt nekem, aki már korábban úgyis használt Quicksilvert. A Quicksilver egy productivity app OSX-re (bár valahol olvastam, hogy már van Windows-os változata is), ami többek között alkalmazásgyorsindító (OSX-en szükség is van rá, ugyanis a Dock-on korlátozott számú ikon fér el, az Applications foldert megnyitni, és abban keresni körülményes, a Spotlight kereső pedig erre a célra lassú), és mellesleg egyéb lehetőségeket is kínál, például gyors levélírás a címjegyzék és a levezelőprogram felhasználásával vagy, amit most ki fogok használni, gyorsbillentyű hozzárendelése szinte bármihez (többek között Applescriptekhez is). A program egyébként tartalmaz iTunes modult is, amivel mellesleg az iTunes vezérlése is könnyedén megoldható.

Az Applescript pedig egy nagyon egyszerű, magas szintű nyelv, majdhogynem angol szöveget kell leírni csak ahhoz, hogy a kívánt funkcionalitást elérjem. Például az iTunes alkalmazás megcímzése a következőképpen történik: tell application "iTunes".

Ezután szerepelt mintakód is, de nekem nem tetszett az eredmény, ugyanis az eredeti Growl-pluginhez hasonló megjelenítést ért el, míg én Last.fm felhasználóként kicsit másfajtát vártam. Ezután kis testreszabás következett, meg persze Applescript dokumentáció böngészés (igen, ilyen is van és használható) után a következő végső kódot produkáltam (megosztom, mondván talán másnak is hasznos lesz.

tell application “System Events” to
if (application processes whose name is “iTunes”) is not {} then
log
tell application “iTunes”
if player state is playing then
set trk to current track
set trk_arts to the artist of trk
set trk_name to the name of trk
set trk_albm to the album of trk
set trk_dur to the time of trk
–Artwork
if (count of artwork of trk) ≥ 1 then
set trk_artwk to data of artwork 1 of trk
tell application “GrowlHelperApp”
set the allNotificationsList to ¬
{“Show Status”}
set the enabledNotificationsList to ¬
{“Show Status”}
(register as application ¬
“iTunesScript” all notifications allNotificationsList ¬
default notifications enabledNotificationsList ¬
) notify with name “Show Status” title trk_name description trk_arts & “
” & trk_albm & “
” & trk_dur application name “iTunesScript” pictImage trk_artwk
end tell
else
tell application “GrowlHelperApp”
set the allNotificationsList to ¬
{“Show Status”}
set the enabledNotificationsList to ¬
{“Show Status”}
register as application ¬
“iTunesScript” all notifications allNotificationsList ¬
default notifications enabledNotificationsList ¬
icon of application “iTunes”
notify with name “Show Status” title trk_name description trk_arts & “
” & trk_albm & “
” & trk_dur application name “iTunesScript”
end tell

end if
end if
end tell
end if
Az OSX rendszer egy nagy előnye, hogy viszonylag sokféle library-t kifejlesztett az Apple, ezek után a programozók elkezdhetnek a hozzáadott értékekkel foglalkozni, mint amilyen az alkalmazások közötti kommunikáció. Ez a rendszeren látszik. Természetesen az én megoldásom, mivel nem a háttérben, hanem a felhasználó segítségével történik, nem a legelegánsabb megoldás, de ez nem von le semmit az értékéből. A módszer használható, pár óra alatt össze lehetett hozni a dolgot minta alapján, és ha az embernek extra igényei vannak, elég részletes dokumentáció, és ügyes Applescript-készítő program áll a rendelkezésére.

Végeredmény: egy újabb jól használható pont azok számára, akik szeretik a végletekig testre szabni a rendszerüket, de nem kívánnak túl mélyen belefolyni a részletekbe, forrásba (tudom, Linux alatt is el lehet érni frontend megoldásokkal ugyanezt a hatást, mielőtt valaki kötözködne, de sokkal több munkát igényel). Nem véletlen használnak egyre többen OSX-et desktop operációs rendszernek.