Magyar Opera

Címkék » labs


Opera Labs: SPDY támogatás!

A pénteki napon nem a 12.5 első előzetese volt az egyetlen fontos operás esemény. Azt megelőzően mutatták be ugyanis az Opera Labs legfrissebb kiadását is, ami az aktuális 12.01 és az SPDY protokoll találkozása. Ez egy, a Google által fejlesztett átviteli protokoll, ami nem a megszokott HTTP helyett, hanem annak kiegészítésére készült.

A projekt célja az volt, hogy a mára elavultnak tekinthető HTTP-t felhozza a 2010-es évek internetjének színvonalára. A főbb célkitűzések a következők voltak:

  • Egyszerre több elem beolvasása egy kapcsolaton keresztül
  • A szerver is kezdeményezhessen adatátvitelt
  • Tömörített, kevésbé redundáns fejlécek és válaszok
  • Tömörített adatátvitel (opcionális)

A lényeg tehát az adatátvitel egyszerűsítése, ezáltal a forgalom gyorsítása és a késleltetések csökkentése volt. A Google mérései szerint az oldalak betöltődési sebessége akár 40-60%-kal gyorsulhat. Fontos továbbá, hogy ez nem pusztába kiáltott szó, számos - elsősorban persze Google-höz kötődő - oldal már most is támogatja, például a Gmail, de a Twitter is fent van a listán, ami várhatóan tovább nő majd. A böngészők közül értelemszerűen a Chrome, illetve a Firefox ismeri az új protokollt.

Az Opera Labs kiadás - egy két apró kivételtől eltekintve - mind a SPDY draft 2, mind a SPDY draft 3 specifikációt támogatja. A protokoll használata automatikus, nem jelenik meg hozzá semmilyen extra ikon, vagy jelzés. Később - ha az API-ba implementálták a szükséges változásokat - lehetséges lesz olyan kiegészítők létrehozása, amik valamilyen formában mutatják, ha a böngésző SPDY-t használ.

Mint minden Labs kiadás, ez is csak 1-2 funkcióra koncentrál (jelen esetben az SPDY implementációra), tehát csak azt töltse le, aki ezt akarja kipróbálni. A 12.5 újításai nincsenek benne! Hogy melyik verzióba kerül be az SPDY támogatás, az jelenleg nem ismert, szerintem a 12.5-ben már benne lesz, de erre egyelőre senki ne építsen.

Opera Labs kiadás, SPDY támogatással (b1495):

Opera Labs: webkamera a böngészőben

Tegnap egy új verzió érkezett az Opera Labs gondozásában. Róluk, ugye, azt kell tudni, hogy fognak egy nagyjából aktuális Operát, és nevelő célzattal beleépítik valamelyik, még nem szériaérett, új funkciót azok közül, amelyeken egyébként a háttérben folyamatosan dolgoznak. Teszik mindezt azzal a nem titkolt szándékkal, hogy a webfejlesztők minél korábban megismerkedhessenek az általában szabványtámogatást jelentő újítással, és nem mellesleg annak operás implementációjával. Egy szabvány ugyanis annyit ér, amennyit és ahogy a böngészőfejlesztők képesek megvalósítani belőle.

A tegnapi előzetes nem előzmények nélkül való. Tavaly októberben már kaptunk egy fejlesztői kiadást, aminek a mostanihoz hasonlóan a getUserMedia nevű alkalmazásprogramozási felület (API) volt az (egyik) fő újdonsága. A mostani kiadás ezt emeli új szintre, hiszen a kötelező jellegű hibajavítások mellett az API-t az egyébként folyamatosan fejlődő specifikációhoz igazították.

Az új engedélykérő párbeszédpanel

Emellett a már-már hagyományossá váló információs ablakban (lásd a fenti képet) engedélyezhetjük az oldal esetleges webkamera-használati szándékát. Ráadásul a szintén innen elérhető "lap adatai" panel immár 2 oldalassá vált. Az elsőn a szokásos biztonsági információkat láthatjuk, a másodikon pedig azt, hogy helyzetmeghatározás (Geolocation) és kamerahasználat funkciók közül melyikeket engedélyeztünk az adott oldalnak.

