Számítógép használat másképpen

A héten bukkant fel a neten egy videó, R. Clayton Millertől 10/GUI címmel. Röviden bemutat egy koncepciót arról, hogyan lehetne használni a jövő számítógépeit.

Azok kedvéért, akik még nem látták, itt a videó:

Először is szeretném leszögezni, hogy a koncepció alapvetően tetszik. Konzisztens, motorikus reflexekre épít a felület használata (az gyorsan tanulható), az asztalra kirakott néhány widget koncepció az, ami nekem a KDE4-ben is nagyon tetszett, stb.

Az kérdéses, hogy a 2D helyett 1D ablakelhelyezés mennyire használható. Átlátni bizonyosan könnyebb, ugyanakkor kérdés, mit csinál akkor, ha egyszerre sok ablakot/alkalmazást szeretnék egyszerre használni. Megvan a kockázata, hogy arra nem annyira jól használható.

További lehetséges probléma, hogy mennyire lehet finom műveleteket végezni úgy, hogy a többi ujjunk bezavar(hat). Ez persze csak finomhangolása a rendszernek, mindez megtörténhet a mostani billentyűzet + egér/touchpad/trackpoint kombinációkkal, vagy a touchscreenekkel is.

Amit meg végképp nem látok, hogy a rendszer hogyan működne adatcentrikus alkalmazásokkal. Amikből van egy pár: különböző űrlapok kitöltése, megjelenítése, adattáblák áttekintése gyakori feladat a különböző enterprise alkalmazásokban. Persze, ezt is lehet jobban és rosszabbul csinálni, de ha egy rendszer használatához minden meglevő alkalmazást át kell írni, akkor sokáig élni fog a régi… Látjuk ezt IE6 kapcsán is, de ez most off volt. 😀

Mindenesetre ötletnek jó a folytatást tekintve – sőt, szerves folytatása az eddigi trendeknek. Kérdés, hogy mi lesz belőle, ha ténylegesen bekerül a mindennapokba.

Update: amit kihagytam az előző értékelésből.

A legtöbb interakciónál nem használjuk az ujjainkat külön-külön, hanem csak valami közös, motorikus reflex alakul ki. Persze, vannak esetek, amikor kivételek vannak, de ez ritkaság. Sokan nem tudnak 10 ujjal gépelni, kevesen zongorázak/hegedülnek/játszanak hangszeren, ami efféle problémákat vet fel.Megtanulható, de nem mindenki veszi rá a fáradtságot.

Persze az egy interakciós pont sávszélessége kérdéses, de ha jobban belegondolunk, amikor papírra írunk, akkor is egy pont az interakció, mégis egész gyorsan tudnak egyesek írni.

Kapcsolódó probléma, hogy mi történik, ha úgy próbálok többujjas gesztusokat végrehajtani, hogy az ujjaim különböző ablakok felett vannak?

És a legvégső problémám a rendszerrel: az emberek többsége nem képes egyszerre több mindent végezni – és itt a többujjas gesztusokat muszáj egyszerre csinálni. Nem biztos, hogy könnyű.

Most a frissítés hatására a kritikák abszolút túlsúlyba kerültek a pozitív tartalom mellett, ezért fontosnak tartom még egyszer megjegyezni, hogy szerintem érdekes koncepció, esetleg ki is próbálnám, ha lenne rá lehetőségem. De amire biztosan jó, az az, hogy végiggondoljuk, mire jó, és levonjuk a konzekvenciákat.

Eclipse Trivia: ListDialog

Némi bugfixing kapcsán eljutottam egy Eclipse plug-in belsejében a JFace ListDialog osztályhoz.

A dolog lényege, hogy egy definiált listát megjelenít, és lehetővé teszi a felhasználó számára az elemek kiválasztását egy dialógusban. Az ötlet jó, hiszen viszonylag gyakran szükséges feladat.

Ugyanakkor egy érdekes adalék a működéséhez: működik az a hasznos (és elvárt) funkció, hogy a lista elemei dupla kattintással történő kiválasztása működik. Feltéve, hogy a Mégsem gomb is engedélyezve van… 😀 No comment. (Ld. még Bug 292576).

Mi a hiba a kódban?

Volt ma egy szép debug köröm. Nagyon nem értettem, miért nem működik egy kód – ami ráaásul régebben (július végén) szépen ment, és azóta nem nyúltam hozzá, és elvileg a kapcsolódó libekben sem volt lényegi változás azóta.

Úgy gondolom, bemutatom a kódot, és felteszem a kérdést, látja-e más is a hibát benne.

[ccw_java]private ICoreNotificationObject notificationObject;

public void actionPerformed(ICoreNotificationObject notification) {
this.notificationObject = notification;
Display.getDefault().aSyncExec(new Runnable() {

public void run() {
String action = notificationObject.getActionType();
if (isOneOf(action, new String[] {
ICoreNotificationObject.TA_TRANSACTION_END,
ICoreNotificationObject.TA_UNDO_END,
ICoreNotificationObject.TA_SUBTRANSACTION_END})) {
updateGraph();
transactions.pop();
} else if (isOneOf(action, new String[] {…}){
//…
}
});[/ccw_java]

Még némi információ a kód működéséről: a kód egy eseményfigyelő osztály belsejében van, és a Runnable adatváltozásokat próbál követni, amely tranzakciókba van szervezve, ill. a tranzakciók során visszavonás események is érkezhetnek.

Na, kinek van tippje, mi lehet a hiba? Ha nincs tipp véges időn belül (előre nem specifikálnám), akkor majd megosztom a helyes megfejtést. Annyit mondok előre, hogy fejet falbaverős hiba 😀 .

Update: először is helyesbítettem a kódot, mert sikeresen a javított változatot töltöttem fel.

A problémát az okozta, hogy az asyncExec() hívás indított egy új jobot, amit valamikor majd végrehajt. Csak közben visszaadja a vezérlést, és ezzel lehetővé teszi a rendszer számára, hogy felülírja a run() metóduson belül is használt notificationObject változót.

Az asyncExec() hívás syncExec()-re cserélése megoldotta a problémát, ugyanis az megvárja, hogy visszatérjen a meghívott thread.

Ez a hiba kifejezetten mocskos dolog, mert eredetileg működött, míg a környezet refactoringja előhozta a bugot…

New service release: 0.7.1

I created a quick service release to incorporate the changes since the last release.

This includes some minor adjustments in order to provide a more seamless user experience (sorry for the bullshit, but I just couldn’t withstand it 🙂 ).

Well, the new release fixes a nullpointer exception, and adds an option to save the current graph.

There are further tweaking regarding usability: the default layout is changed to Tree Layout in order to allow faster responses, and it is possible to hide the Local context node. These changes are the beginning of some serious overhaul, our goal is to increase the usability of the plugin.

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?