2. Fórumok
  3. OS, alkalmazások
  4. Opera böngésző
  5. (kiemelt téma)

Új hozzászólás Aktív témák

  • #20117 Sk8erPeter nagyúr Penge_4 #20109
    Új Válasz #20117
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Sk8erPeter

    nagyúr

    válasz Penge_4 #20109 üzenetére

    "Miért azt jelzi, hogy a harmadik content script nulladik match-jával van gebasz, amikor a hiba (egész pontosan a csillag után nem tettem pontot) az ötödik content scriptben volt?"
    0-tól indexelődik (ahogy általában a numerikus kulccsal ellátott tömbök; itt a content_scripts objektumok tömbje), így ez elvileg azt jelenti, hogy sorban a negyedik elemben (0-1-2-3) kellett volna, hogy legyen a hiba. Hogy nem pontosan ott volt, azt így kód híján nem tudjuk megmondani.

    Vannak egyébként online JSON-validáló eszközök.

    "értelmetlen karaktersorozat nevű kiegészítők"
    Miért értelmetlen karaktersorozat a nevük? :D Melyek ezek? Saját, vagy letöltött? Ha saját, akkor miért nem adsz tisztességes nevet nekik? :DDD

    "egyszer csesződik el valami a JSON-ban, és onnantól a kiegészítők megszűntek létezni"
    A kiegészítők léteznek, csak legfeljebb nem tudnak betöltődni, mert már a manifest.json-validáció során elbuknak. Javítani kell a hibát, és máris megszűnik ez a probléma.

    "A kiegészítő könyvtárai eltűnnek"
    Azt hogy, mitől? Hova tűnnek el? Egy fekete lyuk beszippantja? Csak mert ilyet még nem tapasztaltam a JSON-fájl elcseszése során. Csak az extensionök oldalánál hasonló hibaüzenetet kiírt, mint nálad, javítottam, újratöltöttem, és már volt kiegészítő.

    "Meg most komolyan, minden kiegészítőt egyenként backupolgassak? Natív funkció kéne ezekre, mert ez így katasztrófa. Instabil és veszélyes, ilyesmiben nemhogy Notes, Bookmarks, UserJS és társait nem szabad tárolni, de még napi ToDo-t sem bíznék rájuk. Korrumpálódik az adatbázis, törlődik az értelmetlen karaktersorozatú könyvtár, aztán elfelejtem megetetni a hörcsögöt és az kimúlik. :D"
    Most itt nem értettem, végül is konkrétan mivel is van a gond? Mert eddig a JSON-formátumot szidtad (bár jogtalanul :D), meg a Chrome Extension API-t, aztán a Tampermonkey-t, aztán még ki tudja mit, most meg már elvesztettem a fonalat, hogy mi is lett más például ebben, mint a régi Opera esetén. A régi Operánál is nyugodtan elcsesződhettek kiegészítők. Az pedig a kiegészítő felelőssége, hogy biztosít-e mondjuk adatexportálási lehetőséget.
    Milyen natív funkcióra gondolsz? A tárolásról beszélünk, vagy miről? localStorage, sessionStorage és társai?
    Vagy a kiegészítő-fájlrendszer teljes mentésére szeretnél natív eszközt? (Ezt mondjuk megteheted külső programmal.)

    "run_at": [ "document_start" ],
    Ez így NEM jó, lásd dokumentáció:
    https://developer.chrome.com/extensions/content_scripts.html#run_at
    string típust vár, tehát csak simán:
    "run_at": "document_start",
    Pontosan ezért dobta tehát teljes joggal az "invalid value"-t, mert valóban érvénytelen értéket (stringet tartalmazó egyelemű tömböt (lásd szögletes zárójelek)) adtál meg.

    "WebDev Tools-ban nem lehet szerkeszteni a cookie-kat, csak megnézni meg asszem törölni. Szóval végképp el van lehetetlenítve a cookie szerkesztés, tényleg külön kiegészítő kell még erre is. Még a DevTools sem tudja."
    Valóban csak megtekinteni és törölni lehet a Resources fülön, a Cookies-nál. JavaScripttel tudnád módosítgatni őket a Console fülön (pl. [link]). Speciel ez nekem megint nem egy nagy érvágás, mert nem igazán hiányzott. Bár valóban bővíthetnék ezzel a funkcionalitással, túl nagy programozói tudást nem igényelne.
    A "külön kiegészítő kell még erre is" speciel a fejlesztői panel esetében picit túlzás, mivel amit eddig hiányoltál, és ami egyáltalán nem volt meg (vagy más formában), az a screenshot-készítő és color picker natívan. Ez tény, ettől még maga a fejlesztői panel speciel igen jó. :)

    "De nem is 4 különböző érték lesz ott, csak 1."
    Hogy mi van?? Most szándékosan szívatsz, ugye?! :DDD
    Itt részletesen kifejtettem, hogy rohadtul nem 4 érték lesz, csak ezt az 1 értéket ki lehet bontani a befelé mutató nyílra kattintva értelemszerűen a paddingnél, hogy szépen lásd, hogy mit is jelent egész pontosan az a sor, hogy
    padding:4px 3px 2px 1px;
    De akkor a kedvedért leírom, mit is jelent ez külön-külön, és még egyszer belinkelem neked a képet, hogy jól lásd:

    padding-top:4px;
    padding-right:3px;
    padding-bottom:2px;
    padding-left:1px;

    Ezt jelenti tehát a fentebbi padding:4px 3px 2px 1px; sor, a kettő teljes mértékben ekvivalens, DE CSAK EGY HELYEN KELL SZERKESZTENI, NEM 4 HELYEN... capisce?
    Az, hogy ki tudod bontani erre a 4 értékre, OPCIONÁLIS. CSAK AZ ÁTTEKINTHETŐSÉGET SEGÍTI. A Te érdekedben. Nem kib@szásként. NEM MUSZÁJ KIBONTANOD, ÉS AKKOR NEM LESZ BELŐLE 4 ÉRTÉK 1 HELYETT. Kezd derengeni már, hogy ez csak a kényelmet szolgálja, de NEM egy fikáznivaló dolog? Szólj, ha még mindig nem esett le, hogy NEM "4 különböző érték lesz ott", hanem csak 1, mert akkor elmagyarázom még tízféleképpen. De azért reménykedem, hogy szép lassan átmegy az üzenet.

    "Az, amit szerkesztesz akár globálisan, akár lokálisan."
    Milyen globális-lokálisról is beszélsz? A fentebb is látható képen az adott elemre vonatkozó stílust módosítom, tök egyszerű módon, belekattintva az element.style részbe, ami teljes mértékben ekvivalens azzal, ha én a régi Operában tökölősen hozzáadom a style attribútumot KÉZZEL (mennyire ratyi, hogy nem lehet ezt egyszerűbben, ilyen logikusan, mint ahogy a Chrome/Chromium panelénél van), aztán ott belepötyörészem, amit akarok. Az CSAK az adott elemre fog vonatkozni. Nincs semmiféle globális vonatkozása. Nem egy selectort adtam meg, aminek megfelelő elemek stílusa meg fog változni, hanem az adott elem stílusát módosítottam.

    "Ha az összes többi padding 10, kivéve a left, ami 8, akkor ne jelölje már ki nekem az összeset."
    Hogy mit ne jelöljön ki? Ezt most már nem is értem. Mintha két külön nyelvet beszélnénk.

    "Még egy: Jelöld ki a "Legfrissebb anyagok" egy linkjét Dragonfly-ban és nyisd le a "Computed Styles"-t. Fogsz látni egy ilyet:
    font: normal normal 400 12px/16px Arial;
    Chrome-ban meg bontva van, egyenként másolgassam ki az összeset."
    Valóban nem a shorthand CSS property-ket adja. Szerintem viszont pont szar az Opera Dragonfly-ban, hogy egyáltalán nem mutatja, hogy melyik fájlból szedi konkrétan melyik betűstílust, és melyik értékek lettek felülbírálva egy később jövő stílusfájlból származó értékekkel; valamint nem a CSS-fájlokban megadott módon szedi szét a stílust, hanem összegzi a végső renderelés eredményét, és kész.
    Chrome-ban ezzel szemben a nyílra való kattintás után kibontva láthatod mindezt, és a fájlnevek még be is vannak linkelve, hogy azokra kattintva könnyen át is tudd írni egyből magában a fájlban az értékeket, így a stílusok érvényre jutásának sorrendje is egyezni fog azzal, ahogyan az épp fejlesztett oldal renderelődik a böngészőben.
    Dragonfly-ban megmondanád, hogyan is szerkesztek bele konkrétan az egyes fájlokba?
    A shorthand CSS property-kkel az a baj, hogy átláthatatlanabb, könnyebb elcseszni, szétbontott formában jóval beszédesebb, ráadásul ha a shorthand CSS property-k közül kihagyod valamelyiket, akkor faszán felülírod a máshol különbontva szerkesztett stílust, és az az alapértelmezett értékre áll be, lásd:
    https://developer.mozilla.org/en-US/docs/Web/CSS/font
    Pont ezért, meg a nehezebb átláthatósága és nehezebb módosíthatósága miatt én speciel kerülöm ennek a használatát.
    Bár ha karakterspórolás a cél, akkor jó lehet... (de ez ne legyen már érv manapság, főleg a CSS compressorok korában)

    font: normal normal 400 12px/16px Arial;
    ez speciel nálam Tahoma, tehát:
    font: normal normal 400 12px/16px Tahoma;
    de tök mindegy, ennek a megfelelője Chrome-ban:

    font-family: Tahoma;
    font-size: 12px;
    font-style: normal;
    font-variant: normal;
    font-weight: normal;
    line-height: 16px;

    (a "normal" érték egyenlő a 400-zal, lásd ezt)
    ebből látható, hogy csak a line-height tulajdonságot kell "egyenként" hozzámásolni, a többi pont egymás alatt van, így szépen kijelölhető az egész, én is úgy illesztettem ide. :)

    Egyébként egészen pontosan sorrendben a shorthand CSS property-k megfelelője így néz ki:

    font: normal normal 400 12px/16px Tahoma;

    ekvivalens ezzel (sorrendben, ahogy itt látható):

    font-style: normal;
    font-variant: normal;
    font-weight: normal;
    font-size: 12px;
    line-height: 16px;
    font-family: Tahoma;

    Nem mintha a sorrend nem lenne tökéletesen mindegy, csak a pontosság kedvéért leírtam ide. :)
    Szóval itt is úgy érzem, bolhából csinálsz elefántot.
    Hidd el, a külön-külön módosítás kényelmesebb, mert akkor teljesen egyértelmű, hogy épp mit módosítasz, csak ránézel a tulajdonság nevére, és már tiszta, nem kell gondolkodni, milyen sorrendben is van. De ha ez a fejedben lenne, még akkor sem érezném ezt olyan problémának, ami tényleg számíthat fejlesztés során.
    Sőt, ezt a megoldást én az említett fájlfelsorolós megoldás miatt jóval praktikusabbnak találom, mivel így egész pontosan követheted, adott esetben mivel sikerült - rosszul - felülbírálnod egy másik stílust (és hogy ne kelljen alkalmazni az amúgy kerülendő !important kulcsszót, ez nagyon is számít).

    "Én pl. kifejezetten szeretem, ha nem akar a program okosabb lenni, mint én, mert az ilyen próbálkozások mindig kudarccal végződtek. Nem létezik olyan algoritmus, ami engem ki tudna ismerni."
    Nagyon ügyes vagy, de hogy jön ez ide, amikor arról beszélünk, hogy Dragonfly-ban egy szar, kényelmetlen megoldást választottak, hogy nekem manuálisan kelljen hozzáadnom egy attribútumot, jobb klikk, Add attribute, "style" bepötyögésének bénázásával, amikor ez tök egyszerűen elkerülhető lenne úgy, ahogy Google-nál megoldották, hogy eleve felkínálták a style-attribútum módosításának lehetőségét, és csak akkor kerül az elembe a style-attribútum több értéke, amikor már oda be is pötyögtél valamit? Most itt a lázadozásod nem vagány, meg nem válasz semmire.
    Itt olyan jellegű problémáról beszélünk, mintha kábé az otthoni fürdőszobádban a WC-tartályodon végül is lehetne egy lehúzózsinór, de te minden alkalommal inkább felmászol a vécédeszka tetejére, és kézzel lenyomod a lehúzókart, mert az úgy tök vagány. Ja, várjunk csak, mégsem. ;]

    "Pl. Dragonfly-ban ha HTML nézetben ráklikkelek duplán egy tag-re, akkor nem a taget akarja szerkeszteni, hanem az egész tag alá tartozó részt. Itt meg ez is külön van csapva gondolom userbarát célból. De nekem nagyon nem tetszik ez sem."
    Hát akkor ebben is tök más az igényünk. Fejlesztés során nem egyszer fordult már elő, hogy mondjuk egy divet p-re akartam cserélni, vagy egy p-t spanre, vagy hasonló, ebben az esetben ráklattyolok az adott tagre, és mind a kezdő-, mind a zárótaget egyből lecseréli, szemben az Opera megoldásával, ahol nekem ezt manuálisan kell megtennem, még a HTML-szerkesztős részben, vagy ha rosszul csinálom (pl. elfelejtem lezárni), az is lehet, hogy a Dragonfly automatikusan kicsapja a kódból az adott taget, mert invalid abban a formában (mivel elfelejtettem jól lezárni). Nem is beszélve arról, ami NAGYON a Google megoldása mellett szól, hogy ha például egy adott taget módosítani akarsz, és azonbelül van mondjuk egy b@szomnagy <table>, akkor nekem azon végig kell görgetnem a textarea-ban (mondjuk igaz, van Ctrl+End, de érted). Szóval nem "userbarát" célból (ezt a szót itt egy fejlesztőpanel esetében nem is értem, mire akartál ezzel célozni? Szerinted az átlaguser tudja egyáltalán, hogy van ilyen?), hanem "fejlesztőbarát" célból.
    A HTML szerkesztése pedig jobb klikk, "Edit as HTML", ne mondd, hogy ez akkora katasztrófa.

    Már tényleg nüansznyi dolgokon vitatkozunk, szerintem tök feleslegesen.

    Az AdBlockeres probléma-felvetésre nem tudok mit reagálni, nem próbálgattam még ezt a részét. De ha a CSS-útvonalról van szó, azt megbeszéltük, hogy nagy hátránya a Google-ös megoldásnak, valóban gáz, hogy kimaradt, addig oldd meg Firefox-szal, vagy kiegészítővel, vagy nem vágom. Ezt én is hiányolom, ahogy írtam is. Remélhetőleg majd vmikor bekerül.

    "Nem. Ez a szokásos "még a legjobb és viszonylag egyszerű ötletet is képesek elbaszni" típusú monológ volt."
    Mint a fentiekből látszik, nem biztos, hogy a panel fejlesztőivel volt a gond. Máshoz szoktál hozzá, vagy kákán is keresed a csomót.

    "ha a böngészőben nincs konfigurálási lehetőség, hogy felülbíráld egy oldal hülyeségét, akkor az igenis faék"
    Ennél a résznél is elvesztettem a fonalat, most milyen hülyeséget is akarunk felülbírálni? Hogy ne irányítson át? Korábban már meg lett beszélve (Te magad bizonyítottad be), hogy az Opera sem védekezik ez ellen, mert megkérték rá a másik oldalnál, hogy menjen át a másik címre, és át is ment. Hát felháborító valóban.

    A beállíthatóság hiánya a Chrome-nál teljesen más kérdés, ezt ne keverjük ide. De ez is olyan dolog, ami nem a WebKit/Blink-vonal gyengesége, általad kitalált "szar kódja" miatt van, hanem valószínűleg azért, mert ez a koncepció (kiindulópont: a userek hülyék, a sok beállítás csak összekavarja őket) - de ezt még Te magad is kifejtetted. Akkor most miért azt igazolod, hogy ez a szar kódja miatt van?

    Az meg továbbra is inkább a vicc kategória, hogy az, hogy nem adják ki nyílt forráskódnak a Presto kódját, azt igazolja számodra (azt írtad, ez "már önmagában elegendő bizonyíték"), hogy az márpedig sokkal jobb és igényesebb. Aha, tényleg, amit nem látunk, amit letakarnak előlünk, az tényleg tuti sokkal jobb.
    Végül is lehetne az ember előtt tányéron kirakva egy székelykáposzta, meg egy fém ételhordóban egy darab szar is, és a fém ételhordóban lévő valamire simán ráfoghatnánk, hogy az biztos jobb kaja, mert nem látjuk. :DDD Jó, nyilván a Presto nem egy darab szar, de érted az ellentmondást...
    Nem tudom, milyen, ahogy Te sem. Csak tippelni tudunk. A Presto-t ötezer éve fejlesztették, épp emiatt tartalmazhatott rendkívül elavult, mégis bedrótozott kódokat, amiktől függött egy csomó minden más. Ez lehetett akár gány is. De lehet, hogy ezt folyamatosan javították. Lehet, hogy igényesebb, mint a WebKit/Blink, lehet, hogy pont nem. Ezt így egyikünk sem tudja eldönteni. Az tény, hogy sok mindent tudott, sok mindenben meg ezzel voltak problémák. Érdemes lenne sztem lezárni ezt a "szerintem akkor is sokkal jobb volt a Presto"-vitát, amíg pontosabb információk birtokába nem jutunk.

    "De miért kell ágyúval verébre?"
    Kezd fárasztó lenni ez a téma. Ugyan miért lenne már a JSON ágyúval verébre? :O :W

    "Programozásra biztos jó, de arra, amire nekem kellett egy INI is bőven megfelelt."
    Aha, mert az INI tényleg sokkal jobb, mint a JSON, főleg feldolgozás és adatstruktúrák, típusok szempontjából... na ne már. Ez viccnek is rossz. Azt azért elárulhatnád, hogyan deklarálod objektumok tömbjét INI-ben.
    Ja, tényleg, mielőtt megfeledkezem róla, a JSON-fájlok feldolgozása, írása gyorsabb, mint az INI-fájloké.

    "Linuxban miért is nem JSON-ban vannak a config fájlok? Talán mert elmebetegség lenne ilyen triviális célokra egy karácsonyfa programnyelvet alkalmazni?"
    Te milyen karácsonyfa programnyelvről beszélsz? Eleve milyen "programnyelvről"? :U A JSON nem egy "programnyelv".
    Hogy a JSON "karácsonyfa" lenne, az meg eleve vicc, meg nem is nagyon támasztható alá semmivel. Szóval bocs, de ez hülyeség úgy, ahogy van.

    "Igen. Úgy adtam meg, hogy http://*example.com/* nem pedig úgy, hogy "http://*.example.com/*"
    A dokumentáció szerint ez a sima example.hu-ra is vonatkozni nem csak a www-re (meg a többi aldomainre, ha van olyan).
    Na ez például logikus? Mert én eddig abban a (tév)hitben éltem, hogy a csillag helyettesítő karakter. Ennél fogva helyettesíti a . (azaz pont)example.com előtti részt. De mivel a domain http://example.com (pont nélkül), nem pedig http://.example.com, ezért logikusnak tűnt, hogy így adom meg."

    Nyilván megvolt az oka, hogy így találták ki. De a "logikusnak tűnt" állítások helyett mennyivel ésszerűbb lenne olvasni a dokumentációt, nem?

    https://developer.chrome.com/extensions/match_patterns.html

    A példád egész pontosan ott van a "Here are some examples of (I)invalid(/I) pattern matches:" részben:
    Bad pattern:
    http://*foo/bar
    Why it's bad
    '*' in the host can be followed only by a '.' or '/'

    A *example.com egyébként ilyen alapon illeszkedne az "example.com" és "fosexample.com" hostokra is (fosexample meg nyilván tök más domain, míg a fos.example.com esetében a "fos" egy aldomain az "example.com" domainhez).
    A *.example.com meg illeszkedik a sima example.com-ra, www.example.com-ra, meg a fos.example.com-ra is.

    [ Szerkesztve ]

    Sk8erPeter

Új hozzászólás Aktív témák