Megjegyzés: A most következő postban a NEX, avagy egy böngészőgyártó-független csomagformátum kerül bemutatásra, amelyet az Opera fejlesztői a Chrome saját .crx formátuma alapján készítettek el. Céljuk, hogy egy nyílt, szabványokon alapuló add-on formátumot hozzanak létre. Innentől az ODIN blog fordítását olvashatjátok:

Amikor először bejelentettük, hogy Chromium-alapra állunk át, már rendelkeztünk egy részletes, mély áttekinthetőséggel az adoptálásra szánt Chromium rendszerrel kapcsolatban. Ezen fontos aspektusok egyike volt annak a folyamatnak az áttekintése, hogy a fejlesztők miként fejlesztik a Chromium alapú böngészőkhöz a kiegészítőket. Megnéztük a dokumentációt a böngésző kiegészítőkről és a csomagolt webalkalmazásokról.

A Chromium natívan támogatja a CRX formátumot a Google által lehetővé tett számos Application Programming Interface-szel (API). Mivel az Opera korábban csatlakozott a Google-höz, mint aktív Chromium projekt közreműködő megoldást akartunk találni arra, hogyan terjeszthetnénk ki a CRX funkciókészletét anélkül, hogy megbolygatnánk a már köré épült, meglehetősen méretes ökoszisztémát a rengeteg létező kiegészítővel.

A CRX formátum, mint egy egy-fejlesztő általi formátum (egészen mostanáig), nem foglalta magába a saját architektúrája kiterjeszthetőségét. Választás elé kerültünk: vagy kiterjesztjük a CRX formátum lehetőségeit, vagy készítünk valami újat, ami lehetővé tenné az Opera és más böngészőgyártók számára, hogy innoválják a saját Add-on API-jukat. Kutatásunk során arra jutottunk, hogy a hasonlóságok a különböző böngészők manifest formátumaiban (lényegében a bootstrap mechanizmus a kiegészítők betöltésére) messze túlhaladják a különbségeket. Miközben kerestünk a módját, hogy innováljunk és kiépítsük a saját kiegészítő környezetünket az Operánál, megláttuk a lehetőséget is, hogy ezzel párhuzamosan egy nagyobb és szélesebbkörű ötletet is beterjesszünk a nyílt webfejlesztői közösségek számára.

Ennek érdekében ma bemutatjuk a NEX formátumot. A NEX formátum kezdetben egyfajta szuper-készlete a CRX fejlesztői környezetnek melyet a Chromium fejlesztői már használnak. Az Opera mindig is erős elkötelezettje volt a nemzetközi, nyílt szabványoknak és ő maga is régóta aktív szerepet játszik a nyílt webes szabványok fejlesztésében. Ez nem változott azzal, hogy Chromiumra váltottunk. Céljaink egyike, hogy idővel a NEX is egy ilyen nyílt internetes szabvány legyen, melyet a W3C is támogat majd, kezdetben megosztott csomagok és manifest formátumokként kereszt-böngészős kiegészítőfejlesztéshez, megszüntetve a hallgatólagos függőségeket a CRX formátum irányába a NEX runtime segítségével, ahogy haladunk.

A nyílt webes szabványok használói képesek lesznek kiválasztani a böngészőjüket anélkül, hogy hozzá lennének láncolva egyetlen gyártóhoz vagy termékhez (akár a kiegészítőkön keresztül is). Egy rendszer, mely támogatja a felhasználók választási lehetőségét, könnyebbé teszi a kiegészítőfejlesztők életét és támogatja a megosztott innovációt mely egy egészséges, versenyképes web ökoszisztémát tesz lehetővé. A NEX egy ajánlás, amellyel a Chromium kiegészítőket - a komponenseket, melyek vitathatatlanul olyan fontos részévé váltak a mai webnek, mint maguk a weblapok tartalmai - egy olyan jövőkép kialakítása felé mozgathatjuk, ahol egy nyílt web magjának létrehozásában működünk közre és szilárdítjuk azt meg.

Mit kínál a NEX ma?

