Támogatni fogja a kiegészítők használatát az Opera 11

Szervusztok!
Mentségemre csak pár órája foglalkozom az Opera böngészõvel, de nem jövök rá, hogyan lehet új könyvjelzõt hozzáadni a meglevõkhöz.

A Chrome alatti beüzemelésen problémáztál, engem nem érdekel honnan vannak a scriptek, annyit írtam hogy itt másképp mennek a dolgok. A Chrome pedig nem fog neked manifest.json állományt generálni.

Az Ext API-t olyannak írom le amilyen. A tényeket közlöm, a doksi linkje még mindig ott van lentebb, ellenõrizheted. Vannak benne kiforratlan részek, egyáltalán nem tökéletes, de amit állítok az úgy is van.

"Nincs ilyen hogy csak egy userJS, hidd el, írtam már Chrome bõvítményt."

Látom, nem érted. A userscripts.org-ról beszélek. Vannak fent 2005-ös scriptek is, amik még mûködnek és akkor még sehol nem volt a Chrome.

Tehát két eshetõség maradt. Az egyik, hogy a userscripts.org adminjai összefogva a sokszázezer script mellé írtak manifest fájlt, ami ilyenkor települ a Chrome-ba, a másik, hogy ebben az esetben a Chrome generálja le az alapszintû manifest fájlt, ami a userJS header információit tartalmazza.

"Egyetértek azzal hogy ésszel kellene csinálni, de logikus lépés hogy ezzel próbálják megvédeni a tájékozatlan felhasználókat."

Aki egy ilyen mûveletet végrehajt az tájékozatlan?

Egyébként nem szándékoztalak meggyõzni semmirõl, én örülnék a legjobban, ha tényleg olyan lenne ez az Extensions API, amilyennek leírod, az elsõ biztos az lenne, hogy az Illegal URL-es marhaságot kilõném, de sajnos az is belsõ lap. 😞

Félig off: Nem érdekes amúgy, hogy már két napja megjelent a cikk és rajtuk kívül csak egy ember írt a topicba, õ is kérdezett (+ akik válaszoltak neki), sehol egy troll aki jól megmondja a magáét, hogy miért szar az Opera?

Gyanús. Mikor megnyitottam a cikket már ösztönösen néztem a scrollbar méretét. <#nevetes1>

Bár ha belegondolok már az oldalak is elfogytak, amik nem mennek Operával (vagy ha van is, az Chrome-mal vagy talán Firefox-szal vagy IE8-al is szar) és most a végsõ döfés is megvan, tehát már azt sem mondhatják, hogy "Az Operában nincsenek addonok."

Sakk-matt.

Manifest.json állomány nélkül nincs Chrome ext. Nincs ilyen hogy csak egy userJS, hidd el, írtam már Chrome bõvítményt. A CRX a csomagformátum, ugyan azt a cuccot fogja felpakolni mint egy csomag nélküli ext. A különbség csak egy hitelesítõkulcs, ez szolgál pl. a frissítések letöltésére. Ugyanakkor ez is csak egyszeri alkalommal generálódik (amikor létrehozod a csomagot), utána minden statikus marad.

A Google ellenõrzi a bõvítményeket, de nem csak az Extension Gallery-bõl tudod telepíteni õket. Egyetértek azzal hogy ésszel kellene csinálni, de logikus lépés hogy ezzel próbálják megvédeni a tájékozatlan felhasználókat.

Az Opera mindig is más réteget célzott meg, elismerem hogy hozzá képest a Chrome egy fapados böngészõ, ugyanakkor a legtöbb embernek bõven elég a tudása, amit tud azt pedig jól tudja.

Az igénytelen oldalak süti- és munkamenetkezelése tényszerûen rosszul mûködhet, az a vita az általánosításról szólt. Egy-két oldalnál járható út lehet amit mondtál, de a szerveroldali nyelvek alapbeállításban sem ennyire engedékenyek mint ami pl. megjátszható az IWIW-nél.

Ami nekem nem szokott tetszeni az ilyen jellegû vitákban, hogy végeláthatatlan hosszúra nyúlnak. Leírom a véleményem, nem muszáj egyetérteni vele, de ne az legyen a cél hogy valamiképp mindig megcáfoljuk a másikat. Ez rám is igaz lehet, de ha beleolvasnál a lentebb linkelt doksiba, akkor sok fals információtól kímélhetnénk meg ezt az eszmecserét.

