So we are now starting a blog…

Debug Visualisation for Eclipse… Who knows what is it good for. Maybe a quick detection of some misplaced references. Maybe more.

The project started as a home assignment for an Eclipse course at the university, but we were interested in it, so we continued the development. Our goal was to support the debugging process by helping the detection (or exploration) of the state space of the program.

We are not calling our software a 1.0 release, as we don’t think it can help in a lot of cases. But we believe it is worth to invest time to increase its usefulness. Maybe in the end something good will come out from it.

This page is started for reporting our progress, share ideas. We would be glad to hear your opinions about the project. Your idea may help – we are not capable of solving the problem in general, we need potential use cases. We need testing.

So to help the communication a blog is born. Please if you test our project, give us feedback: what do you like, what are the worst points. Do you have an idea to share with us? We are glad to hear it. Maybe we will implement it, if we are interested enough. Or if you implement it, we are glad to include it. So let’s rock.

Kiválasztás átvitele eclipse nézetek között

Érdekes problémákba ütközik az ember, ha eclipse környékén fejleszt. Ezek nagyrészét ugyan már megoldották, de a megoldást külön művészet megtalálni a tengernyi dokumentációban. Mindenesetre legalább dokumentálták. A probléma, amiben pár napja az örömömet leltem, az az, hogy hogyan lehet egy nézet által kiválasztott elemeket átadni egy másik nézetnek, ami természetesen hasonló modell felett dolgozik. Konkrétan a Debug Visualisation projektem által definiált nézetet akartam összekötni a Variables View-vel és vice-versa.

Érdekes problémákba ütközik az ember, ha eclipse környékén fejleszt. Ezek nagyrészét ugyan már megoldották, de a megoldást külön művészet megtalálni a tengernyi dokumentációban. Mindenesetre legalább dokumentálták. A probléma, amiben pár napja az örömömet leltem, az az, hogy hogyan lehet egy nézet által kiválasztott elemeket átadni egy másik nézetnek, ami természetesen hasonló modell felett dolgozik. Konkrétan a Debug Visualisation projektem által definiált nézetet akartam összekötni a Variables View-vel és vice-versa.

Pár óra keresgélés és javadoc olvasgatás után rábukkantam a megoldásra: Minden view-t tartalmazó IWorkbenchPartSite lehetőséget biztosít egy ISelectionProvider regisztrálására, amely interfészt ad kiválasztási információk kinyerésére és átadására, továbbá listener-ek regisztrálására. A másik, csatlakoztatni kívánt view által megadott ISelectionProvider-nek az általunk generált kiválasztási eseményeket át lehet adni, illetve figyelni lehet az általa generált ilyen eseményeket.

A problémát csak az okoz, hogy egy adott view által generált és elfogadott kiválasztandó elemek az adott view modelljéből kerül ki, tehát ugyanezen modell elemeit kell neki átadni. Ha az általunk írt view más modellen, vagy ugyanazon modell felett máshogy definiálja a kiválasztást, akkor a kiválasztást konvertálni kell a modellek között. Ez természetesen csak akkor oldható meg, ha egyáltalán értelmezhető a közös kiválasztás.

Mindehhez persze az első lépés az, hogy megtaláljuk a csatlakoztatni kivánt view-t, amit az azonosítójának ismeretében tehetünk meg a következő módon:


PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().findView(viewID).getSite().getSelectionProvider();

ahol a [cci_java]viewID[/cci_java] helyére a keresett view szöveges azonosítóját kell megadni. A Variables View azonosítóját az org.eclipse.debug.ui plugin egy [cci_java]IDebugUIConstants[/cci_java] nevű publikus interfész elérhetővé teszi.

Mint az eclipse esetében általában erre problémára is egy jól kitalált megoldás létezik, ami megfelelően egyszerű ahhoz, hogy a módszer ismeretében könnyű legyen implementálni, a nehézséget csak a módszer megtalálása jelenti.

Az első harapások az almából

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. [intlink id=”683″ type=”post”]Stampie válogatását[/intlink]. É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!

A 10+1 kedvenc OSX-es programom

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/

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

Új TeXlipse – új lehetőségek

Még októberben írtam arról, mire való a [[LaTeX szerkesztés OSX-en|synctex]], és ezt hogyan lehet felhasználni a Skim és a Texlipse környezet összekötésére. Illetve arról is, hogy helyenként problémás.

Most, hogy megjelent egy újabb Texlipse változat (1.3), és újabb, rövid határidejű LaTeX dokumentumokat kell előállítanom, ezért megnéztem, hogy mi a helyzet most.

Még októberben írtam arról, mire való a synctex, és ezt hogyan lehet felhasználni a Skim és a Texlipse környezet összekötésére. Illetve arról is, hogy helyenként problémás.

Most, hogy megjelent egy újabb Texlipse változat (1.3), és újabb, rövid határidejű LaTeX dokumentumokat kell előállítanom, ezért megnéztem, hogy mi a helyzet most.

Természetesen a helyzet rossz és reménytelen :D, de kicsit konkrétabban (és kevésbé pesszimistán szemlélve rá lehet jönni), hogy egészen pontosan mi/hogyan változott, és ezt hogyan lehet exploitolni.

A Texlipse 1.3-as változatának számomra legfontosabb újdonsága, hogy együtt működik a Skim auto reload funkciójával, azaz nem kell kézzel frissítgetnem a pdf kimenetet.

Ugyanakkor a synctex (vagy a hasonló célú pdfsync) továbbra sem az igazi. A pdfsync segítségével gyorsan tudok lépdelni a pdf illetve a tex-fájl egyes helyei között, ami roppant hasznos dolog, ha pl. aki proofreadel, az oldalszámmal tudja jelölni a hibát, amit kicsit nehézkes visszakonvertálni latex source-ra.

De ahhoz, hogy ez működjön, fontos, hogy a generált synctex.gz (pdfsync esetén most nem mondom meg a generált kiterjesztést) ugyanabban a könyvtárban legyen, mint a tex fájl, ugyanis a LaTeX környezet ebben a mappában keresi; ugyanakkor az is fontos, hogy ugyanabban a mappában legyen, mint a pdf fájl, mert a pdf néző meg ott keresi… Szóval a kiforrott, több-könyvtáros megközelítések problémásak tudnak lenni. De legalább így működik.

És még egy fontos dolog: amit a múltkor mutattam scriptet a Texlipse megszólítására, frissíteni kell, ugyanis direkt meg lett szólítva a texlipse.jar fájl, és a frissítés után az elérhetősége ennek megváltozott. Eltartott egy darabig, amíg erre a gondra rájöttem, ugyanis semmilyen hibaüzenetet nem kaptam a visszafele kereséskor. De azért csak meglett.

Az új, módosított scriptem:

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

És most a végére néhány apróság, amire érdemes lehet odafigyelni:

  • Ha még nem frissítettél az 1.3.0-s változatra, akkor várj pár napot, ugyanis felbukkant egy elég idegesítő bibtex parsing hiba. A hétvégére ígértek új kiadást.
  • Amikor frissíteni próbáltam, akkor a P2 valami miatt nem akarta letölteni a cuccot, de a dropins mappába könnyen tudtam telepíteni. Emiatt is változott az elérési útja a texlipse.jar-nak. Nem tudom, mi volt az oka, de majd egyszer esetleg ezzel is elszórakozom.

Alapvetően azért szeretem az új kiadást, de vannak gyenge pontok. Mindenesetre a váltást nem bántam meg, de jöhetne már az 1.3.1.:D