Mint ismeretes, a Google már korábban "beépítette" a Chrome-ba a Flash-t.

A böngésző továbbá rendelkezik egy PDF-olvasóval is, mely alapértelmezés szerint be van kapcsolva. Amikor ráklikkelünk egy PDF fájl linkjére az interneten, akkor az közvetlenül a böngészőablakban nyílik meg. Megtetszett a két ötlet, így megpróbáltam ezeket "átmenteni" az Operába.

A dolog úgy áll, hogy a Flash integrálása másodperceket vett igénybe, ellenben a PDF-olvasó már nagyobb falatnak bizonyult, de természetesen a kitartó keresés meghozta gyümölcsét.

A Flash

Keressük fel ezt a weboldalt, majd töltsük le az alkalmazást. A letöltött program létre fogja hozni a CommonFiles mappát. Ebből a mappából helyezzük át az NPSWF32.dll vagy az NPSWF64.dll nevű állományt - a 32 bites Operánál az elsőt, míg a 64 bitesnél értelemszerűen a másodikat érdemes választani - az Opera Bővítmények mappájába. Utóbbi helyét a címsorba begépelt opera:about parancs fogja elárulni. Az újraindítás után próbáljuk ki a plugin működését.

A PDF olvasó 

Egy ingyenes és nagyon gyors PDF olvasó programot kerestem, mely rendelkezik beépülő modullal. A Sumatra PDF pontosan megfelel ezeknek a kritériumoknak. Töltsük le a PDF-olvasó legfrissebb, telepítős kiadását. Nyissuk meg a fájlt (például) a 7-ZIP tömörítővel, majd másoljuk ki a SumatraPDF.exe, az npPdfViewer.dll és a libmupdf.dll nevű fájlokat. A cél természetesen megint a Bővítmények mappája. Ezzel lényegében végeztünk is, de még néhány észrevételt megosztanék. Ha zavar a sumatrapdfcache mappa, mely az első PDF-állomány megnyitása után jön létre, akkor a következő műveletet ajánlom. Indítsd el a SumatraPDF.exe alkalmazást és a beállítások menüpont alatt a "Korábban megnyitott file-ok listájának tárolása" opció elől vedd ki a pipát.

Zárás

Ha az Opera hordozható változatát telepítjük számítógépünkre, illetőleg elvégezzük a fenti műveleteket, akkor összerakhatunk egy olyan portable böngészőt, ami rendelkezik beépített PDF olvasóval és Flash pluginnal - itt látható egy kép a várható állapotról. Az így elkészült böngészőnket könnyedén magunkkal vihetjük, és olyan helyeken is alkalmazhatjuk, ahol nem állnak rendelkezésre a szóban forgó beépülők, azonban nincs jogosultságunk azok installálására.

Egyszerűsített verzió

Gondoltam azon olvasókra is, akiknek megtetszett a dolog, ám valamelyik ponton végérvényesen elvesztették a fonalat, esetleg egy még könnyebben megvalósítható módszert szeretnének. Számukra jó hír, hogy a fent megnevezett fájlok ide kattintva egyben letölthetőek.

A címben szereplő lehetőségek állnak rendelkezésünkre a következő Dither-féle patch használatával. Ezúttal nem kapunk futtatható állományt, csak egy Perl scriptet, amit legegyszerűbben úgy tudunk futtatni, hogy a XaNoCTA patch azonos nevű (xa-nocta.pl) fájlját lecseréljük a postban szereplőre.

Mikor engedélyezzük a UserJS-ek futását HTTPS kapcsolatokon, az Opera hülyebiztos okokból minden indítást követően, mikor meglátogatjuk az első oldalt HTTPS kapcsolaton keresztül, feldob egy dialógust, amelyben megkérdezi, hogy biztosan akarjuk-e engedélyezni. Ez hosszútávon zavaró lehet. A patch erre is megoldást nyújt.

Hogy miért jó ez nekünk? Mert nem biztos, hogy a számunkra szükséges funkcionalitás elérhető kiegészítő formában, vagy nem akarunk kiegészítőt használni olyasmire, amire egy pár soros UserJS is bőven elég. A HTTPS kapcsolat viszont egyre terjed, már a legnépszerűbb oldalakon, mint Facebook, Twitter, Google is lehetőségünk van ezt a némileg lassabb, de biztonságosabb módot használni. Ennek persze leginkább nyílt hálózatokon, mint WiFi, több gépes hálózatok van lényegi értelme, ahol bárki monitorozhatja a hálózati forgalmat.