"A manifest.json állomány nem generálódik, a bõvítmény készítõje írja."

Bõvítményeknél (CRX) igen, ott ha kicsomagolod a ZIP fájlt, benne is van a manifest, de sima userJS-eknél a Chrome generálja a userJS header információi alapján, mivel csak egy JS fájlt töltesz le.

"Mi lenne ha egy külsõ forrásból származó káros bõvítmény átírná az Extension Gallery oldalt? Mi lenne ha a letöltés linkre egy káros állományt akarna letölteni a böngészõ?"

Mi lenne, ha ésszel töltögetnénk le addonokat és nem adnánk esélyt az ilyesmire? A Google saját addonos oldalán hivatalosan ellenõrzik a forráskódot minden feltöltésnél. Ugyanez minden ilyen oldalon adott, a Unite Appokat is ellenõrzi az Opera, mielõtt engedélyezné õket. Nem véletlenül szokta Rafal is közzétenni a fórumban az UJS Manager újabb verzióját, mivel a hivatalos Unite-os oldalon átfutási ideje van neki.

Elvileg ezt a Mozillánál is megtették, csak ott sajnos voltak kiemelt szerkesztõk, akiknél ez elmaradt, mondván: õk már évek óta megbízhatóak, ilyen volt Giorgio Maone is.

Semmit sem egészséges túlzásba vinni, a biztonságot sem. Van, ami indokolt (pl: UAC), van, ami azonban már a digitális Darwin-díj kategória.

"Ez az utolsó bekezdés nem érdemel választ, bocs, de ez már csak szarrágás a javából."

Tudom, kicsit nehéz eset vagyok, de szeretem, ha valami úgy mûködik, ahogy azt én szeretném. Nem véletlenül használok Operát, ez jár a legkevesebb kompromisszummal.

De itt is van olyan apróság, ami kifejezetten idegesít. Például a korábban említett gyári Flashblock nagyon jó lenne, ha lenne fehérlista, de így nem az, mivel az egyik oldalon vannak olyan oldalak, ahol szeretném engedélyezni, vagy kénytelen vagyok, különben nem enged be. Erre van a Flashblock userJS.

Ez tökéletes lenne, két apró hibától eltekintve. Az egyik, hogy csak a böngészõ részen mûködik, tehát például az RSS-ben lejövõ postokban nem blokkolja a beágyazott Flash-t.

A másik pedig, hogy nem mûködik együtt magával a böngészõvel, értem ez alatt az urlfilter.ini-t, amelyben ha blokkolva van egy Flash banner, akkor ugyanúgy kiteszi a placeholdert 468x200-as méretben, de alatta nincs semmi, mert blokkolva van.

A "gyári" pedig csak oda teszi ki, ahol nincs blokkolva alatta a tartalom.

"Úgysem foglak meggyõzni, nem is akarlak, nem is tudnálak, korábban sem tudtalak semmiben."

Arra gondolsz, mikor azt állítottam, hogy bizony vannak szép számmal olyan igénytelen oldalak, ahol a cookiek lejárati dátumának átírása egyenlõ az örökös loginnal? Sikerült meggyõznöd, mivel én csak a tapasztalataimról beszéltem, vannak, ahol hiába írom át, de vannak, ahol ha átírom, akkor bejelentkezve marad. Vannak olyanok is, ahol a cookie-kban plain/text formában van a jelszó és olyan is, ahol a SSID-et kicserélve egy teljesen más felhasználóval leszel belépve anélkül, hogy tudnád az illetõ jelszavát.

De visszatérve a lényegre, most is sikerült, ha majd látok olyan addont Chrome-hoz és Operához fogok, ha majd megjelenik az alfa, amire nincs már létezõ userJS, illetve nem lenne megoldható vele, akkor meg leszek gyõzve. Addig viszont hadd legyek már kicsit szkeptikus.

"amúgy csak a contentscriptek esnek e limitáció alá, a background file mindig és mindenhol fut"

Jó tudni.

A manifest.json állomány nem generálódik, a bõvítmény készítõje írja. Pont az egységesítést szolgálja, abszolút nem körülményes, a JS-ekben nem kell semmit szerkeszteni. Opera alatt lehet azoknak a JS kommenteknek van valamilyen speciális jelentésük, Chrome alatt viszont nem, minden a manifest.json állományban van.