A mai Opera által implementált NEX formátum egy szuper-készlet a CRX futtatói környezet felett, habár elméletileg a CRX alap nem kötelező a NEX implementálásához. Az Opera 15-ben a NEX formátum exkluzív hozzáférést biztosít a Opera Extensions Speed Dial API-hoz. Más implementációkat is bárki szabadon hozzáadhat a saját API-jához.

Egy NEX fájl .nex fájlkiterjesztéssel rendelkezik és HTTP-n keresztül érkezik az application/x-navigator-extension MIME type-pal. A fájltípus és a tartalomtípus megváltoztatásával különbséget kívánunk tenni a kereskedelmi fejlesztések között és azok között, amelyek a közvetett kompatibilitás miatt szükségesek más futtatókörnyezetekkel. Az ezzel kapcsolatos témákról a továbbiakban itt olvashattok.

Az Opera a továbbiakban is implementálni fogja a létező CRX formátumot különállóan az Opera 15+ verziókban, így a fejlesztők akik jelenleg a Chromium API-t ismerik, továbbra is folytathatják a fejlesztést és tölthetik fel a CRX-alapú kiegészítőiket az Opera Add-ons katalógusba ugyanúgy, ahogy a Chrome Web Store-ba.

Hogyan fog a NEX fejlődni?

A NEX fejlesztésének kezdeti célpontja a csomagoló és manifest formátumok normalizálása körül fog zajlani, melyek a Chromium és más böngészőfejlesztők folyamatban lévő projektjei — a munkát jelenleg a Mozilla koordinálja a W3C-n keresztül.

A közeljövőben azt szeretnénk, hogy a NEX olyan rugalmas legyen, akárcsak maga a web és egyben egy hely a web legjobb praktikáinak használatára és népszerűsítésére. Konkrétan azt szeretnénk, hogy a böngészőkiegészítő fejlesztők a legjobb gyakorlatot tegyék magukévá, avagy feature detection és kereszt-böngészős környezet a kiegészítők kompatibilitása érdekében. Adott egy szabványos kiegészítő-csomag, mely végrehajtható különböző futtatókörnyezetek alatt - hogy egy hidat nyújtson a funkcionálisan egyenértékű, ám programozásilag eltérő API-k között - ami egy hatalmas lehetőség a webfejlesztők számára. Azt akarjuk, hogy ennek segítségével a fejlesztők egyesített böngészőbővítmény kódot tudjanak írni a különböző API könyvtárakhoz és képesek legyenek futtatni ugyanezen fájlokat különböző futási környezetekben.

Hosszabb távon az Opera azt szeretné, hogy a NEX ösztönözze a valódi és jeletőségteljes eszmecserét a szabványosított API-kkal kapcsolatban (esetleg kezdetben a már meglévő kereskedelmi, de-facto szabványokkal együtt). Amennyiben a böngészőgyártók magukévá teszik ezt az általános csomagolási és manifest formátumot, akkor ezzel egy új, sokkal magasabb szintre lépnének a rendszerszintű alkalmazás API-k terén, továbbá nagyban megkönnyítenék a kiegészítő fejlesztők munkáját. A tény, hogy a gyártók nem osztoznak egyetlen közös környezeten eléggé megnehezíti ezen törekvés véghezvitelét. A NEX-szel reméljük, beindíthatjuk ezt a törekvést az API-k szabványosítása irányába, hogy végül egy egyesített böngésző kiegészítő fejlesztői környezetet hozhassunk létre.

Az Opera a közeljövőben továbbra is folytatja a CRX futtatókörnyezet követését mind a csomagolás, mind a manifest fájlok, mint a Chromium API által nyújtott lehetőségek terén. Idővel azonban az a tervünk, hogy a NEX-et a nyílt, W3C szabványok irányába toljuk, miközben fokozatosan eltávolításra kerülnek a CRX rendszer kereskedelmi részei annak érdekében, hogy az NEX annyira szabványos legyen, amennyire csak lehet.

Hogyan vehetek részt a folyamatban?

Számos dolog van, amit megtehetsz annak érdekében, hogy segíts sikerre vinni az elképzeléseinket egy nyílt, megosztott ökoszisztéma irányába a jövőben.

