PICkit 2 + PIC16F690, avagy új játék nagy gyereknek

Talán ez lesz az első eset, hogy olyan dologgal kezdtem el foglalkozni, ahol minden első kattintásra úgy működött, ahogy az meg van írva. Pedig néhány lépésnél határozottan kételkedtem az azonnali sikerben. Hozzávetőleg fél éve elmélkedek egy hardveres probléma megoldásán, amihez kézenfekvő és egyszerű lehetőségként merült fel PIC alapú megoldás. A döntést felgyorsította egy akció, amivel vizsonylag olcsón juthattam egy PICkit 2 programozóhoz, és egy pic16F690-es processzorhoz.

Talán ez lesz az első eset, hogy olyan dologgal kezdtem el foglalkozni, ahol minden első kattintásra úgy működött, ahogy az meg van írva. Pedig néhány lépésnél határozottan kételkedtem az azonnali sikerben. Hozzávetőleg fél éve elmélkedek egy hardveres probléma megoldásán, amihez kézenfekvő és egyszerű lehetőségként merült fel PIC alapú megoldás. A döntést felgyorsította egy akció, amivel vizsonylag olcsón juthattam egy PICkit 2 programozóhoz, és egy pic16F690-es processzorhoz. A csomag ráadásul tartalmaz egy egyszerű próbapanelt, néhány leddel, egy kapcsolóval és egy potméterrel továbbá természetesen kivezetésekkel más kapcsolásokhoz. Az említett processzor nagy előnye a beépített A/D konverter, amire nagy szükségem lesz a tervezett munkában (erről egy másik bejegyzés fog szólni, várhatóan néhány hónappal később).

Az első ismerkedésem az új játékszerrel arra fókuszálódott, hogy megoldást keressek a programozó linux alatti használatára, mivel természetesen a csomaghoz adott lemezeken csak windows-kompatibilis szoftverek találhatóak. Nem estem kétségbe, ugyanis vásárlás elött tájékozódtam a rendelkezésre álló eszközökről, így volt kiindulási alapom. Szerencsére a [[http://www.microchip.com|Microchip]] kiadta a programozóját parancssorból vezérlő, pk2cmd program forráskódját, így egy lelkes fejlesztő munkája nyomán ez a program megjelent linuxra is, immár [[http://home.pacbell.net/theposts/picmicro/|pk2cmdlinux]] névre keresztelve. A Microchip által fejlesztett MPLab IDE fejlesztői környezettel már egészen más a helyzet, bár a [[http://piklab.sourceforge.net/|Piklab]] értelmesnek látszó alternatíva, az általam használt eszközt egyelőre nem támogatja. Mindenesetre érdemes követni a fejlődését.

A csomagban kapott lemezen találtam pár példaprogramot előrefordított programfájlokkal, amikkel sikeresen felprogramozva a kütyüt néhány látványos LED-villogtatást sikerült kicsikarnom. A példaprogramok között számomra a leghasznosabbnak az A/D konverter működéséét bemutató alkalmazás tünt, ami a próbapanelen található potméterrel beállított feszültséget 4 bitre skálázva jeleníti meg a rendelkezésre álló 4 leden.

A következő megoldandó feladat az volt, hogy az előrefordított program felhasználása helyett a forráskódot magam fordítsam le, így kipróbálva a teljes fejlesztési folyamatot. Fordítónak a [[http://gputils.sourceforge.net/|GNU Pic utils]] csomagot választottam. Valójában nem vártam, hogy módosítás nélkül lefordul a kód, azonban kellemes meglepetésként a fordító csupán néhány “message” szintű megjegyzést adott. A lefordított kóddal se volt semmilyen probléma, bár néhány részletében különbözött az előrefordítotthoz képest.

Az első bátortalan lépéseim a PIC világában biztatóak, az egyszerű használat, a rengeteg integrált periféria, és az alacsony ára remekül használható eszközzé teszik a kütyüt.

Az általam kipróbált példaprogram:

#include __config (_INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _BOR_OFF &
_IESO_OFF & _FCMEN_OFF)

cblock 0x20
Delay1 ; Assign an address to label Delay1
Delay2
Display ; define a variable to hold the diplay
endc

org 0
Start:
bsf STATUS,RP0 ; select Register Page 1
movlw 0xFF
movwf TRISA ; Make PortA all input
clrf TRISC ; Make PortC all output
movlw 0x10 ; A2D Clock Fosc/8
movwf ADCON1
bcf STATUS,RP0 ; back to Register Page 0

bcf STATUS,RP0 ; address Register Page 2
bsf STATUS,RP1
movlw 0xFF ; we want all Port A pins Analoga
movwf ANSEL
bcf STATUS,RP0 ; address Register Page 0
bcf STATUS,RP1

movlw 0x01
movwf ADCON0 ; configure A2D for Channel 0 (RA0), Left justified, and turn on the A2D module
MainLoop:
nop ; wait 5uS for A2D amp to settle and capacitor to charge.
nop ; wait 1uS
nop ; wait 1uS
nop ; wait 1uS
nop ; wait 1uS
bsf ADCON0,GO ; start conversion
btfss ADCON0,GO ; this bit will change to zero when the conversion is complete
goto $-1

swapf ADRESH,w ; Copy the display to the LEDs
movwf PORTC
goto MainLoop
end

A kód lefordítása:

gpasm -p pic16F690 A2D.asm

A kütyü felprogramozása a lefordított programmal:

pk2cmd -Ppic16f690 -Fad_proba/A2D.hex -M

A felprogramozott kütyü bekapcsolása:

pk2cmd -Ppic16f690 -t

Ha kijátszottuk magunkat, ki is kapcsolhatjuk:

pk2cmd -Ppic16f690

  • A gyártó: [[http://www.microchip.com|Microchip]]
  • A csomag oldala: [[http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805|PICkit 2]]
  • A processzor adatlapja elérhető itt: [[http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en023112|PIC16F690]]
  • GNU assembler PIC készülékekhez: [[http://gputils.sourceforge.net/|GNU Pic utils]]
  • A pk2cmd linux portolása: [[http://home.pacbell.net/theposts/picmicro/|pk2cmdlinux]]
  • QT alapú GUI a pk2cmdlinux programhoz: [[http://www.cannasoftware.com/component/option,com_jdownloads/Itemid,33/task,viewcategory/catid,1/|KPK2cmd]]

A próbapanel kapcsolási rajza:
Próbapanel

A programozó, és a próbapanel:
PICkit 2

A lényeg, egy PIC16F690:
pic16f690

J2EE – a nagy aknamező

Hát, megvan egy ideje, hogy utoljára írtam. Pedig magamban már többször megfogadtam, hogy rendszeresebben írok. Úgy volna értelme csinálni az egészet, hogy hetente legalább egy bejegyzés születik. Persze ez így hiú ábránd ennyi házi feladat mellett.

Ez az UML házi kész volt. 80 órát egy hét alatt beletolni abba, hogyan kell leimplementálni egy hello world-nél egy szinttel bonyolultabb feladatot J2EE alapon, na ez teljesítmény. És örülök, hogy ennyi idő alatt összeállt…

Hát, megvan egy ideje, hogy utoljára írtam. Pedig magamban már többször megfogadtam, hogy rendszeresebben írok. Úgy volna értelme csinálni az egészet, hogy hetente legalább egy bejegyzés születik. Persze ez így hiú ábránd ennyi házi feladat mellett.

Ez az UML házi kész volt. 80 órát egy hét alatt beletolni abba, hogyan kell leimplementálni egy hello world-nél egy szinttel bonyolultabb feladatot J2EE alapon, na ez teljesítmény. És örülök, hogy ennyi idő alatt összeállt…

Nem véletlen tartott eddig. Van benne egy gyönyörű implementált objektumrelációs leképezés, néhány tag elhelyezése, egy xml-fájl és még néhány sor kód megírása után az objektumokat szépen kimenti az adatbázisba, illetve visszaolvassa onnan igény szerint. Tényleg szép. Csak az ember el ne szúrja a tagelést, mert olyan exception-trace-t kap futáskor, hogy öröm nézni. A legnagyobb, amit sikerült kapni, 40 kB méretű volt. Iszonyatosan redundáns, gyakorlatilag az egész háromszor szerepel, az értelmes tartalom másfél-két sor. Szűrd ki…

A fejlesztés során mi RAP-t használtunk GUI-készítéshez. Nem gyenge technológia: Eclipse plugineket AJAX-szal támogatott weblapokra fordít. De azért ezt több projektből összefejleszteni szép teljesítmény. Például nem mindegy, hogy hol kapcsoljuk össze a projekteket. Ha az Eclipse projekt tulajdonságainál fogjuk, és beikszeljük a Referenced projects résznél (hogy szerepeljen a build path-ban), az nem jó. A plugin.xml fájlban kell a depencencies blokkban bejelölni.

Remek, most már lefordul, elindul, és gyönyörű exception trace megint. Most az a baja, hogy nem töltötte be a futás közben a hivatkozott projekteket. Némi szórakozás után kiderült, hogy a megoldás az, hogy még a futtatási konfigurációnál is fel kell venni a hivatkozott projekteket, mint bundle-t. Eredetileg ezt nyersen az xml-be hakkoltam bele, később hívta fel valaki a figyelmemet, hogy a futtatási konfigurációnál is fel lehet venni.

Hasonló szépségek vannak az APIban is. A RAP1.1M1 és az 1.1M3 között megváltozott az alkalmazás belépési pontjának szintaktikája: az M1-ben Display típusú, míg az M3-ban int típusú visszatérési értéket vár. Érdemes megnézni a sorrendet, Display-ből int.

Beletelt némi időbe, amíg rájöttem, hogyan kell megváltoztatni a mintakódot, hogy lefusson. Gyakorlatilag a Display egy azonosítóját kell visszaadni a metódus végén. Szóval minden érdekes.

Hasonlóan jópofa volt az, hogy amikor beraktuk a szükséges webservice meghívásához szükséges fájlokat, akkor kb 25-30 MB méretben kellett jar-fájlokat a lib könyvtárba tenni. Ami problémássá teszi a dolgot, hogy ez csoportmunkában készült házi feladat, azaz fel kellett tölteni egy svn szerverre, és a többieknek le kellett szedni. Hab a tortán, hogy az svn csak fájlok között frissíti a status bart, így a 10 megás jarnál úgy néz ki a dolog, mintha meghalt volna menet közben. A csúcs az volt, amikor ezt upload közben sikerült valakinek fagyásnak értelmeznie, és kilőtte az Eclipse-et. Ezután egy órába került, amíg sikerült rendbe tennie a rendszert…

Érdekes ez az Enterprise Java technológia. Ekkora aknamezőt még nem láttam… Elég valami apró hiba, és hihetetlen mennyiségű hiba bukkan fel, és a hibaüzenetekből is alig lehet kikövetkeztetni, hogy mi lehetett az ok. Elég bonyolult architektúra, rengeteg 3rd party lib, és nagyon korlátozott tapasztalat: ez elég ahhoz, hogy a nem túl bonyolult feladat megoldását nagyon megnehezítse.

Freemail problémára megoldást keresek

Érdekes problémával találkoztam a freemail kapcsán. Úgy nagyjából az előző egy-másfél hónaptól kezdve a Mail folyton panaszkodik, hogy nem fogadja el a freemail a jelszót, hiába adom be újból és újból, folyton előjön a probléma. Persze ez nem jelenti azt, hogy a jelszó el van írva, mert máskor simán belép.

Nem értem… A beállításokat ellenőriztem, azok stimmelnek (stimmelniük is kell, hiszen van, amikor megy). Esetleg más tapasztalt hasonlókat (esetleg más klienssel hasonlókat)? Ha igen, talált-e rá megoldást?

Érdekes problémával találkoztam a freemail kapcsán. Úgy nagyjából az előző egy-másfél hónaptól kezdve a Mail folyton panaszkodik, hogy nem fogadja el a freemail a jelszót, hiába adom be újból és újból, folyton előjön a probléma. Persze ez nem jelenti azt, hogy a jelszó el van írva, mert máskor simán belép.

Nem értem… A beállításokat ellenőriztem, azok stimmelnek (stimmelniük is kell, hiszen van, amikor megy). Esetleg más tapasztalt hasonlókat (esetleg más klienssel hasonlókat)? Ha igen, talált-e rá megoldást?

Sokat segítene ez az információ nekem, ezért kérem, hogy aki tud segíteni, az tegye meg. Kellemetlen lenne ezeket a címeket migráltatni valami másra – és már ebben gondolkozom…

Hibrid CSS menü

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Tudom, mire gondoltok… „Biztosan szükség van még egy cikkre a CSS legördülõ menükrõl?” Hadd gyõzzelek meg titeket. Mi történne, ha lenne egy tiszta, jól struktúrált menünk, ami egyszerre hordozná magában a legördülõ menük dinamizmusát, egyszerû kódját de megszüntetné a fõ problémáit (nem is beszélve a szép megjelenésrõl)?

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Tudom, mire gondoltok… „Biztosan szükség van még egy cikkre a CSS legördülõ menükrõl?” Hadd gyõzzelek meg titeket. Mi történne, ha lenne egy tiszta, jól struktúrált menünk, ami egyszerre hordozná magában a legördülõ menük dinamizmusát, egyszerû kódját de megszüntetné a fõ problémáit (nem is beszélve a szép megjelenésrõl)?

A gondok a legördülõ menüvel:

  1. az almenük pontjai nem érhetõek el addig, amíg nem kezdjük el az egész menürendszert használni, és
  2. nem ad megfelelõ tájékozódási pontot a felhasználónak. Nehézkes lehet vele az oldalon belüli navigáció, mert mindig le kell gördíteni a menüt az oldalak váltásához.

Ez a technika egy bombabiztos megoldás a böngészõkkel való kompatibilitás és a hozzáférhetõség biztosítására még azon felhasználók számára is, akik régi böngészõt használnak, esetleg problémáik vannak a legördülõ menük használatával, akár mert nem tudja, akár mert nem találja kedvezõnek a legördülõ menük alkalmazásának elveit. Emellett sokkal pontosabb információt ad a hagyományos legördülõ menüknél az oldalon belüli pozícióról.

Figyelem! Ez a technika nem mûködik nagy elemszámú listákra, ahol a hagyományos legördülõ menük még jól használhatóak vagy összeomlanak a puszta tömegük alatt, a nézõponttól függõen.

Egy olyan hibrid menüt fogunk készíteni, ami vízszintesen halad keresztül az ablakon. Két szintû navigációt használ (példánkban a fõ témák és a kapcsolódó oldalak). A menünkben legördülõ hozzáférést biztosítunk minden oldalnak mindkét navigációs szinten, valamint állandóan megjelenítjük a kiválasztott témához tartozó választási lehetõségeket, emlékeztetve a felhasználót, hogy az oldal melyik részén van. Emellett a kódja egyszerû és gyorsan mûködõ lesz.

Jól hangzik? Vágjunk bele.

Elõször is vegyünk egy listát

Készítsünk egy listát az építészeti korszakokról és az õ nagyobb alakjaikról. Egy ID-t kapcsolunk az <ul> elemhez és „off” illetve „on” class-t a menülista elemeihez (ami persze feltehetõleg nem a legjobb megoldás, de a cikk céljainak megfelel):

Formázzuk meg!

Ez egy jó hely az induláshoz. Egy egyszerû, szemantikus jelölés, ami könnyen karbantartható és egy helyen található. Úgy néz ki ahogy az elvárható.

Az elsõ dolog, amit a CSS felhasználásával el fogunk érni, az az, hogy az elsõ szintjét vízszintesen jelenítjük meg (a float tulajdonság felhasználásával) és elrejtjük az alsóbb szinteket. A linkeket pedig félkövéren, színezve és kerettel jelenítjük meg.


#nav li {
/*float the main list items*/
margin: 0;
float: left;
display: block;
padding-right: 15px;
}

#nav li.off ul, #nav li.on ul {
/*hide the subnavs*/
display: none;
}

#nav li a {
/*for all links in the list*/
color: #f90;
font-weight: bold;
display: block;
height: 15px;
width: 100px;
border: 1px solid #29497b;
padding: 5px;
}

Most helyezzük el a második listaszintet a fõ lista alá, hogy amikor újra megjelenik, amegfelelõ helyen legyen.


#nav li.off ul, #nav li.on ul {
/*put the subnavs below and hide them all*/
display: none;
position: absolute;
top: 33px;
height: 15px;
left: 0;
padding-top: 10px;
}

Végül jelenítsük meg az almenüt az aktív tématerülethez, ami a példánkban „Modern”. A legjobb megoldás erre, ha egyetlen központi, mindent lefedõ menüt használunk, egy osztály használata, mondjuk, a „Modern” elemen, és ennek megfelelõ kijelölõket használunk. Ebben a cikkben, ami egy másik oldalon belül lesz közzétéve, és önmagában is elégségesnek kell lennie, egy „on” osztályt adunk a kiválasztott témához és „off”-ot az inaktív témákhoz.


#nav li.on a {
/*change border color for active topic area*/
border: 1px solid #f90;
}

#nav li.on ul a, #nav li.off ul a {
/* cancel inherit of border
on subnav of active topic */
border: 0;
}

#nav li.on ul {
/*display active subnav list*/
display: block;
}

Még hozzáadunk néhány keretet, és így kapjuk az itt látható eredményt.

És akkor mindenki gördült, de egy kiesett…

Most pedig aktiváltjuk a legördülõt. Ez nem különbözik lényegesen a többi CSS legördülõ menütõl – a hover a li elemen jelenik meg, így az IE alatt nem fog mûködni a rosszul implementált :hover pszeudo-osztály miatt. Ezzel is mindjárt foglalkozunk. A következõ CSS eltünteti a kereteket a második listaszinten, a kiválasztott almenüt mindig megjeleníti, és beállítja az inaktív menük megjelenítését, ha az õsükre rámutatunk az egérrel. Beállítjuk a z-index tulajdonságot is annak érdekében, hogy az egérrel kiválasztott téma mindig elsõbbséget élvezzen az aktuális téma almenüjével szemben.


#nav li.on ul a, #nav li.off ul a {
float: left;
/*ie doesn't inherit the float*/
border: 0;
color: #f90;
width: auto;
margin-right: 15px;
}

#nav li.on ul {
/*display the current topic*/
display: block;
}

#nav li.off:hover ul {
/* display the other topics when
their parent is hovered */
display: block;
z-index: 6000;
}

We’ll make it a little more user-friendly, with a background on the hovered tabs.
Egy kicsit felhasználóbarátabbá is tesszük azzal, hogy hátteret váltunk a kijelölt(:hover) füleken.


#nav li.off a:hover, #nav li.off:hover a {
background: #29497b;
color: #f90;
}

Itt lehet megtekinteni, hol is tartunk.

Foglalkozzunk a „különleges” böngészõinkkel…

Két választás van azon böngészõk felé, mint az Internet Explorer, amik nem támogatják a :hover osztályt a <a> elemen kívül. Hagyhatjuk úgy, ahogy van, tudva, hogy mûködni fog néhány éven belül, amikor minden böngészõ támogatni fogja a :hover osztályt (lekopogom). Ugyanakkor nyugodtak lehetünk abban a tudatban, hogy minden navigációs elem látható és elérhetõ minden felhasználó számára. Esetleg megpróbálhatunk egy kis JavaScript kódot írni, ami megfelelõen átírja a CSS kijelölõket úgy, hogy az IE is megérti, ezáltal elérhetõvé téve a legördülõ menü dinamizmusát mindenki számára.

(A mûködés IE-ben úgy-ahogy értelmezhetõ) Kicsit igazítani kell az elhelyezésen a csillag-hack segítségével:


#nav li.off ul, #nav li.on ul {
/*put the subnav below*/
top: 33px;
*top: 44px; /*reposition for IE*/
}

Tehát a menü nagyszerûen mûködik a modern, szabványkövetõ böngészõkben, és korlátozottan, funkcionálisan mûködik megfelelõ elhelyezéssel az Internet Explorer 5 és 6 böngészõkben is. Egy kis segítséggel a legördülõ menüt az Internet Explorer 5-ös és 6-os verzióiban is mûködésre lehet bírni. Ehhez egy egyszerû JavaScipt kódot kell írni a kijelöléskor a kijelölõk módosítására, ez az IE 5.x és 6.x verziókon mûködik (Windows alatt). Köszönet a módszerért Patrick Griffiths-nek és Dan Webbnek, akik a „Suckerfish Legördülõ menükkel”elindítottak a CSS-alapú menürendszerek fejlesztése felé (az írás magyarul az oldalon olvasható [[Suckerfish menük]] címmel). Az õ JavaScript részletük a következõképpen néz ki:


startList = function() {
if (document.all && document.getElementById) {
navRoot = document.getElementById("nav");
for (i=0; i<navRoot.childNodes.length; i++) {
node = navRoot.childNodes[i];
if (node.nodeName=="LI") {
node.onmouseover=function() {
this.className+=" over";
}
node.onmouseout=function() {
this.className=this.className.replace
(" over", "");
}
}
}
}
}
window.onload=startList;

Még egy egyszerû módosítás szükséges a CSS-en:


#nav li.off:hover ul, #nav li.over ul {
display: block;
z-index: 6000;
}

#nav li.off a:hover,
#nav li:hover a,
#nav li.over a {
background: #29497b;
color: #f90;
}

ahhoz, hogy az „.over” osztály hozzáadása a lista elemekhez, amelyeket kijelölünk, mûködésre bírja a rendszert az IE/Win felhasználók számára. Nem mintha nem lenne érdemes egy új böngészõben gondolkodni, de egyelõre folytatjuk a tömegek kiszolgálását olyan módon, amit már õk is megszoktak.

Tehát ez lenne az. Egy inkrementális változtatás, talán, a korábbi CSS legördülõkhöz képest, de egy másik szemszög ahhoz, hogy felfedezzük azokat az eseteket, ahol tényleg hasznos a navigáció megjelenítése ahelyett, hogy elrejtenénk egy legördülõ menü belsejében.

És lehet szép isl?

Ok, hogy nem túl szép még. Nem tehetem meg, hogy egy sokkal szebb grafikával ellátott verziót mutatok ezzel a technikával a pedánsak kedvéért a való világnak. Néhány változtatással, a CSS sprite navigációs képekkel (köszönet Dave Sheanak, egy fénykép New York Citybõl, egy kicsit több CSS, és olyan menürendszert kapunk, ami megmutatja a CSS igazi erejét, ha grafikai tervezéssel kombináljuk. Kipróbálható a végleges Hibrid CSS legördülõ menü, tökéletesen mûködõképes az összes modern böngészõven.

A szerzőről

Eric Shepherd az alapítója az arkitrave web media-nak, egy kis, webbel és grafikával foglalkozó cégnek a new yorki Buffaloban. Éppen egy építészeti diplomát szerez (Master of Architecture degree) a a Buffaloi Egyetemen. Emelett még zongorista is. A munkája megjelent a CSS Zen Garden oldalon, és stratégiai partnere a Nepo Strategies-nek, egy buffaloi e-kereskedelmi és webes stratégiai cégnek. Már foglalkozik vele, hogy hogyan magyarázza el az XHTML, a CSS és Javascript DOMmal kombinált erejét a zseniális egyhónapos lányának, Naia-nak.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2005. március 30. óta elérhető itt.

Google Calendar szinkronizálás naptárprogrammal

Az elmúlt időszakban a többiekkel gyakran kellett időpontokat egyeztetnünk különféle ügyek miatt, és felmerült az ötlet, hogy legyen a zárt használatú wikirendszerünk mellé naptárrendszerünk is.

Az első ötlet egy php script alkalmazása lett volna, ami képes megfelelően kezelni pl. az ics fájlokat. Találtunk is ehhez használható scriptet, de bugzott. Ehelyett végül is az egyszerűbb megoldás mellett döntöttünk, és elkezdtünk Google Calendart használni.

Ez egy szép és jó szolgáltatás, de valahogy (számomra legalábbis feltétlenül) kényelmetlen volt a használata, jobban örültem volna, ha az asztali levelező (és címjegyzék, stb.) kliensemhez szépen csatlakozó naptárprogramot használhatok.

Az elmúlt időszakban a többiekkel gyakran kellett időpontokat egyeztetnünk különféle ügyek miatt, és felmerült az ötlet, hogy legyen a zárt használatú wikirendszerünk mellé naptárrendszerünk is.

Az első ötlet egy php script alkalmazása lett volna, ami képes megfelelően kezelni pl. az ics fájlokat. Találtunk is ehhez használható scriptet, de bugzott. Ehelyett végül is az egyszerűbb megoldás mellett döntöttünk, és elkezdtünk Google Calendart használni.

Ez egy szép és jó szolgáltatás, de valahogy (számomra legalábbis feltétlenül) kényelmetlen volt a használata, jobban örültem volna, ha az asztali levelező (és címjegyzék, stb.) kliensemhez szépen csatlakozó naptárprogramot használhatok.

Ehhez a Google azt a segítséget nyújtja, hogy ad ics-linket a naptárhoz, amit be lehet tölteni a kliensprogramba. Ez mind nagyon szép és jó, de események felvétele kapcsán nem ad támogatást a kliensprogramokhoz (pedig erre is van tulajdonképpen szabványos megközelítés, a nyílt forrású szoftverek között is. A csak olvasható hozzáférés meg kényelmetlen…

De az is lehetséges, hogy ics-fájlt importáljon az ember az online naptárba. Igen, migrációt támogat, viszont azt, aki kliensprogrammal veszi igénybe a szolgáltatásokat, nem. Feltehetőleg azért, mert így nem nézik meg a Google reklámjait, esetleg nem kezdik el használni a további szolgáltatások
Hát, fogtam magamat, és beütöttem a Google-be a problémámat, és adott egy fizetős (15$/év) szoftvert, ami képes kétirányú szinkronizációra. Nem nevezem meg, pláne, mert nem is éri meg az árát, ha az ember hajlandó egy kicsit szórakozni a dologgal.

Egy későbbi keresésnél viszont találtam egy Javaban íródott (és tényleg crossplatform) scriptet, ami megoldja a gondot olyan kliensprogramokkal, amik ics-fájlba mentik (tudják menteni) a fájlokat – ilyen az Apple iCal programja OSX-en (naná, eredetileg ennek a formátuma volt a mostanra kváziszabvánnyá vált ics), a legtöbb Linuxos naptárprogram, Windowsra pedig meg lehet próbálni a Mozilla Sunbird programját – esetleg a Thunderbird-del egybecsomagolt változatát, a Lightninget (figyelem, ez még csak a 0.5-ös verziónál tart, azaz nem stabil változat!). Outlook (Express) felhasználók így jártak…

Ez a script a GCalDaemon, és teljesen használható a fent említett célra, és mellesleg néhány egyéb információt is ki tud nyerni a Google accountból. A telepítését nagyon részletes dokumentáció, és most már GUI is segíti, ezért ezzel nem foglalkozom.

Viszont a script működése megér pár szót még: a kiens gyakorlatilag HTTP-kérésekkel importáltatja a Google Calendarba a helyi gépen megváltozott fájlt, és a privát ICS URL-en keresztül lehúzza, ha ott megváltozott, ezzel téve lehetővé az egyszerű szinkronizációt. Igen, ezért szeretjük a nyílt protokollokat…