A Google belsõ lapjainak tiltása teljesen logikus, jobb is ez így. Mi lenne ha egy külsõ forrásból származó káros bõvítmény átírná az Extension Gallery oldalt? Mi lenne ha a letöltés linkre egy káros állományt akarna letölteni a böngészõ?

Ez az utolsó bekezdés nem érdemel választ, bocs, de ez már csak szarrágás a javából. Vannak hiányosság, de ezek a mindent megmagyarázó szélsõséges példálózások már nem érdekelnek. Úgysem foglak meggyõzni, nem is akarlak, nem is tudnálak, korábban sem tudtalak semmiben. Mész a saját fejed után, ez nem is baj, de ne nekem kelljen válaszolgatni a millió egy felvetésedre. Nem minden tökéletes, Operában sem az, idõvel fejlõdni fog.

ui.: amúgy csak a contentscriptek esnek e limitáció alá, a background file mindig és mindenhol fut, szóval ha van jogosultsága kezelni a füleket, akkor gond nélkül mûködni fog. Ez itt a baj, nem ismered, bár erre is biztos tudnál írni valami szépet.

"A manifest.json állományban kell ezeket definiálni."

Megtaláltam. De akkor is körülményesebb két fájlt szerkeszteni (értsd: a JS-eket viszem magammal, mivel az adja a funkciót, nem az utólag generált json).

"A Google belsõ oldalain tiltva vannak a bõvítmények használata, de pl. a GMail-en gond nélkül mennek, plusz az összes többi HTTPS oldalon is."

De akkor is. Ez olyan, mintha Operában a userscripts.org-on, vagy az extendopera.org-on nem mennének a mozdulatparancsok. Ezt is kivágnám, ha így lenne. A mozdulatparancs olyan nálam, mint egy tudatalatti rutin. Rohadt kellemetlen, mikor nem mûködik. Operában tudom, hogy ilyenkor a Flash a hibás, de azokat az oldalakat kerülöm. De Chrome-ban még az új lap oldalát sem tudom vele bezárni.

Amúgy tök jó, hogy például a tabokhoz is hozzáfér, valaki beállít magnak egy egyéni tabbezárási metódust, majd mikor Ctrl+W-vel az új lapot vagy valamelyik belsõ lapot, például a memóriahasználati statisztikát zárja be, akkor teljesen máshova ugrik, mivel ott hatástalan az addon hatása.

Na mégegyszer: http://magyaropera.blog.hu/2010/07/11/google_suggestion

A többit köszönd meg a Google-nak.

"- Google suggestions a keresõbõl"



- Egygombos könyvjelzõzés

A Ctrl+D-vel mi bajod? Egyébként bekapcsolod az egygombos billentyûparancsokat és választasz egy neked szimpatikus gombot.

"- Oldalra scrollozás tapipaddal"

Ismert bug.

"- pluginek, de ez már másodlagos"

Mire gondolsz? Flash, Java, Acrobat, WMP, QuickTime, RealPlayer, DivX Webplayer, minden mûködik Operával is.

Operában ha kirakod a címsor mellé az új könyvjelzõ gombot, akkor az is egygombos lesz.

Hát az URL sorban van egy csillag, amire ha rákattintasz, berakja a könyvjelzõk közé az oldalt.

Mi az az egygombos könyvjelzõzés?

nem tudom erre gondoltál? :

jupiii Opera überalles<#worship>
Bár engem az idegesít néha, hogy van amikor szerinte fut az opera de közben nem, de a gép úgy látja 😊 Bár ez lehet a 64 bitnek tudható be

Persze hogy nem mûködik a reload, mert nem jól csináltad. A manifest.json állományban kell ezeket definiálni.

A Google belsõ oldalain tiltva vannak a bõvítmények használata, de pl. a GMail-en gond nélkül mennek, plusz az összes többi HTTPS oldalon is.

ui.: ha már megnézted a bõvítmények doksiját (link fentebb), akkor kicsit turkálhatnád, lehet átjönne hogy milyen dolgokhoz nem fér hozzá a natív JS.

Én Operát használok netbookon, mert keveset fogyaszt, de rettentõen hiányzik pár dolog a Foxból:
- Google suggestions a keresõbõl
- Egygombos könyvjelzõzés
- Oldalra scrollozás tapipaddal
- pluginek, de ez már másodlagos

Felhasználói szemmel nézve (nem (csak) 1.0-s userekrõl beszélek) viszont annál inkább hatékony. Legalábbis megkönnyíti a napi teendõket és egy csomó dolgot lehet vele automatizálni.