Annak érdekében, hogy legyen egy megosztott csomagoló és manifest formátumunk, az Opera nagy erőkkel vesz részt a szabványosítási munkálatokban a W3C bizottságban és másokat is bíztatunk a részvételre és arra, hogy segítsenek nekünk céljaink véghezvitelében.

A NEX hosszú távú céljai között szerepel, hogy végig kell gondolnunk mely dolgok legyenek a megosztott kiegészítő API-kban és hogyan nézzenek ki a könyvtárak. Van egy csoport a W3C-nél akik kifejezetten ezt a célt tartják szem előtt. Eközben népszerűsítenünk kell a feature-detection-t annak érdekében, hogy a lehető legzökkenőmentesebben történjen meg a böngészők közötti átmenet. Tudunk ma írni olyan JavaScript könyvtárakat, amelyek segítik a kiegészítők böngészők közötti átjárhatóságát? Hogyan tudnánk enyhíteni a fejlesztőket érintő kihívásokat a böngészők közötti kiegészítők írásában? Ezek mind magas prioritású feladatok egy erős, kiegészítő-fejlesztési platform érdekében, és szeretnénk minél több különböző érdekeltségű felet találni, hogy közösen találjuk ki a legjobb megoldásokat.

Következtetés

Az Opera 15 aktuális NEX implementációja tükrözi az első lépést a nyílt, szabvány-alapú fejlesztői környezet irányába. Mindkét tényező elengedhetetlen az alapvető stabilitáshoz és ahhoz, hogy a jövőben egy valóban univerzális alkalmazás platformot kínáljunk. Mint közösség és mint részvevők ebben a folyamatban, rengeteg szabványosítással kapcsolatos munkánk lesz, mellyel megalapozhatunk egy szebb jövőt.

Amennyiben még többet szeretnél tudni a NEX-ről, esetleg írni is szeretnél NEX kiegészítőket, bátran fordulj a NEX documentációnkhoz további információkért.

(forrás)

Pár nappal azután, hogy kiadták az Opera történetében mérföldkőnek számító 15-ös verziót, a böngésző fejlesztői úgy érezték, hogy kicsit részletesebben beszélniük kell a böngészőmotor-váltás hátteréről és a várható változásokról. Mindezt egy Desktop Team bejegyzésben tették meg, amit Nekomajin fórumtárs volt oly szíves és lefordított magyarra. Az alábbiakban ezt olvashatjátok, neki pedig köszönjük a remek fordítást!

Ez a bejegyzés a "The vision behind Opera 15 and beyond" című cikk fordítása. Az eredeti cikk 2013. július 4-én jelent meg a Desktop Team blogon.

Most, hogy végre elérkeztünk a keddi mérföldkőhöz, és kiadtuk az Opera 15-öt, itt az ideje, hogy egy kis betekintést adjunk a jövőbeli elképzeléseinkbe.

Amikor 1996-ban kiadtuk az első böngészőnket, a webet használók többségének nem volt ellenére egy kis barkácsolás, és szerették, ha mindent személyre lehetett szabni. Ugorjunk 17 évet, és azt látjuk, hogy a web körbevesz minket. A legtöbb ember számára a gyors böngészés és az oldalak megfelelő működése a legfontosabb.

Ezzel el is érkeztünk ahhoz a problémához, amivel minden szoftverfejlesztő szembenéz előbb vagy utóbb: hogy csináljunk egy olyan felületet, ami elég egyszerű az átlagfelhasználónak, aki csak böngészni szeretne, de mégis személyre szabható és bővíthető, hogy a különlegesebb igényeket is kielégítse?

A válasz: építsünk egy erős és bővíthető alapot, amire később építkezni lehet. Az Opera 15 egy új kezdet, amihez újabb és újabb funkciókat fogunk hozzáadni.

Egy közelebbi pillantás az Opera 15-re

Amikor elhatároztuk, hogy Chromiumra váltunk, a kompatibilitás volt az egyik szempont, de ennél sokkal fontosabb, hogy több időt akartunk szánni az innovációra a böngészőmotor fejlesztése helyett. Alaposan átnéztük az Opera belső felépítését, és gyorsan egyértelművé vált, hogy a Quick – a saját fejlesztésű, keresztplatform rendszerünk, amivel a felhasználói felületet készítettük már 2003 óta – olyan mélyen bele van ágyazva a Presto kódjába, hogy nem tudjuk csak simán kicserélni a Prestót a Chromiumra.