Mire is jó ez az egész? Röviden arról van szó, hogy a honlapok készítői számára elérhetővé és kezelhetővé válik a felhasználó webkamerája. Tágabb összefüggésekben vizsgálva a kérdést: még egy példa arra, hogy az alapvető és a jövő webes alkalmazásai számára szinte szükségszerű területeken hogyan szorítja ki a natív, szabványos megoldás a különféle beépülőket. Ennek az egyik legfőbb előnye, hogy a honlap többi része képes hozzáférni és manipulálni a beolvasott tartalmat, amint azt a cikk végi linkeken lévő példák is mutatják.

Az új információs panel

Az új kiadás elsősorban a fejlesztőket célozza, akiknek egy cikkel is kedveskedtek az operások, amiből megtudhatják, mi fán is terem a getUserMedia. A fejlesztői kiadást viszont bárki letöltheti, hogy egy kicsit bepillantson a "jövőbe", például úgy, hogy megtekinti a linkelt alkalmazási példákat. Nem mellesleg kerek 20 ponttal is gazdagodhat a népszerű HTML5 tesztoldalon. Ahol elég komoly pontokat kaphat, elvégre ez a Labs kiadás a legfrissebb(?) hardvergyorsításos kiadás felturbózásával született meg.

A korábbiakhoz hasonlóan a webkamera-kezelést is tartalmazó Labs kiadást az Opera előzetes-oldaláról tudjátok letölteni.

Opera Labs: 64 bit és külön beépülő-processz!

Nem tudom, ti hogy vagytok vele, én vártam ma egy előzetest. A számításom be is vált, meg nem is. Előzetes ugyanis érkezett, de nem szorosan az Opera 12-höz kapcsolódva, hanem úgynevezett Labs Release-ként. Ez tulajdonképpen egy olyan előzetes, ami - legalábbis egyelőre - nem illeszkedik bele a kiadások sorába. Célja az, hogy valami radikálisan új funkcionalitást vagy koncepciót ismertessen meg a nagyközönséggel, aminek a kiadása még eléggé távoli. Talán még emlékeztek rá, a video tag és a WebGL is így kezdte egykoron...

Beépülők külön processzben

opera_plugin_crash.png

A mai kiadás két komoly újítással ismertet meg minket. Az első igazából nem az, legalábbis FreeBSD és Linux rendszereken már régóta létezik: a külön processzben futó beépülőkről van szó. Más böngészőkben egy ideje szintén megtalálható ez a technika. Arról van szó, hogy a stabilitást veszélyeztető tényezők között nagyon előkelő - egyesek szerint egyenesen első - helyen találhatók a beépülőkkel kapcsolatos fagyások.

A dolog rákfenéje - és egyben a beépülők ellen szóló egyik legfontosabb érv -, hogy ezen külsős elemek fejlesztésére nincs rálátása a böngészőgyártóknak. Ha az SVG rajzolás összeomlasztja a böngészőt, vagy a GPU gyorsítás kékhalálba taszítja a rendszert, az legtöbbször a böngésző hibája, tehát nekik is illik javítani. A beépülőket ugyanakkor csak integrálják, de nem ők fejlesztik. Viszont ha az adott plugin fejre áll, viszi magával a böngészőt is, amit az egyszeri felhasználó biztos nem vesz jó néven.

Egy megoldás lehet a problémára, ha egyszerűen elhagyjuk a beépülőket. Ez viszont - bármennyire hatékony - nem járható út a net jelenlegi állapotában. Hosszútávon a HTML5 hozhat enyhülést (nem megváltást!), de addig is itt egy szolidabb megoldás: ha már egyszer a beépülő a böngésző többi részétől függetlenül működik, szeparáljuk el processz-szinten is. Így egy esetleges összeomlás a halálba küldi a Youtube videónkat, de a böngésző élni fog.

Böngészés 64 biten 