A kikapcsolható domain kiemelésnek leginkább a konzervatívabb felhasználók örülhetnek, akik egyrészt maguktól is el tudják dönteni, hogy egy URL-ben melyik rész a domain és kiszűrni az adathalász trükköket, valamint zavarja őket a még skin.ini-vel is megváltoztathatatlan, halványabb szürke szín, amely az URL többi részének a színe.

A XaNoCTA-féle Flash-patch-hez különösebb kommentárt nem fűzök, mert ugyanaz a funkciója, mint a már korábban postolt UserJS-nek, előnye azon túl, hogy tisztább megoldás (értsd: jobb kiiktatni a szükségtelen dolgot, mint automatizálni valamit, amire eleve nincs szükségünk, értve ez alatt a plusz kattintást, amit a UserJS végzett el helyettünk) és, hogy mindenhol működik. A HTTPS korlátok a mostani patch segítségével eltűnnek ugyan, de ha RSS-ben jön le egy post beágyazott videóval, akkor ott ugyanúgy el kell végeznünk a plusz klikkelést. Valamint a UserJS-es megoldás (mint minden userJS) kódot injektál a céloldal(ak)ba, ami főként globális userJS-eknél (amik minden oldalon működnek, nem egy oldalt bővítenek specifikus funkciókkal) előidézhet oldalmegjelenítési és működésbeli problémákat.

Hátránya viszont, hogy minden frissítéskor el kell végezni, mivel az opera.dll hordozza az Opera aktuális verzióját. Ez főként azon felhasználóknál jelent kellemetlenséget, akik mindig az aktuális előzetest használják, de valamit valamiért.

Mivel a most következő műveletsor valószínűleg nem lesz magától értetődő mindenki számára, ezért egy kis bevezetés következik, de ne riasszon senkit el, nem olyan bonyolult, mint amennyire hosszú ez a post. Ettől függetlenül erősen javasolt, hogy csak azok próbálják ki, akik rendelkeznek némi alapismerettel az általuk futtatott operációs rendszert illetően.

A patch úgy működik, hogy lecserél a célfájlban, esetünkben az opera.dll-ben egy sort egy másikra.

Lépések:

1. Töltsük le ezt a fájlt
2. Bontsuk ki egy tetszőleges, user jogosultságú helyre.
3. Töltsük le ezt a patchet
4. A lementett .txt fájlt nevezzük át xa-nocta.pl-re
5. Írjuk vele felül a régi xa-nocta.pl nevű fájlt.
6. Másoljuk át az opera.dll-t abba a mappába, ahol a xa-nocta.pl található
7. Futtassuk a xa-nocta.bat nevű fájlt duplaklikkel.
8. Ha kiírta mindenhol, hogy SUCCESS, akkor sikerült a művelet
9. Az új opera.dll-lel írjuk felül a régit. Ha bármi problémát tapasztalunk az opera.dll_original nevű fájlt visszanevezve opera.dll-re és visszamásolva minden a régi.

A patch 4 különböző módosítást is magába foglal:

• No-Click-To-Activate
• Natív mp3 lejátszás HTML5 alapokon (ehhez az itteni zipben lévő gstreamer könyvtárban lévő fájlok szükségesek, csak az exét nem kell futtatni.)
• URL többi részének kiszürkítésének kikapcsolása
• Ha engedélyezzük a UserJS futtatást HTTPS kapcsolatokon, akkor nem kapunk megerősítő dialógust minden alkalommal, mikor meglátogatunk egy HTTPS oldalt böngésző indítás után.

Ha valamelyik nem kell, akkor töröljük ki azt a részt a két kapcsos zárójellel ({},) együtt.

                        #halfgray addresstext patch by Nibiru
                        {
                                desc =>   'Halfgray address to black Opera 11.x',
                                assert => undef,
                                test =>   qr/\xD9.{4}\x67\xD9\xBC\x24.\x00\x00\x00/,
                                match =>  qr/\xDD(.{4})\x67\xD9\xBC\x24(.)\x00\x00\x00/,
                                replace => '"\xD9$1\x67\xD9\xBC\x24$2\x00\x00\x00"'
                        },

