Sziasztok, Krystian Kolondra vagyok, a Desktop Team menedzsere.

A legutóbbi postunk óta itt az ideje, hogy további információval szolgáljunk felétek a jövőbeli terveinket illetően.

Tegnap érkezett egy Chromium frissítés az Opera 15 stabil ágához (Windows-ra egy további frissítés érkezik a mai nap folyamán), az Opera 16 hamarosan elérhető lesz a Next csatornán (a csapat nagy része most szünetet tart, mert a havazás Oslo-ban átmenetileg elállt).

Azt mondtuk, hogy jelenleg az Opera Link-re, a továbbfejlesztett fülkezelésre és a témákra összpontosítunk. Mindazonáltal, miután meghallgattuk a visszajelzéseiteket, az első dolog, amit meg kell tennünk, hogy növeljük a natív könyvjelző funkcionalitás fejlesztésének prioritását.

Miért is nem tettük ezt az első helyre? Egy kis betekintés a saját statisztikáinkba, melyet figyelembe vettünk a funkciók fejlesztésekor.

2007 óta véletlenszerűen kiválasztott embereket kérdeztünk meg (azaz a telepítő - a szerk.), hogy szeretne-e névtelen statisztikákat küldeni az Opera használati szokásairól. Manuálisan is lehetett engedélyezni az opera:config#UserPrefs|EnableUsageReport bekapcsolásával. Ennek segítségével a fejlesztők láthatták, mely funkciókat használtak a felhasználók. Bizonyos felhasználók önkéntesen is szolgáltatak számunkra adatokat 2007 óta.

100 000+ felhasználó felhasználási szokásai alapján alapján (khm... mi is van azzal a 300 millióval? - a szerk.) azt láttuk, hogy a felhasználók 90%-a igazából sosem adott hozzá egyetlen könyvjelzőt sem azokhoz, amik az Operával együtt default beállításra kerültek. Amit a legtöbb ember igazából tett:

• A kedvenc oldalaikat folyamatosan nyitva tartották.
• Munkamenet-kezelővel együtt használták a fenti metódust
• Gyorshívót használtak

Azt is láttuk, hogy az emberek elég gyakran használták a Ctrl+D/Cmd+D billentyűparancsot (én itt valahogy ellentmondást érzek - a szerk.) - csak azért, hogy tároljanak dolgokat, hogy visszatérjenek rá később. Az eredmény rengeteg könyvjelző volt a gyökérkönyvtárban, amely eléggé használhatatlanná tette az egészet, ha valaki a menün keresztül szeretett volna hozzájuk férni. (WTF? - a szerk). Ez az oka, amiért megcsináltuk a Stash-t egy vizuális indikátorral és gyorskeresővel, hogy kézreállóbb legyen (a címsorkeresés és a könyvjelző gyorskeresője is kézreálló volt és az inkrementális keresője is jobb volt. Még "oogle"-re is lehetett keresni - a szerk.).

De megértjük, hogy a könyvjelzők teljes eltávolítása nagy változás azok számára, akik aktívan használták ezt a funkciót, szóval csinálunk egy natív könyvjelzőkezelő funkcionalitást.

Nem tudok pontos dátummal szolgálni és nem lesz az Opera 12 klónja, de el akartam mondani, hogy meghallgatjuk a felhasználókat és felismerjük, hogy a könyvjelzők nem léte azok számára, akik használták ezeket megnehezíti a váltást az Operára, akár az Opera 12-ről akarsz átköltözni, akár egy másik böngészőről.

Köszönjük mindegyikőtöknek a visszajelzéseiteket, nagyon szenvedélyes közösség vagytok!

Ma bejelentette Haavard Twitteren, hogy a Google szintén nem rég bejelentett új motorját, a Blinket fogja az Opera is használni.

Kezdjük a legelején. A Google tegnap bejelentette a fejlesztői blogján, hogy kinőtték a WebKitet és a multiprocessz architektúrájuk miatt szükségük van egy új motorra, ezért forkolják a WebKitet. Így motorral megmarad az egyensúly, a webdiverzitás, ahogy Bruce Lawson fogalmazott, aki szintén bejelentette a blogján. És a személyes véleménye, - amit nemhogy az Opera Software, de még a hörcsöge sem befolyásol - alapján is jó döntés és ígéretesnek tartja az új motort. De az is lehet, hogy csak túl sok rumot töltött reggel a kávéjába. A Google ígéretei szerint az új motor minden eddiginél stabilabb, gyorsabb, jobb és bugmentesebb lesz, valamint a globális felmelegedést is csökkenteni fogja. De maradjunk a tényeknél. Amit tudunk, hogy a kód mérete drasztikusan le fog csökkenni (tehát előfordulhat, hogy az új telepítő már nem lesz 30+ mega) és emiatt átláthatóbb lesz.

