Hibrid CSS menü

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Tudom, mire gondoltok… „Biztosan szükség van még egy cikkre a CSS legördülõ menükrõl?” Hadd gyõzzelek meg titeket. Mi történne, ha lenne egy tiszta, jól struktúrált menünk, ami egyszerre hordozná magában a legördülõ menük dinamizmusát, egyszerû kódját de megszüntetné a fõ problémáit (nem is beszélve a szép megjelenésrõl)?

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Tudom, mire gondoltok… „Biztosan szükség van még egy cikkre a CSS legördülõ menükrõl?” Hadd gyõzzelek meg titeket. Mi történne, ha lenne egy tiszta, jól struktúrált menünk, ami egyszerre hordozná magában a legördülõ menük dinamizmusát, egyszerû kódját de megszüntetné a fõ problémáit (nem is beszélve a szép megjelenésrõl)?

A gondok a legördülõ menüvel:

  1. az almenük pontjai nem érhetõek el addig, amíg nem kezdjük el az egész menürendszert használni, és
  2. nem ad megfelelõ tájékozódási pontot a felhasználónak. Nehézkes lehet vele az oldalon belüli navigáció, mert mindig le kell gördíteni a menüt az oldalak váltásához.

Ez a technika egy bombabiztos megoldás a böngészõkkel való kompatibilitás és a hozzáférhetõség biztosítására még azon felhasználók számára is, akik régi böngészõt használnak, esetleg problémáik vannak a legördülõ menük használatával, akár mert nem tudja, akár mert nem találja kedvezõnek a legördülõ menük alkalmazásának elveit. Emellett sokkal pontosabb információt ad a hagyományos legördülõ menüknél az oldalon belüli pozícióról.

Figyelem! Ez a technika nem mûködik nagy elemszámú listákra, ahol a hagyományos legördülõ menük még jól használhatóak vagy összeomlanak a puszta tömegük alatt, a nézõponttól függõen.

Egy olyan hibrid menüt fogunk készíteni, ami vízszintesen halad keresztül az ablakon. Két szintû navigációt használ (példánkban a fõ témák és a kapcsolódó oldalak). A menünkben legördülõ hozzáférést biztosítunk minden oldalnak mindkét navigációs szinten, valamint állandóan megjelenítjük a kiválasztott témához tartozó választási lehetõségeket, emlékeztetve a felhasználót, hogy az oldal melyik részén van. Emellett a kódja egyszerû és gyorsan mûködõ lesz.

Jól hangzik? Vágjunk bele.

Elõször is vegyünk egy listát

Készítsünk egy listát az építészeti korszakokról és az õ nagyobb alakjaikról. Egy ID-t kapcsolunk az <ul> elemhez és „off” illetve „on” class-t a menülista elemeihez (ami persze feltehetõleg nem a legjobb megoldás, de a cikk céljainak megfelel):

Formázzuk meg!

Ez egy jó hely az induláshoz. Egy egyszerû, szemantikus jelölés, ami könnyen karbantartható és egy helyen található. Úgy néz ki ahogy az elvárható.

Az elsõ dolog, amit a CSS felhasználásával el fogunk érni, az az, hogy az elsõ szintjét vízszintesen jelenítjük meg (a float tulajdonság felhasználásával) és elrejtjük az alsóbb szinteket. A linkeket pedig félkövéren, színezve és kerettel jelenítjük meg.


#nav li {
/*float the main list items*/
margin: 0;
float: left;
display: block;
padding-right: 15px;
}

#nav li.off ul, #nav li.on ul {
/*hide the subnavs*/
display: none;
}

#nav li a {
/*for all links in the list*/
color: #f90;
font-weight: bold;
display: block;
height: 15px;
width: 100px;
border: 1px solid #29497b;
padding: 5px;
}

Most helyezzük el a második listaszintet a fõ lista alá, hogy amikor újra megjelenik, amegfelelõ helyen legyen.


#nav li.off ul, #nav li.on ul {
/*put the subnavs below and hide them all*/
display: none;
position: absolute;
top: 33px;
height: 15px;
left: 0;
padding-top: 10px;
}

Végül jelenítsük meg az almenüt az aktív tématerülethez, ami a példánkban „Modern”. A legjobb megoldás erre, ha egyetlen központi, mindent lefedõ menüt használunk, egy osztály használata, mondjuk, a „Modern” elemen, és ennek megfelelõ kijelölõket használunk. Ebben a cikkben, ami egy másik oldalon belül lesz közzétéve, és önmagában is elégségesnek kell lennie, egy „on” osztályt adunk a kiválasztott témához és „off”-ot az inaktív témákhoz.


#nav li.on a {
/*change border color for active topic area*/
border: 1px solid #f90;
}

#nav li.on ul a, #nav li.off ul a {
/* cancel inherit of border
on subnav of active topic */
border: 0;
}

#nav li.on ul {
/*display active subnav list*/
display: block;
}

Még hozzáadunk néhány keretet, és így kapjuk az itt látható eredményt.

És akkor mindenki gördült, de egy kiesett…

Most pedig aktiváltjuk a legördülõt. Ez nem különbözik lényegesen a többi CSS legördülõ menütõl – a hover a li elemen jelenik meg, így az IE alatt nem fog mûködni a rosszul implementált :hover pszeudo-osztály miatt. Ezzel is mindjárt foglalkozunk. A következõ CSS eltünteti a kereteket a második listaszinten, a kiválasztott almenüt mindig megjeleníti, és beállítja az inaktív menük megjelenítését, ha az õsükre rámutatunk az egérrel. Beállítjuk a z-index tulajdonságot is annak érdekében, hogy az egérrel kiválasztott téma mindig elsõbbséget élvezzen az aktuális téma almenüjével szemben.


