hogyancsináld – Page 2 – cubussapiens.hu

Színbeállítások Eclipse-ben – javított megoldás

Ahogy tegnap is írtam, [intlink id=”623″ type=”post”]Eclipse-hez beállító ablakokat[/intlink] könnyen lehet készíteni. De ez még mindig bonyolultabb, mint az optimum, ha csak színeket (és esetleg betűtípusokat) akar az ember beállíthatóvá tenni.

Hogy miért is mondom ezt? Azért, mert így teljesen úgy beállításlapot kell csinálni, amikor az Eclipse már tartalmaz egy színbeállítással foglalkozó oldalt (General/Appearance/Colors and Fonts). És ha az ember jobban megnézi, akkor itt bizony jó néhány olyan beállítás is szerepel, ami semmilyen hivatalos Eclipse csomagban nincs benne, innen kezdve adódik a következtetés: kiterjeszthető. 🙂

És valóban: az [cci]org.eclipse.ui.themes[/cci] kiterjesztési pont az, amit mi keresünk. Ami lényeges előrelépés az általános beállításpanelhez képest, hogy itt a beállításokat mindössze a plugin.xml megfelelő kitöltésével megoldhatjuk, és ez rögtön legenerálja a megfelelő felhasználói felületet. Lustaság fél egészség.:D

De a lényeg az egészben, hogy ez oda kerül, ahol a többi hasonló beállítás van, ezért talán a felhasználó is könnyebben megtalálhatja (nem szabad elfelejteni, hogy az Eclipse környezetnek a célközönsége nem a mezei felhasználó, hanem annál hozzáértőbbek, legalább poweruser-ek, de egyelőre még inkább programozók, így megengedhető, hogy az összes beállítás így jelenjen meg).

A kiterjesztéshez definiálhatok különböző paramétereket: ami az én esetemben lényeges volt, az a [cci]themeElementCategory[/cci] és a [cci]colorDefinition[/cci] attribútumok: az előbbivel egy kategóriát definiálhatok, míg a másodikkal színeket (a betűtípusok definiálásához a [cci]fontDefinition[/cci] attribútumot lehet használni, hasonlóan a colorDefinitionhöz).

A színekhez meg lehet adni egy alapértelmezett színt (nem kódban, hanem az XML-ben), ezt a value elemhez érdemes tenni, egy színazonosítót (a későbbi hivatkozáshoz), valamint egy categoryId-t (itt lehet megadni a korábban definiált kategóriát). A plugin.xml grafikus szerkesztőjén teljesen magától értetődő a kezelés.

A kategóriának meg egy Id-t és egy feliratot kell megadni.

Ha ezeket az elemeket megadtuk, akkor már késznek is tekinthető a beállítási felület, és nincs más hátra, minthogy a kódból elérjük a színeket. Ez hasonló bonyolultsággal, de kicsit eltérő kóddal kezelhető, mint a beállítások esetén. Kicsit konkrétabban:
[cc_java]IThemeManager themeManager = PlatformUI.getWorkbench()
.getThemeManager();
ITheme theme = themeManager.getCurrentTheme();
ColorRegistry colorRegistry = theme.getColorRegistry();
ENTITY_BG = colorRegistry
.get(“org.eclipse.viatra2.visualisation.entity.background”);[/cc_java]

Betűtípus lekéréséhez pedig a getFontRegistry hívással kell a témától elkérni a betűtípus-tárat, és annak a get metódusával a betűtípusokat lehet megkapni. Az így megkapott Color, ill. Font objektumokat nem kell felszabadítani, ezt a rendszer elvégzi helyettünk.

Ennyi munkával már össze lehet rakni egy jól működő beállításablakot, ezt képekkel illusztrálva a következő oldalon is lehet látni (angol nyelven): http://blog.eclipse-tips.com/2008/08/adding-color-and-font-preferences.html. Így ennyit se nagyon kellett volna írni, de egy aprósággal ezt is kiegészítettem még: a kiterjesztés megengedi, hogy egy előnézetet hozzak létre az így elkészült beállítási ablakhoz. Hogy megmutassam, ezzel mire gondolok, megmutatom az elkészült panelt.

Az elkészült színbeállítóablak grafikus képe

Röviden: összerakhatok egy tetszőleges SWT formot, ami megjeleníti a beállítások eredményét. Ehhez a kategória class nevű attribútumát kell beállítani egy általunk létrehozott osztályra. Az interfész két metódus megvalósítását követeli meg: egy [cci]createControl[/cci] és egy [cci]dispose[/cci] metódust. A megvalósítás magától értetődő(nek tűnik): a createControl mindig meghívódna, amikor a beállítások módosulnak.

De sajnos nem. Az csak egyszer hívódik meg. Ezért a [cci]createControl[/cci] futása során fel kell iratkoznunk a téma változásaira az [cci]addPropertyChangeListener[/cci] metódus segítségével, és amikor ott befut az eredmény, akkor frissíteni kell az előnézetet.

Az előnézetet tényleg tetszőleges módon meg lehet valósítani, én például simán hozzácsaptam egy Zest Graph Viewert, és azt paramétereztem fel némi “dummy” adattal, és az eredmény a fenti képen látható (és a gyakorlatban tényleg azonnal frissül 🙂 ).

Ez az kiterjesztés láthatóan arra van kihegyezve, hogy egységes módon lehessen színbeállításokat tenni, és ennek a legjobb módja, hogy ne adjuk ki a kódot a kiterjesztő kezébe, hanem csak lehetőséget adjunk a felparaméterezésre. Ugyanakkor ez kellően rugalmasan sikerült megoldani, és a dokumentáció alapján tényleg magától értetődő a kitöltés. De nem szabad elfelejteni, hogy ez nem egy teljes körű megoldás, például vonalvastagságot vagy vonaltípust itt beállítani nem lehet, noha grafikus pluginek témabeállításaihoz ez is hozzátartozik.

Eclipse Preference Page készítésről röviden

A héten egy „egyszerű” problémát kellett megoldanom: egy Eclipse-pluginhoz konfigurációs lehetőségként kellett lehetővé tennem színek kiválasztását. Elhangzott ötletnek, hogy csináljak akár Java properties fájlokat vagy valami hasonlót (értsd: kódold le kézzel), de ha már Eclipse házinak készül a dolog, inkább úgy döntöttem, nézzük meg, hogy az Eclipse mit kínál.

Egyik természetes megoldásnak tűnik egy saját Property page létrehozása, amin be lehet állítani a megfelelő színeket. Ehhez kiderült (némi keresgélés után, ez tényleg gyorsan megvan), hogy az org.eclipse.ui.PreferencePages kiterjesztési ponthoz kell kapcsolódni. És még további próbálkozás után kiderül, hogy érdemes legeneráltatni a mintát az Eclipse-ből, mert lényegesen okosabb kódot rak össze, mint ami az interfész naiv implementációjából kijönne. De erről egy kicsit később.

Az extension point igényli, hogy megadjuk, milyen névvel illetve milyen másik Page alá szeretnénk betenni az új lapunkat, ami lehetővé teszi a kényelmes hierarchikus beállításszervezés összeállítását. Nice.

Ami meglepően egyszerűvé teszi az oldal tervezését, hogy a JFace API tartalmaz beépített FieldEditor osztályokat, így a beállítások lap tervezéséhez egyszerűen annyira van szükség, hogy ezeket (esetleges SWT konténerekkel együtt) kidobálok egy API-tól kapott konténerre. Triviális. És ami még fontosabb, egy percig sem kell azzal szórakoznom, hogy mikor/hogyan mentsem ki az adatokat a háttértárra, hogyan olvassam ki a mezőkből, mert ezt automatikusan elvégzi a rendszer. Nekem csak minden egyes mezőhöz egy azonosítót kell rendelnem, és a többi már gyorsan megy. Ha valami speciális feltételek vannak a kitöltéshez, ahhoz pedig a legtöbb komponens validator hozzátételével működik – ezzel az egyszerű struktúrával a legtöbb gyakorlatban előforduló eset kezelhető (szerintem).

A FieldEditor osztályok nagyon könnyen kezelhetőek: van köztük színválasztó, fontválasztó, egyszerű szöveges beviteli mező, checkbox, könyvtárválasztó és még sok minden más, egyszóval a gyakorlatban előkerülő legtöbb igényt le lehet fedni velük. És ami igazán fontos: ezek a megfelelő natív dialógusokat hívják be (pl. OSX-en a natív színválasztót, nem valami Javaból összetákolt valamit…).

A generált mintakód igazából három fájlból áll: a PreferenceConstants.java fájlban konstansokat lehet felvenni, amellyel később azonosíthatjuk az elmentett adatokat, a PreferenceInitializer.java fájlban a kezdőértékeket, míg az általunk választott nevű harmadik fájlban lehet összerakni a tényleges adatokat. Ezeket a fájlokat tovább nem is elemezném, ha valakit jobban érdekel, nézze meg, ennyi ismerettel könnyen érthető és módosítható igény szerint. Vagy meg lehet nézni a http://www.eclipsepluginsite.com/preference-pages.html oldalon a részletesebb kifejtést.

Inkább csak azt írom le, hogy ebbe hogyan lehet betenni a színkezelést (amit nem ír le az eredeti forrás). A form összerakásakor egyszerűen ColorFieldEditor-t kell létrehozni, hasonló paraméterezéssel, mint a mintában, míg az inicializálásnál a következő módon lehet gondolkodni:
PreferenceConverter.setDefault(store, PreferenceConstants.P_ENTITY_BG_COLOR, new RGB(216,226,248));

Azaz egy RGB értéket példányosítok, és ezt töltöm be alapértelmezésként. Ettől a pillanattól kezdve van egy kész színbeállító komponensem, menti is az adatait. Zsír. Akkor már csak egyszerűen be kell tudni olvasni. Szerencsére ez sem túl bonyolult. Ha egyszerűen Stringként akarom beolvasni a beállítást, és a stringet átadni a Color konstruktornak, akkor a következő kód jöhet számításba:
IPreferenceStore store = RmpPlugin.getDefault() .getPreferenceStore(); String colorCode = store.getString(PreferenceConstants.P_ENTITY_BG_COLOR);

De lehet egyszerűbben is: a JFace tartalmaz egy PreferenceConvertert, aminek segítségével ez még egyszerűbben elintézhető.
RGB color = PreferenceConverter.getColor(store, PreferenceConstants.P_ENTITY_BG_COLOR);

Röviden összefoglalva ez is egy kényelmesen használható API, jól illeszkedik az Eclipse filozófiájába, aminek az az előnye, hogy gyorsan megtanulható, ráadásul kellően rugalmas is. Az előre megírt FieldEditorok pedig tényleg egyszerűvé teszik az egységes (ráadásul ugyanakkor platformfüggő!) kinézet összerakását a beállítópanelen is.

Ugyanakkor a végleges megoldásom nem ezt a menetet követi, helyette egy másik beépített megoldást használtam, de arról majd inkább legközelebb írok egy kicsit.

Navigáció IPAQ módra

A probléma azóta foglalkoztat, hogy szerencsé[s/tlen] felhasználója lettem egy HP Ipaq rx3715-nek. Aki [intlink id=”552″ type=”post”]olvasta[/intlink], tudja hogy volt már egy próbálkozásom lecserélni az operációs rendszert, amivel sikeresen megátkozták a kütyüt, de sajnos az a projekt befulladt, így marad a Windows Mobile 2003SE, ezen kell megoldanom a navigációt. Az integrált GPS vevő hiánya által okozott hardveres korlátot egy NAVILock bluetooth vevő oldotta fel. A problémát már csak a megfelelő program kiválasztása okozza.

Kézenfekvő megoldásként elöször Aeromap merült fel, hiszen a kütyühöz vásárláskor kaptam egy licensz kódot hozzá, ami ráadásul a honlapról letölthető újabb verziókkal is működik. Az Aeromap teljeskörű navigációt ad Magyarország területére, a legtöbb városban házszámszintű térképpel, útvonal-kereséssel és hangos irányítással. Remekül működik, amíg határon belül maradunk, Magyarország határát átlépve viszont kiesünk a nagy semmibe. Bár ritkán járok külföldön úgy, hogy térképre is lenne szükségem (mivel nem egyedül vagyok), de úgy döntöttem körülnézek más megoldások után, főleg az ingyenesen hozzáférhető szoftverek területén.

Első lépésként a Google Maps Mobile felé vetettem a tekintetem, ami a Google maps térképeit használja, amiket közvetlenül az internetről tölt le, és képes GPS alapján pozicionálni is. Apró probléma, hogy ha nincs útközben folyamatos internet kapcsolat, akkor nincs térkép se. Ráadásúl az újabb verziókban megjelent egy idegesítő bug (vagy feature?), miszerint a program csak és kizárólag GPRS vagy UMTS kapcsolattal tud az internethez csatlakozni, Wifi-n keresztűl nem hajlandó. Bár ez megkerülhető, ha az ember keres egy megfelelően régi verziót, de láthatóan ez a program nem arra lett kitalálva, amire én használnám. Az rx3715 nem telefon, nem lehet mobil hálózathoz csatlakoztatni, így nincs internetkapcsolatom út közben.

A következő állomás az Open Street Map wikije volt, ahol van egy kimerítő felsorolás a programokról, melyek elérhetővé teszik egy átlag felhasználó számára az OSM térképeket. A felsorolásban több WM program is szerepel, melyek többsége java-t igényel, így számomra nem jöhet szóba (egyelőre, megfelelő JVM-et keresni egy WM 2003 kütyüre nem egyszerű, és nem tárgya a jelen cikknek). A natív programok közül kettőt emelnék ki, melyekkel kicsit többet foglalkoztam.

A Bluemapia egy főleg hajózásra kifejlesztett program. Az érdekessége az, hogy több ingyenes térképszolgáltatóról is képes adatot gyűjteni, közöttük a fent említett OSM, a Google Maps és a Microsoft Map. Azonban sajnos internet kapcsolat nélkül ez sem működik, akkor sem, ha letöltjük a térképeket offline tárolóba.

Utoljára a TurboGPS-t néztem meg, ami alapvetően offline adatokkal dolgozik, bármilyen raszterizált képet meg lehet neki adni térképként, megadva a kép sarkainak koordináltáit, és erre képes rápozicionálni a GPS koordinátákat. Ahhoz, hogy ilyen térképeket kapjunk, használhatjuk az OSM automatizálható letöltőjét, majd a letöltött képeket át kell neveznünk a térképeket a poziciójuknak megfelelően a következő leírás alapján: http://www.turboirc.com/forum/index.php?topic=117.0.

Sajnos egyelőre a nyílt forráskódú alternatívák nem versenytársai az olyan kereskedelmi megoldásoknak, mint az Aeromap vagy az iGo, főleg Windows Mobile rendszeren. Linux alapú eszközön jobb a helyzet, bár útkeresés, illetve irányított navigáció csupán néhány projekt tervei közt szerepel, megvalósított módszert még nem láttam. Talán egyszer megoldom azt is, hogy laptopomhoz csatlakoztassam a GPS vevőt. De ez egy másik történet lesz.

További pdfTeX gyöngyszemek

A múltkor beszéltem arról, hogyan érdemes szerintem [intlink id=”604″ type=”post”]LaTeX szerkesztést végezni OSX-en[/intlink] Eclipse kiterjesztés segítségével. Azóta némi további érdekességet sikerült összeszedni a témáról – és az ötletek szerintem a TeX környezetek többségére alkalmazhatóak.

Egyik alapvető érdekesség, hogy a pdfTeX motor csak a jpg, png és pdf fájlokat támogatja képfájlként. Ez egyfelől jó (lehet), mert bizonyos képek könnyebben elérhetőek ilyen formátumban, másrészt viszont rossz, mert ezek nem szerkeszthetők vektorosan olyan egyszerűen, ha úgy hozná a sors. Ezért lenne jó vagy svg vagy pedig eps támogatás hozzá.

EPS támogatás beizzítása pdfTeX motorhoz

Abban az esetben, ha az ember gépére telepítve van az imageMagick program, annak a convert parancsát ki lehet hívogatni, és ezzel szinte bármilyen formátumból bármilyen formátumot elő lehet állítani. A megoldás nyilvánvaló előnye, hogy hihetetlenül rugalmas, hátránya, hogy igényli a convert parancs jelenlétét a rendszerben – azaz a hordozhatóság csökken. A következő parancs megmutatja, hogy milyen jellegű utasítást kell kiadni a LaTeX preambulumban:

[cc]\DeclareGraphicsRule{.tif}{png}{.png}{`convert #1 `dirname #1`/`basename #1 .tif`.png}[/cc]

A DeclareGraphicsRule parancs során meg kell adni fájlkiterjesztést, amire figyelni kell, egy típust, egy beolvasási fájlkiterjesztést és egy parancsot. Részletek a következő pdf fájlban: http://www.ctan.org/tex-archive/macros/latex/required/graphics/grfguide.pdf

De tegyük fel, hogy eggyel hordozhatóbb megoldást szeretnénk. Itt jöhet szóba az az opció, hogy a legtöbb TeX disztribúció tartalmaz egy epstolatex parancssori alkalmazást – amint a neve is mutatja, ez egyszerűen eps fájlokat konvertál pdf-re. Külön előnye a programnak, hogy van egy package, ami ennek az egyszerűbb felparaméterezését teszi lehetővé. A package a könnyen megjegyezhető epstopdf névre hallgat.

Az alapértelmezett könyvtárstruktúra és az epstopdf parancs elérhetősége esetén mindössze a package-et kell importálni, és működik, némileg komplexebb felállás esetén a megoldás tovább hegeszthető. Én például azt valósítottam meg, hogy vegye figyelembe az img, src és temp mappákat, amikbe dolgozom, és miközben a LaTeX könyvtára az src, az eps-t az img-ből vegye, míg a pdf-et a temp-be dobja. Ezt a következőképpen sikerült elérni:

Először is megadtam a preambulumban a [cci_latex]\epstopdfsetup{outdir=../temp/,verbose}[/cci_latex] parancsot – ez a temp mappába teszi a pdf-et, és a verbose segítségével kicsit részletesebben kifejti a hasfájásait…
És ezután a képek beszúrásánál az [cci_latex]\includegraphics[width=10cm]{../img/csp.eps}[/cci_latex] módon adom meg a képfájlokat.

Ezután már a rendszer megfelelő hegesztés után elkezd működni. Az epstopdf package dokumentációja alapján a package-et rá lehet venni a DeclareGraphicsRule-lal, hogy mégse az eps2pdf-et használja, vagy ne az alapértelmezett paraméterezéssel.

PDF-specifikus beállítások a rendszerben

Ha csak simán pdfTeX-hel lefordítjuk a LaTeX forrásunkat, akkor már egy használható pdf fájlt kapunk – lehet böngészni meg továbbítani. De mi van, ha mi szeretnénk néhány fancy pdf feature-t kihasználni (na, ez szép hunglish lett 🙂 )? Tipikusan olyasmikre gondoltam most, mint az, hogy a pdf metaadatokat töltsük ki, illetve tegyük klikkelhetővé a hivatkozásokat, valamint a pdf megjelenítő számára is tegyük elérhetővé a dokumentum szerkezetét. Nem hangzik túl extrának, de nagyban növelheti az online olvashatóságot (aki kinyomtatja, annak nyilvánvalóan nem számít…)

Na, csapjunk is bele a lecsóba: a hyperref package jelenti a megoldást a problémára. A bekapcsolt állapot mellett automatikusan klikkelhetővé válnak a hivatkozások, és értelmezni fogja a dokumentum szerkezetét. A metaadatokat nem tölti ki azért automatikusan (noha nem lenne rossz 🙂 ). Mindenesetre ezeket a hyperref csomag opcionális paraméterei között lehet megadni, vagy pedig a hypersetup parancs segítségével. Részletek itt: http://andy-roberts.net/misc/latex/pdftutorial.html

Két fontos megjegyzés a hyperref használatával kapcsolatban: egyrészt opcionális paraméterről van ugyan szó, mégis érdemes megadni a fordítót (esetemben pdftex), ugyanis többféleképpen is keletkezhet pdf a kimeneten, és nem lehet ránézésre eldönteni, hogy melyik fog következni. Az előző oldalon szerepelnek a használható fordítók.

A másik: a hyperref csomagot olyan későn importáljuk, amennyire csak tudjuk (gyk. csak azt tegyük utána, amit feltétlenül szükséges), mert ellenkező esetben sok-sok warningot kapunk, hogy bizonyos hivatkozások megkettőződtek, stb. ami nem könnyíti meg a tényleges hibák felderítését. Ha a végére kerül, akkor ez a probléma nem lép fel (de legalábbis kevésbé). Igen, szép dolog a makrónyelv, ott ilyen szép kis függőségek is kialakulhatnak.

LaTeX szerkesztés OSX-en

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:

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:
*.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.