Ugyanez volt a helyzet az M2-vel. Ahhoz, hogy hozzá tudjuk adni az Opera 15-höz, teljesen újra kellett volna írnunk a semmiből. Ráadásul plusz letöltendő adatmennyiség és felhasználói felület lett volna azoknak, akik nem használták ezt a funkciót. Ezért választottuk le a kódot, és készítettünk egy különálló programot.

Ugyanakkor szerettük volna, ha az Opera jobban illeszkedik az operációs rendszerbe. Szerencsére a szükséges eszközök sokat fejlődtek az elmúlt 10 évben, főleg Mac-en, ezért úgy döntöttünk, hogy a teljes felhasználói felületet natív kódban fogjuk megírni. Leválasztottuk a Chromium UI rétegét, és írtunk egy sajátot az alapoktól. Ez egy hatalmas vállalkozás volt, de amit most láttok, az csak a kezdet.

Először a Gyorshívót, a Gyűjtőlapot, a Felfedezést és még egy csomó mindent natív kódban akartunk megírni, de amikor láttuk, hogy az első, működőképes böngésző prototípusunk milyen jó teljesítményre képes, úgy döntöttünk, hogy maradunk a web alapú (éppen ezért keresztplatform) megoldásoknál. Akár meg is nézhetitek a Webfelügyelővel a forráskódot.

Tehát új alapokkal rendelkezünk, és úgy döntöttünk, hogy alaposan megfontoljuk, hogyan építjük fel újra az Operát, mivel a régi már nagyon túlzsúfolttá vált. Sok funkció inkább zavaró volt a felhasználóknak, minthogy segítette volna őket. El sem tudjátok képzelni, hogy milyen sok visszajelzést kaptunk a felhasználóktól, amiben azt írták, hogy a kedvenc weboldaluk szétesett, aztán kiderült például az, hogy véletlenül bekapcsolták az illeszkedést.

Szóval az új böngészőt úgy fogjuk felépíteni, hogy minél többféle böngészési szokásnak megfeleljünk, de alapjában véve azt akarjuk, hogy a felhasználói felület minél egyszerűbb maradjon, hogy bárki használni tudja.

Most pedig nézzünk meg négy funkciót az Opera 15-ből, hogy részletesebben is megismerjétek a fejlesztési folyamatot.

Gyorshívó

A Gyorshívót 2007-ben mutattuk be. Amikor megszüntettük a létrehozható elemek számának korlátozását, rájöttünk, hogy a Gyorshívó és a hagyományos könyvjelzők közötti határ egyre inkább kezd elmosódni. Ahelyett, hogy egy menüben vagy egy panelen böngészték volna a fa-struktúrát, a felhasználók egyre inkább a címsáv automatikus kiegészítését, a Gyorshívót és a beépített keresőket kezdték el használni. Ez adta az ötletet, hogy vigyük át a könyvjelzőket közvetlenül a böngészőablakba, ahol minden más is zajlik. A mappázhatóság, az előnézeti képek és a szuper gyors keresés lehetővé teszi, hogy pillanatok alatt megtaláld bármelyik kedvenc oldaladat.

Gyűjtőlap

Azt vettük észre, hogy a modern böngészőkben elég nehéz kutatni. Megnyitsz egy csomó fület, (például amikor különböző termékeket hasonlítasz össze), és egy idő után már nem tudod, hogy melyik fülön mi van. A böngészési folyamatok és a fülcsoportosítás segítenek egy kicsit, de sok felhasználót össze is zavarnak, mert növelik a felület bonyolultságát. Ezért találtuk ki a Gyűjtőlapot, ami lehetővé teszi, hogy a függőlegesen egymás alá rendezett oldalakon villámgyorsan keress. Ezzel csökkentheted az egyszerre megnyitott fülek és az egyszerre futó processzek számát.