#nav li.on ul a, #nav li.off ul a {
float: left;
/*ie doesn't inherit the float*/
border: 0;
color: #f90;
width: auto;
margin-right: 15px;
}

#nav li.on ul {
/*display the current topic*/
display: block;
}

#nav li.off:hover ul {
/* display the other topics when
their parent is hovered */
display: block;
z-index: 6000;
}

We’ll make it a little more user-friendly, with a background on the hovered tabs.
Egy kicsit felhasználóbarátabbá is tesszük azzal, hogy hátteret váltunk a kijelölt(:hover) füleken.


#nav li.off a:hover, #nav li.off:hover a {
background: #29497b;
color: #f90;
}

Itt lehet megtekinteni, hol is tartunk.

Foglalkozzunk a „különleges” böngészõinkkel…

Két választás van azon böngészõk felé, mint az Internet Explorer, amik nem támogatják a :hover osztályt a <a> elemen kívül. Hagyhatjuk úgy, ahogy van, tudva, hogy mûködni fog néhány éven belül, amikor minden böngészõ támogatni fogja a :hover osztályt (lekopogom). Ugyanakkor nyugodtak lehetünk abban a tudatban, hogy minden navigációs elem látható és elérhetõ minden felhasználó számára. Esetleg megpróbálhatunk egy kis JavaScript kódot írni, ami megfelelõen átírja a CSS kijelölõket úgy, hogy az IE is megérti, ezáltal elérhetõvé téve a legördülõ menü dinamizmusát mindenki számára.

(A mûködés IE-ben úgy-ahogy értelmezhetõ) Kicsit igazítani kell az elhelyezésen a csillag-hack segítségével:


#nav li.off ul, #nav li.on ul {
/*put the subnav below*/
top: 33px;
*top: 44px; /*reposition for IE*/
}

Tehát a menü nagyszerûen mûködik a modern, szabványkövetõ böngészõkben, és korlátozottan, funkcionálisan mûködik megfelelõ elhelyezéssel az Internet Explorer 5 és 6 böngészõkben is. Egy kis segítséggel a legördülõ menüt az Internet Explorer 5-ös és 6-os verzióiban is mûködésre lehet bírni. Ehhez egy egyszerû JavaScipt kódot kell írni a kijelöléskor a kijelölõk módosítására, ez az IE 5.x és 6.x verziókon mûködik (Windows alatt). Köszönet a módszerért Patrick Griffiths-nek és Dan Webbnek, akik a „Suckerfish Legördülõ menükkel”elindítottak a CSS-alapú menürendszerek fejlesztése felé (az írás magyarul az oldalon olvasható [[Suckerfish menük]] címmel). Az õ JavaScript részletük a következõképpen néz ki:


startList = function() {
if (document.all && document.getElementById) {
navRoot = document.getElementById("nav");
for (i=0; i<navRoot.childNodes.length; i++) {
node = navRoot.childNodes[i];
if (node.nodeName=="LI") {
node.onmouseover=function() {
this.className+=" over";
}
node.onmouseout=function() {
this.className=this.className.replace
(" over", "");
}
}
}
}
}
window.onload=startList;

Még egy egyszerû módosítás szükséges a CSS-en:


#nav li.off:hover ul, #nav li.over ul {
display: block;
z-index: 6000;
}

#nav li.off a:hover,
#nav li:hover a,
#nav li.over a {
background: #29497b;
color: #f90;
}

ahhoz, hogy az „.over” osztály hozzáadása a lista elemekhez, amelyeket kijelölünk, mûködésre bírja a rendszert az IE/Win felhasználók számára. Nem mintha nem lenne érdemes egy új böngészõben gondolkodni, de egyelõre folytatjuk a tömegek kiszolgálását olyan módon, amit már õk is megszoktak.

Tehát ez lenne az. Egy inkrementális változtatás, talán, a korábbi CSS legördülõkhöz képest, de egy másik szemszög ahhoz, hogy felfedezzük azokat az eseteket, ahol tényleg hasznos a navigáció megjelenítése ahelyett, hogy elrejtenénk egy legördülõ menü belsejében.

És lehet szép isl?

Ok, hogy nem túl szép még. Nem tehetem meg, hogy egy sokkal szebb grafikával ellátott verziót mutatok ezzel a technikával a pedánsak kedvéért a való világnak. Néhány változtatással, a CSS sprite navigációs képekkel (köszönet Dave Sheanak, egy fénykép New York Citybõl, egy kicsit több CSS, és olyan menürendszert kapunk, ami megmutatja a CSS igazi erejét, ha grafikai tervezéssel kombináljuk. Kipróbálható a végleges Hibrid CSS legördülõ menü, tökéletesen mûködõképes az összes modern böngészõven.

A szerzőről

Eric Shepherd az alapítója az arkitrave web media-nak, egy kis, webbel és grafikával foglalkozó cégnek a new yorki Buffaloban. Éppen egy építészeti diplomát szerez (Master of Architecture degree) a a Buffaloi Egyetemen. Emelett még zongorista is. A munkája megjelent a CSS Zen Garden oldalon, és stratégiai partnere a Nepo Strategies-nek, egy buffaloi e-kereskedelmi és webes stratégiai cégnek. Már foglalkozik vele, hogy hogyan magyarázza el az XHTML, a CSS és Javascript DOMmal kombinált erejét a zseniális egyhónapos lányának, Naia-nak.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Google Calendar szinkronizálás naptárprogrammal

Az elmúlt időszakban a többiekkel gyakran kellett időpontokat egyeztetnünk különféle ügyek miatt, és felmerült az ötlet, hogy legyen a zárt használatú wikirendszerünk mellé naptárrendszerünk is.

Az első ötlet egy php script alkalmazása lett volna, ami képes megfelelően kezelni pl. az ics fájlokat. Találtunk is ehhez használható scriptet, de bugzott. Ehelyett végül is az egyszerűbb megoldás mellett döntöttünk, és elkezdtünk Google Calendart használni.

Ez egy szép és jó szolgáltatás, de valahogy (számomra legalábbis feltétlenül) kényelmetlen volt a használata, jobban örültem volna, ha az asztali levelező (és címjegyzék, stb.) kliensemhez szépen csatlakozó naptárprogramot használhatok.

Az elmúlt időszakban a többiekkel gyakran kellett időpontokat egyeztetnünk különféle ügyek miatt, és felmerült az ötlet, hogy legyen a zárt használatú wikirendszerünk mellé naptárrendszerünk is.

Az első ötlet egy php script alkalmazása lett volna, ami képes megfelelően kezelni pl. az ics fájlokat. Találtunk is ehhez használható scriptet, de bugzott. Ehelyett végül is az egyszerűbb megoldás mellett döntöttünk, és elkezdtünk Google Calendart használni.

Ez egy szép és jó szolgáltatás, de valahogy (számomra legalábbis feltétlenül) kényelmetlen volt a használata, jobban örültem volna, ha az asztali levelező (és címjegyzék, stb.) kliensemhez szépen csatlakozó naptárprogramot használhatok.

Ehhez a Google azt a segítséget nyújtja, hogy ad ics-linket a naptárhoz, amit be lehet tölteni a kliensprogramba. Ez mind nagyon szép és jó, de események felvétele kapcsán nem ad támogatást a kliensprogramokhoz (pedig erre is van tulajdonképpen szabványos megközelítés, a nyílt forrású szoftverek között is. A csak olvasható hozzáférés meg kényelmetlen…

De az is lehetséges, hogy ics-fájlt importáljon az ember az online naptárba. Igen, migrációt támogat, viszont azt, aki kliensprogrammal veszi igénybe a szolgáltatásokat, nem. Feltehetőleg azért, mert így nem nézik meg a Google reklámjait, esetleg nem kezdik el használni a további szolgáltatások
Hát, fogtam magamat, és beütöttem a Google-be a problémámat, és adott egy fizetős (15$/év) szoftvert, ami képes kétirányú szinkronizációra. Nem nevezem meg, pláne, mert nem is éri meg az árát, ha az ember hajlandó egy kicsit szórakozni a dologgal.

Egy későbbi keresésnél viszont találtam egy Javaban íródott (és tényleg crossplatform) scriptet, ami megoldja a gondot olyan kliensprogramokkal, amik ics-fájlba mentik (tudják menteni) a fájlokat – ilyen az Apple iCal programja OSX-en (naná, eredetileg ennek a formátuma volt a mostanra kváziszabvánnyá vált ics), a legtöbb Linuxos naptárprogram, Windowsra pedig meg lehet próbálni a Mozilla Sunbird programját – esetleg a Thunderbird-del egybecsomagolt változatát, a Lightninget (figyelem, ez még csak a 0.5-ös verziónál tart, azaz nem stabil változat!). Outlook (Express) felhasználók így jártak…

Ez a script a GCalDaemon, és teljesen használható a fent említett célra, és mellesleg néhány egyéb információt is ki tud nyerni a Google accountból. A telepítését nagyon részletes dokumentáció, és most már GUI is segíti, ezért ezzel nem foglalkozom.

Viszont a script működése megér pár szót még: a kiens gyakorlatilag HTTP-kérésekkel importáltatja a Google Calendarba a helyi gépen megváltozott fájlt, és a privát ICS URL-en keresztül lehúzza, ha ott megváltozott, ezzel téve lehetővé az egyszerű szinkronizációt. Igen, ezért szeretjük a nyílt protokollokat…

PHP debug Eclipse PDT-ben

Bevezetés

Gondolom, többekkel előfordult már, hogy volt egy olyan PHP-kódja, ami valami miatt nem az elvárható eredménnyel futott le. Ilyenkor nincs mit csinálni, lehet debuggolni. És ekkor szembesül az ember azzal, hogy az nem lesz olyan egyszerű…

A legegyszerűbb PHP-telepítésnél nincs debugger, azaz lépésenként nem lehet futtatni, töréspontokat elhelyezni, változók értékeit vizsgálni. Mármint automatikus módon. Amit lehet csinálni, az az, hogy megsaccolni, hol a hiba, és ezután a megfelelő helyeken a megfelelő változók értékeit kiíratni (akár echo, print_r vagy var_dump segítségével). Ha az adott helyen az elvárható érték adódik, akkor lehet továbblépni. A módszer működik, bár kissé favágás jellegű.

Persze nem én vagyok az első felhasználó, aki ezzel a problémával szembesül. A Zend cég kínál PHP IDE-t, a megfelelő áron. Itt csak az árral volt a probléma (a kalózkodással kíméljetek, valószínűleg én is szoftveres leszek, ezután illene, hogy én azért gondoskodjak a legális szoftverhasználatról a lehetőségeken belül).

Léteznek ingyenes megoldások is, de ezek többnyire a szolgáltatások terén hagynak kívánnivalót maguk után. De most végre sikerült találnom egy megoldást (több helyen kifejtve az interneten Setting up Eclipse PDT and XDebug Debugging PHP5 with Eclipse PDT under OSX: a piece of cake!), az Eclipse rendszer megfelelő beállítását.

Bevezetés

Gondolom, többekkel előfordult már, hogy volt egy olyan PHP-kódja, ami valami miatt nem az elvárható eredménnyel futott le. Ilyenkor nincs mit csinálni, lehet debuggolni. És ekkor szembesül az ember azzal, hogy az nem lesz olyan egyszerű…

A legegyszerűbb PHP-telepítésnél nincs debugger, azaz lépésenként nem lehet futtatni, töréspontokat elhelyezni, változók értékeit vizsgálni. Mármint automatikus módon. Amit lehet csinálni, az az, hogy megsaccolni, hol a hiba, és ezután a megfelelő helyeken a megfelelő változók értékeit kiíratni (akár echo, print_r vagy var_dump segítségével). Ha az adott helyen az elvárható érték adódik, akkor lehet továbblépni. A módszer működik, bár kissé favágás jellegű.

Persze nem én vagyok az első felhasználó, aki ezzel a problémával szembesül. A Zend cég kínál PHP IDE-t, a megfelelő áron. Itt csak az árral volt a probléma (a kalózkodással kíméljetek, valószínűleg én is szoftveres leszek, ezután illene, hogy én azért gondoskodjak a legális szoftverhasználatról a lehetőségeken belül).

Léteznek ingyenes megoldások is, de ezek többnyire a szolgáltatások terén hagynak kívánnivalót maguk után. De most végre sikerült találnom egy megoldást (több helyen kifejtve az interneten Setting up Eclipse PDT and XDebug Debugging PHP5 with Eclipse PDT under OSX: a piece of cake!), az Eclipse rendszer megfelelő beállítását.

Rövid összegzés

Azok kedvéért, akik vagy nagyon értenek hozzá, vagy csak bizonyos részek érdeklik őket, álljon itt egy rövid összefoglaló a lépésekről (a lépéseket természetesen nem feltétlen ebben a sorrendben kell végrehajtani, de érdemes pl. az Eclipse-et feltelepíteni, mielőtt össze akarod kapcsolni az XDebug-gal 🙂 ):

  • Alapvető PHP környezet beállítása
  • XDebug telepítése a PHP-hoz
  • Az Eclipse PDT projekt telepítése
  • Az Eclipse-hez XDebug plugin telepítése
  • Egyéb nyalánkságok

Feltételezések

Annak érdekében, hogy a cikk olvasható maradjon, és ne tegyen ki kisebb könyveket, bizonyos feltételezésekkel élek az olvasó ismereteire vonatkozóan:

Az alapvető PHP környezet telepítését nem részletezném. Ha gondot okoz, akkor nem javaslom a cikk további olvasását sem, ugyanis az Eclipse nem egy könnyen megtanulható, egyszerű eszköz, és a megfelelő beállítás szintén gondot okozhat. Esetleg ha feltétlen ragaszkodsz hozzá, léteznek olyan csomagok, amik egyben tartalmaznak Apache-ot, PHP-t és MySQL-t (pl. MAMP, WAMP, LAMP, stb.). A cikk további részében feltételezem továbbá, hogy a php.ini szerkesztése (megtalálása) nem okoz gondot.

Nincs módom/időm az összes elérhető rendszeren és verzióval tesztelni a környezetet, így csak korlátozott tapasztalatokat tudok megosztani. Az íráskor az Eclipse Core pluginek a jelenlegi legfrissebb, 3.3-as verzióval futnak, a PHP 5.2-es verziójú Apache (2.2.4) modulként futtatva. Az XDebug a 2-es verziónál tart (helyenként 0.2-esként hivatkoznak rá). A saját rendszerem Mac OSX 10.4 alapon fut, és erre a fent említett programok általam lettek lefordítva. A debugger ezen a rendszeren tökéletesen működött, gondot nem tapasztaltam.

PHP és XDebug

Az XDebug telepítése érdekesebb kérdés – szükség van egy lefordított modulra belőle – Windowsra és Linuxra van belőle a hivatalos XDebug oldalon, legalábbis bizonyos PHP verziókhoz, ha más platformon futtatod (mint én az OSX-szel), vagy nem megfelelő a PHP verzió, akkor lehet fordítani, vagy esetleg a Komodo IDE-jébe befordított változat is használható, amint az egyik OSX-es forrás is ajánlja. A fordítással kapcsolatban volt egy félmondatos megjegyzés, hogy azért nem azt követi, mert állítólag ahhoz a PHP-t (és azzal együtt az Apache-ot is) le kellene fordítania.

Erre én nagy bátran arra gondoltam, hogy mivel úgyis MacPorts-sal (korábban DarwinPorts) telepítettem fel a rendszert, és ezáltal lefordítottam, gondoltam, bátor leszek, és lefordítom inkább forrásból, minthogy egy harmadik gyártó programját kelljen használni, vagy hogy másik fizetős szoftvert telepítsek ezért a gépemre (pontosabban a demóját). Még egyszer: Linuxra és Windowsra van bináris változat is, azokat lehet használni, csak arra kell ügyelni, hogy a saját PHP verziónkhoz való változatot töltsük le.

Ha megvan a bináris változat, akkor jöhet a bűvészkedés a php.ini fájllal. A következő néhány sort kell beszúrni a fájlba: zend_extension=/xdebug/bináris/elérési/útja/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
. Ha ez megvan, akkor újraindítandó a szerver (feltéve, hogy a php apache modulként van telepítve). Ezután a phpinfo lekérésével (akár parancssorból a php -i -vel, akár pedig a phpinfo(); parancs meghívásával egy scriptfájlban) az elején, amikor a Zend Engine verzióját kiírja, meg kell, hogy jelenjen az XDebug verziója is. Esetleg a php -m paranccsal a modulok listájában is meg lehet keresni az XDebug modult (mind a modulok, mind a Zend modulok között szerepelnie kell). Az említett módszerek közül bármelyikre elegendő megvizsgálni, nincs szükség az összes vizsgálat végrehajtására. Ha megvan, örülhetünk. Ha nem, akkor jöhet a vadászat, hogy mit rontottunk el. Ilyen esetekben némi segítséget jelenthet a hivatalos XDebug oldalon található dokumentáció.

A telepített XDebug megjelenik a phpinfo()-ban

Megjegyzés:Windows felhasználók esetén a lefordított bináris nem .so, hanem .dll kiterjesztéssel rendelkezik, és érdemes lehet a php bővítményei közé rakni (de természetesen ez nem kötelező); valamint a fájlnevet is megfelelően módosítani kell.

Abban az esetben, ha rossz XDebug binárist kaptunk, itt elképzelhető, hogy a PHP nem indul el – velem előfordult. A fordítás során ugyanis egy gusztustalan hibába futottam: sikerült 4.3-as PHP-hoz lefordítanom az XDebug-ot, és ez az 5.2-es PHP-val nem működik együtt, méghozzá olyan szinten, hogy a PHP el sem indult, hanem mindenféle különös hibaüzenetet dobált. Hogy ez hogyan jött elő? Az OSX 10.4 gyárilag tartalmaz egy 4.3-as PHP-t, amit elég nehézkes eltávolítani a rendszerből, ezért inkább MacPortsszal mellételepítettem az 5.2-es változatot. Ugyanakkor a fordításkor egyéb paraméterek megadása nélkül a 4.3-ast találta meg. Amikor a fordításkor megfelelő paraméterrel megadtam az 5.2-es PHP elérési útját, az így kapott binárissal rögtön elindult a PHP.

Eclipse

Mi is az az Eclipse? Egy teljesen nyílt IDE (gyengébbek kedvéért: integrált fejlesztői környezet). Nyílt azért is, mert teljesen nyílt forráskódú, és azért is, mert pluginalapú. Ez azt jelenti, hogy ha egy másik nyelvhez akarsz fejlesztői környezetet használni, azt ugyanúgy el lehet készíteni az Eclipse IDE felett, és ugyanazokat az elemeket képes is használni (például az Eclipse PDT-vel együtt feltelepülnek azok a pluginek is, amivel a Java fejlesztést lehet végezni). Mindezek felett az Eclipse Java nyelven íródott, ezért nagyszerűen egyforma (lassan) működik az összes nagyobb operációs rendszeren (persze a gépigénye megvan, rengeteg memóriát eszik például).

Netes bogarászás alapján az Eclipse PDT (Php Development Tool) plugincsomag kellően jó választásnak tűnik. Ha korábban nem volt telepített Eclipse és csomagkezelőből sem tölthető le akár mert az operációs rendszerhez nincs csomagkezelő (pl. Windows), akár mert az elérhető csomagkezelő nem tartalmazza (pl. OSX-en a MacPorts), akkor legegyszerűbb a
PDT Project oldaláról lehúzni. Egyébként a frissítések között is megadható az http://download.eclipse.org/tools/pdt/updates/ URL, és azon keresztül is telepíthető. Ez használható a Linuxon csomagkezelőből telepített Eclipse esetén is (a beépített frissítések egyébként a Help menü Software Updates pontja alatt érhető el – a lehető leglogikusabb hely a funkcióhoz :-p). Az Eclipse csomagkezelőjét használó funkciót nem teszteltem, de Balage tapasztalatai alapján a 3.2-es core modulokkal nem működik, 3.3-assal nem sikerült tesztelnie.

Léteznek egyéb PHP kiterjesztések is az Eclipse rendszerhez, de azok vagy abbamaradtak (pl. a PHPEclipse csomag utolsó kiadása 2005-ös), vagy még nem jutottak el egy bizonyos érettségi fokra. Természetesen a PDT Project sem jutott fejlődésének csúcspontjára, de előnye, hogy a PHP-t támogató Zend (is) mögötte áll, és arra készül, hogy az egész platformját átírja Eclipse alapra, miután a projekt megfelelő szintre eljutott.

Maga a telepítés teljesen magától értetődő, nem is fektetnék rá nagyobb hangsúlyt.

Eclipse és XDebug

Módosítás: 2007. szeptember 26-án.

Na, ez szép fázis. Az Eclipse PDT jelen helyzetben nem támogatja beépítve az XDebug-ot. Persze nincs semmi veszve, hisz az Eclipse pluginelhető rendszer, és a feladathoz létezik plugin. Ezt az Eclipse plugint kell még telepíteni az azEclipse Bugzilla-ról (a tervek szerint ez a funkció később bekerül az Eclipse PDT-be, de az még arrébb van). A megfelelő verzió választása itt is fontos lehet. Fontos: nem véletlenül nincs más helyen letölthető verzió. Szerencsére az Eclipse pluginek telepítése és eltávolítása egyaránt egyszerű művelet: bemásolás az Eclipse pluginkönyvtárába a pluginkönyvtár a telepített Eclipse struktúrában könnyen megtalálható, illetve eltávolítás ebből a könyvtárból. Természetesen eközben célszerű, ha maga az Eclipse nem fut, vagy ha mégis, akkor a változások érvényre juttatásához újra kell indítani. Természetesen ez a plugin nem érhető el egyelőre az Update Manageren keresztül.

Nekem ez a rész teljesen simán működött, a plugin létrehozta a szükséges új View-kat, beállítópanel(rész)eket. De mivel ez még nem hivatalos plugin, nem biztos, hogy mindenhol tökéletesen működni fog, óvatos kezelést igényel.

A 2007. szeptember 17-én megjelent Eclipse PDT már beépítve tartalmazza az XDebug-on keresztüli debuggoláshoz szükséges plugineket – és megváltoztatták a módot is, ahogy XDebug-os debug session-öket lehet létrehozni. Mostantól nem külön debugtípus az XDebug-on keresztüli, hanem a debug mód egyik paramétere a választott debugger.

Ha korábban az én írásom alapján állítottad össze a rendszert, és használtad a debuggert, és hagytad az Eclipse-nek, hogy frissítse magát, akkor azt vehetted észre, hogy mindenféle hibaüzenet nélkül megszűnik a debuggolás, a töréspontoknál nem áll meg futás közben, stb.

A probléma megoldására két megoldás van: az egyszerűbb az, hogy eltávolítod a meglevő Eclipse-et, és újratelepíted az új verziót (ezzel biztosan eltűnik minden hivatkozás az időközben elavulttá vált Bugzillán közölt pluginre), vagy ha nagyon profi vagy, akkor megpróbálhatod kézzel kihackelni a pluginek közül a kapcsolódó részeket.

Ha ezzel is megvagy, akkor már (elvileg) van egy teljesen működőképes PHP-debuggolásra alkalmas fejlesztői környezeted.

Amikor persze a Debug-ot meghívod, figyelni kell rá, hogy a felajánlott lehetőségek közül azokat válaszd, amiknek a nevében XDebug van – a másik másfajta debuggerhez való.

Egyéb nyalánkságok

Természetesen a lehetőségek itt még messze nem merültek ki. Például az Eclipse-et könnyű rávenni arra, hogy CVS vagy SVN verziókezelő rendszerrel szinkronizálja a projektet. A CVS támogatás a legtöbb Eclipse-verzióban benne van (konkrétabban én még nem láttam olyat, amiben ne lenne benne 🙂 ). Az SVN-hez legegyszerűbb a Subclipse plugin letöltése. Részletes telepítési útmutató a projekt oldalán található. A használata elsőre furcsa lehet (a Workspace view-ban a Project jobb gombos menüjében a Team menüben találhatóak az ehhez tartozó részek).

Hasznos lehet, ha a PHP projekt olyan mappába kerül, amit a webszerver is lát. Ez Eclipse alatt kis fejtörést igényel, ugyanis az Eclipse workspace alapon működik – viszont a workspace mappát nem (feltétlenül) érdemes a helyi gépen levő webszerver elérhetőségébe tenni. Én azt csináltam, hogy a workspace-t a saját mappámban hoztam létre, míg amikor ezen belül projekteket hoztam létre, azoknál gondoskodtam róla, hogy az Apache által kezelt mappába jöjjön létre a megfelelő mappa (ez az új projekt varázsló egyik pontjánál elérhető szolgáltatás, alapértelmezetten le van tiltva).

Az aktuális projekthez tartozó debug útvonalakat (pl. a felparaméterezett index-fájl, stb.) érdemes felvenni a rögzített debug módok listájára, sokkal gyorsabban felhasználható, különösen, ha hozzám hasonlóan olyan url-en keresztül érhető el a php-fájl, amit az Eclipse nem jól „tippel” meg.

Azok a bizonyos utolsó szavak

Balage volt olyan kedves, hogy a cikk egy félkész változatát tesztelte a Kubuntu Linux-án. A tapasztalata szerint a rendszer csomagkezelője által telepített 3.2-es Eclipse-core nem volt kompatibilis a linken elérhető Eclipse PDT-vel, az Eclipse honlapjáról letölthető változat meg nem igazán akart futni (pl. üres splash screen, csomagkezelője első nekifutásra kifagyott). Nem is sikerült megoldani így a gondot. Azoknak, akik hasonló cipőben járnak, tudom ajánlani az EasyEclipse PHP módját. Lényegesen egyszerűbben telepíthető, mint a teljes Eclipse csomag, benne van többek között a Subclipse plugin is, és nagyobb hangsúlyt fektetnek a kompatibilitásra, ugyanakkor ezért a rugalmasságban kell fizetni: nem biztos, hogy bármely Eclipse plugin gond nélkül együttműködik vele, illetve csak csomagként lehet frissíteni tudomásom szerint. Én ezt sem teszteltem, de Balage-nál megoldotta a gondokat.

És végül egy bizonyos „copyright” célú megjegyzés: az csak a véletlen műve, hogy nem olyan régen János egy hasonló témájú írást jelenített meg az oldalán: PHP fejlesztői környezet berendezése. Nem használtam fel semmit az írásából, nem a Zend debuggerét használtam fel. Erre két okom is volt: nem rajongok a csak egy dll/so formátumban terjesztett megoldásért teljesen nyílt rendszer összerakásakor (ugyan nem nézem meg a forrást, de csak megnyugtatóbb, ha én fordítom le… az meg már tényleg csak mellékes, hogy a Windows-nál is zártabb OSX felett építem fel ezt a rendszert… 🙂 ), valamint én ehhez találtam leírást. Az meg már csak hab a tortán, hogy ezzel elméletben remote debuggingra is lehetőség van, de ezt már végképp nem használom ki.

Sok sikert mindenkinek a rendszer használatához, ha van, aki megosztja a tapasztalatait, örömmel venném, ha kiegészíthetném vele ezt a leírást.

Soha ne figyelmeztess, ha a visszavonás is elegendő!

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Soha ne figyelmeztess, ha a visszavonás is elegendő!
Miért? Mert a szoftvernek tudnia kellene, hogy szokásokat veszünk fel. Tudnia kellene, hogy azután, hogy számtalanszor válaszolunk OK-val a kérdésre, feltehetőleg akkor is az OK-t választjuk, ha nem arra gondoltunk. És azt is tudnia kellene, hogy nem lesz lehetőségünk gondolkodni, mielőtt véletlenül eldobjuk az egész munkánkat.

Miért kellene tudnia a szoftvernek ezeket a dolgokat? Mert a szoftvertervezőknek is tudniuk kellene, hogy szokásokat veszünk fel, akár akarjuk, akár nem.

A szokások felvétele tulajdonképpen egy jó dolog: segít megkímélni minket annak a gondjától, hogy gondolkodni kelljen, amikor az interfész bosszantó apróságaival találkozunk és csökkenti a valószínűségét, hogy a gondolatmenetünk eltérül. A „Biztosan ki akar lépni?” kérdésre a kezünkben van egy memorizált kattints-és-zárd-be folytonos folyamat. Ez jó, mert a legtöbb esetben nem akarunk gondolkodni a kérdésről – csak a jó dolgot csináljuk. Szerencsétlen módon, a szokásaink időnként félrevezetnek: nem lesz időnk rájönni a hibánkra, amíg meg nem csináltuk.

Így a tervezők számára egyenes út vezet az általános felhasználói felülettervezési elvhez: Ahhoz, hogy egy felhasználói felület emberi legyen, figyelembe kell vennie a szokások kialakulását.

Lehetséges megoldások

Mi lenne, ha a figyelmeztetést nehezebb lenne figyelmen kívül hagyni? Egy diszkrét figyelmeztetés felett könnyű átugrani, így vegyük elő a teljes eszköztárat: villogtatjuk a képernyőt és egy hangos, idegesítő zajt játszunk le annak érdekében, hogy biztosítsuk a felhasználói figyelmet. Próbálkozhatunk, ahogy tetszik, továbbra sem fog működni. Minél tolakodóbb a figyelmeztetés, annál gyorsabban meg akarunk szabadulni tőle (az OK-ra kattintva) és annál többször fogunk hibázni. A gond az, nem számít, mennyire tolja a képünk elé a figyelmeztetést a szmítógép, mi ugyanazt a hibát fogjuk elkövetni: akkor is az OK-ra kattintunk, ha nem azt akartuk. De ez még mindig nem a mi hibánk: addig, amíg szokások felvételével figyelmen kívül lehet hagyni a hibaüzenetet, felvesszük a szokásokat, azután pedig hibázni fogunk.

Mi lenne, ha a figyelmeztetést lehetetlen lenne figyelmen kívül hagyni? Ha a szokások okozzák a problémát, miért nem tervezzük úgy meg a felületet, hogy ne lehessen szokásokat felvenni? Így mindig rá leszünk kényszerítve, hogy gondolkodjunk a válaszadás előtt, és így mindig azt válaszoljuk, ami választ mi szeretnénk. Ez megoldja a problémát, nem?

Ez a fajta gondolkodás nem új: ez az írd-be-az-n-edik-szót-ebből-a-mondatból-a-folytatáshoz megközelítés. Például a Guild Wars játékban ahhoz, hogy egy karaktert töröljünk, először a „Törlés” gombra kell kattintani, majd a karakter nevét be kell írni megerősítésként. Sajnálatos módon ez nem mindig működik. Pontosabban:

  1. Arra kényszerít minket, hogy koncentráljunk a szokatlan feladatra és nem arra, hogy tényleg el akarjuk-e dobni a munkánkat. Így a nem figyelmen kívül hagyható figyelmeztetés se sokkal jobb, mint a teljesen átlagos: mindkét esetben végeredményben elveszik a munkánk. Ez (a munka elvesztése) az elképzelhető legnagyobb bűn a szoftver világában.
  2. Figyelemre méltóan idegesítő, és mert mindig szükséges a figyelem, szükségszerűen elterel minket a munkánkról (ami a második legnagyobb szoftver-bűn).
  3. Mindig lassabb és több munkát igényel, mint egy egyszerű figyelmeztetés. Ezzel elköveti a harmadik legnagyobb bűnt – azzal, hogy több munkát igényel tőlünk, mint az szükséges.

A Guild Wars-os példánkban a második és harmadik pont nem túl lényeges, mert a karakterek törlése elég ritka esemény. De ha be kellene írni a dokumentum nevét, mielőtt mentés nélkül kiléphetnénk, nagyon megterhelőnek éreznénk.

Mit tanultunk? Azok a felületek, amik nem veszik figyelembe a megszokást, nagyon rosszak. A figyelmeztetés nagyobbá, hangosabbá és nem-figyelmen-kívül-hagyhatóvá tétele nem működik; akárhogy is nézzük, a figyelmeztetések egy nagy, sötét csapdát jelentenek az interfészben. Inkább szabaduljunk meg a figyelmeztetésektől.

A mentőöv: visszavonás

Ha csak simán eltávolítjuk a figyelmeztetéseket, nem mentjük meg a munkánkat a végzettől, de ha egy „visszavonási” lehetőséget beteszünk, akkor már igen. Hadd ismételjem meg: a figyelmeztetéses nyomorúságunkra a visszavonás a megoldás. Egy kellően robosztus visszavonással akár nemtörődöm módon is bezárhatjuk a munkánkat tudva, hogy mindig visszanyerhetjük. A visszavonással ezt a szörnyű „Hoppá!” érzést eltüntethetjük a munka visszaszerzésévelA „Hoppá!”-tényező egy Laura Creighton-nal folytatott megbeszélés alapján született meg..

Mivel szokásokat veszünk fel, soha nem fogjuk tudni garantálni, hogy nem lesz ilyen „Hoppá!” pillanatunk. Ezzel szemben a tervezőknek tudomásul kell venniük, hogy meg fog történni, és ennek megfelelően tervezni. Ahányszor csak megvan a lehetősége, hogy eldobjuk a munkánkat, a számítógépnek lehetővé kell tennie, hogy visszacsináljuk a dolgokat.

Ez elvezet minket az egyik legalapvetőbb és legfontosabb felülettervezési mantrához: Soha ne figyelmeztess, ha a visszavonás is elegendő!

A Google Mail egy jó példája ennek a mantrának. Ha törölsz egy e-mailt, azonnal ad lehetőséget arra, hogy visszavond ezt a lépést. Milyen felhasználóbarát! Ezzel ügyesen kikerüli a figyelmeztetések kérdését (csakúgy, mint a visszavonás láthatóságát). Ha hibázunk (ami elő fog fordulni), nem kerül túl sokba, mert egyszerűen visszavonhatjuk. A visszavonással kevesebbet aggódunk és több időt dolgozunk.

Gmail visszavonás: Ezt a beszélgetést áthelyeztem a kukába. Link a Visszavonás opcióra.
1. ábra: Még nincs túl késő. A Gmail lehetővé teszi, hogy visszavonjuk a törlést.

Természetesen ez csak egy rétege a visszavonhatóságnak – és Gmail ennél tovább megy. Ha törölsz egy levelet, az nem veszik el örökre… ott van a kukában, hogy visszaállíthasd, ha később úgy döntesz, mégsem akartad törölni.

Sajnos, ezt a leckét a Google Calendar még nem tanulta meg. És, ahogy megjósolható volt, töröltem már olyan eseményeket, amit nem akartam. Sokszor a rossz eseményt töröltem, ami különösen rossz, mert ekkor abban sem vagyok biztos, hogy mit töröltem. Visszavonás nélkül nincs is rá mód, hogy kitaláljam.

Google Calendar figyelmeztetőablaka: Biztos, hogy törölni akarod az
2. ábra: Légy óvatos! A Google Calendar nem engedi a téves törlések visszavonását.

Tulajdonképpen még Google Mail sem mindig használja ezt a módszert. Ha egy címkét törölsz, már jön is egy ilyen figyelmeztetés. Miért van az, hogy Google ilyen jól megcsinálja egy helyen, és alig néhány kattintással arrébb meg ilyen rosszul? Talán mert ez a figyelmeztetés alapú gondolkodás annyira beágyazódott, hogy hősies erőfeszítéseket igényel a meghaladása. Még olyan cégek is, amelyek egyébként a jó tervezés védőbástyái (ilyen a 37Signals), ezt nagyon rosszul csinálják.

Highrise figyelmeztetés: Biztos, hogy törölni akarod ezt a feladatot?
3. ábra: A Highrise, a 37Signals alkalmazása is figyelmeztet visszavonási lehetőség nélkül

Figyelmeztetések használata a visszavonás helyett a legkisebb ellenállás felé mozdulás útja a programozó szemszögéből, és nem igényel különösebben újító gondolkozást a tervező nézőpontjából. De ez nem mentség a számítógépeink számára, hogy nem emberi módon gondolkodnak.

Következtetés

A figyelmeztetések miatt elveszíthetjük a munkánkat, bizalmatlanok leszünk a számítógépekkel szemben és magunkat hibáztatjuk. Egy egyszerű, de bolondbiztos tervezési módszertan megoldja a problémát: „Soha ne figyelmeztess, ha a visszavonás is elegendő!” És ha a felhasználó törli a munkáját, mindig elegendő.

Ó, és a következő alkalommal, amikor azt látod, hogy figyelmeztetnek a visszavonás helyett, küldj az alkalmazás/weboldal tervezőjének egy kedves e-mailt, amiben javaslod, hogy inkább implementáljanak egy „visszavonás” funkciót. Küldj nekik egy linket erről a cikkről. Nézzük meg, meg tudjuk-e változtatni annak a módját, ahogy az emberek a webre terveznek – és ebben a folyamatban mindenki számítógépes életét egy kissé emberközelibbé és kevésbé frusztrálóvá tegyük. Kezdődjön a háború a figyelmeztetések ellen!

Illusztráció: Kevin Cornell

A szerzőről

Aza először 10 éves korában a SIGCHI helyi, san franciscoi székházában beszélt a felhasználói felületekről, és a rabjukká lett. 17 évesen nemzetközi megbeszéléseken és konzultációkon vett rész; 19 évesen egy fizikakönyv társszerzője lett, mert túl fiatal volt, hogy alkoholt vegyen; 21 évesen elkezdett inni, és társalapítója a Humanized-nek. Aza szeret játszani a kürtjén és a laborjában tenni-venni, ha az ideje engedi.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

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.