Vagyis a PasteBin-en lévő forrásban a 26-tól 33-ik sorig mindent.

Hosszú idő eltelt már azóta, hogy az Opera a 10.50-ben beépítette a HTML5 video és audio támogatást, akkor még csak Theora és Vorbis alapokon, amely 10.60-ban kiegészült a WebM formátummal. Az mp3-at a mai napig nem támogatja, ahogy a H.264-et sem. Utóbbi oka sokak számára ismert, míg előbbi talán nem egészen. Az mp3 ugyancsak egy jogdíjköteles, fizetős formátum, csak szintén nem a végfelhasználónak kell megfizetni a jogdíj összegét. Habár ma már annyira elterjedt, hogy teljesen egybefonódott a zene fogalmával.

Annyira még a Google sem volt bátor, hogy kivegye, pedig kétségkívül jót tenne az - amúgy technikailag mérföldekkel jobb - Vorbisnak.

Az Opera és a Mozilla bele sem rakta a támogatást, részben anyagi, részben elvi okokból. És itt jön képbe a Gstreamer, az Opera által használt codec könyvtár amely a HTML5 video/audio alapjául szolgál. Ez Linux alatt (mivel ott natív környezetben van és a Linux különben is a végletekig konfigurálható) korlátlanul bővíthető, szinte egy K-Lite tudását bele lehet integrálni, akinek erre van igénye.

Windows alatt viszont egy előre gyártott gstreamer.dll határozza meg, hogy a gstreamer könyvtárban milyen codekeink vannak. Tehát hiába másolunk bele bármit, a gstreamer.dll-t meg kell hozzá patchelni, hogy "lássa" az új codec(ek)et az Opera.

A Linuxosoknak tehát a mostani írás nem újdonság. Dither-nek köszönhetően viszont mostantól Windowsos Operában is lehetőségünk van mp3-at lejátszani natívan (Flash nélkül), mindehhez csak egy apró patch szükséges, ami a gyári gstreamer könyvtárunk képességeit bővíti.

szerkesztés: A post megírása közben Dithernek eltűnt a postja. Nem tudom pontosan milyen okokból. Instabilitást nem tapasztalok, tehát valószínűleg nem minőségi, inkább jogi (=jogi szankciók megelőzése) okok játszottak közre.

A HTML5Test oldalán is kapunk egy bónuszpontot érte.

Instrukciók:

• Töltsük le a fájlt!
• Bontsuk ki a zip állományt az Opera mappájába (Program Files) egy könyvtárban az opera.dll-lel.
• Indítsuk el (Vistán és fölötte jobbklikk->Rendszergazdaként)
• Kattintsunk a patch gombra és várjunk a "Success" feliratra.
• Létrejön egy opera.dll.BAK fájl. Ha bármi probléma lenne, ezzel visszaállíthatjuk a régi állapotot.
• Indítsuk el az Operát és ellenőrizzük a fenti kép mögött található linken, hogy sikerrel jártunk-e.

Opera MP3 codec letöltése

Aki ismer olyan oldalakat ezeken kívül, ahol ki lehet használni és nem kell hozzá Safari, IE9 illetve Chrome maszkolás, (mert a többi nem támogatja), az írja meg kommentben.

A most bemutatott userJS jelenleg még béta állapotban van és csak azért teszem közzé, mert a fejlesztője, Baldric, időhiányban nem tudja folytatni.

De előbb egy kis magyarázat, mire is jó ez az egész. Az RSS-t remélhetőleg mindenki ismeri. Egy nagyon jó idő, sávszélesség és idegrendszer kímélő megoldás, amivel egy központi kliensben, például az Opera beépített RSS olvasójában megkapjuk a híreket, amikre feliratkoztunk egy kattintással.

Sajnos napjainkban nem örvend túl nagy elterjedtségnek, aminek az ismertség hiánya lehet az oka, elvégre egy forradalmi megoldásról van szó.

Éppen emiatt elég kevés helyen alkalmazzák és ahol alkalmazzák ott is általában csak egyszerűen a hírekre, esetleg még a kommentekre (mint itt), de nem használják ki a specifikációban rejlő lehetőségeket.

Erre még rátett egy lapáttal az Internet Explorer, Firefox és Safari részleges implementációja, amivel a könyvjelzők szintjére degradálták le ezt az XML lehetőségeivel bíró szabványt. A Google nem is tartotta fontosnak az implementációt a böngészőjébe.