• 7 build rendszert eltávolítanak
• Több, mint 7000 fájlt törölnek
• 4 és fél millió kódsort törölnek

Az új motor természetesen továbbra is BSD licences nyílt forráskódú marad és továbbra is támogatni fogja a háziszabványokat és a WebKit-es vendor prefixekkel is kompatibilis lesz (amit a kezdetekkor szintén jó ötletnek tartottak, de ma már kiderült, hogy a gyakorlatban horrible mess az egész.. Bővebben a tervekről a projekt oldalán angolul.

Itt az idő, hogy búcsút vegyünk a Presto motortól.

A mai napon az Opera Software bejelentette, hogy az Opera felhasználóinak létszáma elérte a 300 milliót. Ezzel egy időben egy már korábban sejthető lépést is hivatalossá tettek, miszerint az Opera hamarosan Presto-ról Webkitre vált.

Ezzel a lépéssel az Opera lesz az első nagyobb böngésző, amely teljesen lecseréli a böngészőmotort. (Elvileg Az internet-szerte fellelhető spekulációk szerint a Mozilla is tervezi, hogy a Firefox átáll Webkitre).

A Presto egy nagyszerű motor. Kicsi, gyors, rugalmas és szabványkövető, miközben képes kezelni a való-világban létező (sokszor koránt sem szabványkövető) weboldalakat. Ez tette lehetővé, hogy az Operát bármilyen eszközre portolják a fejlesztők. És - ellentétben a userek véleményével és tapasztalataival - a Presto-t a kezdetektől fogva a kompatibilitást szem előtt tartva tervezték. Mindig is az volt a cél, hogy kompatibilis legyen a valós-webbel, miközben a szabványokat szem előtt tartja. Ez pedig nem kis kihívást jelentett, mivel a web egy kaotikus aknamező, ha szabványkövetésről van szó. Ez a véget nem érő munka (mivel a többi böngésző szerencsés módon a piaci részesedésnek köszönhetően jól jelenítette meg az oldalakat) pedig hatalmas erőforrásokat emésztett fel. Erőforrásokat, melyeket bugok javítására, új fícsörök implementálására és innovációkra fordíthattak volna.

Ez a helyes út

Habár első hallásra még Haavard is szkeptikus volt a döntéssel kapcsolatban, de a felmondási nyilatkozat láttán mostanra már teljesen bizonyos benne, hogy ez a helyes döntés. Nem csak, hogy rengeteg, jobb célokra fordítható erőforrást szabadít fel, de a felhasználók is nagyságrendekkel jobb oldalkompatibilitást kapnak.

Ezzel sokkal jobban ráfeküdhetnek a felhasználói élményre.

Hozzájárulás a monokultúrás (egy motor mind felett) webhez?

Igen, a monokultúra rossz, de az Opera soha nem volt abban a pozícióban, hogy ezt az első helyen megakadályozza. Hiába domináns tényező mobilfronton és rendelkezik 300 millió felhasználóval, a webfejlesztők továbbra is Webkitre optimalizálnak.

Ha a Webkitre váltás felgyorsítja az Opera fejlődését és meghatározó hozzájárulói lesznek a projektnek (már beküldték az első patch-et a következő bugra), akkor végre ők is közvetlen hatással lehetnek a web fejlődésére (akárcsak az Apple, Google és újabban Microsoft, aki saját maga gyártja a szabványokat, immáron szabványosított keretek között).

A web versenyben áll zárt megoldásokkal

Lényeges szem előtt tartani, hogy miközben a böngészők versenyben állnak egymással, addig a web szintén versenyben áll a natív alkalmazásokkal. A web talán nem teljesen nyílt, de így is sokkal nyíltabb, mint az "alkalmazások" zárt világa. A Webkitre váltás lehetővé teszi, hogy az Opera növelje az erejét és megerősítse a böngészőt, mint nyílt alkalmazás platformot, amely félig nyílt webet kínál a zárt alkalmazások helyett.

Elengedhetetlen, hogy a web ne csak túléljen, hanem folytassa a növekedést, fejlődést. Nem hagyhatjuk a zárt, szerzői jogvédett megoldásokat nyerni. (Egy Petőfi veszett el ebben a srácban - a szerk.)

A helyes lépés a megfelelő időben

Az Opera Webkitre váltása talán újdonság és meglepő egyesek számára, mások már sejthették, mivel nem ez az első alkalom, hogy a cég új irányt vesz hirtelen.

A Webkit ma már elég kiforrott ahhoz, hogy lehetővé tegye a váltást és az Opera is besegíthet a fejlesztésbe a nyílt forráskódnak köszönhetően, cserébe pedig nem kell folyamatosan csiszolni a böngészőt az állandóan változó webhez. Ez pedig lehetővé teszi, hogy felkészítsék a platformot a jövőbeli növekedésre az erőforrások felszabadulása által, amely eddig visszafogta az Operát és segíthet a webet a helyes irányba terelni.

További információ az ODIN blogról, hogy a Carakan-t is lecserélik V8-ra. Arra is utalnak, hogy a böngésző sokkal több, mint motor, ezért ezt egyfajta "motorháztető alatti" változásnak kell felfogni. (Remélem a fícsörök megmaradására céloznak, nem valami norvég humor arra vonatkozóan, mikor a Porsche-be tesznek Trabant motort - a szerk.) Az váltás első terméke mobil-fronton érkezik (Opera Ice), melyet Barcelonában mutatnak majd be a Mobile World Congress rendezvényen a hónap végén. A desktop változat átalakulása később történik meg.

TL;DR

• Ez nem fogja megváltoztatni a webfejlesztési praktikáidat, amennyiben webfejlesztő vagy: a szabványok alapján kódolj!
• Az Opera kiegészítők nem lesznek elavultak (ez érdekes lesz, de ha ők mondják... - a szerk.)
• Az Opera hozzájárul a Webkit és Chromium projektek fejlesztéséhez
• Továbbra is szabványkövetőek maradnak

Mit jelent ez a webfejlesztők számára?

A rövid válasz az, hogy semmit, továbbra is szabványosan kódolj. De néhány dolgot nem árt figyelembe venni.

• A Chromium és így az Opera jövőbeli verziói a következő beépített codec-ekkel rendelkeznek majd: WebM, Ogg Theora és Ogg Vorbis, de nem támogatják natívan sem az MP3-at, sem a H.264-et (habár ha az oprendszered rendelkezik ezekkel a codec-ekkel, tudod kezelni böngészőből ezeket a médiákat). A megfelelő módon ellenőrizd a támogatást: HTML5 canPlayType. A legegyszerűbb módja, hogy megbizonyosodj minden modern böngészőben, rendelkezik-e az adott codec-kel, hogy kezelje akár a WebM, akár a H.264-es tartalmakat a <source> elements vagy használd a canPlayType -ot, hogy ellenőrizd a támogatást (lásd itt: Bevezetés a HTML5 videó rejtelmeibe további információkért).
• A window.opera értelemszerűen megszűnik az Opera következő verzióiban. Továbbra is ajánlják a fejlesztőknek, hogy NE HASZNÁLJANAK browser-sniffing-et. Helyette vagy feature-detection-t - vagy valami 3rd party megoldást, mint a Modernizr vagy hand-rolling, mert az sokkal jobb.

Mit jelent ez a kiegészítő fejlesztők számára?

A kiegészítők a legsikeresebb Opera "kiegészítők" ezért a legfontosabb az Opera számára is, hogy a már létező kiegészítők működjenek. Egy konvertáló eszközön dolgoznak, ami a létező OEX kiegészítőket a Chromium-alapú Opera által használt változatra konvertálja. Ezen felül dokumentációkat és how-to-kat is biztosítanak majd és a dev.opera.com fórumán is segítenek. Továbbra is elkötelezettek a fejlesztői közösség és a userek iránt, ezért mindent megtesznek, hogy az átmenet olyan simán menjen, amennyire csak lehetséges.

Mi a váltás oka?

A kezdetekkor, 1995-ben ki kellett hozni egy új motort, hogy versenybe szálljanak a Netscape-pel és az Internet Explorerrel, hogy webes szabványokat alkossanak és terjesszenek. Mikor a "HTML5"-nek hívott specifikációt elkezdték implementálni a cél az volt, hogy egyfajta platform (azaz böngésző) független webet alkossanak, avagy minden böngészőben egyformán (jól) jelenjen meg minden oldal.

A WebKit projekt szabványkövető, amely az Opera egyetlen álma volt a kezdetekkor. Ahelyett, hogy feleslegesen duplikálnák a Webkitben már létező szabványokat, az innoviciókra koncentrálhatnak, mellyel jobbá teszik a böngészőt. Olyan innovációk, mint a füles böngészés, gyorshívó vagy az Opera Turbo

18 év tapasztalatával továbbra is aktív részesei lesznek a szabványosítási folyamatnak. Lásd: HTML5, native video and Media Queries egészséges részei a modern webnek.

Ezen felül hozzájárulnak a WebKit és a Chromium projektek fejlesztéséhez. A belső összeállítások, melyet már tesztelt a QA és talán az Elektrans csapat is (Karbonade?), további szabványokat támogat és továbbfejlesztettek néhány fícsört is, ami hiányzott a Presto-hoz képest (például, multi-column layout).

Az elmúlt néhány hétben megegyeztek, leszerződtek a Webkit projekttel, és az azt aktívan fejlesztő szervezetekkel, hogy megvitassák a szándékaikat és hogy mivel tehetnék a WebKitet még jobbá. Azzal, hogy egy patch-et nyújtottak a Webkit számára, nem csak az Operát, de az összes Webkit-et használó böngészőt tették jobbá.

Megjegyzés: A Dragonfly is megy a levesbe.

Majdnem pontosan egy évvel a tavalyi, hagyományteremtőnek szánt sajtótájékoztató-bemutatkozó Opera-nap után ma sikeresen lezajlott a második ilyen összejövetel. A helyszín ezúttal is Oslo volt. Később kicsit részletesebben is bemutatjuk majd az egyes termékeket, mostani cikkünkben csak egy gyors áttektintéstre vállalkozunk, annál is inkább, mert még nincsenek feltöltve a rendezvényen készült videók. Mivel személyesen nem tudtunk jelen lenni, ezért csak más, nálunk szerencsésebb blogírókra tudunk támaszkodni.

Egy hasonló horderejű (Opera mércével mérve) eseménytől azt várja az ember, hogy sok, és jelentős újítást hoz. Szerencsére nem is kellett csalódnunk, hiszen számos bejelentés hangzott el, köztük olyanok, amire már régóta várunk.

Kezdeném azokkal, amit már bármelyik Android tulajdonos akár személyesen is kipróbálhat. Ez pedig nem más, mint a mobilos Operák legfrissebb verziói, az Opera Mini 6.5 és az Opera Mobile 11.5. Ahogy azt már az asztali változatban is megtapasztalhattuk, a 11.5 nem hoz túl sok újítást.

Elsősorban a Presto motort frissítették 2.9.201-re, ami majdnem megegyezik a legutóbbi PC-s előzetessel, de egy fontos elem, a Ragnarök nevű HTML5 feldolgozó kimaradt belőle. Ennek ellenére a népszerű HTML5-ös tesztoldalon 295+9 pontot kap. Ezen felül némi felhasználói felületbeli módosításokat kapott, például itt is megjelent a címsorbeli csillag az oldal gyors könyvjelzőzéséhez. Ezen túl mind a Mobile, mind a Mini kapott egy aloldalt, ahol megnézhetjük, hogy a Turbó funkció mekkora adatforgalmat spórolt már meg nekünk.

Bár a mobilos böngészők egyre népszerűbbek, és a Mobile sosem állt rosszul ezen a téren, az Operások érdeklődésének homlokterébe mégis az Opera 12 alfája került. Nos, örömmel jelenthetem, hogy az előzetes várakozásoknak megfelelően az Opera bejelentette, hogy a 12-es verzió tartalmazni fogja a hardveres gyorsítást, mindezt WebGL támogatással karöltve. Némi üröm az örömben, hogy ezt kipróbálni csak csütörtöktől tudjuk, akkor jelenik meg ugyanis az első publikus változat.

Nem csak ez volt az egyetlen újítás. A The Register jelen lévő újságírója szerint a friss jövevény újraírt JavaScript motort, javított témázhatóságot és még több funkciót kapott - utóbbi mibenlétét nem közölték. Ezen felül megemlékeztek az új olvasó módról, ami leginkább a Safariból lehet ismerős. Ez arra jó, hogy a honlap tartalmát a háttérbe szorítva csak és kizárólag az általunk olvasott cikkre fókuszálhassunk. Állítólag elég impresszív lett a demonstráció, majd meglátjuk, ha megjelennek a videók is.

Egyelőre ennyit a nagy eseményről. Te azt kaptad, amire számítottál? 

A cikk pár napja jelent meg Ruari blogján, de gondoltam beírom ide is, mivel magyar fórumokról is elég sokan linkeltek közvetlenül az előzetesekre.

Észrevették a fejlesztők, hogy túl magas a régebbi előzetesek letöltési aránya. Jóval magasabb, mint a normális érték, ha valaki például össze akarja csak hasonlítani az újabb előzetesekkel.

Mostantól tehát már csak a mindenkori legfrissebb linkek élnek, a korábbi előzetesek postjainál csak egy hibaüzenet jelenik meg, amivel eljuthatunk a Desktop Team főoldalára vagy az archívumba, ha mindenképpen régebbi előzetest keresünk.