Hi-DPI Eclipse screenshots


A picture is worth a thousand words.

Recently I was writing a paper based on EMF-IncQuery, and I wanted to include some screenshots. For good reasons, a 300 dpi photo was recommended, but that represents quite large resolutions for reasonably sized images. Although I couldn’t always get this resolution, but I found some nice tricks to use for later.

Eclipse always allowed configuring some fonts – some time ago I experimented with the theming capabilities of Eclipse 3.x, and could increase a few font sizes, but some widgets such as list or tree viewers did not support such theming. ((Note to myself: I want to experiment with the 4.x theming capabilities, and update the presentation theme to work with the CSS-based themes of e4.))

GMF-based editors, such as the Papyrus UML editor or the Ecore Diagram editor provide support for exporting the diagram in PDF format – a format that retains (most ((However, I did see some interesting glitches related to the background settings of Ecore Diagrams…))) graphical information of the diagram in a vector-graphic format, usable for inclusion in LaTeX documents.

The multitouch zooming support for Zest graphs also helped a lot for screenshots, as I could simply use all available screen area to get a nice shot. Even for graphs that do not contribute their Zoom Managers to the user interface.

Finally, OSX already supports Hi-DPI modes for its entire operating system (dubbed Retina Display), that can also be enabled on non-Retina displays with some hacking: basically by downloading the Quartz Debug program (details for Lion and Mountain Lion) I can reduce the visible resolution to 960×540 pixel on my Full HD monitor. It also supports the use of one monitor as HiDPI and the other as normal – that comes quite hand with applications that do not support HiDPI mode (such as Eclipse out of the box, or Firefox).

OSX supports HiDPI modes

One big issue was that Eclipse 4.2 does not support HiDPI resolutions out of the box. Luckily, this was already evaluated in Bugzilla, and in a corresponding Stack Exchange entry.  Basically, the info.plist file ((By the way, the XML syntax of the plist files is something awful – it reminds me of the parameter handling in shell scripts or console applications – odd numbered parameters are the keys while even ones are the values. Not that XML allows the definition of attributes or inlined elements – but who cares?)) of the Eclipse.app has to be updated to state it supports High DPI mode, and then the Application itself moved in order to OSX detect the changes.

As a result: Eclipse sees that it has a limited amount screen estate, while in practice it uses 4 times as many pixels. While it is not usable at all for everyday programming, it helped a lot for screenshot creation. ((Except when using Skitch – a nice screenshot manager app. But it does not know about the underlying HiDPI mode, and always created a low DPI shot.))

A low DPI version of a small screenshot
A HiDPI version of the same editor

Alltogether, there are various ways to create high definition screenshots in Eclipse. It helps knowing them and using accordingly. For this reason, I am curious what other ways are there to create screenshots with high resolution – how do you do it?

Generating LPG 1.0 parsers on OSX using Eclipse

In fall I began maintaining the parser of the VIATRA2 framework. Funny.

Mostly because it uses the LPG parser generator framework, and to make things worse, a very old version (v1.1) of it. Today it is available a new 2.0 version (since 2008), but they are not compatible at all, e.g. they define define packages in the LPG runtime. As the release was near, there was no chance of upgrading the parser, so we were stuck with version 1.0.

The problem with the old version is, that although it is written in C++, even its makefile uses explicitely the Visual C++ compiler, so simply compiling it for OSX is not possible. That means, every time I have to change the grammar file, I have to start a Windows binary. And I like to do it from Eclipse.

My two chances were Wine and VMware (not Parallels, because I don’t have a licence for it 🙂 ). The latter is too hard on resources and is so much harder to integrate with my Eclipse in OSX, so the first choice was Wine. Luckily the Wine developers did quality work, so the LPG generator binary can be run with wine.

The Eclipse integration is not too hard (at least in a basic way, that would work for a while), as there is support for running External tools using the appropriate icon from the toolbar (or from the Run menü).

Such an External tool can be parameterized using various variables of Eclipse, of which two are needed:

  • [cci]$resource_loc[/cci]: the file system path (not workspace-relative path) of the selected resource
  • [cci]$container_loc[/cci]: the the container folder’s (or directory) location, that holds the selected resource (also in the file system)

The tool will be the wine installation, as it will execute the lpg.exe binary, that will receive it as a runtime parameter. This way both the location of the lpg.exe binary and the lpg parameters have to be written to the tools parameters section. It is important to note, that the location of the lpg binary can be given using OSX paths, there is no need to translate them into Wine paths, Wine can handle native OSX paths.