De mielőtt nagyon eltérnék a tárgytól, lényegében emiatt van szükség olyan megoldásokra, mint a címben szereplő két kiegészítő és mivel ezek egyike sem létezik Operára, ezért van szükség a cikk további részében bemutatott userJS-re, ami sok szempontból még fejlettebb is, mint a fenti két megoldás, habár felhasználóbarátnak nem igazán mondható, de mint említettem, még csak béta.

Működése:

• Element alapon működik. Kijelöljük azokat az elemeket, amiket figyelni akarunk (ahogy a NoAds-ban), majd kattintunk, az oldal újratöltődik és eltárolódik a domainspecifikusan a Local Storage-ban.
• Az lap frissítésekor összehasonlítja az eltárolt tartalmat az aktuális tartalommal, ha változás van, akkor bekeretezi box-shadow használatával azt a DIV-et, amely tartalma megváltozott és hangjelzést ad, valamint, hogy Visual Tabs-szal is kompatibilis legyen, megjelenik két nagy piros felkiáltójel az oldalon, egy absolute a bal felső sarokban és egy fixed pozíciós középen.
• Ha rávisszük a felkiáltójelekre az egeret (és azok eltűnnek) azzal eltároltuk a változást és az aktuális tartalomhoz fog innentől fogva a következő frissítés alkalmával viszonyítani. Amíg ez nem történik meg, minden egyes frissítési periódusban hangjelzést ad és kiteszi a két felkiáltójelet.
• Változáskor automatikusan a legfelső megváltozott elemhez görgeti az oldalt.

Használata:

• Helyezzük el a UserJS-t a userjs mappánkban.
• Csináljunk egy billentyűparancsot, mozdulatparancsot, sajátgombot vagy könyvjelzőt, amelyik nekünk a legszimpatikusabb a következő paranccsal: Go to page, "javascript:forumAlert.on_off(); void 0"
• A fenti paranccsal fogjuk tudni majd aktiválni a kijelölő keretet, amivel utána egérrel kiválasztjuk az oldal figyelni kívánt elemeit.
• Miután kijelöltük a figyelni kívánt területet, két lehetőségünk van. Állítsunk be igény szerinti periodikus frissítést. Ez persze oldalfüggő. Ahol csak hetente van változás, azért felesleges nyitva tartani egy fület. Ha legközelebb meglátogatjuk és van változás, akkor jelezni fog nekünk a script.
• Kombinálhatjuk az Opera Unite Webserver nevű alkalmazásával. Ez pörgősebb oldalaknál hasznos, mert a periodikus újratöltés az oldalt teljes egészében újraellenőrzi, tehát nagyobb a CPU használat, adatforgalom és a szerverre rótt terhelés is. A Unite segítségével pedig egy általunk (némi HTML ismeret birtokában) meghatározott méretű iframe-ben elhelyezhetjük a figyelni kívánt oldalakat. Ez esetben a mellékelt HTML fájlban kell megadni a frissítési gyakoriságot milliszekundumban.
• Ha hibáztunk és rossz elemet jelöltünk ki, vagy már nincs rá szükségünk, akkor az opera:webstorage oldalon tudjuk törölni a domainhez tartozó rekordokat. Ugyanez törlés nélkül is működik, ha a fent említett parancsot újra kiadjuk és kijelölünk valami mást, ami felülírja a korábbit.

Unite:

