26
-
gyűjtő #26 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.
-
#25
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. -
#24
"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.
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. -
#23
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. -
#22
"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. -
#21
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. -
#20
"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. -
#19
Na mégegyszer: http://magyaropera.blog.hu/2010/07/11/google_suggestion
A többit köszönd meg a Google-nak. -
#18
"- Google suggestions a keresőből"
[url=http://magyaropera.blog.hu/2010/07/11/google_suggestion][/url]
- 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. -
WoodrowWilson #17 Operában ha kirakod a címsor mellé az új könyvjelző gombot, akkor az is egygombos lesz. -
Ferrer #16 Hát az URL sorban van egy csillag, amire ha rákattintasz, berakja a könyvjelzők közé az oldalt. -
WoodrowWilson #15 Mi az az egygombos könyvjelzőzés? -
tricky #14 nem tudom erre gondoltál? :
![]()
-
Rotyoka #13 jupiii Opera überalles 
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 -
#12
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. -
Ferrer #11 É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
-
#10
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. -
messen #9 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. -
#8
"- 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? -
#7
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. -
#6
- 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. -
#5
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. -
#4
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. -
#3
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. -
#2
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. -
#1
"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.