Az elmúlt hetekben azt láttuk, hogy a felhasználók többféle módon próbálják kihasználni a funkciót, úgyhogy érdeklődve várjuk, hogy hová fog fejlődni a dolog.

Felfedezés

Most, hogy a web már körbevesz minket, teljesen általánossá vált, hogy a kanapén heverve vagy a buszra várva egy notebookkal vagy telefonnal a kezünkben töltjük el az időt. De olyan sok az információ, hogy nehéz eldönteni, honnan induljunk el. A Felfedezés egy olyan funkció, ami előre kiválasztott tartalmakat közvetít feléd többféle nyelven, egyenesen az agyadba.

Rally mód

Nincs mindenkinek állandó szélessávú hozzáférése. Az Opera 10-ben mutatkozott be a Turbo, ami gyorsabb megjelenítést tett lehetővé lassú internet kapcsolat mellett. Az Opera 11.1-ben ezt azzal bővítettük ki, hogy a képeket WebP formátummal tömörítettük. Az Opera 15 ehhez még a SPDY protokoll támogatást is hozzáadja, hogy még az eddigieknél is gyorsabban böngészhess.

...és a jövőbe

Nem véletlen, hogy az Opera 15 megjelenésével együtt átálltunk a gyorsított kiadási ütemezésre. Hamarosan látni fogjátok, hogy miket tervezünk még. Jelen pillanatban a témákon, a szinkronizáláson és a fejlettebb fülkezelésen dolgozunk.

Ha profi felhasználó vagy – ha ezeket a sorokat olvasod, akkor valószínűleg az vagy –, és úgy érzed, hogy egy számodra fontos funkció hiányzik az Opera 15-ből, akkor először böngészd át az egyre növekvő kiegészítő listánkat! Lehet, hogy az alapszintű könyvjelzőkezelő kiegészítőnk megfelel számodra, de az is lehet, hogy a cottonTracks kiegészítő innovatív megközelítése oldja meg a problémádat. Ha hiányoznak a jegyzetek, akkor próbáld ki az Evernote kiegészítőt!

Ha úgy érzed, hogy az Opera 15-ből valami alapvető dolog hiányzik, nem muszáj frissítened, mert az Opera 12 továbbra is él, és természetesen az Opera 16 is hamarosan érkezik.

Várjuk a hozzászólásaitokat és visszajelzéseiteket, ahogy az elmúlt 17 évben is tettük. Arra kérünk, hogy küldjél jelentést, ha valami hibát találsz! A cégen belül nekünk is van saját kívánságlistánk. Bruce például a Ctrl+Enter és a török nyelvű Felfedezés miatt rágja a fülünket, Andreas pedig a kiegészítő API és a könyvjelzők miatt sürget.

Ezek egy része elérhető lesz a több, mint 50 millió felhasználónk számára, másik része viszont nem. Nem akarjuk az Opera 12-t klónozni, ahogyan semelyik másik böngészőt sem. Továbbra is azon dolgozunk, hogy a legjobb böngészőt fejlesszük ki.

• Utálod, hogy bizonyos oldalak teljesen indokolatlanul használják a target attribútumokat?
• Mivel ismered az Operás trükköket (akár keresőformokban, címsorban is Shift+Enter illetve Ctrl+Shift+Enter) teljesen feleslegesnek tartod, hogy bármi új lapon nyíljon meg?
• Szeretnéd, ha a javascript: kezdetű linkekre is érvényes lenne a Shift+klikk illetve Ctrl+Shift+klikk?
• Esetleg régi álmod, hogy az MDI ablakok ne csináljanak maguknak új fület?

Ha ezek közül akár egyre is "Igen" a válaszod, akkor mindenképp próbáld ki az AdvancedPopup nevű kiegészítőt.

Működése:

Kétféle beállítási lehetősége van. Az egyik a globális beállítás, amit az Opera gomb → Kiegészítők/Extensions → Kiterjesztések kezelése/Manage Extensions → helyen érhetsz el a csavarkulcs ikon → Beállítások/Preferences menüpontjára kattintva. Ez minden oldalra érvényes lesz.