Minden nagyobb cég mögé állt, szóval ez a jövõ, akár tetszik, akár nem.

17 programozáso/script nyelvet ismerek, ebbõl 6-ot használok napi szinten a munkámhoz. Egy dolgot megtanultam az utóbbi 15 év során, amit fejlesztéssel töltöttem. Qvára nincs idõm minden alkalommal lefejleszteni ugyanazt! Ez a userJS nagyon jó, de nevetséges dolog plug-in rendszernek, uram bocsá', API-nak titulálni!
Egy API-val szemben támasztott igények nem csak abban nyilvánulnak meg, hogy legyen gyors és lehessen benne megoldani ezt és ezt! Akinek ennyi elég, az nem látja a fától az erdõt.

"- Igen, de miért nekem kellene megtenni?"

Mert az addon fejlesztõje sem fog 1000 különféle verziót létrehozni, hogy mindenkinek a saját egyéni preferenciája alapján legyen beállítva. A konfigurációt neked kell megtenni.

Elhiszem, hogy egy kezdõnek barátságosabb egy legördülõmenükkel dúsított GUI, de neked és nekem szerintem teljesen mindegy, hogy egy .ini fájlban írsz át egy 0-t 1-re, vagy ugyanezt egy GUI-n teszed meg. Mindkettõ ugyanannyi kattintás.

INI-nél: Átváltasz TC-ben a megfelelõ fülre, duplaklikkel megnyitod, ha hosszú a fájl nyomsz egy Ctrl+F-et, beírsz pár karaktert, Enter, átírod, Ctrl+S majd a böngészõben F5

GUI-nál: Ha van rá billentyûparancs, akkor megnyitod a konfigurációs globális felületet (ha nincs, akkor menübõl nyitod), megnyitod a kívánt extension konfigurációs beállításait, görgetsz egérrel a megfelelõ checkboxig, esetleg itt is használsz Ctrl+F-et, legördíted a menüt, ahol kiválasztasz egy másik opciót, majd legörgetsz a Save gombig és ha szerencséd van nem kell F5, de általában itt is kell.

"- Reload gomb"

Na ez az, ami nem mûködött. Hozzáteszem, utoljára valamikor a 4-es verzió környékén próbáltam, de most megnéztem a legújabb 8-as Chromiumban a kedvedért és ugyanaz.

Bizonyíték:



Amint látható a 4 YouTube-os include linkbõl töröltem 3-at, az utolsót pedig átírtam exclude-ra, majd újratöltöttem Chrome-ban az oldalt. Alul jól látható, hogy betöltõdött a script.

"HTTPS is megy már, az incognitot külön kell engedélyezni, a belsõ lapok tényleg hiányoznak viszont, de ez nem olyan nagy érvágás."

Hol? Zárd már be mozdulatparanccsal a https://chrome.google.com/extensions?hl=en-US oldal valamelyik aloldalát Chrome-ban. Az, hogy 1-2 Google szolgáltatásban megy az dícséretes, de szarra sem jó.

A belsõ lapoknál szintén illene 1-2-nek mûködnie, például a Mouse Gestures-nek, vagy ha lenne egyéni billentyûparancsok létrehozására szolgáló addon, akkor annak, meg ilyesmi.

Még azt a tetves letöltési sávot sem lehet kiiktatni, vagy ha már ott éktelenkedik, pazarolva a vertikális helyet lenne egy "Delete from system" opció, de nemhogy az nincs, de még csak saját cache sem olyanoknak, mint torrentfájlok, vagy böngészõbõl megnyitott Office dokumentumok és társai. Nem, nem kell PDF olvasó vagy Office nézegetõ, ha én célszoftverben akarom megnyitni, akkor akarok rá lehetõséget.

1: A kibõvített szolgáltatásokkal és a hozzáféréssel még várjunk, amíg megjelenik az elsõ alfa, de a többivel egyetértek.

2: Ezzel szintén egyetértek, habár féltem a userJS-eket, amik emiatt háttérbe fognak szorulni és olyasmire is addont fognak írni, ami nemhogy userJS-sel, de még beépített funkcióval is megoldható.

Jó példa az On Demand Plugin, amit rosszul terveztek meg, mivel nem lehet kikapcsolni oldalspecifikusan.

Használhatok rá userJS-t, az meg nem mûködik az RSS feedekbe beágyazott videóknál. Ezen pedig félek, hogy az addon sem fog változtatni, mert az sem fog hozzáférni.

