Magyar Opera

Dev, Next? Mi van?

Az Opera a mai nappal, a 17 Dev verzió megjelenésével állt át rendesen a Chrome és a Firefox által is használt, úgynevezett gyorsított kiadási ütemezésre. Lássuk, hogy miből is áll ez a váltás!

Az Opera korábban a "klasszikus" kiadási ütemezést követte. Ez azt jelentette, hogy a fejlesztők belső összeállítások sokaságán tesztelték a fejlesztéseket, majd amikor úgy érezték, hogy az előre megtervezett funkciócsomag már működőképes, akkor kiadtak egy alfa verziót, és onnantól átálltak a fejlesztésről a hibák javítására. Ebben a fázisban tudtak bekapcsolódni a felhasználók azzal, hogy telepítették az alfa verziót, és a mindennapi használat közben előjött hibákat jelezték a fejlesztőknek.

Ezt követte egy vagy több béta és kiadásra szánt (RC) verzió közzététele, amik jó esetben már csak kisebb hibákat tartalmaztak, és általában mindennapi használatra is alkalmasak voltak. Az alfa és a végleges, stabil összeállítás kiadása között viszont sokszor több hónap is eltelt, hiszen egy-egy verzió több funkciót és újdonságot is tartalmazott.

Az iparág azonban felismerte, hogy a web fejlődési üteme mellett ez a stratégia nem tartható, ezért kialakult az a stratégia, amit ma gyorsított kiadási ütemezésnek nevezünk. A jelmondat az, hogy "adj ki kevesebbet gyakrabban", de a stratégiaváltás valójában többről szól. Az alábbi három jelentősebb változás következett be.

Az első természetesen az, amit a jelmondat is megfogalmaz. A fejlesztők a tervben lévő fejlesztéseket kisebb csomagokra osztják, így a gyorsabban elkészülő fejlesztéseknek nem kell a fiókban várni a lassabban elkészülőkre. Ez teljesen logikus, hiszen ha valami már készen van, akkor adjuk oda a felhasználóknak minél hamarabb. Egy ilyen gyorsított ciklus általában egy-másfél hónapot jelent.

A második változás a verziószámozást érinti. Sok szakmabelit és felhasználót megbotránkoztatott, hogy az évtizedek óta megszokott számozást a kukába dobva, havonta növelik a verziószámot a gyártók. Ami korábban 15.1 lett volna, az most a 16-os számot kapta. Ez azonban csak marketing fogás, semmilyen funkcionális dolog nincs mögötte. A nyilvántartás korábban is az összeállítások számozása alapján történt, bár az tény, hogy a verziószám több információt rejtett magában. Ez azonban, ahogy írtam, csak marketing, nem érdemes vele bővebben foglalkozni.

A harmadik változás az összeállítások elnevezését érinti. A korábbi alfa és béta verziók helyett bevezették a kiadási csatornákat. Ezek a csatornák egymástól függetlenül telepíthetők és használhatók. Jelen esetben egymás mellett böngészhetünk a stabil 15-ös verzióval, tesztelhetjük a 16-os Next verziót, és próbálgathatjuk a 17-es Dev verziót.

A Dev csatorna olyan már működőképes, de még fejlesztés alatt álló funkciókat tartalmaz, amiket lehet már próbálgatni, de még nincsenek teljesen készen, és bármelyik pillanatban összeomolhat tőlük a böngésző. A Next csatorna olyan funkciókat tartalmaz, amik már késznek tekinthetők, de lehet, hogy még hibásan működnek. Odafigyeléssel akár mindennapos használatba is vehetők, de nincs kizárva, hogy előfordul valami probléma. A stabil csatorna az, ami bárki számára használható a mindennapi böngészéshez. Elvileg nem tartalmaz hibát. (Gyakorlatilag igen.)

A Developer és Next csatornák közötti fontos különbség az, hogy a Developer verziókba bármelyik frissítéskor kerülhetnek új funkciók, míg a Next verziók már lezártnak tekinthetők. Új funkciókat már nem kapnak, csak a meglévő hibákat javítják.