A másik a domainspecifikus beállítás, amit a kiegészítő eszköztáron lévő ikonjára kattintva érhetsz el és módosíthatsz eltérően a globális beállításokról. Ez csak az adott domainre lesz hatással.

Itt természetesen a 4 funkciót határozhatod meg, hogyan működjön (illetve működjön-e)

Funkciói:

DisOpenWin: Minden lehetőséget kiiktat, hogy valami új lapon nyíljon meg, legyen az target="_blank" vagy éppen window.open

InsidePopup: Az MDI ablakok helyett belső ablakok jelennek meg az adott fülön belül. Hátránya, hogy a mozdulatparancs, illetve Ctrl+W az egész fület bezárja, tehát ezt a popupot csak a sarkában lévő X-el lehet bezárni.

TargetPopup: Amik popup-ként nyílnának meg normál esetben azok rendes popupként nyílnak meg ezzel a beállítással.

ForcePopup: Mindenképp rendes popupként nyílik meg az oldal. Ennek paramétereit az option helyen a beállításoknál legalul lehet szerkeszteni. Vagyis mekkora legyen a popup, legyen-e címsor, legyen-e scrollbar, ilyesmi.

Még fél év sem telt el a kiegészítők bejelentése óta, máris több hasznos kiegészítő jelent meg. Leszámítva az új funkciókat kínáló kiegészítőket, az Anti BrowserSniffer az egyik leghasznosabb, amely olyan oldalakat is életre kelt, amit eddig maszkolással sem sikerült és böngészőspecifikus JS függvények javítására is kísérletet tesz.

Mielőtt mindenki örömmel telepítené, megjegyezném, ahogy whochan (a fejlesztő) is írta, néha ez a kiegészítő oldalmegjelenési problémákat is okozhat, szóval csak óvatosan vele.

Félni nem kell tőle, mivel ilyeneket a piros kapszula ikonra kattintva javíthatunk. Ez egyébként többnyire olyankor fordul elő, mikor egy weboldalnak képletesen szólva "lóg a bele" és a webfejlesztő szabványos kód helyett valamelyik régebbi Internet Explorerre írja meg, majd user agent alapján egy script dönti el, hogy a forráskód cafatok, - amiket Frankenstein is megirigyelne - hogyan jelenjenek meg egyes böngészőkben.

Mindenesetre jól szimbolizálja, hogy hol fejlesztett a webfejlesztő, hol pedig kókányolt és maximum külső nyomásra rakott a gányolt kódba egy "if (navigator.userAgent.indexOf("Opera")" kezdetű függvényt. Amit ez esetben workaround céljából tett meg, nem pedig szokás szerint azért, hogy diszkriminálja a böngészőt, mert ugyebár normális (még csak teljesen szabványosnak sem muszáj lennie) kód esetén nincs erre semmi szükség. Legalábbis nem olyan esetben, hogy ne működjön miatta az oldal.

A javított oldalak (a japán oldalakat leszámítva):

• Google Maps: Google Earth kompatibilitás.
• YouTube: A képernyő nem gördül, mikor kiválasztunk egy kulcsszót a suggestion listából.
• Picasa: A "Nem támogatott böngésző" dobozt eltünteti.
• Google Docs: A Spreadsheetsben javítja a cella kiválasztó keret padding hibáját és az oldal is valamivel gyorsabban reagál (vagy csak placebo hatás).

Magyar oldalak (nincsenek a felsorolásban):

• Tom's Hardware: Alul a charts legördülő nem hullik szét.
• Hírek.hu: Már betöltődik a dobozok tartalma.
• Napi online: Már nem kell az Illeszkedést bekapcsolni a teljes grafikon megtekintéséhez.
• Fegyvernek Nagyközség honlapja: A lenyíló menük almenüi már jó helyen jelennek meg, nem az oldal közepén.

Valamint a Scribd-en is javított valamennyit, de az még mindig problémás, de legalább már nem használhatatlan. Ahova bejelentkezés szükséges (Battlefield Heroes, DIGI Sport, Lord of Fultima, Quake Live, K&H Bank, CitiBank, HotDog, ELMŰ) nem tudom ellenőrizni. Lehet, hogy azok közül is javít.