Ha igen, akkor visszaszívom, de jelenleg, publikus alfa híján kénytelen vagyok az eddigi tapasztalataim és a fejlesztõi blogokban elejtett morzsák alapján képet alkotni.

Végül: postMessage helyett Web Sockets?

Egyébként semmi értelme az ilyen sok-sok kiragadott részletkérdésnek, szerintem le is állok ezek megválaszolásával. Pár fontos dolog kell az egész bõvítményes sztorihoz:

1: egységesített fejlesztõi környezet, kibõvített szolgáltatások, lehetõségek, interakció a böngészõ szolgáltatásaival és adataihoz való hozzáférésével.

2: frontend a felhasználók felé, könnyû kezelhetõség, egységes és rendszerezett felületeket

A mostani userJS jó móka, sok mindent meglehet velük oldani, de sok dolog biztonsági kérdést vet fel, illetve túl korlátozott lehetõségek közé szorítanak. Elõzõbõl amúgy kimaradt hogy a postMessage-nek kétirányúnak kell lennie, szóval nem igazán alternatíva az ajaxhoz képest.

- A böngészõ beállításai, funkcióihoz való hozzáférés, személyes adatok lekérdezése, stb.
- Igaz, mindig is voltak rá trükkök, újabban már eszközök is, de ettõl még kell az egységesítés.
- JS által szabályzott contextmenu. Bizonyos eseményre megjelennek plusz opciók, bizonyos esemény hatására meg eltûnnek.
- Azért problémás mert az Operában nincs egy elkülönített steril környezet minden egyes bõvítménynek külön-külön, plusz talán (erõsen FIXME) hozzáférhetnek az megtekintett lap sütijeihez pl.
- LocalStorage és a sütik kb. egy kategória, mindkettõ olvasható, mindkettõ titkosítható. LS-nak nagyobb tárhelyet enged a böngészõ és könnyebb vele dolgozni, ezért jobb.
- Összeakadhat, ha a fejlesztõ jQuery-t akar használni, de pl. a lapon is be van húzva egy másik verzió. Komoly bõvítményt megírni natív JS-sel halál, kell a jQuery, így viszont problémás. Itt jöhet képbe megint a "mindent nekem kell megoldani és ellenõrizni" probléma.
- Személyes adatnál ez csak paranoia. Ha le akarom kérdezni hogy az sg.hu oldalból hány fül van megnyitva - mert mindegyikben frissíteni akarok valamit - akkor az ne legyen már tiltott gyümölcs.
- Az AddEventListener-rel semmire sem mész, ha az a cél hogy a böngészõ szabályzása szerint töltõdjön be egy-egy script. Jelenleg az összes betöltõdik, aztán ellenõrizheted hogy jó helyen jársz-e. Bár ez is FIXME kateógória, de összességében sokkal többrõl van itt szó, az Opera userJS kezelése meg jelen formájában primitív. Rugalmas és minden egyéb jelzõ igaz rá, de nincsenek igazán szabályozva.
- jQuery ismét egy jó példa lehet ennél a pontnál.
- Ez csak egy DOM-manipulációs minimál GUI. Nincs a böngészõben normális, egységesített beállítópanel minden bõvítménynek külön-külön. Ez az egész errõl szól, nagyon sok pontnál elmondhatnám ezt. Mondjuk ez itt most pont részletkérdés, de úgy általában fragmentált ez az egész userJS történet.
- Igen, de miért nekem kellene megtenni?
- Reload gomb
- HTTPS is megy már, az incognitot külön kell engedélyezni, a belsõ lapok tényleg hiányoznak viszont, de ez nem olyan nagy érvágás.

Attól függ mit értünk böngészõ alatt. A böngészõ "részhez" eddig is hozzáférése volt például a Unite appoknak olyan szinten, hogy tudtak küldeni beúszó értesítést, ilyesmi.

A mostani extensions API pedig attól tartok, hogy nem fog kiterjedni sem az M2-re, sem a beépített IRC kliensre, tehát ott tartunk majd, ahol eddig.

"Nincs cross-origin XHR-re lehetõség, globális beállítás van, de az nem túlságosan kívánatos."

De használhatsz helyette postMessage-t.

"Nincs lehetõség dinamikus contextmenükre sem."