Az alábbi táblázat összefoglalja a legfontosabb ismereteket a csatornákkal kapcsolatban:

Csatorna neve Régi verzió Firefox/Chrome megfelelő Frissítési gyakoriság Kiknek ajánlott
Stable végleges Release/Stable

Kiadási ciklusonként (egy-másfél havonta)

Átlagos felhasználóknak, akik csak használni akarják a böngészőt.
Next béta, RC Beta/Beta 1-2 hetente Bárkinek, aki kíváncsi, van ideje, és ért annyira a dolgokhoz, hogy el tudja magyarázni a hibát, amit tapasztalt.
Developer lab, alfa Aurora/Developer Hetente Fejlesztőknek, kockáknak, hozzárétőknek.

Opera 17 – az első fejlesztői kiadás

A mai napon megérkezett az Opera Developer ág első kiadása a 17-es verzióval. A kiadási ágakról és ciklusokról egy későbbi bejegyzésben olvashattok majd. Most lássuk, milyen finomságokat kapunk.

Amit már tud

  • Indítási beállítások: gyorshívó, előző böngészési folyamat vagy fixen beállított weboldal(ak)
  • Rögzített fülek
  • Rocker mozdulatok: bal -> jobb és jobb -> bal egérkattintás
  • Újabb kiegészítő API-k: bookmarks, commands, omnibox, webNavigation (Ezekről bővebben is fognak írni hamarosan.)
  • Személyre szabható keresők

Teljes változáslista

Amit tudni fog

  • Témák: Amik ráadásul oda-vissza kompatibilisak a 12-tes verzióval.
  • Kamera/mikrofon: A getUserMedia API újra implementálva van.
  • HiDPI támogatás: Windows alatt már elérhető a kis merű, de nagy felbontású kijelzők támogatása.

Ezek a funkciók az opera:flags oldalon kapcsolhatók be.

További tervek

  • További fülkezelés fejlesztések: oldalra helyezhető fülek, vizuális fülek, fülek mozgatása ablakok között
  • Könyvjelzősáv
  • További szinkronizálás fejlesztések

Jelenleg tehát így áll az Opera Developer 17, viszont a fejlesztők felhívták a figyelmünket, hogy a Next 15 verzióval ellentétben ez még nem végleges funkciólista. Mire a Next 17 megjelenik, újabb funkciók is kerülhetnek bele, és a fentiekből is kerülhetnek ki, ha túl bugosnak bizonyulnak.

Letöltések: Windows, Mac

A bejegyzést frissíteni fogjuk, ha lesz időnk rendesen kipróbálni a programot, hogy ne kelljen a hozzászólások között keresgélni. Felhívjuk mindenki figyelmét, hogy ez egy fejlesztői előzetes! Bugos, összeomolhat, adatvesztés történhet!

Eddig tartott a hivatalos bejegyzés többé-kevésbé fordítása. Mostantól a blog szerkesztőinek észrevételei következnek.

  • Eltűnt a bezárás gomb az utolsó nyitva lévő fülről. Jelenleg nem lehet úgy állítani, mint a Firefoxban. (Látszik, hogy piszkálják a GUI-t, mert a bezárás gomb margója mintha nagyobb lenne a füleken.)
  • A könyvjelzősáv (quick access bar) GUI-ja már bekapcsolható, de elemeket még nem lehet hozzáadni. Könyvjelzőkezelő még nincs.
  • Saját keresőket már lehet hozzáadni, de még nem a régi módon. A keresőmezők helyimenüjében nincs ilyen opció. A címsáv helyimenüjében viszont van. Egy párbeszédablakban, elég macerásan lehet megoldani, de működik. Ráadásul a saját keresők is megjelennek a címsáv lenyíló részének jobb alsó sarkában. (Bár az oldal faviconja helyett a default nagyító ikont mutatja. Biztosan bug.) UPDATE: A böngésző újraindítása után megjelenik a helyes favicon.
  • A beállításokban van egy kapcsoló, amivel a fülek fölötti margó eltűntethető. Ha feltoljuk az egeret a képernyő tetejére, biztosan a fülre fogunk kattintani, nem az ablakkeretre.
  • A szinkronizálás gombja eltűnt a kezdőlapról. A menüből vagy a beállításokból vagy a címsávból lehet elérni az opera:sync belső lapot, ahol be lehet jelentkezni. Bugos, a fül bezárása után elfelejti, hogy bejelentkeztél.
  • A beállítások belső lap kapott egy kis fejlesztést. Magyarázatokat csatoltak néhány elemhez.
  • A beállításokban opcionálisan megadható, hogy ha előző böngészési folyamattal vagy fix lapokkal indul az Opera, akkor egyből elkezdje tölteni az összes lapot, vagy csak azt töltse be mindig, amelyik aktív, ahogyan a Firefox csinálja.

