Európa-fogyatkozás

Elég hamar kicseréltem az Eclipse 3.3 Europa integrált fejlesztői környezetemet az új verzióra. Hamarabb, mint eredetileg terveztem. Ennek annyi volt az oka, hogy letöltöttem az M6-os release-üket kipróbálásra, és amikor meghalt a rendes fejlesztői környezetem (volt 900 MB telepítve, rendes kis pluginkönyvtár :p ), úgy döntöttem, megspórolom az egész újratöltését, és inkább berakom a Ganymede-be a cuccokat.

Nem mondom, akkor még korai volt egy kicsit (de csak egy kicsit), nem volt (sokkal) nagyobb szívás ott újra összerakni a munkakörnyezetet, mint az Europa-ban lett volna. Mostanra meg már, hogy van végleges 3.4-es változat, nem mennék vissza.

Elég hamar kicseréltem az Eclipse 3.3 Europa integrált fejlesztői környezetemet az új verzióra. Hamarabb, mint eredetileg terveztem. Ennek annyi volt az oka, hogy letöltöttem az M6-os release-üket kipróbálásra, és amikor meghalt a rendes fejlesztői környezetem (volt 900 MB telepítve, rendes kis pluginkönyvtár :p ), úgy döntöttem, megspórolom az egész újratöltését, és inkább berakom a Ganymede-be a cuccokat.

Nem mondom, akkor még korai volt egy kicsit (de csak egy kicsit), nem volt (sokkal) nagyobb szívás ott újra összerakni a munkakörnyezetet, mint az Europa-ban lett volna. Mostanra meg már, hogy van végleges 3.4-es változat, nem mennék vissza.

Ami a leghasznosabb újdonság számomra, az a megújult csomagkezelő. Egyrészt az az előnye, hogy nem kell előre eldönteni, hogy én most új csomagot akarok telepíteni, vagy a meglevő csomagokon akarok valamit módosítani (korábban idegesítő volt, amikor a rossz menüpontra kattintottam, és egy percig várhattam, amíg megnézte, hogy mit lehet csinálni), ugyanis két almenüpont helyett egy közös dialógusablakból lehet változtatni két fül között – ezek a fülek tartalmazzák a korábbi funkcionalitást. Legalábbis nagyrészt.

Ami úgy tűnik számomra, hogy hiányzik, az a korábbi változatban Select required nevű gomb a telepítendő csomagok választásánál. Lehet, hogy már nincs rá szükség, mert automatikusan bejelöli (nem vagyok benne egészen biztos, ezért ezt nem merem elítélni). Amiben biztosabb vagyok, az a csomagok eltávolítása. Ezt még egyáltalán nem sikerült az új verzióban véghezvinni.

Ami viszont roppant hasznos új funkcionalitás, az a dropin mappa koncepciója. Ez egy kijelölt mappa, amibe ha bedobunk letöltött csomagokat, akkor azokat a csomagkezelő látja, és a függőségeivel együtt telepíthetőek. Ez nagyon hasznos lehet akkor, ha valami olyan projektet akarunk telepíteni, ami valami miatt nem szerepel az Eclipse csomagkezelőben.

Egy másik apró változás, amivel találkoztam, az az Eclipse pluginek (illetve RAP programok) fejlesztésekor jött elő: bizonyos fájlokat megnyitva az Eclipse nem jön rá, hogy én egy megadott futtatási konfigurációval akarom futtatni egy automatikus futtatás parancs kiadásakor, hanem kézzel kell megjelölni. Az Europaban erre nem találtam alternatív megoldást, de a Ganymede sokkal kevésbé idegesítő. A problémát ugyen nem oldották meg, de legalább megkerülték: első futtatáskor lehet, hogy ki kell választanom a futtatási konfigurációt, de utána megjegyzi, és nyugodtan futtatja úgy is.

Az Eclipse 3.4 lesz Ubuntuhoz is – az Europa nem volt, mert valami ütközött az SWT-ben és az Ubuntuban, és ezt csak az új verzióra javították ki; ezért is van az, hogy még az LTS kiadásban is csak a két éves 3.2 (Callisto) került be. Nem tudom, hogy végül is kijavították-e, mert per pillanat nincs lehetőségem ezt ellenőrizni, de valamikor majd ezt is meg lehet tenni. Ez a probléma egyébként akkor merült fel, amikor Balage a leírásom alapján telepíteni próbálta az [[PHP debug Eclipse PDT-ben|Eclipse PDT-t debuggerrel]].

Apropó PHP debugger: a PDT projekt nincs szinkronizálva az Eclipse kiadásokkal, ebből még nincs hivatalosan kiadott verzió (sem pedig update site). De a dropin megoldás segítségével könnyen telepíthető a rendszerbe, és utána minden gond nélkül megy. A php debugger is szépen megy.

Viszont még egy negatívumról is írnék: az SWT widget-készlet még mindig Carbon-alapú OSX alatt, ami nem jó hír. Java 6-tal nem megy, mert az OSX-en kötelezően 64 bites, míg a Carbon 32. De szerencsére már elkezdődött a Cocoa-alapú változat fejlesztése, ha minden jól megy, a következő kiadásba már be is kerülhet. Ha ez tényleg így lesz, akkor lehet, hogy megint kiadás előtt fogok váltani. De ez majd kiderül. 🙂