Mit értesz dinamikus alatt? Minden ha linkre kattintasz mást kapsz, mintha kijelölt szövegre, vagy magára az oldalra. El nem tûnnek a kiszürkült elemek, de ki vannak szürkülve, amiket nem tudsz használni, ez sajátmenünél is adott. A kép context menüje például tartalmazza a kép nevét és kiterjesztését.

Ráadásul az alap változókat is használhatod, mint %s %l %u, stb.

Amúgy a menük, eszköztárak és billentyûparancsok telepítése eddig is egy kattintás volt, ha htaccess-ben úgy volt megadva, hogy települjön, ne pedig szöveges fájlként nyíljon.

"Továbbá problémásak a beállításokkal és egyéb adatmentéssel kapcsolatos dolgok"

Ezzel egyetértek, de a Chrome-os addonok is ezekben tárolják az adatokat, mivel a fájlrendszerbe nem tudnak írni.

A süti talán a legstabilabb, egyrészt kiforrottabb (az LS bizonyos snapshotoknál van, hogy felejt), másrészt olvashatóak az adatok ember számára is, nem kódolt formában tárolódnak.

De például nézd meg a NoAds.js-t.http://magyaropera.blog.hu/2010/10/13/adblock_plus_operaban_masodik_felvonas

Megoldható lett volna technikailag egy Export/Import gomb, nem?

A más bõvítményekkel való kommunikáció mindenhol hadilábon áll. Általában amik ütik egymást azok ütik egymást. A JS mivel általában egy bizonyos feladatra van írva, nem telepakolva mindenféle funkcióval, így nem akad össze egymással.

"nem férsz hozzá semmilyen személyes adathoz, stb."

Ezt én inkább elõnynek fognám fel, mivel sajnos nincs sem idõm, se kedvem minden frissítésnél forráskódot proofreadelni, hátha egy újabb Giorgio Maonéval van dolgom...

"Nem tudod szabályozni hogy melyik userJS hogyan és mikor fusson le."

Ez téves. Ott az AddEventListener, amivel tudod. A GM scripteket nem tudod.

"Nem tudod szabályozni hogy ezek a scriptek ne írják felül egymást vagy az oldal adatait."

Bõvebben? Nálam 26 van és egyik sem akad a másikkal, mivel ahogy fentebb is említettem, 1-1 funkciót látnak el, nem arra törekednek, hogy minden szart belesûrítsenek, csak éppen azt ne tudja, amit kéne.

Két példa:

Firefox-os popup selection context menü (nem tudom hogy hívják).
Van 8 tab, 2-3 altab, 50+ checkbox meg minden konfigurációs lehetõség, mégis lehetetlen arra az egyszerû mûveletre rávenni, hogy csak az oldalon kijelölt szöveg esetén ugorjon fel duplaklikkre, szövegdobozban ne ugorjon fel.

Tab Previews: Fejlettebb konfigurációs lehetõségekkel rendelkezik, mint az Operás megfelelõje, mégis lehetetlen arra rávenni, hogy amíg a fülsávon van az egér és ott húzom a kurzort, addig ne alkalmazódjon újra és újra minden egyes tabnál a beállított timeout, mivel ha 50 tabnál 50*500ms-t végig kell várnom az zavaró.

"Problémás egyáltalán bármilyen beállítópanelt írni ezekhez."

Ezt láttad-e már? http://userscripts.org/scripts/show/33042

"Operában nem gond ha bele kell túrni a forráskódba, de Chrome-nál már igen?"

1: Egy INI fájlt egy nagymama is képes szerkeszteni, csak akarni kell, egy JavaScript már kicsit húzósabb.

2: Mikor Chromeban userJS-hez (ami szintén addonként települ) hozzáadtam a headerhez @exclude-ba 1-2 URL-t, egyáltalán nem mûködött tovább az userJS.

Amikor ugyanazt a JS-t feltöltöttem tárhelyre onnan eleve telepíteni sem tudtam, amíg meg nem adtam htaccess-ben, aztán utána legenerálta újra a manifest fájlt és mûködött.

Elhiszem, hogy biztonsági okokból ellenõrzõ hash-t tárol, de azért ennyire ne essünk már túlzásokba a biztonság terén...

"mibõl gondolod hogy nem építenek bele ilyen szolgáltatásokat?"

Mert egyrészt a Chrome sem enged és azzal példálóztak, másrészt a Core blogban is megjegyezték, hogy habár ezek a cuccok nem adnak annyi szabadságot, mint a Firefoxos addonok, de szabványos webes nyelveket használnak és kevésbé erõforrásigényesek.