A kiegészítőn belül van egy preferences mappa, benne egy sitelist.js nevű fájl, ezt szerkesztve lehet fix (tehát nem Local Storage alapú) tiltásokat felvenni.

Jelmagyarázat:

• Engedélyezve:
• Letiltva:
• Nem szükséges:

Több, mint egy évvel ezelőtt merült fel itt a blogon egy cikksorozat megírásának lehetősége, amit nem mi, hanem ti, az olvasók jegyeztek. Számunkra is meglepő volt a pozitív reakció, amivel ezt a kezdeményezést fogadtátok. Ennek jele volt a számos elküldött cikk, amiket folyamatosan jelentettünk meg.

Egy pont után aztán telítésbe ment a téma, és a cikkek kezdtek talán kissé unalmassá válni. Na nem azért, mert rosszabbak lettek volna, mint a legelsők, egyszerűen olyan sűrűn követték egymást, hogy megszoktuk őket, és kevésbé jelentettek újdonságot.

Emiatt úgy döntöttünk, hogy egy időre jegeljük őket, ami olyan jól sikerült, hogy a legutóbbi óta is közel hét hónap telt el. Szóval mostanra remélhetőleg már mindenki ki van éhezve az újabb bemutatókra, így örömmel jelenthetem, hogy a közeljövőben újra elindítjuk a sorozatot.

Nem felejtkezünk el a nyereményjátékról sem, amiben annak idején a beküldött és megjelent cikkek szerzői vehettek részt. Minden 10. írás után terveztünk szavazást Opera ajándékokért, az első menet rendben le is ment. Természetesen nem felejtkeztünk el a többiekről sem, akik már egy újabb szavazás mezőnyét képezik. Ezúttal is elnézésüket kérjük a hiányosságért, de ami késik, nem múlik...

Vannak olyanok is, akik annak idején beküldték a maguk írását, de még mindig nem kerültek sorra. Nekik szeretnénk lehetőséget biztosítani arra, hogy akkori cikküket kiegészítsék, aktualizálják, ha jónak látják. Ebben az esetben jelezzék nekünk szándékukat, különben pedig az eredeti mű fog megjelenni.

A fentieken túl pedig mindenkit buzdítanék, hogy aki eddig nem tette volna meg, most fogjon neki a saját cikkének. Sőt, szívesen fogadjuk olyanok írását is, akiktől már korábban olvashattunk valamit, hiszen érdekes látni hogy az elmúlt évben hogyan változtak a szokások. Értelemszerűen ez rövidebb cikket jelent, hiszen a "történelmet" felesleges lenne még egyszer leírni.

Egyfajta kedvcsinálóként - versenyen kívül - álljon itt tehát a saját művem, amivel szeretném újra bevezetni a köztudatba cikksorozatot. Szóval az Én Operám - cousin333 jóvoltából. Kellemes olvasgatást!

I. - Én és az Opera

A kezdetek

Első tétova netes lépéseimet még a gimnázium számítástechnika termében tettem meg. Ehhez eszközül a Netscape Navigator nevezetű szoftvert használtam, ami kb. az általam ismert egyetlen böngésző volt. AZ akkor net (az ezredforduló előtt vagyunk) még meglehetősen egyszerű és ingerszegény volt a mostanival összevetve, és sokkal kevesebb lehetőséget nyújtott, mindenesetre izgatottan merültem el ebben az új világban

Idővel az eszköz is változott, egyre többet használtam ugyanis az akkor megjelent Internet Explorer 4-et, mivel a Netscape egyre instabilabbá vált, ez meg nagyjából ugyanazt tudta. Mit sem tudtam az akkoriban dúló szörnyűséges Első Böngésző Háborúból, egyszerűen böngészni akartam, az IE pedig megfelelt erre.

Ismerkedés az Operával

A helyzet az, hogy nem emlékszem, mi késztetett arra, hogy valamikor 2001 őszén kipróbáljam az Operát. Valószínűleg a természetes kíváncsiság vitt rá, hogy egy akkori bemutató cikk alapján(?) letöltöttem és telepítettem. Nem tudom pontosan, de vélhetően az Opera 5 volt az első alany, amit hamarosan felváltott az Opera 6.