Új hozzászólás Aktív témák
-
#601
BigBlackDog
veterán
BigBlackDog
veterán
Nem rossz kis kieg! Grat!
[ Szerkesztve ]
-
#602
Sk8erPeter
nagyúr
ntomka
#597
Sk8erPeter
nagyúr
"És örültem volna, ha ide sem kerül át."
Akkor bocs.
De egy kiegészítő fejlesztésének menete szerintem sokakat érdekelhet, de nem biztos, hogy épp a Chrome topicban van az érdeklődök nagy része. 
"Amúgy többnyire nem a Chrome felhasználók szoktak megjelenni minden topicban azzal, hogy márpedig az ő böngészőjükben ez azért jobb, mert... ugye?"
Erről statisztikát készítettél, vagy honnan tudod?
Ha meg rám célozgatsz (bár akkor ezt mondhatnád kicsit egyenesebben is - ha már itt tartunk, ki is kezdte az Opera fikázását a Chrome topicban? Nem én, hanem Te. 
De veled ellentétben én ezt nem vettem magamra! ), hát elképzelhető, hogy néha meg szoktam említeni a Chrome topicban, hogy mi az, amit igazából az Operától nyúltak le, mint jó ötletet, de elismerem azt is, hogy van, amiben jobb a Chrome - pl. az extension API-ban. A Google-nek amúgy is nagy tapasztalata van a nyilvános API-k megjelentetésében, és elég jók is benne.
Hozzáteszem, a hasznos funkciók lenyúlása más böngészőktől nem egy haszontalan dolog, sőt - DE azért nem árt tudni, honnan is származik, mielőtt bárki (én viszont most nem rád célozgatok) elkezdené terjeszteni azt a nyilvánvalóan fals állítást, hogy márpedig a Chrome volt az első igen innovatív ötletekkel előálló böngésző. Azért azt szerintem még Te is elismerheted (mostantól hivatalos Opera-gyűlölőként is
), hogy az Opera nem gyengén tett hozzá a manapság szinte minden böngészőben megjelenő szolgáltatásokhoz, funkciókhoz, kezdve egészen a többfüles böngészéstől (hadd ne soroljam tovább). Persze ez nem változtat azon, hogy ellúzerkedték az asztali piaci szereplésüket és térnyerésüket, melyet nagyon jól jellemez a nevetségesen alacsony részesedésük.Tehát tényleg mindenki azt használ, amit ő maga kényelmesnek talál, engem speciel az általános böngészés (hangsúlyozom, NEM a fejlesztésről beszélek) során a Chrome hihetetlenül színvonaltalan beállítási lehetőségei, testreszabhatóságának hiánya rendkívül zavar.
Amúgy nem egyszer beszéltünk már a gyorsaság kérdéséről is, és most pl. Ubuntu alatt Chrome-ban böngészgetek, és meglepődve tapasztalom, hogy Linuxos környezet alatt tényleg a Chrome nyer gyorsaságban az Operával szemben!
Nagyon meglep, hogy ekkora a különbség, mert Windows alatt viszont nálam vitathatatlan az Opera radikális előnye, pedig kiegészítőkből, userJS-ekből (utóbbi Operánál) pontosan ugyanannyi van mindkét platform alatt.Hogy még én is egyet hozzátegyek ahhoz, és most egyetértésben veled, hogy gyenge az Opera fejlesztőeszköze: csak most tapasztaltam, hogy Opera alatt nem lehet több példányt futtatni a fejlesztőeszközből. Chrome alatt több oldalnak is vizsgálgathatom a szkriptjeit, DOM-fáját, stb., míg Opera alatt csupán egyetlen oldal vizsgálata megy, és ez olykor nagyon zavaró tud lenni. Fejlesztés során nem egyszer fordult már elő, hogy szükségem lett volna arra, hogy két vagy akár három oldalnak is vizsgálgassam a dolgait, de ezt csak Chrome alatt tudtam megtenni.
De lehet, hogy csak valami beállítási lehetőség az én figyelmemet kerülte el, mindenesetre ez a hiányosság feltűnő volt.
Ja, és nem extensiont, hanem weboldalt fejlesztgettem, ott jött elő ez a probléma."Itt nem a sávszélességről van szó, hanem arról, ha már JS-ben írunk mindent, akkor miért nem a saját formátumait használjuk, ezzel is gyorsítva az alkalmazást?"
Ez is igaz, de az is, hogy a kisebb méret miatt gyorsabb is lehet.
Na mondjuk ez lehet, hogy nem pont egy kiegészítőnél jön elő, de pl. formok AJAX-szal történő feldolgozásánál és hasonló esetekben kitűnhet.
Az se utolsó, hogy jQuery-vel milyen egyszerű a JSON-formátumú doksik (akár szerveroldali válasz) feldolgozása."Szépen elférnek egymás alatt, nem takar ki semmit, nem kell nyomogatnom semmit, és minden hibát ott látok, ahol keletkezik."
Akkor áruld már el, mégis a Te képeden látható Chrome fejlesztőeszköz+konzol az utóbbi fekete háttérszínén kívül megjelenésben mégis miben különbözik a Dragonfly fejlesztőeszköz+konzol párosától így fedésben (ez most Ubuntu alatti Opera 11.11):
Ez mégis miben rosszabb, mint amit Te mutattál?
Ezt most tényleg nem vágom.
Mindkettőnél Escape-pel lehet ki-bekapcsolgatni a konzolt, ha mégis zavarna."Elég nekem a munkahelyemen hangoztatni egész héten a szakmai véleményem, nem fogom ezen kívül fárasztani magam ilyesmivel. Szabadidőmben ami működik, az működik, örülök neki, ami nem, azzal meg egyszerűen nem foglalkozok."
Pedig pont a hozzáértőbb vélemények segítenének a legjobban az ilyen funkciók jobbá tételében. Nyilván a Chrome fejlesztőeszközének kialakításába is nem kevés olyan ember szólt bele legalább a véleményének elmondásával, aki valamelyest konyít a webfejlesztéshez.
Ha mindenki így állna hozzá, akkor nehezen fejlődnének az ilyen segédprogramok. Most ezt tényleg nem kötekedésként mondom, de nagyjából ugyanannyi idő megírni egy ilyen kritikát a fejlesztőcsapatnak, mint nekünk, a topicba. Mindkét helyen értékelik a hozzáértő véleményt, de előbbinél lehet, hogy még inkább. "Igen, még olyan nyelveket is körberöhög a JS, mint a PHP, csak még gyerekcipőben jár, senki nem foglalkozott vele. "
De most tényleg egy elsősorban kliensoldalon használt nyelvet hasonlítunk össze egy elsősorban szerveroldalon használt nyelvvel?
Persze, ott a Node.js és a hasonló kezdeményezések, de ahogy Te is mondtad, ezek a próbálkozások még mind gyerekcipőben járnak, így nyilvánvalóan nagyon nagy mértékben fognak még bővülni, javulni, tágulni, stb., aztán majd lehet, hogy ugyanott fog tartani, mint a PHP.
Vagy kifejthetnéd jobban is, mire gondoltál, mert ez így elég kevés - legalábbis nekem.
Ettől függetlenül simán lehet, hogy igazad van, csak így túl leegyszerűsítettnek hangzott.
Amúgy mondják, az ASP.NET is gyorsabb tud lenni, mint a PHP, mert pl. osztályok kódját jelentősen optimalizálva tudja kiszolgálni a felhasználók felé, ennek pontos módjának még nem néztem utána, így erről bővebbet nem tudok, de nyilván tény, hogy vannak alternatívák a PHP-re.Egyébként megmondom őszintén, én sem értem, mire alapozva mondta azt Penge_4, hogy "A JavaScript pedig minden, csak nem gyors." Ezt nem igazán indokolta.
Most nem olvastam el még egyszer a fentebbi sorokat, remélem nem írtam semmi sértőt, vagy legalábbis remélem, hogy nem gondolod azt, hogy a kákán is csak csomót keresek, nem az a célom, hogy kötekedjek, inkább csak az érdemi vitába akartam belemenni, annak van értelme szerintem.
A vita azon a tényen nem változtat, hogy a kiegészítőd egyre faszább.
Sk8erPeter
-
#603
Sk8erPeter
nagyúr
Penge_4
#594
Sk8erPeter
nagyúr
"A JavaScript pedig minden, csak nem gyors. Még a jelenlegi JS motorokkal sem."
Mire alapozva mondod azt, hogy nem gyors?JSON vs. XML témáról Wikipédián is írnak: [link]
Lényege, hogy bizonyos esetekben jóval több felesleges adatot is átvihet az XML-formátum, mint a JSON, mert ugye minden egyes taget le kell zárni, stb., és ez esetben jóval sávszélkímélőbb kliens-szerver kommunikációnál a JSON. DE persze előfordulhat olyan eset is, amikor a JSON-formátummal megegyező, vagy annál kisebb méretet eredményez az XML-formátum, pl. ha teledobálunk egy adott taget mindenféle attribútummal, ahogy a Wikipédiás példában is látható. Mindenesetre tény, hogy az XML ezerszer nehezebben olvasható emberi szemmel, egy XML-fájl iszonyat gány tud lenni, és nem feltétlenül a fejlesztő hibájából.
Persze egyáltalán nem azt mondom, hogy "le az XML-lel", félre ne értsd. Csak azért bőven vannak vele szemben előnyei a JSON-nek, főleg JavaScript-környezetben - pl. a jQuery-könyvtár nagyon jól fel van készítve a JSON-formátum olvasására, AJAX-szal történő formküldözgetés-válaszfogadás esetén nagyon leegyszerűsíti a fejlesztői munkát, tapasztalatból mondom, úgy, hogy eleinte XML-formátumban küldtem vissza az adatokat, aztán rájöttem, hogy jóval szebb és egyszerűbb JSON-nel. PHP-nél pluszban ott a json_encode() függvény, amivel full egyszerűen átalakítható egy tömb JSON-formátumra.Sk8erPeter
-
#604
Sk8erPeter
nagyúr
ntomka
#597
Sk8erPeter
nagyúr
Ja tényleg, még egy, a látványos oldalugrálás elkerülésére:
userJS-nél én azt csináltam az ilyen oldalugrálások elkerülésére, hogy eleve betöltés közben már hozzácsaptam egy saját <style> elemet a headerhez, ahova bepakoltam a stílusmódosításokat (tudom, Operánál van userCSS is, de egy helyen akartam elintézni a dolgot, néhány stílusmódosítással), valahogy így:// lekérjük a headert
var headID = document.getElementsByTagName("head")[0];
// saját CSS-kód
var newStyle = document.createElement('style');
newStyle.type = 'text/css';
newStyle.id = 'Neptun_mod_hiddensheet';
newStyle.innerHTML = ' \
#blabla_id { margin:0px 20px; } \
.valami_css_osztaly { display:none; } \
/* és így tovább... */ \
';
// hozzácsapjuk a headerhez
headID.appendChild(newStyle);Lehet, hogy emiatt az innerHTML-es megoldás miatt nem olyan szép, hogy hozzá kell csapnunk a CSS-kódot, de tök jól megoldja a problémát, meg működik ugrálás nélkül, ha ezt a kódot eleve a userJS elejére rakom, és nem a window objektum betöltődéséhez kötve.
Ilyesmit nem lehet csinálni extensionnél?
[ Szerkesztve ]
Sk8erPeter
-
#605
Penge_4
veterán
Sk8erPeter
#603
Penge_4
veterán
válasz
Sk8erPeter
#603
üzenetére
"Mire alapozva mondod azt, hogy nem gyors?"
Arra, hogy jelenleg már mindent kisajtoltak belőle a hardvergyorsítással, innen már nincs feljebb, csak a történelem újabb ismétlése az órajelekkel és a magokkal, ezúttal a GPU-nál is. Tehát ezen a szinten már a desktop, például C++-ban írt dolgokkal illene összevetni. Úgy viszont messze elmarad a sebesség/erőforrásigény tekintetében. A web alapja még mindig a HTML, mégis a sok JavaScripttel rendelkező oldalak rohadtul nehézkesek, értem ez alatt akár a Gmailt, akár a Google Docs-t, akár az MS Office Live-ot. De még WYSIWYG editorban sem láttam olyat, ami ne lenne érezhetően lassabb, mint például ez a HTML form, amibe most gépelem ezt a hozzászólást.
"Mindenesetre tény, hogy az XML ezerszer nehezebben olvasható emberi szemmel, egy XML-fájl iszonyat gány tud lenni, és nem feltétlenül a fejlesztő hibájából."
Számomra egyszerűbb a szintaxisa az XML-nek. A JSON többre képes már csak a RegExp miatt is, de ez egy kiegészítőnél nem tűnik ki, lévén a config.xml csak dokumentációkat és egyszerűbb utasításokat tartalmaz true/false értékekkel. Minek bonyolítsuk. A méret/sávszélesség kérdés ne egy normál esetben egyszeri alkalommal letöltendő kiegészítőnél számítson, amikor csak max pár kilobyte a különbség. Onnantól a vinyóról már úgyis elhanyagolható a beolvasási különbség, a RAM-ból meg főleg.
A postMessage viszont tényleg elég korlátozottnak tűnik. De ez remélhetőleg majd fejlődik, egyelőre még XHR2 támogatás sincs.
[ Szerkesztve ]
-
helkis
addikt
ismét ötlet: a user alá bekerült "aprohirdetései" szűrőt lehetne felvenni a figyelési listára? mert akkor amint felrak valamit a kiválasztott, már látnám is..
lehetne a témák és üzenetek után egy apróhirdetés fül is, esetleg megspékelve a phmegbizhatoság.atw.hu oldalról az aktuális piros-feketepont állást is kijeleztetni?"Egyedi vagy és megismételhetetlen! Csakúgy, mint bárki más!!!'" - 3Dmarkillers - hwbot.org
-
#607
Sk8erPeter
nagyúr
Penge_4
#605
Sk8erPeter
nagyúr
"Tehát ezen a szinten már a desktop, például C++-ban írt dolgokkal illene összevetni. Úgy viszont messze elmarad a sebesség/erőforrásigény tekintetében."
Ezt honnan tudod? Láttál erről valami hiteles összehasonlító tesztet? "De még WYSIWYG editorban sem láttam olyat, ami ne lenne érezhetően lassabb, mint például ez a HTML form, amibe most gépelem ezt a hozzászólást."
Hogy lehet ezt a kettőt összehasonlítani egyáltalán? Amibe most gépeled a hsz.-t, semmiféle szövegvizsgálatot nem végez, semmiféle formázást nem hajt végre rajta, csak egy sima egyszerű mezei szövegmező, amibe nyers szöveget írsz, azt kész. Mellesleg itt a TinyMCE: [link]; egyszerű gépelésnél nem igazán érzek sebességkülönbséget. A formázás is gyors.
Nem tudom, hogy vagy vele, de én jobban szeretem egyből félkövéren látni a szöveget, amit félkövéríteni akarok, mint hogy így lássam: "[B]ez most egy félkövér szöveg[/B]". Ezek a BBCode-jellegű kódrészletecskék legalábbis számomra nagyon gányak, de persze tény, hogy egyszerűek.
De ha tényleg ezekkel van a bajod, miért nem kapcsolod ki a JavaScriptet? Max. nem lesz ugyanolyan a felhasználói élmény, ami azért nagyon nem mindegy szerintem.
De én nem érzem nehézkesnek a Gmailt sem. Ha tudod, hogyan kell, próbáld meg, hogy fejlesztesz egy webalkalmazást, ami AJAX nélkül, minden egyes műveletnél újrafrissíti az egész oldalt, aztán csinálj olyat, ami csak adott részt frissít. Szerintem utóbbi lesz a gyorsabb, ha ésszel csinálja meg egy fejlesztő. De legalábbis az biztos, hogy sokkal jobb a felhasználó szemszögéből, hogy csak az frissül, aminek kellene, mint egy "rendes" asztali programnál.
Sok webes alkalmazást persze tényleg úgy készítenek el, hogy nehézkes lesz, mivel JavaScriptben is nagyon könnyen lehet gányolni, ami könnyen a teljesítmény rovására mehet, és még ennél a gyorsnak számító kliensoldali nyelvnél is érezhető lesz a lassúság.
De elég csúnya lenne, ha még mindig olyan webes világban élnénk, hogy minden egyes formot csak szerveroldalon lehetne ellenőrizni, minden online szerkesztőben minden egyes formázást csakis BBCode-okkal lehetne elvégezni, mindenféle oldalon belüli linkre/gombra való kattintás mindenhol az oldal teljes frissülését eredményezné, stb...Mondj jobb alternatívát, ha tudsz. Én jelenleg nem tudok, pedig lehet, hogy van.
"Számomra egyszerűbb a szintaxisa az XML-nek."
A JSON-é semmivel sem bonyolultabb, max. ott a sima tagek helyett van még idézőjel, szögletes és kapcsos zárójel, meg vessző is.
Tényleg gyorsan rá lehet érezni, csak két JSON-doksit elkészít az ember, és már nagyjából vágja, mi a pálya. Nagyjából ugyanannyi tanulást igényel, mint az XML."A JSON többre képes már csak a RegExp miatt is"
Ezt most nem értem. Hogyhogy a RegExp miatt is? A JSON-t is parse-olják, ugyanúgy, mint az XML-t, mindkettő igazából adatcserére szolgál.
Egyik sem tud többet ilyen szempontból, attól függ a kiértékelése, hogy a parser hogyan értelmezi.
Amúgy pont a JSON-re mondják sokszor, hogy gyorsabb parse-olni. Ezt alátámasztani és cáfolni sem tudom, mivel nem mértem, de rengeteg helyen olvastam már. Mellesleg el tudom képzelni, mert a nyitó- és zárórészt JSON-nél talán gyorsabb ellenőrizni (legtöbb esetben kevesebb karakterből is áll), hogy az-e az, amit keresünk."config.xml csak dokumentációkat és egyszerűbb utasításokat tartalmaz"
Nem tartalmaz utasításokat, csak karaktersorozatokat tartalmaz. Ezt kell parse-olni."A méret/sávszélesség kérdés ne egy normál esetben egyszeri alkalommal letöltendő kiegészítőnél számítson, amikor csak max pár kilobyte a különbség."
Pedig reméltem, hogy ezt nem fogod kiemelni. Nyilván ilyen méretű adatoknál tök mindegy a leíró formátum a méret szempontjából. Olyan szempontból viszont nem, hogy a kiegészítőknél 90%-ban JavaScripttel programozgatunk (van HTML is pl. a popupoknál is, na, az a maradékba tartozik), akkor minek belekeverni az XML-t is, mikor van egy ilyen könnyen olvasható formátum, mint a JSON - a Google ilyen szempontból következetes volt, Chrome-nál JSON a használt formátum az alapbeállító manifest.json fájlnál. ([link])Sk8erPeter
-
#608
Penge_4
veterán
Sk8erPeter
#607
Penge_4
veterán
válasz
Sk8erPeter
#607
üzenetére
"Mellesleg itt a TinyMCE: [link]; egyszerű gépelésnél nem igazán érzek sebességkülönbséget. A formázás is gyors."
Az, de nagyon gáz.
A táblázatokról meg ne is beszéljünk. Elvileg általános iskolában megtanítják, hogy először nyers szöveget gépelsz, utána formázol. Ez azért gáz, mert egy kilométeres kommentnél elfelejtesz visszafelé idézgetni, kihagyhatsz véletlenül részleteket, ezért jó a BBCode, mert Ctrl+B-vel (userJS) ugyanúgy félkövérré teszem és ugyanúgy alkalmazom a Wordben megszokott billentyűparancsokat, csak éppen nem kell kínlódnom vele, hogy véletlenül átveszi a következő bekezdés formázását és a többi hülyeséggel.
Lineárisan nem lehet leprogramozni, hogy mit akar az ember éppen, mikor mit hogyan formáz.
A legapróbbtól (amikor egy kijelölésnél belelóg valamelyik szóköz) a durvábbaktól (mikor a forráskódnézetben nem látsz a sok <br /> és -től) a katasztrófálisig (tabulátor, illetve CSS helyett szóközökkel végzett behúzások), itt minden hibafajta elkövetése pár kattintásra van.
Baromság. Az egyetlen előnye, hogy a profitorientált blogszolgáltatók és Gportál típusú next-next-finish webhostingot kínáló portálok ezzel elhitetik az átlagfelhasználóval (aki a legnagyobb csoport), hogy ő is tud weblapot/blogot készíteni HTML tudás nélkül.
"De ha tényleg ezekkel van a bajod, miért nem kapcsolod ki a JavaScriptet? Max. nem lesz ugyanolyan a felhasználói élmény, ami azért nagyon nem mindegy szerintem."
Nem, nekem az ágyúval verébre filozófiával van bajom. Például itt is, sehol nincs JavaScript, ahol nem szükséges (formázási gombok alkalmazása), kivéve például a hozzászólásküldés sikerességéről szóló kiíratás.
1. Az eddigi 3000+ hozzászólásom közben egyszer nem kaptam eltérő üzenetet. Mindig sikeres volt. Még 1-2 éve RIOS errorok alkalmával is vagy sikeres volt (és nem jelent meg x ideig), vagy internal server error.
2. Ha tényleg annyira szükségszerű, akkor dobjon vissza egyenesen a hozzászólások oldalra és ott írja ki egy felső csíkba, de már lássam a saját szememmel a hozzászólást. Annak jobban hiszek, mint az adatbázisnak.
"De én nem érzem nehézkesnek a Gmailt sem. Ha tudod, hogyan kell, próbáld meg, hogy fejlesztesz egy webalkalmazást, ami AJAX nélkül, minden egyes műveletnél újrafrissíti az egész oldalt, aztán csinálj olyat, ami csak adott részt frissít."
Félreértesz. Én az asztali szoftverekkel vetettem össze. Nem kell ide mérőprogram, próbálj ki egy Opera Mail-t, egy Thunderbird-öt, mind gyorsabb lesz, mint a Gmail webes felülete (vagy akármilyen más levelező webes felülete).
Az AJAX valóban gyorsabb azonos körülmények között, viszont ha választhatnék egy olyan szerver között, ahonnan akár 4-5MB/s sebességgel is jön a cucc és egy olyan között, ahol a betöltés eleve 10+ másodpercet vesz igénybe, mert folyamatos töltés alkalmával képtelen elérni a 30kB/s sebességet, akkor előbbi AJAX nélkül is ezerszer gördülékenyebb lenne.
"Mondj jobb alternatívát, ha tudsz. Én jelenleg nem tudok, pedig lehet, hogy van."
A BBCode-ot leszámítva nem is volt ellenvetésem. Amúgy én sem szeretem, jobb lenne az egységes HTML code. De a WYSIWYG editorokat utálom.
A JSON témával kapcsolatban passz, kérdezd meg a Dev Operán valamelyik fejlesztőt, hogy miért döntöttek így. Gondolom valami kulturális oka van, a dialog.ini-t például YAML-ra cserélték, mert az INI kinőtte magát és a különböző nyelvek különböző hosszúságúak, ezért INI-ben nehéz volt definiálni, hogy ami angolban például 30 karakter az oroszban 50 magyarban meg 80 meg ilyesmi.
-
#609
Sk8erPeter
nagyúr
Penge_4
#608
Sk8erPeter
nagyúr
Hát most jól mutattál egy általad szándékosan szanaszétgányolt formázott szöveget. Hát ilyen alapon ugyanezt a szanaszéjjel-gányolást BBCode-dal is nyugodtan meg lehet tenni - pl. nagyon sok júzer a BBCode-nál sem veszi észre, hogy egész a kommentje végéig tolódott a [/quote] tag, így az egész saját kommentje is a korábban idézett hozzászóláshoz fog csapódni, idézetként. De amikor megjelenik pl. egy BBCode-os fórum oldalán , és látszik, hogy a saját kommentje is idézetbe került, akkor sem zavartatja magát, úgy hagyja. Ugyanez jellemző félkövérítésnél, nem veszi észre esetleg, hogy a [/B] eltolódott egészen a sora/kommentje végéig, így az egész jól ki lesz emelve félkövérrel. De nem baj, ezt is bent hagyja.
Szóval nem mondhatod, hogy kevesebb az esélye, hogy ilyen jellegű hibák fordulnak elő BBCode-nál... Főleg, hogy azokat a kódokat a legtöbb kezdő júzer egyáltalán nem érti, hogy az miért úgy néz ki, mi az egyáltalán, stb... Ezzel szemben egy WYSIWYG-jellegű szövegszerkesztőnél legalább azt érti, hogy a következő bekezdésben szereplő szöveg is láthatóan félkövér, na vajon mi történhetett. Legalább megpróbálja kiszedni. Ha nem megy neki, nem jön rá, akkor egy Word-jellegű programnál sem jönne rá, és amúgy is menthetetlen eset. Szóval ugyanott tartunk.
A WYSIWYG-szerkesztőknél is lehet gányolni, a csupán BBCode-ot mutató fórumoknál is lehet gányolni, full mindegy. Nem mellesleg a TinyMCE-ben is lehet korlátozni, hogy milyen formázást engedünk meg. Ha meg valami okoska júzer megpróbálja ezt kikerülni, akkor meg ott a szerveroldali ellenőrzés, bizonyos tageket egyszerűen kiszedhetünk, vagy egy az egyben, HTML-kódokká átalakítva (pl. < helyett <) megjelenítjük, hadd lássa, hogy hatástalan a formázási kísérlete."Lineárisan nem lehet leprogramozni, hogy mit akar az ember éppen, mikor mit hogyan formáz."
Ezt nem értem. Mit értesz azalatt, hogy "Lineárisan nem lehet leprogramozni"?"ezzel elhitetik az átlagfelhasználóval (aki a legnagyobb csoport), hogy ő is tud weblapot/blogot készíteni HTML tudás nélkül."
És szerinted a BBCode-dal ilyen alapon mit hitetsz el? Kb. ugyanezt.
Ebből nagyjából egy kiút lenne, hogy nem engedjük meg a júzernek, hogy formázzon, és kész. Annak meg sokan nem örülnek.
A Wiki-jellegű szerkesztéseket meg az egységsugarú júzer biztos, hogy nem érti, és/vagy folyamatosan elrontja. Ugyanott tartunk."A legapróbbtól (amikor egy kijelölésnél belelóg valamelyik szóköz) a durvábbaktól (mikor a forráskódnézetben nem látsz a sok <br /> és -től) a katasztrófálisig (tabulátor, illetve CSS helyett szóközökkel végzett behúzások), itt minden hibafajta elkövetése pár kattintásra van."
Tény, hogy a kód nem lesz túl szép. Én is utálom nézni a sok nem törő szóközt és a többit. DE még mindig W3C-valid marad! (ha bármilyen elemnél mégis para lenne, könnyű átkonfigolni a JS-ben, hogy validdá tedd, lásd pl. az <img> elemnek adott bordert is könnyű kiszedni)
Pl. vedd azt az esetet, hogy van egy oldal, aminél a fejlesztő(k) megoldotta(/ák), hogy admin-felületen lehessen szerkeszteni a honlap tartalmát, így nem kell folyamatosan cseszegetni a fejlesztő(ke)t. Ha valamennyire vágja a WYSIWYG-szerkesztőket az, akié a weboldal, és aki az admin-oldalon szerkesztget, olyan nagyon nem vágja szét az oldalt.
Max. a kódja nem lesz csodás, valóban.
De akkor is megoldás valamelyest a problémára. Jobbat nehéz kitalálni, hogy a felhasználó szerkeszthesse is, formázhassa is a szöveget (most tök mindegy, WYSIWYG-szerkesztő vagy BBCode, mindkettővel lehet gányolni)."kivéve például a hozzászólásküldés sikerességéről szóló kiíratás"
Jaja, erről már beszéltünk, hogy teljesen felesleges.
De az általad kedvelt BBCode-ok beillesztéséért is JS-kód a felelős.
Most itt viszont nem értem az "ágyúval verébre" kifejezést, hogy itt PH!-n miért is annyira probléma a JS, ha már utóbbi lassúságát akartad bizonyítani, tehát a téma idekeverését nem értem - itt nem lassít semmit, az más téma, hogy van egy felesleges JS-sel és/vagy <meta>-taggel történő átirányítás, ettől még az oldal működését a JS nem lassítja."Én az asztali szoftverekkel vetettem össze. Nem kell ide mérőprogram, próbálj ki egy Opera Mail-t, egy Thunderbird-öt, mind gyorsabb lesz, mint a Gmail webes felülete (vagy akármilyen más levelező webes felülete)."
Azt hiszem, nem olyan meglepő, hogy egy totálisan neten keresztül, online működő program valamennyivel lassabb, mint egy full offline program - már amikor az offline program épp nem letöltöget valami infót.
Nem értem, minek az ilyen jellegű összehasonlítás, teljesen haszontalan, mivel két full más jellegű dologról beszélünk, így nem értem, minek összekeverni a két témát. Ettől még mindig nem lesz igaz az az állításod, hogy "a JS minden, csak nem gyors", mert az, gyors."a betöltés eleve 10+ másodpercet vesz igénybe, mert folyamatos töltés alkalmával képtelen elérni a 30kB/s sebességet"
Ha itt konkrétan a Dzsímélről beszélsz, akkor azzal abszolút nem értek egyet, mert ez nem jellemző rá. Nálunk 15 Mbites net van, tehát nem olyan hűdebrutál gyors, de ilyen nem szokott jelentkezni."Amúgy én sem szeretem, jobb lenne az egységes HTML code."
Nekem nem a BBCode szintaktikájával van a bajom. Inkább az, hogy ilyen jellegű kódokat kell látni a hozzászólásban. Legalábbis amikor egy fórumra felmegyek, ne az legyen már az érzésem, hogy már megint honlapot szerkesztek."A JSON témával kapcsolatban passz, kérdezd meg a Dev Operán valamelyik fejlesztőt, hogy miért döntöttek így. Gondolom valami kulturális oka van"
Ezt a kulturális ok magyarázatot nem nagyon értettem.
Inkább az az oka, hogy végül is megfelelnek egy W3C-szabványnak: [link].========
ntomka:
még az előzőeken túl kommentelnék:
most épp fejlesztgetem az első Opear extensionömet, semmi különöset nem csinál, csak átalakítja a Neptun (tárgyjelentkezésre és egyéb tanulmányi dolgok adminisztálására használható felület) kinézetét, tehát tulajdonképpen egy userJS-t konvertálok át extensionné.
Hát ez az Opera kiegészítő-fejlesztés tényleg valami botrányosan egy okádék szar. Fejlesztői módban szopattam magam azzal, hogy nem értettem, az "includes"-ban szereplő fájlok miért nem válnak érvényessé, és akkor jutott eszembe, hogy írtad, hogy fejlesztői módban nem működnek egyszerűen a kiegek.
Hát ez mekkora egy fos? Botrány. Ez akkor nem is bugos, hanem egyszerűen egy hasznavehetetlen trágya.
Ezenkívül mi az, hogy kötött könyvtárstruktúra van? Nehogy már, includes-ba kell pakolni a userJS-fájlokat? Miért nem lehet megadni a config.xml-ben egyszerűen az elérési utakat, ahogy Chrome-nál a manifest.json-ban?
Ráadásul az include-olandó JS-fájlok elején a userJS-ek szintaktikájához hasonlóan a fájl elején ott kell lennie az @include (és @match, hogy Greasemonkey-szerű legyen) részeknek, hogy mely oldalakra vonatkozzon, ezt szintén nem lehet állítani a config.xml-ben?
És ha én azt szeretném, hogy csak bizonyos megadott oldalnál hadd használjak már jQuery-szintaktikát, és include-olni szeretném a jQuery-t, akkor annak az elejére is kénytelen vagyok bepakolni az @include részeket és a címellenőrzést?
Hát ez hihetetlen. Legszívesebben most izomból pofánverném azt a néhány fejlesztőt, aki ezeket az oltári baromságokat kitalálta az Operánál.
Most már értem, miért szidtad az Opera kiegészítő-fejlesztésre szolgáló eszköztárát.[ Szerkesztve ]
Sk8erPeter
-
#610
Penge_4
veterán
Sk8erPeter
#609
Penge_4
veterán
válasz
Sk8erPeter
#609
üzenetére
"Hát ilyen alapon ugyanezt a szanaszéjjel-gányolást BBCode-dal is nyugodtan meg lehet tenni"
Úgy, hogy az egyik szöveg rácsúszik a másikra, csak azért, mert növelem a betűméretet?
"egész a kommentje végéig tolódott a [/quote] tag, így az egész saját kommentje is a korábban idézett hozzászóláshoz fog csapódni, idézetként."
Az már felhasználói hülyeség. Itt sajnos még quote tag sincs, csak dőlt betű.
"Főleg, hogy azokat a kódokat a legtöbb kezdő júzer egyáltalán nem érti, hogy az miért úgy néz ki, mi az egyáltalán, stb... Ezzel szemben egy WYSIWYG-jellegű szövegszerkesztőnél"
Elkezdi csicsázni a kommentet mindenféle színű betűkkel, ha pedig a BBCode gombok nincsenek kitéve, akkor formázatlanul hagyja többnyire.
"amúgy is menthetetlen eset. Szóval ugyanott tartunk."
Nem, mert BBCode-nál vagy ott a kód, vagy nincs, WYSIWYG-ben pedig így fog kinézni, miután kivette a félkövérséget:
<b></b>volt félkövér szöveg<b> </b>
"Ezt nem értem. Mit értesz azalatt, hogy""Lineárisan nem lehet leprogramozni"?"
Lásd a fenti példát. Ha csak egy szóközzel is eltéveszti a kijelölést már nem fogja tudni a szerkesztő, hogy kiszedje-e a tageket, vagy semmissé tegye a fenti módszerrel.
Ugyanúgy entereknél is <br/> tagekkel pakolja tele ahelyett, hogy az adott sorköztől függően új bekezdésbe rakná két <p></p> közé.
"És szerinted a BBCode-dal ilyen alapon mit hitetsz el? Kb. ugyanezt."
Annyi különbséggel, hogy ott a sokadik sikertelen kísérlet után megunja jobb helyen pedig a moderátor kivágja (például azért, mert nem tud linkelni), de a forráskódot nem fogja nézni, hogy mennyi szemét torlódik fel benne.
A böngésző pedig parsolni fogja és megformázza a szóközt is és itt jönnek a problémák.
"A Wiki-jellegű szerkesztéseket meg az egységsugarú júzer biztos, hogy nem érti, és/vagy folyamatosan elrontja. Ugyanott tartunk."
De a Wikipédiát öröm is olvasni (többnyire) és nincs is tele csilivili rózsaszínű szövegekkel meg HTML marquee-kkal, mert azt bezzeg megtanulja, ha mást nem is.
"DE még mindig W3C-valid marad!"
Ez is az... [link]
"Ha valamennyire vágja a WYSIWYG-szerkesztőket az, akié a weboldal, és aki az admin-oldalon szerkesztget, olyan nagyon nem vágja szét az oldalt."
Én meg a Joomla óta kopaszodom. Biztos bennem van a hiba, hogy képes vagyok különbséget tenni 10-es és 12-es betűméret között, Arial és Times New Roman között és sötétszürke és fekete között.
Az ő és ű betűk o és u betűre cserélése meg megint egy aranyos húzás.
"Ez akkor nem is bugos, hanem egyszerűen egy hasznavehetetlen trágya."
Ez tényleg elég érdekes, ilyen durva bugokat nem szoktak ilyen sokáig benne hagyni.
"Miért nem lehet megadni a config.xml-ben egyszerűen az elérési utakat, ahogy Chrome-nál a manifest.json-ban?"
Mert azt az index.html-ben kell megadni, ha eltérő a könyvtárstruktúra.
[ Szerkesztve ]
-
#611
Sk8erPeter
nagyúr
Penge_4
#610
Sk8erPeter
nagyúr
"Úgy, hogy az egyik szöveg rácsúszik a másikra, csak azért, mert növelem a betűméretet?"
Ez furcsa, az egyik általam készített admin-oldalon van TinyMCE, igazából nagyon egyszerű szövegszerkesztésre, de ilyen jellegű hibát én még nem tapasztaltam, de biztos létező probléma adott esetben, viszont sztem elkerülhető."Az már felhasználói hülyeség."
Igazából az is, ha a felhasználó nem tudja megoldani, hogy ne csússzon át a korábban érvényes formázása pl. az előző bekezdésből. Ugyanez a probléma Gmailnél is simán előfordulhat, végül is annak az e-mail író része is WYSIWYG-szerkesztő, ahogy nagyjából az összes mai modern cloud-alapú e-mailküldő rendszernél, sőt, igazából a legtöbb asztali kliensnél is, mármint ha nem állítja be valaki, hogy csak plain textet küldjön (mint én). Na, és Gmailnél meg a többinél is (ahogy szövegszerkesztőknél is) ki lehet szedni ezt a parát, hogy a korábbi formázás átcsússzon, mindenhol előfordulhat hasonló eséllyel.
Így legalább a felhasználók naponta gyakorolják a WYSIWYG-szerkesztők használatát.
Amúgy van forráskód-nézet is, ha valaki nagyon akarja, bele tud nézni, milyen a generált kód, és javíthatja. Ezt mondjuk a felhasználók többsége nem tudja így megoldani, de a stílus törlésével vagy másképp igen, az eszköztárról. Ne mindig a legbutább emberekre gondoljunk egyből.
Ja, szóval ilyesmire való pl. a linkelt oldalon látható példában a "Remove formatting" gomb."Elkezdi csicsázni a kommentet mindenféle színű betűkkel, ha pedig a BBCode gombok nincsenek kitéve, akkor formázatlanul hagyja többnyire."
Mint említettem, TinyMCE-t és a többi ilyen jellegű WYSIWYG-szerkesztőt is könnyen lehet konfigurálni, hogy milyen formázásokat engedsz, vagyis milyen gombokat pakolsz ki a felhasználónak. Nyilván ha nem akarsz színezést, nem rakod ki az arra való gombot."<b></b>volt félkövér szöveg<b> </b>"
Nem, most próbáltam ki direkt, rátettem a félkövérítést, kiszedtem, aztán ezt ismételtem, és utána megnéztem a generált forráskódot az "Edit HTML Source" gomb segítségével, és nem csinált ilyen jellegű gányolást.Amúgy ha nagyon akarom, ezt itt is meg tudom csinálni, csak úgy, hogy "véletlenül" rákattogok a gombokra:
[B][/B]volt félkövér szöveg[B][/B]"jobb helyen pedig a moderátor kivágja"
Akkor ezt WYSIWYG-szerkesztők alkalmazása esetén is meg lehet tenni.
Na, egyébként pl. a linkelés az egységsugarú júzernek felfoghatatlan művelet BBCode-okkal, de ha ott a gomb, lehet, hogy nem cseszi el (ahogy itt PH!-n is nehéz elrontani, de lehetséges)."Ez is az... [link]"
Hát ez qrva jó, ezen olyat röhögtem! 
Mintául szolgálhat a fejlesztők számára, hogyan készítsünk valid kódot!
"Az ő és ű betűk o és u betűre cserélése meg megint egy aranyos húzás."
No de ennek nem sok köze van elvileg a WYSIWYG-szerkesztőkhöz, hacsak nem rögtön kliensoldalon cseréli le. Mindenesetre nagy barom volt akkor az oldal készítője, ha ez így történik. Vagy ez Joomla alapfelépítésénél külön átszerkesztés nélkül általános jelenség? Én nem tudom, még nem fejlesztettem ilyesmit, meg nem módosítottam tartalmakat ilyen motor alatt működő oldalakon felhasználóként sem.[ Szerkesztve ]
Sk8erPeter
-
#612
Sk8erPeter
nagyúr
Sk8erPeter
#611
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#611
üzenetére
Extension-téma: (Bocs, még szerkesztenem kellett ezt, előzőbe már nem fért bele időben)
"Mert azt az index.html-ben kell megadni, ha eltérő a könyvtárstruktúra."
Na, azt megköszönném, ha tudnál segíteni kicsit az Opera extension fejlesztésében.
ntomka sajnos megalapozottan utálkozott az Operára történő extension-fejlesztés miatt, rendkívül macerás, logikátlan, ráadásul a hivatalos oldalon fellelhető leírások is iszonyat szarok, összecsapottak.Chrome-nál az első extension elkészítése nagyjából 20-30 percet vett igénybe a hivatalos doksi tanulmányozásával együtt, az Opera extensionnel meg nagyjából több órát b@sztam el ennek a full egyszerű oldalmegjelenés-módosító UserJS-nek az átalakításával is, mert számomra valahogy annyira nem világos ennek a működési elve.
Pl. Chrome-nál ugye egyből a manifest.json-ben megadhatom, pontosan melyik oldalra is vonatkozzon egyáltalán a kiegészítő bármely módosító tulajdonsága. Hát de az meg mi már, hogy Operában nincs ilyen a config.xml-ben, hanem ha korlátozni akarom, melyik oldalakra vonatkozzon a módosítás, meg egyáltalán a kiegészítő dolgai, akkor a userJS-jellegű fájlokban az @include részekkel tudom ezt korlátozni?! De írjam bele ezt minden vonatkozó JS-fájlba?
Chrome-nál egyetlen helyen megadom, és kész. Tök logikus.Ezentúl szeretnék mondjuk jQuery-szintaktikát használni a JS-fájlom fejlesztése közben, így nyilván include-olni kell a jQuery-könyvtárat, na meg mondjuk szeretnék saját stíluslapot is érvényessé tenni az általam megadott oldalakon.
Példa arra, hogy Chrome-ban az erre vonatkozó manifest.json-fájlom ez alapján hogy is néz ki (szerintem elég magától értetődő):
{
"name": "Neptun Theme Changer",
"version": "1.0",
"description": "......",
//"background_page": "background.html",
"content_scripts": [
{
"matches": [
"https://frame.neptun.bme.hu/*",
"https://neptun3r.web.uni-corvinus.hu/*"
],
"css": ["styles/Neptun_style.css"],
"js": ["includes/jquery.min.js", "includes/Neptun_theme_changer.user.js"],
"run_at": "document_start"
}
],
"permissions": [
"tabs",
"http://*/*"
]
}(A background_page-et szándékosan hagytam ott kommentben (igazából itt nincs szükség rá), hogy látsszon, azt is ennyi belepakolni, megadni a helyes elérési útját. Azért kerültek itt a js-fájlok az includes könyvtárba, hogy az Operának jó legyen...
)Chrome alatt teljesen hibátlanul megy, ahogy elvárom, ezzel a megadott könyvtárstruktúrával, a megfelelő platformfüggetlen JS-kóddal (tehát nem Chrome-specifikus dolgokat írtam a userJS-ben, nyilván, mivel eleve Operára írtam meg elsőként a userJS-t, az extension mégis Chrome alatt hajlandó csak megfelelően működni egyelőre, mert valahogy a jQuery-t nem szeretné látni).
Korábban a userJS-ben így include-oltam a jQuery-t, hogy hozzácsaptam a Google CDN-ről szedett jQuery-fájlt az eredeti oldal headerjéhez:
var headID = document.getElementsByTagName("head")[0];
var newScript = document.createElement('script');
newScript.type = 'text/javascript';
newScript.id = 'Neptun_mod_jQuery';
newScript.src = 'http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js';
headID.appendChild(newScript);Ez így működött.
De egy extensionnél ne kelljen már ilyen trükköket bevetni.
Nézd meg a Chrome beállító fájlját, full egyértelmű, hogy include-olom a jQuery-t is, és kész.
Próbáltam azt, hogy az index.html-be beraktam az elérési útját, egyelőre sikertelenül.
Amikor már a hajam téptem, úgy döntöttem, inkább abbahagyom az Operára való extension-fejlesztést, mert ez így nem lesz jó, vizsgaidőszakban a fél napjaimat elb@szni Opera extension fejlesztésével...Mellesleg ez úgy működik, hogy elvileg injektálja az oldalba magát a JS-kódot.
Chrome oldalán ezt írják a content scriptekről (simán elképzelhető, hogy Operánál más elven működik, ezt nem tudom):
"A content script is some JavaScript that executes in the context of a page that's been loaded into the browser. Think of a content script as part of that loaded page, not as part of the extension it was packaged with (its parent extension)."
Ja igen, és a konkrét content script oldalon meg a JS-fájlokra vonatkozóan ezt írja:
"The list of JavaScript files to be injected into matching pages. These are injected in the order they appear in this array."
Na, tehát injektálja, csak mondjuk ebből a szempontból elvileg Opera és Chrome között az a különbség, hogy ahogy asszem épp Te írtad itt korábban, Operánál ABC-sorrendben, a fájlok nevei szerint include-olja (úristen, de gáz), Chrome-nál meg meg lehet adni a sorrendet azzal, hogy milyen sorrendben írod bele a tömbbe (így a logikus).Operánál valamiért a jQuery-szintaktikát nem igazán engedi használni (érvénytelen hivatkozást ír a $ jelre konzolon, mint amikor nincs include-olva még a jQuery-könyvtár), pedig ABC-sorrendben a "j" előbb van, mint az "N", ráadásul már teszteltem úgy is, hogy beletettem a jQuery-fájl elejébe egy ilyet: console.log('jQuery-teszt...');
Ezt szépen ki is írja a konzolra, tehát tulajdonképpen mintha figyelembe venné azt, hogy ott van a jQuery-fájl, mégsem működik maga a jQuery-szintaktika a userJS-fájlban (amit elvileg szintén injektál).Ja igen, és az index.html-ben hogy adod meg, ha eltérő a könyvtárstruktúra?
Az Opera extensionökről szóló leírásai, tutorialjai szart sem érnek a Google Chrome extensionök howto-leírásához képest (pedig tudod, nem vagyok Chrome-rajongó, de el kell ismerni, ez ott nagyon jól sikerült), utóbbiaknál full emberi nyelven elmagyarázzák, így rohadt gyorsan meg lehet érteni a működését.
========
ntomka, ha Te is tudsz segíteni, nagyon szívesen várom! És ne haragudj, hogy szétOFF-oltuk a topicodat, megpróbáljuk visszafogni magunkat, bár nehéz lesz!
Igazából azért merészeltem ezt ide leírni, mert végül is itt is extension fejlesztéséről van szó (bár tudom, inkább az ötletelésre szántad ezt a topicot, meg a kieg. esetleges hibáinak megvitatására), és úgy tűnik, eléggé vágod a témát, hátha hozzászólsz Te is...
(Bár egy ideje eltűntél, mióta szétOFFoljuk a topicodat, bocsesz... )
Meg Penge_4 is hozzá tud szólni érdemben.Sk8erPeter
-
#613
Penge_4
veterán
Sk8erPeter
#612
Penge_4
veterán
válasz
Sk8erPeter
#612
üzenetére
Oké, ultimate ellenérv: A HyperTranslate kiegészítő összeakad az összes WYSIWYG szerkesztővel.
"Igazából az is, ha a felhasználó nem tudja megoldani, hogy ne csússzon át a korábban érvényes formázása pl. az előző bekezdésből."
Oké, mit nem csinálok jól?
1. Kijelölöm duplaklikkel például a "primary" szót (csak azt).
2. Font Size legördülő, kiválasztom: 4 (14pt)
3. Amíg a kijelölés aktív csak a "prim" szó látható".
4: Amint elveszem a kijelölést a szó második fele rácsúszik a következő szóra.Gmailnél ilyen durva dolgokat nem tapasztaltam.
Egyéb kritika: A blog.hu-n szvsz korrektebb a forráskódnézet implementációja. Nem szeretem, mikor ilyen pszeudo-ablakban jelenik meg bármi ilyesmi. Már csak azért sem, mert az ömlesztett forráskód, struktúra nélkül elég átláthatatlan, gyakran görgetnék (ha lehetne) a WYSIWYG változatban, kiválasztva egy ritka szót, majd arra rákeresve (ha éppen az ékezetes betűk nem cserélődtek le entitásra, akkor meg is találom) egyből a lényegre tudok ugrani egy 10000+ karakteres kódban is.
Ehelyett itt nyitva kell hagynom egy plusz fület.
Mindegy, ezen kár vitatkozni. Ha normálisan meg van csinálva (ez megint olyan, ami kevés helyen van normálisan megcsinálva), akkor valóban szélsőséges esetekben adhat hasonló eredményt akár pozitív, akár negatív irányban.
Ettől függetlenül én többnyire azt vettem észre, hogy a BBCode-ban (ha használják, tehát egyáltalán tudnak róla) több a hiba abban az esetben, ha az adott oldalon nem lehet a hozzászólást szerkeszteni. Viszont ha lehet, akkor ritkábban jellemző (gondolom mivel kevésbé hívogató), ezzel szemben a WYSIWYG editorokban nagyon gyakori mindenféle csicsa. Az ilyen oldalakon gyűlnek össze az 5-10 megás videó minőségű GIF avatarokat használó 38 db userbaros emberek és társai. Miért? Gondolom mert a csicsa lehetősége hívogatja őket.
Levelező: Ez teljesen más, mert az e-mail azt a célt szolgálja, hogy hosszabb terjedelmű leveleket küldj a másiknak.
Én levelezőlisták kapcsán többnyire azért akartam HTML formázást, mert így pár dolog egyszerűbb volt, mint félkövér szöveg, piros figyelmeztető szöveg, kisebb méretű képek inline beszúrása (nem csatolmányként), ilyesmi.
De ezt követően amint pár ismerősöm rákapott az IncrediMail-re, rögtön átértékeltem a kérdést.
Extension-téma: Melyik verzióval próbáltad? Stabil 11.11 vagy Opera Next (11.50)? Utóbbi mai buildjében javították a Dragonfly bugot, úgyhogy megpróbálhatod, mert 3-4 előzetessel korábban volt egy rakás Core javítás.
Én az első kiegészítőmet (WebM átirányító, ami feleslegessé vált a YouTube WebM Plus kiegészítővel, ami még a cookie-t is eltárolja (jó, a UserJS már adott volt, csak kicsit módosítottam rajta) kb 15 perc alatt elkészítettem, amiből a legtöbb időt a megfelelő méretű transzparens PNG ikon keresése és módosítására ment el.
Volt még egy másik tervem Magyar Opera BrowserJS Plus néven, ami azt szolgálta volna, mint a gyári browser.js, de főként magyar oldalakra koncentrálva. Ebből érdeklődés hiányában nem lett semmi.
"Példa arra, hogy Chrome-ban az erre vonatkozó manifest.json-fájlom ez alapján hogy is néz ki (szerintem elég magától értetődő)"
Én itt elvesztettem a fonalat ott, hogy két https oldalon akarod, hogy lefusson miközben engedélyt csak sima http oldalakra kap.
"De egy extensionnél ne kelljen már ilyen trükköket bevetni."
Nem is lehet. Tudtommal az Opera nem támogatja a @require-t.
Legalábbis elvileg ezért nem megy például ez a userJS Operával.
"Ja igen, és az index.html-ben hogy adod meg, ha eltérő a könyvtárstruktúra?"
<!DOCTYPE html>
<html>
<head>
<title>LinkRedirector</title>
<script src="preferences/lang.js" type="text/javascript" charset="utf-8"></script>
<script src="preferences/filter.js" type="text/javascript" charset="utf-8"></script>
<script src="script/filtersetting.js" type="text/javascript" charset="utf-8"></script>
<script src="script/background.js" type="text/javascript" charset="utf-8"></script>
</head>
<body>
</body>
</html>"Az Opera extensionökről szóló leírásai, tutorialjai szart sem érnek a Google Chrome extensionök howto-leírásához képest"
A Chrome leírásait nem ismerem, de alátámaszthatom így is, hogy az Opera dokumentációi a béka segge alatt vannak. És még amik vannak, azok is többnyire third-party oldalakon jelennek meg, lásd: OperaWiki vagy a skinekről szóló dokumentáció.
Viszont legalább már az opera:config-ban van Súgó egy ideje.
[ Szerkesztve ]
-
#614
Sk8erPeter
nagyúr
Penge_4
#613
Sk8erPeter
nagyúr
Akkor sztem ez nálad valami egyedi bug lehet, nálam nem jelentkezik, lépésről lépésre csináltam, amit írtál, és nincs összecsúszás, nézd a screenshotot (félreértés ne essék, ez Opera, csak most pont kipróbáltam a Chrome theme-et
): [link].Szóval nem tudom, mi a para nálad. Ezért nem is értettem, mi ez a heves kritika a részedről a TinyMCE-re, pedig én ilyen durvább hibákat még nem igazán tapasztaltam ennél. Elvileg ezt is folyamatosan javítgatják ráadásul, ilyen jellegű hibákat sztem javítottak volna. Szóval lehet, hogy nálad van a para. De ha ugyanezt portable-lel is sikerül elérni, akkor azt írd már le, hogy csináltad, mert ezek szerint nem egyszerű elérni, hogy ilyen szétcsúszott szar legyen.
"Az ilyen oldalakon gyűlnek össze az 5-10 megás videó minőségű GIF avatarokat használó 38 db userbaros emberek és társai. Miért? Gondolom mert a csicsa lehetősége hívogatja őket."
Talán mert az oldal szerkesztői engedik, hogy szét legyen csicsázva az oldal.
Most hadd ne mondjam megint, hogy ki lehet szedni a gombokat. Plusz ugye szerveroldalon lehet korlátozni a fájlméretet, a hozzászólás hosszát, a benne lévő képek maximális mennyiségét, stb... Az már az oldal alkotóinak felelőssége, hogy ezeket megoldják. Ha tele van csicsázva az oldal, akkor ez nem a WYSIWYG-szerkesztők hibája, hanem azoké, akik fejlesztik az oldalt.===
Extension-téma:
"Én az első kiegészítőmet [...] kb 15 perc alatt elkészítettem"
Hát akkor Te biztos sokkal ügyesebb vagy, mint én.....
Én is készítettem el 15 perc alatt nem túl komplikált feladatokra szánt kiegészítőt, többet is, de most nem az volt a célom, hogy ilyenekkel gizduljak, hanem hogy az ezzel kapcsolatos problémámat megoldjam. A többi gyorsan elkészíthető kiegészítőnél nem állt szándékomban jQuery-t használni, amivel most a legtöbbet szoptam, mivel nem volt hajlandó include-olni, de azt hittem, ez elég egyértelműen kiderült a hozzászólásomból... Szóval nem engem kell hülyének nézni, nem most kezdtem el foglalkozni a JavaScripttel, elhiheted, pár dolgot fejlesztettem már benne. Nem akarok versenyezni veled ebben, nem azért írtam le a problémáimat, tehát nem kell bizonygatnod, hogy márpedig neked egyszerűnek bizonyult a feladat, elhiszem, hogy ügyes vagy. "Én itt elvesztettem a fonalat ott, hogy két https oldalon akarod, hogy lefusson miközben engedélyt csak sima http oldalakra kap."
Jé, csak most látom, hogy a permissions-nél http maradt bent, hát akkor nem vágom, miért működik, de működik. Ha nem hiszed el, küldhetek screenshotot, vagy átküldhetem a Chrome extensiont... "Nem is lehet. Tudtommal az Opera nem támogatja a @require-t."
Ki beszélt itt @require-ről? Ez most hogy jött ide?
Még be is másoltam a kódot, amiről beszéltem... JavaScripttel megkerestem a headert, és oda beszúrtam a jQuery-kódot, amit az egyik Google CDN-ről szedtem. Most ehhez hogy kapcsolódik a @require? Ilyen sehol sincs a kódomban.Ja, bocs, azt nem írtam oda egyértelműen, hogy a könyvtárstruktúránál egész konkrétan arra gondoltam, hogy mondjuk hogy intézed el ilyen módon, hogy include-olva legyen a CSS illetve a JS is, utóbbinál nyilván megint a jQuery-re gondolok. Félreérthető voltam.
Arra tudsz megoldást? Igazából az érdekelne nagyon, hogy ne kelljen már userJS-ből Google CDN-ről (pl.: https://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js) lehúzni a kódot, hanem legyen ott egyből - azt feltételezném legalábbis, hogy gyorsabb betölteni egy helyi fájlt, mint letölteni külső forrásból...Sk8erPeter
-
#615
Penge_4
veterán
Sk8erPeter
#614
Penge_4
veterán
válasz
Sk8erPeter
#614
üzenetére
"Akkor sztem ez nálad valami egyedi bug lehet"
Nem egyedi, Opera Next. Szűz USB-ben is tudtam reprodukálni.
"nem kell bizonygatnod, hogy márpedig neked egyszerűnek bizonyult a feladat, elhiszem, hogy ügyes vagy."
Éppen azt bizonygattam, hogy a megszokás és a problémák eltérő megközelítése miatt van ez, hogy te (aki amúgy sokkal jobban értesz hozzá) hibaként éled meg, ha valami a megszokottól eltérő, míg én (aki kezdetektől fogva ismerem az Operát) sajátosságként.
Például itt az ABC sorrend. Mi akadályoz meg, hogy átnevezd mondjuk _jquery.min.js-re? Vagy 0jquery.min.js-re?
Inkább úgy mondom, mi hátrányod származik belőle? Azok kívül, hogy máshogy szoktad meg?
Valóban vannak problémák (pl a tartalomscriptes bug), de a sajátosságokat ne aposztrofáljuk már hibaként.
Egyébként meg alapból az EventListener szerinti sorrendben futnak le, ha az egyforma, vagy hiányzik akkor él az ABC sorrend.
Az eseménykezelő pedig kicsit fejlettebb:
Ehhez még jön a nemrég implementált BeforeCSS és AfterCSS. Meg van még MagicVariables is.
"Jé, csak most látom, hogy a permissions-nél http maradt bent, hát akkor nem vágom, miért működik, de működik."
Ez a baj. Pedig ez egy elég súlyos bug, tekintve, hogy akár banki adatlopásra is kihasználható azáltal, hogy neked azt írja a böngésző, hogy csak HTTP-n van neki joga működni, közben meg HTTPS-en is röhögve elfut.
Nem lehet, hogy a Chrome hibáival szemben kicsit elnézőbb vagy?
"hogy intézed el ilyen módon, hogy include-olva legyen a CSS illetve a JS is, utóbbinál nyilván megint a jQuery-re gondolok."
Elvileg egy mappában lévő CSS-t akár másik CSS-ből is include-olhatsz ezzel a szabállyal:
/* @import "css_fajl_neve.css"; */
UserJS-ben nem tudom hogyan, de biztos, hogy működik, mivel a 3 db fájlból álló oAutoPagerize is ezen az elven működött, ahol a 0-val kezdődő fájlt nem volt szabad átnevezni, hogy kiegészítőben működik-e azt nem tudom.
Egyébként a @require úgy jön ide, hogy az általam linkelt SG-s userJS nem működik Operával. És valószínűleg ezért nem működik, de ha ránézel a kódra szerintem te egyből látod, hogy miért nem működik.
[ Szerkesztve ]
-
ntomka
nagyúr
Megnéztem, hogy erre válszoltam-e már, de nem. Az előbbi ötlet megoldható, persze lesz vele meló, de mindenképp jó dolognak tartom.
A piros-fekete pontos dolgot meglátom, mert ugye az +1 domain lenne az engedélylistán, ami még nem is nagy dolog, de az egy teljesen más szerkezetű oldal, külön hegesztést igényel.ツ Headphones on - World off
-
#620
Sk8erPeter
nagyúr
Penge_4
#615
Sk8erPeter
nagyúr
"Nem egyedi, Opera Next. Szűz USB-ben is tudtam reprodukálni."
Hmm, ez fura. Mindenesetre nekem még nem sikerült ezt az össze- és szétcsúszós jelenséget produkálni normális szövegszerkesztés közben."Például itt az ABC sorrend. Mi akadályoz meg, hogy átnevezd mondjuk _jquery.min.js-re? Vagy 0jquery.min.js-re?"
Semmi. Csak elég nevetségesnek tűnő megoldás.
Amúgy mondom, a scriptek úgy vannak, hogy egyik a jquery.min.js, másik a Neptun_Theme_Changer.user.js, szóval az N úgyis hátrább van, mint a j. Elvileg nem kéne tehát átnevezni.
Ettől függetlenül valamiért a userJS-ben nem tudom használni a jQuery-szintaktikát, valamiért ReferenceError-t ír. Amikor korábban a sima userJS-sel csináltam a korábban írt createElement-es megoldással (csak a style helyébe script taget írtam, a típus helyére text/javascript-et, plusz a megfelelő elérési utat), akkor teljesen jól működött.
Egyelőre úgy néz ki, vissza kell térnem a userJS-es megoldásra, pedig gondoltam akkor már csinálok hozzá egy fancy popup-ablakocskát, hogy beállítható legyen a script különböző dolgokra (pl. mit tüntessen el, és mit ne).
Ez elég gáz, hogy ennyire nem sikerül működésre bírni, és ennyire nem lehet hozzá megfelelő dokumentációt találni, hogy mi is az oka... Google Chrome kiegészítő-tutorialban a hivatalos forrásban is ott szerepel az első példák közt, hogy jQuery-t hogy lehet egyszerűen include-olni.
A másik meg, amit már említettem, hogy nagyon nem tetszik, hogy ha most a jQuery-t is include-olni akarom, akkor bele kell gányolnom a userJS @include-részét is ahhoz, hogy csak arra az adott oldalra vonatkozzon. Vagy pedig csekkolni a window.location objektum tulajdonságait, hogy épp azon az oldalon vagyok-e, amire szeretném, hogy vonatkozzon. Ez is full gagyi megoldás, de ezt már írtam."Ez a baj. Pedig ez egy elég súlyos bug, tekintve, hogy akár banki adatlopásra is kihasználható azáltal, hogy neked azt írja a böngésző, hogy csak HTTP-n van neki joga működni, közben meg HTTPS-en is röhögve elfut."
Ez tényleg nagyon gáz, és ha nem mondod, komolyan, észre se veszem, hogy a permissions-résznél nem is https van."Nem lehet, hogy a Chrome hibáival szemben kicsit elnézőbb vagy?"
Pont én?
Aki aktívan kritizálom a Chrome-ot? A Chrome topicban pont azért akartak már nekem párszor virtuális taslit adni, mert túl sokat köpködök a Chrome-ra, és túl sokszor hasonlítom össze az Operával, utóbbit hozva ki győztesnek. CSS-részre:
Ennek az @import-nak a gyakorlati hasznát igazából sosem értettem, mert egyrészt régebbi böngészők előfordulhat, hogy nem támogatják, másrészt ha neadjisten keveredik a <link> tag használata az @import-tal, akkor esetleg párhuzamosítási problémák is felmerülhetnek több cikk szerint is (mármint nem tudja párhuzamosan elindítani a fájlok betöltését esetleg), pl. itt egy ilyen cikk: [link].
De jelen esetben mondjuk megadnám én <link> taggel, csak nem tudom, hova, úgy, hogy vonatkozzon is az adott oldalra - pl. injektálja arra az oldalra, amit módosítani szeretnék. És NE minden oldalra, csak a megadottakra - ahogy ugye a Chrome említett manifest.json-jában meg is lehet adni globálisan, mely oldalakra vonatkozzon."Egyébként a @require úgy jön ide, hogy az általam linkelt SG-s userJS nem működik Operával."
Hát belenéztem a kódjába, és tényleg nem vágom, a csávó miért nem azzal a createElement-es, headerhez hozzácsapós módszerrel csinálja, akkor lehet, hogy egyből megoldódna a gondja.Ja, az Operás események nem rosszak, pl. az AfterCSS-t használtam is a userJS-nél, azt is meg tudtam csinálni, hogy a Neptunos oldalon mondjuk a harmadik CSS-fájl utáni részre injektálom a saját CSS-fájlomat.
A MagicVariables gyakorlati hasznának még nem néztem utána, egyelőre nem tudom, mire tudom majd használni.Sk8erPeter
-
#621
Sk8erPeter
nagyúr
ntomka
#617
Sk8erPeter
nagyúr
"Megnéztem, hogy erre válszoltam-e már, de nem."
A miénkre sem!
Bár tudom, hogy utálsz már minket, mint a sz@rt, hogy itt jártatjuk a szánkat a kiegészítőkről a Te topicodban...Te próbáltad már a jQuery használatát Operánál saját kiegészítőben?
Tényleg érdekelne.Sk8erPeter
-
#622
ntomka
nagyúr
Sk8erPeter
#621
ntomka
nagyúr
válasz
Sk8erPeter
#621
üzenetére
Valóban nem, de nem is fogok. Nem akarom ragozni a nyilvánvalót. Ez a téma meg valóban a kiegészítőmről kéne szóljon, nem arról melyik a legjobbabb böngésző. Én megpróbáltam az operára átírni, több ponton hibádzik valami, vagy épp hiányzik. Emiatt nem minősítettem le magát az egész böngészőt, csak a fejlesztői részét, ami akár idővel még fordulhat is az opera javára. És megnyugtatásul: nem, nem utállak titeket. Ti azt szeretitek és használjátok, azt véditek. Én meg a chrome mellett tettem le a voksom, ez győzött meg. Ízlések és pofonok. És csak ismételni tudom magam: ha kedvet kap valaki, ne tartsa magát vissza, a kapu nyitott más böngészőre való portolásban, szívesen segítek benne ahogy tudok. Különben meg panaszkodni máshol is lehet.
jQuery-t nem próbáltam a kiegészítőmben, mert amikor elkezdtem akkor csak a mootools volt terítéken nálam. De most is, hogy már azt is ismerem és munkahelyen használnom is kell, ugyanígy ezt választanám. Egyáltalán nem minősítem le a jQuery-t, mert remek eszköz, csak számomra szimpatikusabb a mootools. Annyit sajnálok benne, hogy a jQuery-t jobban tolják, emiatt lassa(bba)n fejlődik az előbbi. De a különbségekről egy szerintem objektív és nagyon jó szösszenet itt olvasható.
[ Szerkesztve ]
ツ Headphones on - World off
-
#623
Sk8erPeter
nagyúr
ntomka
#622
Sk8erPeter
nagyúr
Na, de én az előbbi kommentekben pont nem magasztaltam az Operát, hanem hozzád hasonlóan szidtam a fejlesztőeszköz baromságai miatt.
Amikkel sajnos most már tökéletesen egyet kell értenem (bár a konzolos kitakarós problémát még mindig nem értem, az sztem full ugyanolyan mindkét böngészőben, a háttérszínt leszámítva). Dragonfly-nál amúgy az is zavar, hogy ha meg van nyitva egy oldal, és úgy döntök, megnézem a konzolra kiírt dolgokat, akkor előhozván a Dragonfly-t ezek nem jelennek meg egyből, mint Chrome-nál, hanem újra kell tölteni az oldalt.Nem akarom összehasonlítani a jQuery-t és MooTools-t, hogy melyik a jobb, ha neked utóbbi a kényelmes, akkor az is legalább olyan jó, ha Dojo-t használnál, az is rendben lenne.
Viszont akkor már ezzel kapcsolatban kérdezek: a MooTools-t is include-olni kell a jQuery-hez hasonlóan, olyat nem csináltál még, amilyet én szeretnék, hogy mondjuk a MooTools-os szintaktikával módosítod az adott oldalt úgy, hogy injektálod az oldalba a szkriptet?
Vagy egy olyasmit, amit én csinálok, Te hogy csinálnál Opera alatt MooTools-szal, hogy a látható oldal egyes elemeit módosítgatod?Majd amúgy az összehasonlító cikket elolvasom, csak nagyon hosszú, most nincs rá időm, de thx.
Sk8erPeter
-
#624
ntomka
nagyúr
Sk8erPeter
#623
ntomka
nagyúr
válasz
Sk8erPeter
#623
üzenetére
Akkor koncentrálj az általad és az általam linkelt képre erősen. Leginkább a konzol környékén.
"Dragonfly-nál amúgy az is zavar, hogy ha meg van nyitva egy oldal, és úgy döntök, megnézem a konzolra kiírt dolgokat, akkor előhozván a Dragonfly-t ezek nem jelennek meg egyből, mint Chrome-nál, hanem újra kell tölteni az oldalt."
Talán ez lenne a legkisebb baj, de egy ritka, nehezen reprodukálható hibánál valóban kellemetlen. Melóban sok ilyennel találkozom firefox alatt is, mert ugye ott nincs is olyan, hogy fejlesztőeszköz, csak egy kiegészítő, aminek természetéből fakadóan újra kell tölteni az oldalt, hogy működjön az ilyesmi.
"Viszont akkor már ezzel kapcsolatban kérdezek: a MooTools-t is include-olni kell a jQuery-hez hasonlóan, olyat nem csináltál még, amilyet én szeretnék, hogy mondjuk a MooTools-os szintaktikával módosítod az adott oldalt úgy, hogy injektálod az oldalba a szkriptet?
Vagy egy olyasmit, amit én csinálok, Te hogy csinálnál Opera alatt MooTools-szal, hogy a látható oldal egyes elemeit módosítgatod?"Nem igazán értem mi a kérdés. Ha egy adott oldalon használni akarsz valami JS keretrendszert, akkor mindenképp injektálnod kell az oldalba (hacsak alapból nem tartalmazza már), mert a böngészőbeli JS hatáskörkezelésének teteje a window objektum. Legalábbis nagyjából. Tehát ebben a hatáskörben kell működnie a dolognak.
ツ Headphones on - World off
-
#625
Sk8erPeter
nagyúr
ntomka
#624
Sk8erPeter
nagyúr
Most nekem egyetlen különbség tűnik fel a két konzol közt, a lefutott JS-kódok eredményeként kapott objektumoknál, amik a Chrome esetén helyben lenyithatóak, kapásból konzolon megnézhetők. Ami hatalmas előny a Chrome-nál. Arra gondoltál?
Félreértés ne essék, ha nem derült ki a hsz.-eimből, hangsúlyozom, hogy teljes mértékben belátom, immár tapasztalatból is, hogy a Chrome sokkal előrébb jár a fejlesztőeszköz fejlettségében. Mondjuk az valóban elég furcsa/gáz, ami Penge_4-nek feltűnt, hogy a kieg manifest.json-jában a "permissions" résznél csak http-t adtam meg, de engedélyt kapott a kiegészítő https-kapcsolatra is..."Nem igazán értem mi a kérdés. Ha egy adott oldalon használni akarsz valami JS keretrendszert, akkor mindenképp injektálnod kell az oldalba"
Igen, pontosan ez volt a kérdés, hogy Te ilyen feladatnál HOGYAN (milyen kód segítségével) injektálod az Opera-kiegészítő esetén a scriptet, akár a MooTools-t, akár a jQuery-t, az most a lényeg szempontjából mindegy, melyik.
A hatáskörökkel többnyire tisztában vagyok, nem arról érdeklődtem.
Szóval mondjuk vegyünk egy oldalt, aminek Te Opera esetén módosítani szeretnéd a kinézetét, ezért injektálni szeretnéd mondjuk a MooTools-t, mert annak a szintaktikájával szeretnéd manipulálni az oldalt.
Ennél is ugyanúgy pl. ott a $ használata is, amire nálam ReferenceErrort dobott a jQuery-nél, hiába volt az includes könyvtárban a megfelelő sorrendben a jQuery, és utána a userJS-fájlom.Opera-userJS esetén korábban így csináltam az injektálást még az oldal betöltése közben a header részbe, nem is vártam meg a DOMContentLoaded eseményt sem (ami előbb van, mint a load esemény) - annál korábban beillesztve is ment -, ha most belepasszírozom egy függvénybe, így néz ki a kód:
function append_script_tag(source) {
var headID = document.getElementsByTagName("head")[0];
var newScript = document.createElement('script');
newScript.type = 'text/javascript';
newScript.src = source;
headID.appendChild(newScript);
}Na, ezt a bohóckodást akartam elkerülni az Opera kiegészítőjénél.
Van erre mód valahogy a kiegészítő konfigurálásánál? Chrome-nál ugye egyből a manifest.json-ban meg lehet adni, milyen scripteket szeretnél használni, meg ott azt is megadhatod, mikor töltődjön be (document_start, document_end, document_idle), de mondjuk ezt Te is vágod, használod is a kiegészítődben.Sk8erPeter
-
#626
ntomka
nagyúr
Sk8erPeter
#625
ntomka
nagyúr
válasz
Sk8erPeter
#625
üzenetére
Bár ha tényleg használod mindkettőt, akkor ezeknek a különbségeknek ordítania kéne, mert az opera megoldása "enyhén" kényelmetlen, Még a firebugban is sokkal okosabb, annak ellenére, hogy azt nem tekintem igazi fejlesztőeszköznek.
"Mondjuk az valóban elég furcsa/gáz, ami Penge_4-nek feltűnt, hogy a kieg manifest.json-jában a "permissions" résznél csak http-t adtam meg, de engedélyt kapott a kiegészítő https-kapcsolatra is..."
Mondjuk én ezt nem figyeltem egyszer sem. De ez nyilván bug lesz, ha így van. "Fogjátok is jelenteni, vagy csak leírjátok nekem?"
Scriptek: ha egy dom objektumot akarsz módosítani, akkor mindenképp célszerű domready-t (mootools) használni. Ez operában ha jól emlékszem fejből a DOMContentLoaded esemény volt. A keretrendszerek prototípusokon keresztül dolgoznak, ami nyilván ha a script már feldolgozódott, akkor érvényesnek kéne lennie. De ugye egy böngésző adatfeldolgozása minden, csak nem lineáris, annak ellenére, hogy még régen az volt. Ma meg már gyorsítási technikák miatt össze vissza csinálnak mindent, ezért kell fixen eseményekre támaszkodni. A JS amúgy is eseményvezérelt nyelv, erősen használja őket.
Az én scriptjeim is a kiegészítőben mindenhol megvárják a domready eseményt, ezért is végzem pl. a logout középre igazítást css-ben, mert azon kívül, hogy a leggazdaságosabb, egy sor kellemetlen mellékhatást is elkerülök.ツ Headphones on - World off
-
#627
Sk8erPeter
nagyúr
ntomka
#626
Sk8erPeter
nagyúr
Ja, így már értem a konzolos parát, de ez számomra azért nem volt olyan zavaró, mert át is lehet méretezni, meg Escape-pel gyorsan ki lehet lépni a konzolból, ill. vissza. De igazad van, ez is lehetne értelmesebben megoldva.
Tulajdonképpen valóban át kellett méretezgetni néha, de nem ordított a hiba.A Chrome-bugot megpróbálom jelenteni.
Tudok a DOMContentLoaded eseményről, eddig is ezt használtam. Ehhez kötve próbáltam használni a jQuery-t, mivel addigra, mire ez az esemény bekövetkezik, addigra a jQuery-t már rég injektáltam a header-részbe. DE továbbra sem működik.
Amikor simán userJS-ként használtam Operában, akkor látta, jó volt, működött, extension-formában egyszerűen képtelen vagyok működésre bírni, érthetetlen számomra.
Ez hogy van, hogy látszik is a hálózat fülről leolvasva, hogy elsők között csapja hozzá a header-részhez a jQuery-t, amit a createElement-es megoldással rakok oda, és nyilván ez a DOMContentLoaded esemény előtt következik be, mégsem tudom az adott oldalon használni, ha sima JS-szintaktikával mégis megy?Ja, még egy, az közös a kódban ilyen szempontból, hogy Chrome-nál is a DOMContentLoaded-hoz van kötve, hogy fusson le adott függvény. Egyszerűségi szempontból, bár elvileg a document_end is erre reagál. De így közös maradhatott a kód, nem kellett külön manipulálni, és Chrome-ban tökéletesen az elvártak szerint működik a kiegészítőm.
Amúgy az az index.html-es megoldás, ahol át lehet variálni elvileg a könyvtárstruktúrát meg ilyesmit Penge szerint, igazából az injektálás szempontjából nem ér semmit, mert így csak a widget scope-jáig lát el, az oldalt magát ilyen módon nem lehet módosítani.
Most tulajdonképpen az oldal melyik részére injektálja ilyenkor a scriptet, ha azt teszi egyáltalán Operánál, ha mégsem tudom használni a jQuery-t, miközben az elvileg az oldal része?
Sőt, már úgy is megpróbáltam, hogy magába a userJS-fájlba is bemásoltam a jQuery egész tartalmát, mindenféle helyre, úgy sem ment, ami számomra érthetetlen... Mivel Chrome-nál elvileg ehhez hasonló scope-ban van, ott mégis megy.Tehát se a bemásolós, se a createElement-es headerhez csapós megoldással nem tudom használni a jQuery-t az oldal manipulálására Opera-kiegészítő esetén.
Erre irányult igazából a kérdésem, hogy ezt Te hogyan oldanád meg Operánál. Na meg hogy Te próbáltad-e már pl. a MooTools-t hasonló célokra használni (adott oldalon megjelenő elemeket a MooTools szintaktikájával módosítani, nem sima JS-tel), mert annak a könyvtárát is include-olni kell.
[ Szerkesztve ]
Sk8erPeter
-
#628
Sk8erPeter
nagyúr
Sk8erPeter
#627
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#627
üzenetére
Egyelőre szinte hihetetlen, de úgy tűnik, megvan a megoldás.
Opera esetén a kiegészítőben hozzá kell adni ezt a sort:
var $ = window.jQuery;
VAGY
var $ = window.$;Tegnap elgondolkodtam, belenéztem a jQuery forráskódjába, és akkor jutott eszembe, hogy hátha csak ennyi a megoldás...
Ennek mi az oka, hogy ezt csak Opera-kiegészítőnél kell megjátszani, egyébként sosem?
Azért nem világos, mert elvileg így is a window objektum scope-jában vagyunk, ahogy ilyen alapon a window-t az alert elé sem kell kitenni:
window.alert("Hello world!");
HELYETT elég
alert("Hello world!");Azért egy jópár órát elcsesztem ezzel, kár, hogy korábban nem gondoltam erre.
De vajon ez miért van itt így? Chrome-nál sem kell kitenni, na meg normál használat esetén még Operánál sem, amikor egy honlapra beteszem a jQuery-t include-oló script tag után a dollárjellel ($) kezdődő kódot - ott sem írom oda explicite, hogy a window objektum jQuery-jét használja...
Ötlet?Sk8erPeter
-
#629
montyx
aktív tag
Sk8erPeter
#628
montyx
aktív tag
válasz
Sk8erPeter
#628
üzenetére
Ha van időd és kedved, írhatnál egy ilyen appot androidra is. Sokat tanulhatnánk belőle, és sokan használnák is! Legfőképpen én!
Amúgy pedig a chrome verzióért örök hála!Aláírás
-
#631
montyx
aktív tag
Sk8erPeter
#630
montyx
aktív tag
válasz
Sk8erPeter
#630
üzenetére
Oups, akkor eztet beneztem!
Azert k0ff ntomka, meg neked is a hasznos infokert Sk8erPeterAláírás
-
#633
ntomka
nagyúr
Sk8erPeter
#632
ntomka
nagyúr
válasz
Sk8erPeter
#632
üzenetére
És tényleg, még a sörös smiley is.
(#629) montyx: Android: ebben biztos vagyok, csak ne lenne olyan fragmentált a platform...
(#628) Sk8erPeter: Ez jó kérdés, komolyan. De amúgy igen, használom a mootoolst elég sokat, de a kiegészítőm is arra alapul. Elég nehéz is lett volna az életem nélküle.
Ez amit írtál, csak úgy lenne lehetséges, ha más hatáskörben definiálódna a jQuery, vagy Opera bug, és akkor nyilván nem itt lesz a megoldás. [ Szerkesztve ]
ツ Headphones on - World off
-
#634
ComóiVaranus
csendes tag
ComóiVaranus
csendes tag
Sziasztok!
Kéne írni egy programot ami kezel több mint 50+ kedvencek elemet (jelenleg 50 a limit).
És lekérdező is lenne benne ami jelez ha válaszoltak neked, illetve hány új hozzászólás érkezett.
Lehetne benne WYSIWYG editor.
Automata kép átméretező 550pixelre
Kiírja az új nyitott témákat.
stb.
Vagy létezik ilyen?
Ha nem, akkor írni kellene.
Írjatok ötleteket, hogy mit lenne hasznos még tudnia. -
#635
fatal`
titán
ComóiVaranus
#634
fatal`
titán
válasz
ComóiVaranus
#634
üzenetére
Miért ide írod?
Ez a Chromeos PH kieg topicja, kezel több, mint 50 kedvencet.
Isten ments a WYSIWYG editortól..
A többit pedig ide írd.
[ Szerkesztve ]
-
#636
Sk8erPeter
nagyúr
ComóiVaranus
#634
Sk8erPeter
nagyúr
válasz
ComóiVaranus
#634
üzenetére
"írni kellene"?
Hát akkor hajrá! Kimegyek a fazonomból az ilyen "kérésektől"... Ha ötletekkel akartál szolgálni a kiegészítőhöz, ntomka-nak címezve, aki szabadidejében foglalatoskodik ezzel, akkor talán olyan stílusban is fogalmazz, ne követelőzz.
ja, és mi a francnak kéne "Automata kép átméretező 550pixelre"?
Miért pont 550px? "illetve hány új hozzászólás érkezett."
És szerinted ez a kieg. mégis mit csinál?Mondjuk látom, tegnap regisztráltál, akkor nem csoda, hogy nem tanultad még meg a PH!-s netikettet...
[ Szerkesztve ]
Sk8erPeter
-
#637
fatal`
titán
Sk8erPeter
#636
fatal`
titán
-
#638
Sk8erPeter
nagyúr
ntomka
#633
Sk8erPeter
nagyúr
Hát nagyon kíváncsi lennék az okára!
Amúgy onnan jutott eszembe ez a megoldás, hogy Opera Dragonfly-ban kipróbáltam, hogy a sima $-jelre konzolba beírva ReferenceError-t írt betöltés után, window.$-ra pedig nem, úgy működött. Belenéztem a jQuery kódjába, ott pedig ez látható, kiemelve a lényeget:(function( window, undefined ) {
............
var jQuery = (function() {// Define a local copy of jQuery
var jQuery = function( selector, context ) {
// The jQuery object is actually just the init constructor 'enhanced'
return new jQuery.fn.init( selector, context, rootjQuery );
},// Map over jQuery in case of overwrite
_jQuery = window.jQuery,// Map over the $ in case of overwrite
_$ = window.$,.............
// Expose jQuery to the global object
return jQuery;})();
......................
window.jQuery = window.$ = jQuery;
})(window);Az utóbbi sorrol jutott eszembe főként, hogy beletegyem a korábban említett sort:
var $ = window.$;
vagy
var jQuery = window.jQuery;
ekkor láss csodát, működött.Tényleg nem értem igazából, erre miért csak Operában van szükség (külön kiírni a window objektumot is elé).
Igazából azt sem vágom, kinek kellene írni ez ügyben, hogy kiderüljön az igazság, mert abból is sokat lehetne tanulni. Vélhetően ez egyelőre csak Opera-kiegészítő fejlesztése közben jön elő, legalábbis én még máshol nem találkoztam ezzel.[ Szerkesztve ]
Sk8erPeter
-
#639
Penge_4
veterán
Sk8erPeter
#636
Penge_4
veterán
válasz
Sk8erPeter
#636
üzenetére
"Miért pont 550px?"
Gondolom annyi a szövegdoboz mérete leszámítva az avatarnak fenntartott részt. Tehát ha nagyobb képet szúrsz be, megjelenik a vízszintes görgetősáv. Kivéve Operában, ott van Illeszkedés funkció.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Amúgy azért nem lenne jó, mert ez egyfajta IQ teszt is egyben. Ha az alsó dobozt használod képfeltöltésre, akkor automatikusan készít thumbnailt, ami kisebb is, mint ha ugyanazt a képet méretezed le (tehát például a "Milyen a desktopod?" és hasonló topicokban nem töltődik be 50-100 megányi veszteségmentes PNG kép leméretezve).
Ha meg külső tárhelyről szúrsz be... Külső tárhelyről inkább ne nagyon szúrjon be senki sehova, csak linkeljen, mert csak a gond van vele. Jobb esetben fél év, egy év múlva, rosszabb esetben másnap meg is fekszik a szerver és határozatlan időre csak egy "hamarosan visszatérünk" típusú képet kapsz az eredeti helyett.
-
#640
Sk8erPeter
nagyúr
Penge_4
#639
Sk8erPeter
nagyúr
Most néztem meg developer tools-szal, a textarea mérete itt begépelésnél 544px (külső div-vel együtt 602px, de az itt most nem számít), a fórumban a szöveget tartalmazó rész pedig (class="text") 469px, tehát sehogy sem stimmel.
Mindegy is, az eredeti komment amúgy is egy vicc, biztos emiatt regelt, hogy kiossza itt a feladatokat, megmondja a frankót, ki mit csináljon.A külső képfeltöltő szarságoknál a kepfeltoltes.hu-t gyűlölöm, de nagyon, ott már pár hónap után b@szhatod a képeidet. De asszem erről már beszéltünk korábban. Amúgy ja, ne akarjon beszúrogatni senki külső képeket. A Logout-os cikkekbe sem értem, egyesek mi a büdös francnak erőltetnek be külső helyről származó képeket, amikor fel lehet tölteni ide is, és akkor az ráadásul egyből elérhető (ha a PH! is), nem fordul elő olyan eset, hogy egyszerűen nem tölt be, mert esetleg a külső szerver épp meghalt, eltűnt a kép, stb.
Sk8erPeter
-
#641
ComóiVaranus
csendes tag
Sk8erPeter
#636
ComóiVaranus
csendes tag
válasz
Sk8erPeter
#636
üzenetére
higgadalom, ide irányítottak
nem ntomka-nak címeztem, hanem mindenkinek akinek fontos hogy normálisan használható portált kapjunk
550 pixel az ajánlott képméret, olvass utána ha ezt nem tudod, le van írva"Hát akkor hajrá!"
ha nem találok társakat akkor megírom magam, ezért nem kell a fejedet a falba ütni"nem tanultad még meg a PH!-s netikettet"
kérlek nézz magadba -
#642
Sk8erPeter
nagyúr
ComóiVaranus
#641
Sk8erPeter
nagyúr
válasz
ComóiVaranus
#641
üzenetére
Ja, majd pont egy 3 napja regisztrált újonc fog kioktatni a PH!-s netikettről...
Sk8erPeter
-
#643
ntomka
nagyúr
ComóiVaranus
#641
ntomka
nagyúr
válasz
ComóiVaranus
#641
üzenetére
Ha nem nekem címezted, akkor szerintem eltévedtél a téma jellegét tekintve.
(#638) Sk8erPeter: Nekem ebből nagyon úgy tűnik, hogy a window objektumon definiált változónevek nem kerülnek be a globális hatókörbe, ahogy azt kéne. Esetleg azt tudom még elképzelni, hogy az adott tartalom amin nézed egy iframe-ben van. Ott szoktak érdekes dolgok történni JS-nél, ezért sem ajánlot iframe-et használni túl sok mindenre manapság.
[ Szerkesztve ]
ツ Headphones on - World off
-
#648
Sk8erPeter
nagyúr
ntomka
#643
Sk8erPeter
nagyúr
Hali!
Konkrétan ezt az oldalt módosítgatom: [BME Neptun].
Itt nincs iframe, amúgy magamtól meg eszem ágába nem jutna iframe-ekkel szopatni magamat.
Azt viszont tényleg nem tudom, kinek kellene írni ezzel kapcsolatosan, vajon Operánál megér-e ez egy hibajelentést - igazából úgy sejtem, náluk kellene a hibát keresni, mert máshol külön nincs szükség ilyen lépésekre. Nagyon furcsa.
Bár lenne valaki, aki ezeket a hibákat meg tudná magyarázni... Lehet, hogy még Operánál sem értenék. Sk8erPeter
-
#649
ntomka
nagyúr
Sk8erPeter
#648
ntomka
nagyúr
válasz
Sk8erPeter
#648
üzenetére
https oldal, ez nem okozhat valami problémát operánál? Az a böngésző elég allergiás a biztonsági előírások be nem tartására.
ツ Headphones on - World off
De egy kiegészítő fejlesztésének menete szerintem sokakat érdekelhet, de nem biztos, hogy épp a Chrome topicban van az érdeklődök nagy része. 
De veled ellentétben én ezt nem vettem magamra! 
), hogy az Opera nem gyengén tett hozzá a manapság szinte minden böngészőben megjelenő szolgáltatásokhoz, funkciókhoz, kezdve egészen a többfüles böngészéstől (hadd ne soroljam tovább). Persze ez nem változtat azon, hogy ellúzerkedték az asztali piaci szereplésüket és térnyerésüket, melyet nagyon jól jellemez a nevetségesen alacsony részesedésük.
Ezt most tényleg nem vágom.
Chrome-nál egyetlen helyen megadom, és kész. Tök logikus.
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
lo Hirtelen felindulásból született Google Chrome kiegészítő a Prohardver! lapcsaládhoz
- Microsoft Surface Pro 6 12.3" 2736 x 1824/i5 8350u/
- Legjobb ÁR!!!HP EliteBook 640 G9 Ezüst (14" / Intel i5-1235U / 16GB / 512GB SSD / Win 11 Pro)
- HP Probook 340S G7 i5-1035G1/8GB/256SSD/Windows 11
- MSI MAG274QRF-QD QLED Gamer Monitor!27"/2k/165hz/1ms/Freesync-Gsync/Type C/Konzolhoz is/Beszámítás!
- Sennheiser Epos H3 White Gamer Fejhallgató Eladó!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs