Skip to content

GhoUl

A Cubus Sapiens oldal

Archívum

Címke: osx

Megnyertem egy parser frissítésének és karbantartásának feladatát. Igen, ez remekül hangzik. Ahogy az is.

A parser az LPG parser generátorral készült, méghozzá annak az 1.0-s változatával. Most már van 2-es is, ami természetesen nem kompatibilis a régivel (legalábbis generált kód szintjén semmiképp sem – többek között más java package-et használ). Miután nem sokkal release előtt kaptam meg, frissíteni most biztos nem lehet (később meg valószínűleg úgyis kellene).

Na, tehát ott tartottam, hogy 1-es verzió. Minden nagyon szép, minden nagyon jó, mindennel meg vagyok elégedve, úgyhogy módosítottam a grammar fájlt. Na, ideje újragenerálni a kódot. És itt jön a feketeleves: az LPG parser generátor régi verziójához csak egy Windows-os exe fájl van, azzal lehet futtatni. Természetesen forráskód is van, de még a makefile is a Visual C++ fordítóra van kihegyezve. Szóval lefordítani macerás.

Nem is kezdem el, mert feltehetőleg csak ideiglenes megoldás kell (max. 1-2 év :D ). Ugyanakkor cél, hogy a megoldás integrálódjon az Eclipse-be, azaz néhány klikkeléssel sikerüljön a programot elindítani. A lehetőségeim: wine vagy VMware.

Az utóbbi nem tetszene, mert relatíve sok erőforrást eszik, ráadásul egyszerűen csak a VMware alatt futó Eclipse példánnyal lehetne összekapcsolni, amelynek a gyorsbillentyűi teljesen mások, mint a natív Mac-es példányé.

Szóval lehet reménykedni, hogy a wine-osok jó munkát végeztek. És szerencsém van, mert az lpg.exe gond nélkül futtatható vele.

Most már csak az Eclipse integráció van hátra. Ennek remek eszköze az External Tools eszköz (megjegyzés: natív Windows-on is csak így lehet futtatni az lpg.exe-t Eclipse-ből – nincs jobb támogatás) a Run menüben.

Létrehozhatunk egy saját eszközt, amelynek felparaméterezéséhez használhatjuk az Eclipse különböző változóit. Számunkra ehhez kettőre van szükség:

  • ${resource_loc}: az aktuálisan kijelölt erőforrás elérhetősége a fájlrendszerben (nem workspace-relatív módon!)
  • ${container_loc}: az aktuális erőforrást tartalmazó mappa elérhetősége (szintén nem workspace-relatív módon)

Az LPG parser generátor számára fontos a munkakönyvtár beállítása, ide fogja generálni a fájlokat. A többi adat kitöltése magától értetődő, ezért csak egy képernyőfotót illesztek be róla.

LPG futtatása Wine segítségével az aktuális fájlra

LPG futtatása Wine segítségével az aktuális fájlra

Az LPG futásához három dologra van szükség: a nyelvtan fájlra vagy fájlokra, az include fájlokra és a template fájlokra. Ezek lehetnek mind a munkakönyvtárban (ez a helyzet, ha saját sablonokat használunk), vagy pedig környezeti változók által kijelölt mappában, esetleg paraméterként is át lehet adni.

Szerintem a legtisztább a környezeti változók használata, ezért az Environment fülön felvettem az LPG_INCLUDE és az LPG_TEMPLATE környezeti változókat, azokat a megfelelő mappákra irányítva.

Ezután a futtatás gombra kattintva jött a varázslat: a wine az OSX-es útvonalakat lefordítja a Windows-os program számára érthető formátumra (megfigyelhetőek az Y:\ kezdetű útvonalak a szöveges kimeneten – amik természetesen megjelennek az Eclipse Console view-ban), és az ugyanilyen formátumban készülő fájlok megjelennek az OSX-es mappában. Sőt, a környezeti változókra is igaz ez. Nagyon cool.

A technológiával két kisebb gondom van: nem tudom az LPG-t így a .g fájl jobb gombos menüjéből futtatni (nincs ott külső eszköz futtatásához lehetőség), és nem működik a megoldás, ha nem a Navigator view aktív a Run external tool használatakor (természetesen akkor sem, ha nem a .g fájl van kijelölve, de ez természetes :D ). Van ezekre valakinek valami ötlete?

Miután tavaly nyáron tönkrement amúgy sem túl powa laptopom, úgy döntöttem, megválok pingvinemtől és SzuperTehenemtől, és veszek egy MacBookot (remélve, hogy nem fog MacBook-ni). Miért? Azt gondoltam, az OSX megvalósítja azt a közel ideális koncepciót, hogy egy szilárd alapra (UNIX) egy jól átgondolt architektúrával egy emberközeli, ergonomikus rendszer épüljön. Pár hónapos intenzív használat után az alábbi tapasztalatokat gyűjtöttem össze a Leoparddal kapcsolatban.

Ami a legnagyobb pozitívum: minden működik, nem kell semmivel szívni. Olyan alapdolgok, amelyek bár Linux alatt is triviálisak lennének, de valami rejtélyes okból kifolyólag csak konfigfájlokban való turkálásokkal lehetett megoldani, automatikusan vagy egy kattintásra működtek, pl. MIDI-lejátszás, fájl-, ill. vezetékes netmegosztás Windows géppel. Ugyanakkor azt hallottam, és ezt el is tudom képzelni, hogy valami viszont
nem működik, akkor alányúlni a rendszernek a javítás végett nagyon macerás. Szerencsére velem még nem történt ilyesmi.

Természetesen semmi sem tökéletes. Amikor sorra veszem a különböző aspektusokat, bizony bosszantó apróságokról is szót kell ejtenem, amelyek főleg kezdetben rontják az összképet, és hiába szokja meg őket az ember, még sok idő után is képesek néha meglepetést okozni. Sokszor bagatellnek tűnhetnek, de igenis számolni kell velük. Előre kell bocsátanom, hogy ha valamit hiányolok, természetesen előfordulhat, hogy csak én nem találtam a problémára megoldást, ilyenkor tessék nyugodtan szóvá tenni kommentben. :) De akármennyire is kritikusnak tűnik az értékelés, ez ne legyen megtévesztő: végső soron nagyon elégedett vagyok a rendszerrel.

Felhasználói felület: parasztvakítás vagy célszerűség?

Kezdjük a felszínen. Tény: a felület jól néz ki. Ez néhol öncélú eye candy (pl. a default animációk közül a genie és a ripple lassú és zavaró), néhol viszont fontos használhatósági szempontokat szolgál. Ha szabad ilyen apróságokat is említenem, a window chrome minimális területet foglal, és mégis esztétikus. Az alapbeállítású fontméret pedig az én kijelzőm és szemem számára arany középutat képvisel az áttekinthetőség és kompaktság között. Viszont a hosszú neveket nem lehet mindig teljes egészében megjeleníteni, csak három ponttal lerövidítve: ez a Finderben bizonyos fájlneveknél fordult elő, sőt, a Thunderbirdben a “A szemétként megjelölt levelek törlése a mappában” menüpontnál is!

Mi a menü?

Az egységesítés igénye is nagy előny, mely a rendszer sok más részében is megnyilvánul. Ami elsőre feltűnik, hogy nem csak a menüsor helye, hanem a beállítások (és egyéb, minden alkalmazásra jellemző parancs) helye a menürendszerben is centralizált, és ami fontos, a billentyűparancsa is. A menük viszont nem ciklikusak, pedig ez igen jól jönne néhol billentyűzettel való navigáció esetén. Egér használatakor viszont az a furcsa, hogy a szöveges menüből lehet egeret mozgatva navigálni az ikonokra, fordítva viszont nem.

Ablakok (nem picipuha!)

Az is pozitív apróság, hogy a módosított dokumentum ablakának változik a bezárás ikonja. A maximalizálás funkció viszont néhol nem az elvárt módon működik (némely alkalmazásoknál nehéz is értelmezni, mi az a legkisebb terület, amin ugyanakkor minden látszik), különösen éppen a Finderben. A modális gyermekablakok szülőablakhoz kötése nagyon jó ötlet (így nem történhet meg, hogy eltűnik a gyermekablak, és nem tudjuk, miért nem válaszol a szülő), viszont mozgathatónak kénne lenniük, hisz előfordulhat, hogy éppen olyan információt takarnak el, ami szükséges lenne a megválaszolásukhoz. Az ablak-alkalmazás megkülönböztetés, bár szokatlan, de szerintem szerencsés. Viszont nem mindig egyértelmű, mi szolgál a bezárásra, és mi a kilépésre: pl. a System Preferences az ablakának bezárásákor kilép. Az ablakokról még annyit, hogy hiányzik a KDE-ben megszokott snap mechanizmus, amely ablakok mozgatásánál a képernyő vagy másik ablak széléhez passzintja őket. Erre igazán gondolhattak volna a fejlesztők.

Jó és rossz ötletek kikötője

A Dock alapkoncepciója (egy felületen a kedvenc és futó alkalmazások) nekem bejön. De alapvető hibája, hogy nincs neki dedikált képernyőterület, és így (főleg a képernyő oldalára helyezve) mögékerülnek ablakok! Ha pedig lent helyezkedik el, a visszaverődő felület számomra zavaró tud lenni – ez az öncélúság, amire fent utaltam. Az, hogy a Dock változtatja a méretét, nem működik jól együtt a maximalizálással, valamint így mozognak a rajta levő ikonok, s nincs az elemeknek egy megszokott helyük, melyre ösztönösen oda lehetne kattintani. Nem kerülne sokba, ha az éppen aktuális alkalmazás ki lenne emelve, pedig olykor hasznos lenne.

Végül úgy oldottam meg a kérdést, hogy az itt leírt módszerrel megszüntettem a visszaverődést, a Dock maradt a képernyő alján, de bekapcsoltam az automatikus elrejtést – így felszabadul az értékes függőleges terület, és nincs gond a méretváltoztatással, a futó programok listája úgyis látszik Cmd+Tab-os programváltáskor.

Működés

Először igen meglepett, hogy a szövegdobozok natívan nem támogatják a visszavonás funkciót. Így van, amelyik alkalmazásban ez elérhető, van, amelyikben nem.

Billentyűzetkiosztás

Nem tudom, miért kellett oly sok konvenciótól elrugaszkodni az Apple-nek a funkciógombok kapcsán. A Cmd gomb nem a Ctrl helyén van, viszont nem is mindig a Ctrl-t helyettesíti. Az Alt és Fn billentyűk közül nem mindig egyértelmű, melyik szolgál módosítóként. Az, hogy nincs külön Home/End és PageUp/PageDn billentyűpáros, nem lenne nagy baj, ha konzisztensen kezelnék az alkalmazások, de én sajnos legalább 3-féle variációt láttam eddig az Fn/Ctrl/Cmd + navigációbillentyűk értelmezésére. Az AltGr hiányának egyik következménye, hogy (a default magyar billentyűzetkiosztásban, amit, amint megtudtam a módját, átírtam a PC-s változatra) sok gyakori karakter csak 2 módosítóbillentyűvel hívható elő, a másik, hogy a menüknek nincsenek gyorshívó billentyűi. Ez csak egy komponense annak, hogy (legalábbis az én szokásaimhoz képest) a rendszer nem eléggé billentyűzhető.

Fájlrendszer

A ponttal kezdődő rendszerfájlok kezelése szerintem túl szigorú, bár lehet, hogy csak fejlesztőként gondolom így, túl sokszor lehet dolgom ilyen fájlokkal (pl. .htaccess). Így nem csoda, hogy a .DS_Store megoldás is zavar. Az viszont tetszik, hogy a nézetek automatikusan frissülnek a fájlrendszer módosításakor. A társításkezelés ugyanakkor először megzavart: a társítás nem kiterjesztésenként, hanem fájlonként érvényesül, a kiterjesztésenkénti társítást bonyolultabban, a Finder Info ablakában kell beállítani.

Felhasználókezelés

Hiányzik az, hogy a rendszer megjegyezze a leállításkor éppen futó programokat, és újraindításkor újra elindítsa őket. A felhasználóváltást pedig cseles helyre tették: nem a rendszermenübe a kijelentkezés mellé mondjuk, hanem a Lock Desktop alkalmazás szolgál erre.

Alkalmazások

Az OSX alkalmazáskezelési mechanizmusa kétélű kard: a telepítés nagyon egyszerű és intuitív, az eltávolítás viszont nem mindig teljes értékű. Amikor pedig először találkoztam a netről letöltött alkalmazás futtatásának kérdésével, a Vista jutott eszembe, de ez csak reflex, ez a dialógusablak jó is, hogy figyelmeztet erre, és informatív.

Finder

A beépített programok közül éppen a Finderrel volt a legtöbb bajom. Míg pl. a Mailben az accounttól függetlenül egyesített mappák ötlete olyasmi, amit minden levelezőprogramban szeretnék látni, a Findert rövidesen lecseréltem a muCommanderre, abban többek között tömörítvényekben is tudok járkálni, amit gyakran szoktam, de ez se ideális megoldás, lévén lassú és nagyon instabil. Szóval, mi is a bajom a Finderrel? Érdekes módon azok, amiket az internetes közösség már jó ideje egyhangúlag nagyon gáznak minősít. Csak címszavakban:

  • Az Enter átnevez és nem megnyit, és ezt még át sem lehet konfigurálni. Bár léteznek segédprogramok, melyekkel ezt át lehet hackelni, de akkor pl. az átnevezés végén lenyomott Enter is megnyitást eredményez, ill. előfordulhat, hogy nem működnek a Spotlightot és a QuickSilvert aktiváló default billentyűkombinációk.
  • Könyvtárak felülírásakor a Finder a struktúrát nem merge-eli, hanem ami a régi könyvtárban megvolt, de az újban nincs, azt törli. Az így elveszett fájlokat vissza sem lehet állítani.
  • Ami igazán elvárható lenne: az ablakban sehol nem látszik az aktuális elérési út. (Az ablak fejlécére jobb gombbal kattintva ez elérhető, de én valami breadcrumb-szerűséget hiányolok.)
  • Az oszlop nézet nem lenne rossz, de itt is hiányosságok tapasztalhatóak: a kezdeti méret nagyon kicsi, maximalizáláskor pedig előfordul, hogy kilóg a képernyőterületről az ablak. Nem találtam olyan billentyűkombinációt, amellyel a lista tetejére és aljára ugrani.
  • Átnevezésnél nincs lehetőség felülírásra.

Ami viszont tetszett, az a lista nézet tetszőleges mélységig kinyitható könyvtárfája, valamint a pluginekkel látványosan egy csomó tartalomtípusra kiterjeszthető Quick Look.

Automator

Ez az eszköz nagyon ott van! Az, hogy ilyen magas szintű automatizálás rendszerszinten van támogatva, és újrafelhasználható, paraméterezhető munkafolyamatokat lehet létrehozni, sok lehetőséget nyit meg az ember előtt. Én elsősorban tömeges fájl- és képműveletekre szoktam használni (ezekhez más oprendszereken alkalmazásonként külön vagy van támogatás, vagy nincs), de még annyi minden lehetséges. (Ugyanakkor nem mindegyik paraméter van korrektül implementálva, pl. bizonyos fotóműveleteknél a százalékos értéket nem lehet százalék pontossággal megadni.)

Szolgáltatások

  • Growl: Az egységes notifikációs API természetes felhasználói igény, és nagy lépés afelé, hogy ami általános szolgáltatás, arra egyetlen interfész legyen a rendszerben.
  • Spotlight: Az inkrementális keresés jó, de akad egy kis kellemetlenség: amikor folytatom a gépelést, akkor amíg még folyik a keresés, már nem kéne érvényesnek lennie az eddigi találatoknak, hiszen a keresési kulcs már megváltozott.
  • AirPort: Csak egy dolgot hiányolok: az elérhető hálózatok jelerősségének kijelzését.

Konklúzió

Mint már mondtam, az összbenyomás egyértelmű elégedettség: az említett negatívumok egyike sem megkerülhetetlen vagy megszokhatatlan, és egy megbízható, produktivitást serkentő rendszert kapunk, melyhez sok remek program létezik (és ezen belül a szabad szoftverek száma örvendetesen nő), ld. Stampie válogatását. És végül fontosnak tartom hangsúlyozni, hogy az itt leírtak az én személyes tapasztalataim és az én felhasználói szokásaimhoz igazodnak: your mileage may vary, ahogy a művelt francia mondaná. :) Ha esetleg valakinek megjött az étvágya az ominózus almához: jó falatozást!

Kérésre összeállítottam egy listát kedvenc Maces programjaimról, és ha már megtörtént, gondoltam, meg is osztom. A lista egyáltalán nem teljes, de úgy nagyjából a leghasznosabb(nak tűnő) dolgokat szedtem össze. Fontos: semmi olyan program nincs benne, amit az Apple a géphez adott volna, mindegyiket külön kellett beszerezni.

A lista kicsit csalóka – ugyanis nem 10+1 programot ajánlok, hanem 10+1 célra. De attól még remélem, hasznos.

1. MacFuse és MacFusion

Alapvetően a Findert használom fájlműveletekre. Ehhez nagy segítség, ha távoli, FTP vagy SSH szerver tartalmát is hasonlóan tudom megnyitni. A MacFuse éppen ezt kínálja: távoli fájlrendszereket képes mountolni, hasonlóan a külső merevlemezekhez. A MacFusion pedig egy ikont rak a menüsorba, hogy ne kelljen parancssorból felcsatolni ezeket a fájlrendszereket. Hasznos. Bónuszpont: az NTFS meghajtók írásához használható NTFS-3G program is igényli a MacFuse-t.

http://code.google.com/p/macfuse/

http://www.macfusionapp.org/

2. QuickLook pluginek

Az egy gombos betekintő funkció nagyon hasznos a Finderben, de vannak gyenge pontjai. Tömörített fájlokra, mappákra, eps fájlokra nem működik, és egy a szövegnézőkéje sem tud szintaxiskiemelést. Ezen próbálnak segíteni különböző QuickLook pluginek.

Ha nincs telepítőjük, akkor a /Library/QuickLook vagy a ~/Library/QuickLook könyvtárba kell behúzni a .qlgeneratort, majd (ha szükséges), egy

1
qlmanage -r

paranccsal újrageneráltatjuk az elérhető pluginek listáját.

http://macitbetter.com/BetterZipQL-1.0 (a BetterZip fizetős szoftver, de a QuickLook plugin ingyenes)
http://code.google.com/p/qlcolorcode/ (szintaxiskiemelő különböző szöveges fájlokhoz)
http://homepage.mac.com/xdd/software/folder/ (mappabetekintés)
http://www.eternalstorms.at/utilities/epsqlplg (eps képnéző)

3. Smultron

Egy egyszerű, ingyenes kis programozói szerkesztőprogram a Smultron (Windowsra hasonló célra a PSPad-et szoktam használni). Vannak roppant ötletes dolgai. Funkciója az, hogy ami pure text file, de az Eclipse overkill lenne hozzá, azt ügyesen kezeli. Sokrétű a szintaxiskiemelése.

http://tuppis.com/smultron/

4. LaTeXiT

LaTeX képletek gyors renderelésére felhasználható kis program. Használata egyszerű: latex-kód beírása (a sallangok nélkül, azt jól kitalálja), klikk a LaTeX it! gombra, és az eredményként kapott képet már át is lehet húzni tetszőleges programba (pl. prezentációkészítéshez vagy a Finderbe – ekkor pdf formátumban kapjuk meg a képeket). Hasznos…

http://ktd.club.fr/programmation/latexit.php

5. Skim

Szép és jó a beépített Preview pdf olvasásra, de érdemes lecserélni a Skimre. Ugyanazt a motort használják, a Skim (ahogy észrevettem, ez nem 100%, hogy korrekt) két dologban tud többet: egyrészt ki van hegyezve a dokumentum annotálására, azaz különféle megjegyzések hozzáírására, ezen megjegyzések közötti keresésre, valamint LaTeX editorokkal nagyon szépen együttműködik (pdfsync v. synctex alapú szinkronizáció: bekezdés szinten lehet kapcsolatot teremteni az editor és a Skim között).

http://skim-app.sourceforge.net/

6. Forrásmenedzsment: Bibdesk vagy Zotero

Hivatkozások kezelésére használható a Bibdesk alkalmazás vagy a Zotero Firefox plugin. A Bibdesk gyakorlatilag egy grafikus editor BibTex fájlok kezelésére, míg a Zotero egy általánosabb segédlet próbál lenni. A Bibdesk Bibtex fájlokhoz jobban köthető, míg a Zotero killer feature-je, hogy képes a különféle oldalakról (pl. ACM, IEEE, stb.) automatikusan kinyerni a hivatkozási információkat. Más szóval, ahogy megtalálom a neten, már meg is van a hivatkozás. Viszont a bib-exporttal vannak apróbb bugok (gyorsan, akár search and replace-szel javíthatóak, de attól még lehet vele szórakozni).

http://zotero.org

http://bibdesk.sourceforge.net/

7. Site Specific Browser Mac módra: Fluid

Tetszőleges webes alkalmazás becsomagolása Maces alkalmazássá (hasonlóan, mint amit a Google Chrome vagy a Mozilla Prism végez), de van benne néhány Mac-specifikus feature, pl. lehet benne menüsorba csatlakozó alkalmazást csinálni. Másik hasznos feature, hogy lehet hozzá Greasemonkey scripteket telepíteni. Képes a külső url-eket (nem alkalmazáshoz tartozó) tetszőleges programhoz továbbítani. A flickr egyik csoportja nagyfelbontású ikonokat is készít ilyen SSB-khez: http://www.flickr.com/groups/fluid_icons/

http://fluidapp.com/

8. Videolejátszás: Perian, Flip4Mac, VLC

Ha az ember alapvetően szereti a Quicktime-ot (főleg, amióta nincs letiltva benne a full screen playback :D ), jó dolog kiegészíteni a tudását. A Perian és a Flip4Mac kodekeket telepít hozzá, amivel a leggyakoribb formátumokat képes lesz lejátszani. További bónuszpont, hogy ezek a kodeket iTunes és Front Row alatt is működnek. Ha ezek a pluginek mégsem megfelelőek, akkor jöhet az igazi svájcibicska, a VLC. Nem láttam még olyan videofájlt, amit nem tudna az lejátszani, és van néhány érdekes, extra szolgáltatása a programnak, mint a felvétel vagy a streamelési lehetőségek. De kicsit kényelmetlen használni, ezért nem ez lesz az elsődleges médialejátszóm.

http://perian.org

http://www.telestream.net/flip4mac-wmv/overview.htm

http://videolan.org

9. Szótár widgetek

Készültek widgetek a sztaki többnyelvű szótáraihoz. Egy-egy kereséshez gyorsabb lehet, mint az oldalukat direktben használni.

http://www.macmini.hu/html/dashboard.html

10. Caffeine

Láttam már előadás közben beindulni a képernyőkímélőt. Más esetet is el tudok képzelni, amikor hasznos a különféle energiagazdálkodási funkciók ideiglenes kikapcsolása – de ugyanakkor nem szeretném a beállításaimat túl mélyrehatóan módosítani. Pontosan erre a célra használható fel a Caffeine. Egy egyszerű ikon a menüsorban az óra mellett, egy kattintással aktiválható/deaktiválható. Az egyetlen problémám vele, hogy bekapcsolt állapotában az Adium nem veszi észre az inaktivitást (feltehetőleg más programot is érint).

http://lightheadsw.com/caffeine/

+1. Kedvenceim: QuickSilver vagy Google Quick Search Box

Nehéz körülírni, hogy pontosan mit is csinálnak ezek. Ami magától értetődő, az az, hogy programok gyorsindítására felhasználhatóak (bár erre a Leopardban már a Spotlight is megfelelő – Tigerben még lassú volt ehhez). De ezen felül további parancsokat is ki lehet adni a segítségükkel: pl. fájlkeresés, átnevezés, emailhez csatolás, twitter üzenet küldése vagy éppen új feladat felvétele a naptárba.

A programok közti választás nehézkes: a Quicksilver határozottan többet tud, többen írnak hozzá plugineket, viszont a fejlesztése, sorsa kérdéses, ráadásul megosztott a fejlesztő csapat. A Quick Search két-három hónapos lehet, sokkal egyszerűbb a rendszer, de valahogy megbízhatóbbnak érzem ezt a kevesebb szolgáltatást. Figyelem mindkettőt, kérdés, kinek melyik a nyerő.

http://code.google.com/p/qsb-mac/ (Quick Search Box)

http://blacktree.com/?quicksilver

—————————————-

Ha a lista nem elég, akkor hasznos lehet az http://osx.iusethis.com vagy a http://wakoopa.com böngészése további találatokért. Szociális hálóban gyűjtik, ki milyen alkalmazásokat ismer/használ.

Apropó, nektek van olyan programotok, ami szerintetek fontos, és itt nem szerepel? Kíváncsi vagyok.

Volt szerencsém egy-két kernel pánikhoz OSX-en. Szépen néz ki, ahogy elszürkül a háttér, és közli, hogy gáz van, indítsam újra a gépet, de viccesnek nem vicces. Viszont újraindítás után lehetőséget ad, hogy elküldjem a crash reportot, és nem mellesleg megnézzem az utolsó logokat.

Az első alkalommal nem sokat foglalkoztam vele, de amikor legközelebb előjött, akkor rájöttem, hogy akkor történt, amikor a külső merevlemezem csatlakoztatva van. A log tanulmányozása, illetve némi előismeret segítségével egy gyors googlizás kihozta, hogy nem én vagyok az egyetlen, aki a problémával szembesült, és volt rögtön workaround is.

A külső merevlemez NTFS-ként volt megformázva, amit a MacFuse és az NTFS-3G kombinálásával csatoltam fel. Ez a kernel panicot különösen súlyossá tette, mert az NTFS-3G nagyon érzékeny az érvénytelen adatokra – pl. abban az esetben, ha nem volt rendesen leválasztva Windows-os gépeken, akkor egyszerűen nem csatolja fel, stb. Szóval a kernel panicot követő meghibásodás után lehetett szórakozni vele, hogy újra csatolni lehessen. Szerencsére a VMware sokat segít azzal, hogy a külső USB portot átadhatom egy virtuális gépnek, így relatíve kis szívással átcsatoltam Windowsra.

Visszatérve az eredeti problémára a log alapján a bug akkor lép elő, ha a Spotlight próbálja indexelni a felcsatolt lemezt. A megoldás egyszerűen az volt, hogy ki kell kapcsolni az indexelést a Fuse-os lemezekre. A beállítás megtehető: System Preferences/Spotlight/Privacy

Természetesen ez bug, később még javíthatják. Ha ez megtörténik, akkor jelezni fogom.

További információ található a következő levelezőlista threadben: http://groups.google.com/group/macfuse/browse_thread/thread/cd7df99cb5d9cd7f/40bbbd3d13ece42c#40bbbd3d13ece42c

Ugyancsak a múltkor ígértem meg [[Dokumentumszerkesztés OSX-en Stampie módra|dokumentumszerkesztés kapcsán]], hogy írok részleteket a [[http://texlipse.sourceforge.net/|TeXlipse]] beállításáról úgy, hogy minden jól menjen a gépen. Az akkori ígéretben még az is benne volt, hogy akkor nem találkoztam még a koncepció gyermekbetegségeivel. De ennek ellenére érdemes lehet leírni, hátha más is fel tudja használni az itt leírtakat.

Talán éppen emiatt merem azt mondani, hogy érdemes lehet megvizsgálni akár más platformokra is, amiket itt leírtam, mert a TeXlipse szinte mindenhol működik, és a többi platformra is van pdfsync-képes program.

Fontos megjegyzés: a TeXlipse a verziószáma ellenére helyenként még kicsit nehézkesen használható, főleg, ha bizonyos új komponensekkel kerül együttes felhasználásra, de ennek ellenére jól használható TeX környezet kialakítására alkalmas.

De mielőtt belecsapnék a lecsóba, még egy ügyes OSX-es programra szeretném felhívni a figyelmet: a [[http://texlipse.sourceforge.net/|Skim]] nevű PDF nézegető program sokkal alkalmasabb a LaTeX kimenetének nézegetéséhez, mint a beépített Preview nevű program (ami azért a rossztól még mindig távol áll, de hát az Apple programjait is felül lehet múlni :) ). Miért is? Az egyik hasznos dolog, hogy bizonyos esetekben be lehet állítani, hogy automatikusan töltse be a megváltozott pdf fájlt, és tudja a pdfsync nevű dolgot.

Ezek mik is? Hogyan is lehet őket használni? Haladjunk sorban. A módosított fájlok újratöltése egy hasznos lehetőség, hiszen így lehetővé válik, hogy a Skimre átváltva mindig a legfrissebb változatot lássam. Hogyan kell igénybe venni? Először is a Preferences ablak Sync fülén engedélyezni kell a Check for file changes kapcsolót. Ezután, ha észleli, hogy a megnyitott fájl frissült, megkérdezi, hogy be akarjuk-e tölteni. Azért nem tölti be automatikusan, mert ha a fájlhoz tartoztak nem mentett megjegyzések, kijelölések, akkor azok elvesznek. De a kérdésnél rögtön megjelenik az Auto kapcsoló, amivel a folyamat automatizálható – egészen a Skim leállásáig. Zsír.

Amivel még sok jót lehet kezdeni, az a pdfsync. Ez egy viszonylag modern megközelítés, alapvetően az a célja, hogy bizonyos metaadatokat állítson elő, amivel meg lehet állapítani, hogy a pdf fájl melyik sorához a tex forrás melyik sora tartozik (tudomásom szerint alapvetően pdf fájlokhoz képes szinkronizálni, aminek az egyik oka lehet, hogy az [[http://itexmac.sourceforge.net/pdfsync.html|OSX-specifikus LaTeX-szerkesztő]] számára készült el az elején, OSX-en pedig a ps, illetve dvi fájlokkal nehéz mit kezdeni, a pdf-et viszont gyárilag hihetetlenül kényelmesen kezeli. És ez az oka annak is, hogy a LaTeX-et a pdflatex fordítóval érdemes fordítani… Na mindegy, visszatérve a pdfsynchez, ez a metaadat csak akkor használható, ha mind a szerkesztő, mind a nézegető képes értelmezni az adatokat. Az én esetemben ez fennállt, csak megfelelően be kellett állítani a rendszert.

A Skim beállítása viszonylag egyszerű: az előbb emlegetett Sync lapon vannak a kapcsolódó beállítások. Miután a TeXlipse-et nem ismeri, kénytelen voltam egyedi sablont beállítani. A TeXlipse dokumentáció [[http://texlipse.sourceforge.net/manual/build.html|vonatkozó részei]] alapján létrehoztam egy egyszerű script fájlt (be lehetne írni az egyedi paraméterek közé is, de külön fájlban jobban kezelhető), és a fájl tartalma a következő lett:

1
java -classpath /Applications/eclipse/plugins/net.sourceforge.texlipse_1.2.2/texlipse.jar net.sourceforge.texlipse.viewer.util.FileLocationClient -p 55000 -f $2 -l $1

Itt a classpath-nál meg kellett adni a telepített texlipse jarját (sok sikert a kikereséséhez a plugin mappából :) ), a FileLocationClient egy hozzáadott érték, a -p után pedig egy portszámot kell megadni, amit a TeXlipse beállítások között is szerepeltetni kell (nyilván ugyanazt a számot :) ).

A Skim pdfsync paraméterei között egyrészt ezt a fájlt kellett megadni, másrészt paraméternek a %line “%file” paramétereket kell megadni – ezek segítségével lehet visszahívni a szerkesztőt. Ha más szerkesztőt akarunk használni, akkor nyilván a szerkesztő dokumentációjából kell kiszedni a dolgokat. De például az Aquamacs különösebb beállítás nélkül is viszi a szolgáltatást.

Mindenesetre nézzük akkor, hogy mit kell beállítani az Eclipse-ben, hogy működjön. Először is a TeXlipse számára kell a Skimet felvenni megjelenítőként – itt viszont nem a szokásos Skim.app/Contents/MacOS/Skim hívást kell megtenni, hanem egy külön script segítségével kell értesíteni, azaz a Skim.app/Contents/SharedSupport/displayline elemet kell megadni futtathatóként a TeXlipse számára, míg paraméterekként a %line %file %texfile értékeket (a leírások ajánlják a %file és a %texfile értékek idézőjelek közé helyezését, mert ekkor szóközt tartalmazó fájlok esetén is működik, de nálam úgy nem működött a rendszer – a Skim nem találta meg a hivatkozott fájlt).

Ja, igen, a beállítás helye: Eclipse Preferences, TeXlipse/Viewer Settings, és itt lehet felvenni egy új nézőprogramot. A Viewer input format értéke pdf, az Inverse search support értéknek a “Viewer runs external command” értéket kell megadni, és be kell jelölni a “Viewer supports forward search” jelölőnégyzetet. És ha ez megvan, akkor a nézőprogramok listája alatt a megfelelő portszámot be kell állítani.

Na, ha ez megvan, akkor lehet tesztelni. A tex fájl elejére még hozzá kell adni a pdfsync package-et, és jöhet a menet.

Sajnos nálam nem sikerült minden esetben futtatni a megoldást: abban az esetben, ha a forrásfájl, a létrehozott pdfsync fájl és a pdf fájl egy mappában volt, nem több fájlból állt a tex projekt, és nem használtam bibtex-et. Szóval sajnos nem csak a gyakorlatban lényegtelen esetekben nem működött, hanem sajnos elég sokszor… De amikor működött, akkor a Command + 4 (win-esek, linuxosok: ctrl+4) billentyűkombinációval az Eclipse-ből a pdf fájl megfelelő részére ugrott, a pdf fájlból pedig a Command+Shift lenyomása mellett kattintva lehetett visszaugrani az Eclipse-be. Sajnálom, hogy ez most nem működik.

Ha valakinek ezt sikerül jobban működésre bírni, esetleg képes megoldani a rendes futtatást, érdekelnek a részletek.

Ma sikerült egy másik problémakörbe belefutnom a LaTeX szerkesztés kapcsán. A gond akkor lép fel, ha megpróbáljuk SVN-en osztani a LaTeX projekt mappát, és különböző mappában vannak a forrásfájlok és az ideiglenes fájlok. Hihetetlenül idegesítő tud lenni, hogy minden egyes fordításkor (amit gyakorlatilag minden mentés triggerel), és hibaüzenetek nagy tömegét kapom, hogy nem tudta átmozgatni az elkészült ideiglenes fájlokat, mert nem sikerült felülírnia a fájlokat – hála annak, hogy az nem került feltöltésre az SVN szerverre.

Az egyedüli lehetséges megoldás az volt, hogy az ideiglenes fájlokat hozzá kellett adni az svn:ignore változóhoz, hogy ne akarja őket egyáltalán feltölteni az SVN szerverre. Ehhez a projekt jobb gombos menüjéből a Team/Add Property… pontja alatt felbukkanó ablakban kellett adatokat megadni: megadtam a paraméter nevét (svn:ignore), beállítottam, hogy a szabály rekurzívan teljesüljön minden erőforrásra, és a következő értékeket adtam meg a beviteli mezőbe:

1
2
3
4
5
6
7
8
9
10
11
12
*.aux
*.bbl
*.blg
*.bst
*.dvi
*.idx
*.lof
*.log
*.toc
temp
tmp
main.synctex.gz

Ez a megoldás megszüntette a problémát, ezzel lehetővé téve, hogy tovább működtessem a rendszert.