Ebbõl nekem az jött le, hogy ugyanolyan korlátozott lesz, mint Chrome-ban, nuku HTTPS, nuku belsõ lapok, nuku böngészõ többi része (M2, IRC, stb.)

De ne legyen igazam.

Szabályzás, egységesítés, és a böngészõvel való interakció nélkül sosem lesz érdemben használható ez a userJS dolog. Nincs cross-origin XHR-re lehetõség, globális beállítás van, de az nem túlságosan kívánatos. Nincs lehetõség dinamikus contextmenükre sem. Továbbá problémásak a beállításokkal és egyéb adatmentéssel kapcsolatos dolgok, mint pl sütik, localStorage, localSQL használata egy teljesen elkülönített, "steril" környezetben. Nem férhetsz hozzá és nem tudsz kommunikálni a böngészõvel vagy más bõvítményekkel. Nem tudsz bizonyos állapotokat, beállításokat, eseményeket kezelni, nem férsz hozzá semmilyen személyes adathoz, stb. Nem tudod szabályozni hogy melyik userJS hogyan és mikor fusson le. Nem tudod szabályozni hogy ezek a scriptek ne írják felül egymást vagy az oldal adatait. Problémás egyáltalán bármilyen beállítópanelt írni ezekhez. És bár van lehetõséged testreszabni a felületüket, ne nekem kelljen már egy komplexebb (ami nem is létezik) userJS-nél még az .ini-ket is szerkeszteni.

---

1-2: Na de Chromehoz nem is ilyen egyszerû bõvítmények születnek mint az Operás Linkification. Mindegyik sokkal komplexebb összetételû, rendelkeznek beállítópanellel, adatokat tárolnak, meg úgy alapjaiban más a Chrome mûködése. Minden bõvítmény külön szálként kezel, ami kicsit több memóriát eszik, viszont sokkal stabilabb a mûködése. Manapság meg plusz 10-15 MB memória (akár többszörösen is) már nem szempont.

3: Azért ez vicces. Operában nem gond ha bele kell túrni a forráskódba, de Chrome-nál már igen?

"next-next-finish": Még mindig nem érted a lényeget. Itt nem a kényelem a szempont és nem a kényelem viszi el az erõforrást. Azért kell egy extension API (és API, nem GUI amit te mondasz), mert enélkül meg lennél lõve, semmilyen hozzáférésed nem lenne a böngészõhöz. Pont az Operánál lenne ez a legszerencsésebb, annyi jól mûködõ alapszolgáltatással rendelkezik, hogy egyfajta fejlesztõi mennyország lenne az ezekhez való hozzáférés.

Fájlrendszer írása: mibõl gondolod hogy nem építenek bele ilyen szolgáltatásokat? Azért mert az egész webes nyelvekbõl áll össze még nem jelenti hogy nem bõvíthetnék ki azok tudását. A Chrome bõvítmények sem kizárólag natív JS-bõl állnak.

Erre az utolsó bekezdésre nem tudok mit mondani, egyelõre ilyen. A Chrome sem éppen világmegváltó bõvítményekkel indult, azóta azért már vannak kreatív megvalósítások is. Bár megjegyzem, a Chrome extension API-ban is látok egy csomó idióta megoldást, szerencsére igen gyorsan fejlesztik és egyre inkább okosodik, kényelmesedik.

Mutass nekem egy olyan Chrome addont, amit nem lehetne UserJS-sel és esetleg UserJS+UserCSS+sajátgomb+sajátmenü+billentyûparancs+mozdulatparancs kombinációjával megoldani.

Akkor elhiszem, hogy az említett Extensions API többet ad. Anélkül viszont továbbra is a szememnek hiszek, vagyis a Firefoxot lehet bõvíteni, a Chrome pedig megreked a faccsé gomb szintjén.

Mondhatod, hogy egyszerûbb például Chrome-ban megírni egy változó tartalmú gombot a címsor mellé, mint Operában mindezt 40 ikonnal a skin.ini-ben definiálni, majd egy sajátgomb+JS parancs kombóval behívni (hasonlóan a kis bizbaszhoz, ami jelzi nekem, ha egy könyvjelzõ már el van mentve), de amit én látok, hogy

