A beadott TDK dolgozatom – előadás is megvolt belőle. Figyelem: not for the faint hearted! Nem vállalok semmilyen felelősséget az okozott szellemi leépülésért. Viszont arra jó lehet, hogy megnézd, hogyan ne írj angolul 😀
A beadott TDK dolgozatom – előadás is megvolt belőle. Figyelem: not for the faint hearted! Nem vállalok semmilyen felelősséget az okozott szellemi leépülésért. Viszont arra jó lehet, hogy megnézd, hogyan ne írj angolul 😀
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á.
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:
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.
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.
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.
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.
Ez az írás egy tervezett sorozat első darabja: az ötlet (köszönet érte D-neenek) az volt, hogy írjuk le, hogy hogyan/miért úgy használjuk a gépünket különböző feladatok elvégzésére. Miután elméletben erről többen is írunk, ezért van rá esély, hogy a sorozat mások számára is hasznos lehet. Ha nem, akkor csak mi gondoltuk végig, hogy mit hogyan használunk, és ez segíthet abban, hogy még jobban összeszedjük a feladatainkat.
Ennyi bevezető után bele is csapnék a lecsóba: első alkalommal arról beszélnék beszélek írok, hogy mit használok dokumentumszerkesztésre. Illetve még inkább először is azt írnám le, hogy pontosan mit is értek itt dokumentumszerkesztésen. Első körben nagyjából azokat a feladatokat, amiket az Ms Office csomag elemeivel el lehet végezni (többé-kevésbé jó minőségben).
Kicsit részletesebben, illetve az általam végzett feladatokra szabva ez legfőképpen valamiféle szöveg készítése: a tipikus feladatok számomra mérési jegyzőkönyv, házi feladat, esetleg dokumentáció készítése, illetve egy-egy esetben prezentációt, illetve táblázatot készítek. Képeket, ábrákat lényegesen ritkábban készítek, ráadásul az egy külön kategóriát is alkothat a feladatok sokszínűsége miatt, ezért ebbe nem megyek most bele.
A feladatokhoz nem csak egyféle programot használok, méghozzá azért, mert a különböző részfeladatoknál más-más igényeket kell kielégíteni. De az általánosságban elmondható, hogy Microsoft Office nincs a gépen (egy 2004-es Mac-es változatból volt egy demo fenn, de szerintem egyszer sem indítottam még el…). Office csomagból 2+1-féle van telepítve: egyrészt megvettem az Apple iWork csomagját, másfelől az OpenOffice csomagot használom (ebből nagyjából párhuzamosan használom a hivatalos OO.o buildet, illetve egy alternatív, régebb óta az OSX-re fejlesztett NeoOffice csomagot).
A csomagok közti választás viszonylag egyértelmű: szövegszerkesztési feladatokhoz sokkal egyértelműbb, hogy az OpenOffice/NeoOffice csomag a nyerő, mert a saját formátuma is hordozható, és mellesleg ismerik valamilyen szinten a Word dokumentumot is (meglepően jól egyébként – persze messze nem 100%-osan). Az pedig meglehetősen általános felhasználási scenario, hogy közösen készül egy házi feladat – és a partner nem (mindig) ismeri a LaTeXet… Szóval marad a kompromisszum.
Érdekes módon prezentációkészítésre ha csak egy lehetőségem van, mindig az Apple programját használom. Ez talán azzal magyarázható, hogy a prezentációim gyakorlatilag mindig egyedül készülnek, nem annyira gond az, hogy meg kell osztani másokkal, és így jobban merek engedni a kompatibilitásból. De ez a kompatibilitási probléma azért a bemutathatóságot nem befolyásolja: ugyan a ppt-exportálási opcióban nem hiszek (ha az import sem igazán tökéletesen működik, ez miért lenne jobb?), de a pdf export minden igényt kielégít. Egy prezentációnak amúgy sem az animációkról kell, hogy szóljon – minden másra meg tökéletesen megfelelő formátum a pdf.
De akkor miért is áldozom fel a hordozhatóságot (legalábbis részben)? Azért, mert az Apple Keynote egy hihetetlenül kiforrott program, jól megtervezett felhasználói felülettel. Tele van apró, ügyes megvalósításokkal, mint az elemek egymáshoz való igazítása (bármelyik szélhez, illetve középvonalhoz lehet illeszteni, szükség esetén akár többhöz egyszerre) vagy éppen az Inspector logika a formázások kezelésére. Ez az Inspector egy külön ablak, amiben a formázásokat lehet egységesen kezelni. Hasonló szerepet tölt be, mint az MS Office 2007-ben a Szalag: tematikusan rendezetten tárja elénk a funkciókat, de ugyanakkor kevésbé forradalmian új a felület, így gyorsabb megszokni… Mindenesetre, akinek lehetősége van az iWorks 08-at kipróbálni (értsd: mindenki, akinek Mac OSX van a gépére telepítve), érdemes megpróbálni.
Táblázatkezelés: na, itt nincs egyértelmű preferenciám. Tetszik a Numbers (iWork) új megoldása, miszerint egy munkalaphoz több táblázat is kapcsolódhat, stb., de ennél a pontnál azért lényegesen fontosabb a hordozhatóság, valamint az is problémát okozhat, hogy a Numbers még csak az 1.0-s verziónál tart, szóval nagyon kiforrottnak még nem tekinthető, és ráadásul a funkciókészlete is korlátozott egy kissé – de ha csak alapdolgokról van szó, de azt nagyon színesen-szagosan akarjuk végrehajtani, arra kiváló eszköz (lehet – de részletesen nem teszteltem még).
Persze jól kifejlett kockafejként nem csak az irodai szoftvercsomagokat használom szerkesztésre. Egyik érdekes koncepció, amit elég hosszú ideje próbálgatok, az a wiki alapú tárolás. Előnyei közé sorolható az abszolút hordozhatóság: megfelelően telepítve akár még a saját gépemre sincs szükség a szerkesztéshez – hátrányai közé viszont az, hogy egy saját leíró nyelvet kell hozzá megtanulni – ami a wikik között nem is hordozható. Az én személyes preferenciám a Dokuwiki – ez egyszerű dokumentáció írására kiváló, de komoly, sokfelhasználós rendszernek (a sok itt nem a több szinonímájaként szerepel – egy pár fős Dokuwiki telepítést évek óta – sztem – sikerrel üzemeltetek) véleményem szerint nem igazán alkalmas.
És végezetül megemlíteném még azt a tényt is, hogy LaTeX szerkesztést is csinálok időnként – korábban erre az Aquamacs program AucTeX környzetét használtam. Ügyes volt benne, hogy inline previewt képes készíteni sokféle formázáshoz, valamint a gyárilag egészen korrektül összelőtt pdfsync támogatás – ez a támogatás annyit jelent, hogy a TeX forrás és a generált pdf fájl kapcsolódó részei között gyorsan tudtam ugrálni.
A múlt idő viszont azért van, hogy az Emacs sosem állt túlságosan közel hozzám, és az Aquamacs nem Macesítette eléggé, hogy könnyen megszokhassam. Viszont helyette segítségemre sietett a fejlesztők abszolút nehéz súlyú eszköze – az Eclipse. Igen, abszolút nehéz súlyú, mert gyakorlatilag csak kávéfőzésre nem lehet megtanítani (ok, ilyen alapon az Emacs-ről is lehetne beszélni, lásd még az XKCD kapcsolódó epizódját), valamint ehhez jobban is értek. Szóval a TeXlipse környezet mellett döntöttem, és ebben próbáltam összelőni a megfelelő kapcsolatot az Eclipse és az általam használt pdfsync kompatibilis szerkesztőprogram között. Némi dokumentációböngészés, valamint egy gyors shell script megírása után (pontosabban a dokumentációban szereplő módosítása után, de ez aztán senkit sem érdekel) már működött is. A részleteket külön írásban fogom közzétenni (ide behivatkozva), hogy annyira ne dobjam szét az írás témáját – noha ez mostanra már nyilván tökéletesen sikerült…
Nagyjából ez az arzenálom, ami a dokumentumszerkesztést illeti – nyilván még egynéhány segédprogrammal támogatom meg ezt az arzenált, hogy a káosz teljes legyen – de ezt megintcsak nem akarom túl részletesen mellékelni, mert akkor nyilván az írás lényegét borítanám. Remélem, van, akinek segített valamit ez az írás – bár gyanítom, hogy aki elolvasta, mostanra a pokolba kíván, hogy ilyenekkel húzom az idejét – de úgy érzem, lesz ez még jobb is. Főleg, ha olyan témát választok, amiről többet tudok írni. (Akkor még több időt fogok elrabolni azoktól, akik végigolvassák, amit írtam… 🙂 )
Update: elkészült a [intlink id=”604″ type=”post”]LaTeX szerkesztésről[/intlink] az ígért cikk.
Ritka eset, hogy szükségünk van rá, de velem megesett. Szükségem volt a java-t futtató rendszer típusára és architektúrájára. Ráadásul futásidőben. Az ok egyszerű. SWT alkalmazást fejlesztek, és nem akarok minden platformra külön kiadást csinálni, ne a felhasználó találja ki, hogy milyen rendszert futtat. De ez mellékes, a probléma adott, futásidőben kell meghatározni, melyik platformfüggő csomagot töltsem be?
Ritka eset, hogy szükségünk van rá, de velem megesett. Szükségem volt a java-t futtató rendszer típusára és architektúrájára. Ráadásul futásidőben. Az ok egyszerű. SWT alkalmazást fejlesztek, és nem akarok minden platformra külön kiadást csinálni, ne a felhasználó találja ki, hogy milyen rendszert futtat. De ez mellékes, a probléma adott, futásidőben kell meghatározni, melyik platformfüggő csomagot töltsem be?
Egyszerű a megoldás – írják a lelkes és segítőkész, ám nem teljesen tájékozott fórumozók – A System.getProperty() paranccsal le lehet kérni a szabványosított, így minden JVM-ben létező “os.name”, “os.version” és “os.arch” tulajdonságokat, amikkel egyszerű beazonosítani a futtató rendszert. A szabvány valóban rögziti, hogy milyen tulajdonságmezőknek kell lenniük, azonban ezeknek a lehetséges értékeit nem. Most jön csak a szenvedés.
A kisebb problémát az “os.name” mező jelenti, ami többé-kevésbé konzisztens értékeket ad vissza a Sun és az alternatív
Ennél sokkal komolyabb fejtörést okoz a rendszer architektúrájának meghatározása. Ennél rendkívül változatos értékeket tapasztaltam különböző gépeken, rendszertől függetlenül. Még a Sun JVM-ek se konzisztensek ebben. Az még nem túlzottan meglepő, hogy a 64 bites, intel-alapú rendszeremet “amd64”-nek hívja, hiszen a disztróm hivatalosan amd64-re van fordítva. Más gépeken viszont szinte véletlenszerűen kerül elő a fent említett megnevezés mellett “x86_64”, illetve “x64” is. További érdekesség, hogy mivel “Mac OS X”-en még nincs 64 bites 1.6os Java, így azt “i386”-osnak jelzi. Ebből látszik, hogy a kérdéses mező nem a rendszer, hanem a JVM tulajdonságát adja vissza. Ennél a pontnál elérkeztünk a régebbi, 32 bites rendszerekhez, ami lehet “x86”, “i386”, “i686”, és hasonszőrű társai bármelyike. Utolsóként megemlíteném a Power PC architektúrát, ami lehet “ppc”, vagy “PowerPC” elnevezésű is.
A fenti mezők értékeire vonatkozólag láthatóan a Sun berkein belül sincs megegyezés, különböző rendszereken, vagy akár csak különböző verziók más-más értéket adhatnak. A legnagyobb probléma mégis az, hogy ez nincs sehol dokumentálva! A néhány kicsit használható gyűjteményt lelkes felhasználók hozták össze, de ezek hiányosak, és/vagy régen frissültek. Íme az általam talált legjobb, ami határozottan kevés: [[http://lopica.sourceforge.net/os.html]].
Végső megoldás lehet kitaposott úton járni, azaz felhasználni egy már létező megoldást, ami talán megmondja, mégis milyen rendszeren vagyok. Hasonló megoldásokban szinte kizátólagosan az [[http://lopica.sourceforge.net/os.html|Ant]] projekt kerül szóba, ami tartalmaz egy osztályt, mely egy szimpla enumerált értéket állít elő a létező operációs rendszereknek megfelelően. Az “os.arch” változót pedig csak nemes egyszerűséggel kivezeti a felhasználó számára az összes JVM tulajdonsággal egyetemben. Továbbá az Ant csak fordítás-idejű megoldást kínál, ezzel én nem lettem okosabb.
Végső elkeseredésemben azon kezdtem agyalni, hogy a program első futásakor végigpróbálgatom az összes rendelkezésre álló SWT lib-et, és amelyik nem dob kivételt, az működik. Ha ehhez hozzávesszük, hogy felismerhetünk pár “os.name”, “os.arch” értéket, akkor nem is olyan elvetemült ötlet.
[[http://cubussapiens.hu/user/30|Happy]] [[http://cubussapiens.hu/node/593#comment-117|hozzászólása]] alapján a zseniálisan egyszerű megoldás:
package proba;
import org.eclipse.core.runtime.internal.adaptor.EclipseEnvironmentInfo;
public class EnvInfo {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
EclipseEnvironmentInfo eei = EclipseEnvironmentInfo.getDefault();
System.out.println(eei.getWS()+"."+eei.getOS()+"."+eei.getOSArch());
System.out.println(eei.getNL());
}
}
, ami nálam a következő kimenetet adja:
linux.gtk.x86_64
hu_HU
Stampie jól gondolta, ezt a problémát már megoldották az Eclipse-ben, csak akkor én ezt nem találtam meg. Az [[http://mobius.inria.fr/eclipse-doc/org/eclipse/core/runtime/internal/adaptor/EclipseEnvironmentInfo.html|EclipseEnvironmentInfo]] osztály a org.eclipse.osgi_3.4.0.v20080605-1900.jar csomagban található meg, és ez az swt csomagok elnevezésével kompatiblis jelölésekkel adja meg a rendszer jellemzőit.