A másik jelentős újítást a 64 bites kiadások jelentik. Ezek e fejlesztők szerint bizonyos területeken teljesítménynövekedést hoznak magukkal, valamint nagyobb szabadságot a memória-kezelés területén. remélem ez alatt nem a 2GB fölötti megcímezhető memóriaterületet értik... Mindenesetre elmondásuk szerint már egy jó ideje foglalkoznak a témával, de a felhasználók számára transzparens átmenetet szerettek volna. Ami az olvasatukban azt jelenti, hogy a 64 bites Opera képes legyen 32 bites beépülők futtatására is. Találjátok ki, a külön processzben futó beépülők mire jók még az extra stabilitáson kívül...

Egyéb tudnivalók

Az új fejlesztői előzeteseket szokás szerint az Opera Labs oldaláról lehet elérni. A keresztségben egységesen az Opera 12.00.1211 nevet kapták, ennek megfelelően - az előbb bemutatott extrákon túl - elvileg minden eddigi Wahoo-s képességgel rendelkeznek, beleértve a hardveres gyorsítást is! Persze hibák is vannak, ezek közül az ismertebbek.

Ismert hibák, megjegyzések:

  • A Mac-es verzió univerzális, egyben tartalmazza a 32 és a 64 bites kódot. OSX 10.6 (Snow Leopard) vagy afölött automatikusan az utóbbi települ. 
  • Néhol hibás a szöveg renderelése, és a Webfontok támogatása (csak Mac)
  • A 64 bites változat értelemszerűen csak 64 bites Windowson fut
  • Használd a legfrissebb Flash-t az esetleges teljesítményproblémák elkerülésére!
  • A beépülő-interakciók (például kattintások) esetlegesen 7 másodpercre lefagyaszthatják a böngészőt
  • Az Xt-alapú beépülők nem támogatottak (például VLC és Acrobat Reader)

Ez egy fejlesztői előzetes, az újdonságok kipróbálására. Semmiképpen ne telepítsd rá a stabil Operádra, vagy az Opera Next-re! Hordozható verzióként való telepítés javasolt.

Letöltés (Opera Labs Build 12.00.1211):

getUserMedia és Opera Reader

A mai napon új Labs release-t kaptunk néhány újdonsággal, amelyek még nem érettek meg, hogy snapshotok legyenek belőlük.

Az egyik a getUserMedia, amely natív támogatást nyújt a felhasználók webkamerájához, a másik pedig az Opera Reader.

Letöltés

Natív lapok

A böngészők között elfogadott lapozási metódus a görgetősáv, amellyel le-fel navigálhatunk egy-egy oldalon. Ez egy egyszerű megoldás a szoftver számára, mivel minden tartalmat hozzáférhetővé tesz és a lapozási folyamatot a felhasználóra bízza. Ez viszont levágott szövegsorokat eredményez és nehézkesen működik egér nélküli eszközökön. És ezen felül nem szép, nincsenek animációk és nem is stílusos.

Az utóbbi időben egyre több lépést láttunk a helyes irányba az eBook olvasók részéről (például Amazon Kindle) a "nezxt page" és "previous page" gombokkal, amely lehetővé teszi a felhasználóknak, hogy a könyvet, sokkal "könyvszerűbben" olvashassák. De a Kindle egy zárt megoldást alkalmaz: nem lenne előnyösebb, ha lenne egy nyílt technológiánk, amely lehetővé tenné, hogy bármilyen tartalmat ezen a módon olvashassunk a weben?

A fejlesztők most betekintést nyújtanak eme fejlesztés alatt lévő megoldásba, amellyel bármely weblapot natív oldalakká alakíthatsz. Ez egy kísérlet egy CSS3 kiterjesztés alkalmazására, amely lapokra "darabolja" a weblapok tartalmát. Figyeli a pozícionált/lebegő elemeket, megpróbálja kitalálni a megfelelő multi-column elrendezést és egy sokkal következetesebb navigációs rendszert nyújt, mint dokumentumfüggetlen tartalom. Az új CSS3 tulajdonságokról, amelyekkel engedélyezhető ez a mód itt olvashatsz bővebben.