A NEX bemutatása - szabványos kiegészítők

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)

Opera 15+ mappaszerkezet és fájlok

Többen is kérdeztétek, hogy az új Opera különböző beállításait és adatait tároló fájlokat át lehet-e másolni olyan egyszerűen, mint a régi Opera esetében. A válasz igen. A helyzet nagyon hasonló, néhány változás viszont van. Lássuk, hogy Windowson mit hol találunk!

Mappaszerkezet

Az Opera továbbra is a megszokott helyekre terepül. A programot, a beállításokat és a gyorsítótárat a következő helyeken találjuk:

  • Program Files\Opera
  • Felhasználók\<felhasználónév>\AppData\Roaming\Opera Software
  • Felhasználók\<felhasználónév>\AppData\Local\Opera Software

64 bites rendszeren természetesen a Program Files (x86) mappában találjuk az Opera mappát. XP-n pedig a Documents & Settings\Application Data és Local Settings mappákban kell keresni a beállításokért. Ne feledjük, hogy az utóbbi mappák alapértelmezetten rejtve vannak a felhasználók elől!

Fájlok

A második elérési útvonalon találjuk azokat a fájlokat, amiket egy-egy újratelepítés során át tudunk másolni, ahogy régen is. A jól megszokott ini-k és adr-ek helyett viszont a db-kkel és a kiterjesztés nélküli fájlokkal kell megbarátkoznunk. Lássuk!

  • Gyorshívó: favorites.db
  • Böngészési folyamatok: session.db
  • Gyűjtőlap: stash.db
  • Sütik: Cookies
  • Előzmények: History
  • Beállítások: Preferences
  • Űrlapkitöltési adatok: Web Data
  • Bejelentkezési adatok: Login Data

A fenti három elérési utat megtaláljuk az Opera névjegye oldalon is, az egyes fájlok elérési útját viszont még nem. Reméljük, hogy a jövőben ezt is pótolják.

Ahogy azt is, hogy minden fájlt kiterjesztéssel látnak el, mert a kiterjesztés nélküli fájlok között vannak SQLite és JSON fájlok is. Az utóbbi ember számára olvasható, vagyis a korábbi ini-khez hasonlóan tudjuk őket szerkeszteni bármilyen szövegszerkesztővel, az előbbihez pedig ezt az egyszerű programot kell telepítenünk.. (A fenti listából egyedül a Preferences fájl JSON formátumú.)

Opera Next 16 frissítés

Sajnos túl sok újdonságról nem tudunk beszámolni, mindenesetre valamelyest megint jobb lett a böngésző. Az Opera Next 16 ma megjelent frissítése a Chromium 29.0.1547.23 kiadásra épül, ezenkívül javításokat tartalmaz azok számára, akik nagyon sok, vagy éppen elég kevés lappal böngésznek – ezek a főbb újítások.

Letöltés:

Az előző verzió ismert hibáit (DNA-8918, DNA-8133, DNA-8270) még nem sikerült megoldani.

Teljes változtatás lista

süti beállítások módosítása