• Indítsuk el az Opera Unite-ot és a Webserver nevű alkalmazást.
• Tallózzunk be a Webserverben egy tetszőleges könyvtárat, amiben a HTML fájl (nem a userJS!) található. Ha már van betallózott könyvtárunk, akkor értelemszerűen helyezzük el benne a HTML fájlt).
• Nyissuk meg valamilyen szövegszerkesztővel a UserJS-t.
• A második sort módosítsuk erről: forumAlert.domain = ''; erre: forumAlert.domain = 'http://admin.home.NEVED.operaunite.com';
• Nyissuk meg a HTML fájlt és keressük meg a 67. sorban a self.setInterval(refresh,300000);-t
• A 300000 ms-t (ami 5 perc) módosítsuk tetszőleges értékre. Sajnos itt csak globális frissítési értéket tudunk megadni, ami minden itt behívott oldalra érvényes lesz.
• Nyissuk meg Webserveren keresztül a frames.html-t, majd az EDIT linkre kattintva a piros keretbe adjuk meg egymás alá a figyelni kívánt címeket.
• Fontos (1): A figyelni kívánt címeknek ugyannnak kell lennie, amelyen a scripttel kijelöltük a figyelni kívánt elemeket. Vagyis ha a www.example.com-on tároltuk el a figyelendő elemeket és a sima example.com-ot adjuk meg, akkor nem fog jelezni. Éppen emiatt lehetőleg próbáljunk óvakodni a felesleges paraméterektől az URL mezőben.
• Fontos (2): Az URL utolsó karaktere nem lehet # (azaz kettőskereszt). Ha ilyen van, akkor töröljük a végéről. Ha a kettőskereszt után anchor van (például #comments), akkor természetesen maradhat.
• Miután megadtuk a kívánt oldal(aka)t, kattintsunk a SAVE linkre.
• Fontos (3): Olyan oldalakon, ahol regisztációhoz van kötve az általunk figyelni kívánt tartalom, sajnos csak abban az esetben működik, ha figyelni kívánt oldalon az "Minden sütit elfogad" opció van bejelölve.

UserJS telepítése

Ez az írás nem lesz olyan hosszú, mint a korábbiak és részben a 11.10 által bevezetett display:none módosítás kapcsán jött létre.

Akik követték az eseményeket, tudják miről van szó, akik nem, azoknak pár mondatban: Az Opera a kompatibilitás növelése érdekében a 11.10-ben megváltoztatta a működését a CSS display tulajdonság esetében.

Az ajánlás nem tér ki minden részletre, mint például arra, hogy be kell-e tölteni az elrejtett tartalmakat addig, amíg azok meg nem jelennek az oldalon. A többi böngésző fejlesztői úgy gondolták, hogy igen. Ez azt okozta az évek során, hogy sokan kényelemből, sokan JS tudás hiányában olyan esetekben alkalmazták a display:none szabályt, amikor nem kellett volna.

A probléma inkább esztétikai jelentőségű volt, vagyis ilyenkor az Operában, az egyetlen olyan böngészőben, ami nem töltötte be a display:none tulajdonsággal ellátott tartalmakat, elkezdtek villogni, mivel akkor töltötte be, amikor az adott eseményre (például mouseover) megváltozott az elem display tulajdonsága.

A két legszembetűnőbb példája, hogy mikor egy menü fölé vittük az egeret az vagy 1-2 másodperc késéssel jelenítette meg az animációt az első alkalommal, illetve áttűnős diavetítést tartalmazó oldalakon az első alkalommal a képrenderelést (felülről lefelé) láttuk a képváltáshoz társított effektus helyett.

Az előnye viszont a csökkent adatforgalom és ennél fogva csökkent betöltési időn túl az volt, hogy CSS szabályokkal el lehetett rejteni a reklámokat, így bizonyos esetekben sokkal egyszerűbb volt a dolgunk, habár a megbízható tartalomblokkolás továbbra is az urlfilter.ini maradt.

Ezt a lehetőséget kezdetben (8.x verziók körül) még csak UserCSS-vel lehetett kihasználni, utána Lex1 készített egy hibrid megoldást, végül pedig a Local Storage bevezetésével megszületett a NoAds, először userJS, később kiegészítő formájában.

Azóta megjelent a sokkal hatékonyabb URL Filter API is és az arra épülő megoldások, mint az Opera Adblock De sajnos az URL Filter korlátai megmaradtak, vagyis a RegExp hiánya és a element alapú blokkolás hiánya.

Viszont itt jön képbe Dither, aki elkészítette a NoAds Advanced 1.2.1b-t, ami nem pótolja az elveszett display:none-t, de az URL Filter API-nak köszönhetően legalább egy részét visszakapjuk a korábbi lehetőségeinknek.

Változások, a NoAds óta:

• URL Filter API támogatás a hatékonyabb Adblock Filterlista integrációért.
• widgets storage-nak köszönhetően exportálási lehetőség
• Átdolgozott beállítások
• MagicFunction/MagicVariable alapú blokkolás

MagicFunction/MagicVariable példák:

##var GTracking
##var NO_msnads
##function poker_pp
##function print_download_ads
##function trackEvent 
##function trackPageView
##function trackPageViewCustom
##function wmx_counter
##function wmx_track
##function wtslog