Például ahhoz, hogy minden általad látogatott weboldalon kipróbáld ezt a kezdetleges lapozási élményt, egyszerűen be kell illesztened a következő kódot minden lap forráskódjába, illetve csinálj egy globális UserCSS-t.

@media -o-paged {
    html { 
      height: 100%;
      overflow: -o-paged-x;
    }
  }

A működési elv azon alapul, hogy az -o-paged media típus használatakor a <html> elem tartalmát feldarabolja akkora darabokra, amely magasságában belefér az aktuális böngészőablak 100%-ába. Ezek között a lapok között a jobbra-balra nyíllal tudunk navigálni horizontálisan.

Ahogy a könyv forradalmasította az olvasást az 5. században a fejlesztők remélik, hogy az Opera Reader forradalmasítja a weboldalak olvasási metódusát. További, Chris Mills és Hakon Wium Lie által készített demókért látogass el ide.

A getUserMedia-ról bővebben az eredeti cikkben olvashatsz angolul.

Kiadási megjegyzések

  • Az asztali összeállítás a korábbi Opera 12 pre-alpha kiadásokon alapul, tehát a WebGL támogatás és hardvergyorsítás nem működik benne.
  • Két opera:config tulajdonság alapértelmezésben be lett kapcsolva, ezek a: “Scroll is Pan” és a “Smooth Scrolling”. Az első miatt a szövegkijelölés nem működik. Ez a későbbi összeállításokban már javítva lesz.
  • Egy ismert hiba, amikor a lap tartalmaz overflow tulajdonságot a felhasználóknak fókuszba kell helyezni a lapot, hogy képesek legyenek billentyűzettel navigálni.
  • A device API-nak jelenleg nincs felhasználói interfésze. Ez a későbbi összeállításokban lesz.
  • Ez egy Labs build, ami még annyira sem ajánlott mindennapi használatra, mint a snapshotok, tehát az esetleges, szoftver és idegrendszer terén bekövetkezett károkért felelősséget nem vállalnak.

A visszajelzéseket ide kérik.

Ragnarök, avagy az Opera új evolúciója!

Frissítés! Úgy tűnik, akadt némi félreértés ezzel a kiadással kapcsolatban. Ez egy adott funkciót bemutató labs kiadás, ami alapvetően a korábban elérhetővé tett Opera 11.10.2005 előzetes és az új HTML5 értelmező összeépítéséből született. A verziószám 11.50, de ebben az esetben ez nem jelent semmit, csak megkülönböztetésül változtattak a 11.10-hez képest. Szóval a leendő funkcionalitásokat illetően senki ne vonjon le messzemenő következtetéseket...

Ma megjelent az Opera újabb (Labs) verziója egy új Ragnarök kódnevű HTML5 feldolgozó algoritmussal.

Alább a megjelenés alkalmából készült operás bemutatkozó cikk fordítását olvashatjátok, aminek eredetije az Opera Labs oldalán jelent meg.

A legkirályabb HTML5 demó, amit látni fogsz ezen a héten.

A Web tele van canvas demókkal, HTML5 videó lejátszókkal, drag n' drop cuccokkal és társaival. De itt egy demó, amely valószínűleg a legkirályabb, amit ezen a héten látni fogsz. Felkészültél?

<b><i>Yo!</b></i>
Ássunk mélyebbre. A fenti elemek hibásan vannak beágyazva. A legközelebbi elemnek (esetünkben az <i>-nek, kellene az első helyen lenni a bezáró tageknél. Mit csinál a motor a DOM fával ilyen esetekben különböző böngészőknél? Leellenőrizhetjük a Dragonfly-jal és és ennek más böngészőkben lévő megfelelőjével, vagy Ian Hickson DOM viewer-ének használatával. Az Internet Explorer 9 és Safari 5 ebben az innerHTML-ben:
<!DOCTYPE HTML>
<html><HEAD></HEAD><BODY>
<B><I>Yo!</I></B><I></I>
</BODY></html>

miközben az Opera, Firefox és a Chrome ezt produkálja:

<!DOCTYPE HTML>
<html><HEAD></HEAD><BODY>
<B><I>Yo!</I></B>
</BODY></html>
Tovább...