1: Az Opera memóriaigénye nem nõ szignifikánsan a UserJS-ektõl.
2: Chromeban pedig minden egyes addon 2-15 megáig zabál, komplexitástól függõen.
3: Nem is lehet eltüntetni a gombot, ha a fejlesztõ ezt nem oldotta meg egy külön opcióval, míg Operában eldönthetem, hogy a javascript:xyjs_bekapcs és a javascript:xyjs_kikapcs kódot én billentyûparancsként, mozdulatparancsként, sajátgombként, esetleg az általam kiválasztott menü általam definiált almenüjébõl akarom indítani és ne foglaljon nekem egyetlen gombbal sem több helyet a címsorban, mint amennyit én szeretnék.

Egyébként nem vagy lustának titulálva, ha neked megéri a többleterõforrást a next-next-finish, akkor használd.

Viszont ha megnézed például a My Operás kommenteket, egyetlen értelmes ötlet nem hangzott el, csak azokat ismételgették, amik nem elég, hogy évek óta vannak Operához, de még a legnépszerûbbek is, mint AdBlock+, NoScript, stb.

Mivel a fájlrendszerbe nem tud írni, így még a DownThemAll klón is kilõve.
FireFTP klón dettó.

Ami a legfájóbb, hogy a fejlesztõi videóban is miket mutattak? Na miket? StumbleUpon és Reddit megosztó gombokat. Könyörgöm, ez még IE6-os bookmarklettel is megoldható volt. Ennél azért többre számítottam. Legalább egy UJS Manager szintû belépõ appot dobtak volna össze, úgysem a Core csapat dolgozik ezeken, hanem a Widget és Unite fejlesztõk.

Lehet volt már dolgot userJS-sel, de látszik hogy egy normális bõvítményt még nem írtál. Extension API nélkül lehetetlen kreatív és fejlett bõvítmények készítése. Szóval ez a Gizikés hasonlat nem túl szimpi nekem. Egyrészt azért mert semmi köze a dologhoz, másrészt meg ne én legyek már lustának titulálva ha várnék egy kényelmesebb megoldást és a vállalat is ezirányba akar továbbhaladni.

Deakkorhamár: hw vega kellene a legjobban, így a JS sem lenne annyira lemaradva.

"ugyanakkor volt egy komoly hiányossága: nem tette lehetõvé a kiegészítõk alkalmazását."

Néhány kiegészítés:

1: Mióta bõvíthetõ userJS-sel és userCSS-vel (8.0), és sajátgombok, illetve az egész menü testreszabható .ini fájlokból áll, azóta ezekkel egész szépen bõvíthetõ volt.

2: Olyan, mint a Firefoxban, most sem lesz, olyan lesz, mint a Chrome-ban, vagy FF4-ben a Jetpack.

Tehát nem pótolták, csak a nagyközönség kedvéért adnak a már eddig is létezõ szolgáltatásokhoz egy next-next-finish API-t.

A widgetek különálló appok és eredetileg is annak készültek és sokkal inkább a mobil és egyéb hordozható eszközök volt a célterület.

A Unite már inkább mondható addonnak, de az sem tud úgy belenyúlni a böngészõ kódjába, mint Firefox esetében az addonok.

Tehát ezekkel továbbra is csak azt lehet majd megoldani, mint amit eddig userJS-sel (már ha valaki írt hozzá), a különbség, hogy ezt már Gizike is fogja tudni telepíteni, mert 2 kattintás lesz és nem kell még mappát sem létrehozni hozzá az elsõ alkalommal.

"nem annyira erõforrás-igényes, mint a Mozilla megoldása""

És nem annyira biztonsági résekkel dúsított és nem is áll fenn a lehetõség, hogy összefossa magát a böngészõ tõle, mivel az addonok többségét hobbifejlesztõk fejlesztik, már ha fejlesztik.

"nem véletlen, hogy ezekkel a funkciókkal bõvül az Opera 11, ezeket kérték ugyanis a leggyakrabban a felhasználók."

Biztos az én szememmel van a baj, de ezekben a topicokban maximum a hozzászólások száma volt a legtöbb, amibõl 20% volt pozitív, a többiek egyöntetûen elutasították.

A 64 bites verziót valóban többen kérték, vagy hogy azt a tetves plugin-wrapper-t portolják már a Windowsos verzióba is, ami Linuxon évek óta létezik.

Lassítani meg maximum a beépített funkciókhoz képest fognak. Elvégre "sajnos" a C++-ban írt kód még mindig gyorsabban fut le, mint ugyanaz JavaScriptben.