Szóval egy hasznos új változatról van szó, nagyon forradalmi változás nincs benne, de megfelelő továbbfejlesztése a népszerű IDE-nek. Úgy gondolom, tele lehet még az előzőekhez hasonló apró változtatásokkal, de ezek felismeréséhez nem használtam eleget a korábbi változatokat, ezért nem kívánok most róla írni. Majd esetleg máskor. Mindenesetre bárki számára javaslom a verziófrissítést, ha nincs túlságosan előrehaladott állapotban egy projektjében, mert akkor kellemetlen lehet a váltás. De érdemesnek érdemes szerintem, nem sok helyen van inkompatibilitás a következő verziókkal. Az egyedüli gond az lehet, ha valami szükséges plugin nem érhető el az új változatban.

De ha valakinek nincs valami nagyon különleges igénye, akkor nyugodtan lehet frissíteni, szépen megy az új Ganymede is.

HP ipaq rx3715 és Linux

Érdekes, és mint kiderült, kissé veszélyes játékba fogtam ma. Miután feladtam, hogy értelmesen összerakjam a M$ Windows Mobile 2003 SE rendszert, eldöntöttem, hogy lesz ami lesz, kipróbálom a linuxot rajta az [[http://www.handhelds.org/moin/moin.cgi/HpIpaqRx3715InstallFromUbuntu|itt]] található leírás alapján.

Érdekes, és mint kiderült, kissé veszélyes játékba fogtam ma. Miután feladtam, hogy értelmesen összerakjam a M$ Windows Mobile 2003 SE rendszert, eldöntöttem, hogy lesz ami lesz, kipróbálom a linuxot rajta az [[http://www.handhelds.org/moin/moin.cgi/HpIpaqRx3715InstallFromUbuntu|itt]] található leírás alapján.

Az első nehézség nem is ezzel volt kapcsolatos, életem legnagyobb bakiját sikerült elkövetnem, és csak a szerencsén múlott, hogy helyre tudtam hozni. A tanulság: mielött beletörölsz a particíós táblába, alaposan nézd meg, hogy melyik lemezzel teszed. Én nem tettem meg, és mivel az említett tutorial /dev/sda-ról beszél, vidáman beírtam a végzetes “sudo fdisk /dev/sda” sort, és gondolkodás nélkül irtam át a partíciós táblát. Mielött magamhoz tértem, a GRUB zavarbaejtő “Error 17” üzenetével találtam szembe magam. Szerencsére találtam a fiók alján egy linux lemezt, amivel helyrehoztam. Pánik vége. Rövid pihenő, egy erős tea, folytassuk.

A fenti égő de tanulságos baki után nem ütköztem komolyabb ellenállásba a telepítés során. Feszült koncentrációval és minden lépést alaposan átgondolva sikeresen particionáltam az SD kártyámat, és felmásoltam a szükséges fájlokat. Pár pillanat múlva a PDA képernyőjén biztató apróbetűs konzol jelent meg, és azon boot-szagú feliratok. Rövid várakozás után pedig a hőn áhított [[http://opie.handhelds.org|OPIE]] felülete fogadott. Bizakodással és az izgalomtól remegő kézzel ragadtam meg a stylus-t, és kezdtem meg bátortalan lépéseimet az ismeretlen rendszerben. Az első kellemetlenség, ami megzavarta az újdonság izgalmában úszó lelkemet, az a nyílvánvaló tény, hogy bizony a képernyő fekvő helyzetbe van fordítva. Hamar megtaláltam a menüben a “rotate screen” feliratú gombot, ami a kecsegtető hangvétel ellenére a várakozással tökéletesen ellentétes irányba, immár fejjel lefelé fordította a képernyőt. Ez legyen e legkisebb probléma, gondoltam, ha más működik. Azonban további csalódásoknak lettem kitéve. Csak hogy párat említsek a WLan egyáltalán nem működik, a Bluetooth hasonlóképp, és komoly nehézséget okoz a ciril betűs képernyőklaviatúra.

De persze sikereket is értem el, némi szenvedés árán sikerült hálózatba kötnöm a laptopommal usb-n keresztűl. Így sikerült pár srceenshotot töltenem le a kütyüről, amiket a beépített képlopóval csináltam (ügyes, és nagyon hasznos kis eszköz). Általánosságban az interfésszel jók a tapasztalataim, a naptár alkalmazás, jegyzetelés, és dokumentumok kezelése határozottan jobb, mint amivel eddig WM kapcsán összefutottam.

Végeredményben eredményes kisérletet zártam, bár a komoly hiányosságok miatt egyelőre nem jelent használható alternatívát. Íme pár screenshot a miheztartás végett:

Az első képernyő
Az OPIE rendszer kellemesen lágy vonalai fogadtak induláskor.

Konzol
Beépített konzol, és a top program mutatja a rendszer terhelését.

Benchmark
Még egy beépített eszköz: leméri a PDA egyes elemeinek a teljesítményét, ami összehasonlítható más kütyük méréseivel.

Ciril betűk
Zavarbaejtő, mi több, kellemetlen. Ciril betűk a klaviatúrán.

Utóirat: közben megtaláltam a megfelelő beállítást, így már egy sokkal kellemesebb angol billentyűzet fogad, sőt, magyar kiosztást is tartalmaz.

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…