LPG uses a working folder, where it puts the generated parser and AST classes. This will be defined using the [cci]$container_loc[/cci] variable.

LPG needs three types of information: the grammar file (that can be given as a parameter to LPG, we will use the [cci]$resource_loc[/cci] variable), an includes directory (for grammar snippets) and a templates directory (for parser and lexer templates).

The directories can either be found in the working directory (this is needed for local templates), given as parameters or set as environment variables. I choose the third one, as it seemed the most maintainable solution.

For this reason the [cci]LPG_INCLUDE[/cci] and the [cci]LPG_TEMPLATE[/cci] environment variables have to be set on the Environment variables tab respectively.

The described settings (except the environment variables) are shown on the following screenshot:

Running LPG with Wine on the current selection

After these settings are done, by selecting the parser.g file, it becomes possible to run this new tool, that will generate the various parser-related Java classes.

After running the tool, the console output of the lpg generator is shown, where all paths are listed beginning with [cci]Y:\[/cci], although the selected files appear in the folder structure of the Eclipse workspace.

There are some minor shortcomings of this integration: first I cannot use the pop-up menu to execute this tool, as the external tools are not listed. Another annoyance is, that the file has to be selected in Navigator view, the open editor is not enough.

This means, I have to select first the file in the Project Navigator (or Package Explorer, etc.), then run the tool manually from the Run configuration menu. Quite disturbing, but the grammar does not need to be changed too often.

Another problem is, that the error output of the generator is not back-annotated as Eclipse errors (problem markers), only a console output is available. For a brand new grammar this would be not the best solution, but for maintenance it is enough.

The LPG IDE of the IMP (IDE Metatooling Platform) project overcomes this challange by using a newer version of LPG, that is written in cross-platform C (or C++), and uses a builder (that automatically calls the LPG binary if the grammar files are changed), and the builder results are showed as proper error messages.

This means, the future for LPG development in Eclipse is the LPG IDE, but for legacy projects it cannot be used. In these cases my solution can become a good alternative.

Packaging Eclipse in OSX

Recently I experimented a bit with Eclipse packaging. At first it seems not very important, given that the folks at Eclipse work hard to produce executable packages. On the other hand, the Mac OSX packaging is not the best possible one.

The default folder structure of Eclipse applications on Mac OSX is something like follows:

In this structure Eclipse.app is a special folder, that acts as an executable item for OSX.

This structure is easy to produce, very similar to the ones of Windows or Linux, but there are some drawbacks. First, in the /Applications folder the folder icon is a generic folder, instead of an Eclipse icon (okay, this one is easy to resolve, as every folder can have a custom icon). More importantly, all indexer try identifies the executables by name. If there are multiple Eclipse instances installed, then every instance will have the same name displayed. If the path is also displayed, it is possible to distinguish between the instances.
Multiple Eclipse instances shown by the same name

Some time ago (~1 year) I tried simply renaming the Application bundle did not work, as there is seems to be some kind of configuration that won’t work after that. But this was quite a time ago.

Now I found another possible solution: there is an Eclipse repackager script shared in GitHub I could give a try.

The script is a simple bash script, with simple parametering:

[cc_bash]./EclipseOSXRepackager «eclipse source folder» «target.app»[/cc_bash]

A quick testing showed it does not handle dropins, so I hacked and shared a new version (and meanwhile I was able to test Git for the first time – btw. thanks for the fine tutorials, GitHub team 🙂 ).

My updated solution is available also from GitHub: http://github.com/ujhelyiz/yoursway-eclipse-osx-repackager

To tell the truth, even the updated script has some serious issues: I could break the app two ways: the smallest issue was, that P2 could not install or remove anything, or in the worse case the bundle couldn’t even start.

So I have a quick question: does anyone has a working solution for creating proper, working app bundles for OSX from Eclipse? Or simply could help fixing the repackager script?

LPG generálás OSX-en Eclipse-ből

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 😀 ). 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:

  • [cci]${resource_loc}[/cci]: az aktuálisan kijelölt erőforrás elérhetősége a fájlrendszerben (nem workspace-relatív módon!)
  • [cci]${container_loc}[/cci]: 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 [cci]LPG_INCLUDE[/cci] és az [cci]LPG_TEMPLATE[/cci] 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?

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.


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.


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


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.


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.


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.


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.


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


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


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!