- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Meggyi001: Anya, tudsz segíteni a matekban?....Nem érek rá kisfiam, majd segít a ChatGPT...
- bitpork: Phautós tali a Balcsinál 2025 Augusztus 2 napján (szombat)
- gban: Ingyen kellene, de tegnapra
- Szoszo94: Xiaomi Mi Router 3G - Padavanra fel!
- Parci: Milyen mosógépet vegyek?
- Gurulunk, WAZE?!
- Ndruu: Segíts kereshetővé tenni a PH-s arcképeket!
- sziku69: Szólánc.
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
Új hozzászólás Aktív témák
-
#659
Sk8erPeter
nagyúr
Penge_4
#658
Sk8erPeter
nagyúr
"We will also add inline expandable objects in a future build of 1.1."
Érdekes, hogy ez még mindig a jövő zenéje...
Tulajdonképpen ez volt az egyik, amit ntomka hiányolt. Amúgy nekem is szúrja a szemem, hogy ez még mindig nincs implementálva.
Most hirtelen a cookie-s problémán (ami már azóta megoldódott, mint linkelted is) kívül nem ugrik be, hogy még mi volt a para.
-
#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.
![;]](//cdn.rios.hu/dl/s/v1.gif)
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.
-
#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. -
#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... -
#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. -
#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. -
#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]) -
#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. -
ntomka
nagyúr
Ez minden oldalra beszúr egy JS-t és az az adott oldalon feldob egy div-et. Ergo ha nincs a böngésző előtérben, akkor nem is látod.
Ha leszeded a mostani verziót és kicsomagolod, akkor láthatod hol tartok vele.
A tartalom scriptek továbbra sem futnak le. Persze lehet én csinálok valamit rosszul, sőt, biztos. Amíg nem jövök rá mi a probléma, addig nem tudok továbbhaladni. -
ntomka
nagyúr
hunfatal már linkelte: [link]
És a fészbúk milyen sütikhez férne hozzá? Ahhoz neki is haza kéne küldenie az adott sütit. Különben nem a normál böngészős megoldás megy, ahogy írtam: az adott szervernek csak az ahhoz tartozó sütiket küldi el.
Ennek a gyorsindítós dolognak még mindig nem értem mi a lényege. Miért jobb ez annál, hogy non-stop ott figyel az ikon az eszköztáron amire ki van írva az új hozzászólások és üzenetek száma? Aztán ha kíváncsi vagy egy témára amiben érkezett hozzászólás, innen egyből megnyithatod, már ha tényleg érdekel. Inkább van értelme annak, amit már többen kértek, hogy legyen arra ikon, hogy olvasottnak megjelölheted, témában olvasatlannak, ilyesmi.
(#520) Penge_4:
"Persze ha ntomka nem akar nyerni Galaxy Tabot..."
"De tudod nagyon jól, hogy az ilyen csilivili szarokat imádják függetlenül attól, hogy mekkora a gyakorlati haszna. "
Na ez a kiegészítő pont nem erről szól.
-
ntomka
nagyúr
Ebből eskü nemtom mit szeretnél, hogy kihozzak.
Egyébként nemhogy a süti problémát oldanák meg, az sokkal fontosabb funkció lenne a kiegészítőkhöz.(#514) Penge_4: Nem lehet. Mármint egy kiegészítőnek amúgy sem kell feltétlenül hozzáférnie egy oldal sütijéhez. Egyszerűen kéréskor küldje el a már meglévő sütiket az adott domainre. A chromeon is így működik. Ha be vagy jelentkezve, akkor a munkamenet süti automatikusan csatolódik a kéréshez. Olyat én nem fogok implementálni, hogy XY adja meg a felhasználónevét, jelszavát. Kicsit lenne gázos. Különben is, abban megbíznál, hogy bekérem a jelszavad, de abban nem, hogy egy ártalmatlan munkamenet sütit dobjon hozzá a fejléchez a böngésző, és ehhez nekem hozzá sem kell férnem, teljesen automatikus?
(#517) hunfatal: Hát abban nem látom mi jó. Felveszel 10 topicot, aztán a compiz területnagyítójával sem fogod tudni kiolvasni.
-
fatal`
titán
Részemről inkább a popupra szavazok.
Az akkor is látszik, ha épp másik oldalt olvasok. Vagy is-is, esetleg állítható legyen. Majd ntomka eldönti, hogy mennyit van kedve szarolni vele. Egyelőre semmilyen sincs mert a cookie nem működik, ha jól tudom és így nem lehet ellenőrizni a hozzászólásokat.
-
#488
Sk8erPeter
nagyúr
Penge_4
#483
Sk8erPeter
nagyúr
Jaaa, értem már, nem fogtam fel, köszi.
(#482) ntomka : egyáltalán nem kezellek trollként, sőt! Ha mégis így tűnt a hsz.-eimből, akkor bocsánat, nem akartalak megsérteni.
Előbb felfogtam volna, ha tényleg fejlesztettem volna már Operára kiegészítőt rendesen. Szóval sorry, ezt nem vágtam, amit Penge végül elmondott. 
-
ntomka
nagyúr
Tab Stacking? Ilyen funkcióval nem találkoztam Chrome alatt (béta csatorna).
A kiegészítő szinkronizáció jelen formájában annyit tesz, hogy a különböző gépek/böngészők között a telepített kiegészítőket szinkronizálja, azaz a másik gépen is feltelepíti azt, amit az egyiken feltelepítettél, illetve törlésnél ugyanezt csinálja. Kb. fél éve folyamatosan dolgoznak azon, hogy a kiegészítők bizonyos adatokat ugyanilyen módon szinkronizálhassanak, de ugye ez nem olyan egyszerű, mint ahogy te gondolod, hogy copy-paste egy másik böngészőből. Megcsinálhatták volna egyszerűen azt, hogy minden egyes kapcsolódó adat a változásoknál szinkronizálódik, csak ezzel az a baj, hogy vannak kiegészítők, amik folyamatosan írnak a maguk kis localStorage-ükbe. Mondanom sem kell, hogy ez mekkora adatforgalmat generálna, így az alapkoncepció már az volt, hogy mindenképp valami jól átgondolt API-t kell hozzá felépíteni, ahol szabályozottan bizonyos adatokat szinkronizálhatnak a kiegészítők, és ezeket is a fejlesztőnek kell meghatározni, hogy mik legyenek. Ez nem egyszerű feladat megvalósítani, de ha minden igaz, akkor már az implementáción dolgoznak. Egyébként igaz, ez a Chrome OS-nél is elengedhetetlen lenne, de mivel ott már rengeteget csúsztak a megjelenéssel, gondolom fix ütemtervet fektethettek le, amiben ez a funkció ki tudja hol szerepel.
-
#373
Sk8erPeter
nagyúr
Penge_4
#368
Sk8erPeter
nagyúr
Félreértés ne essék, nem tisztem védeni a Java-t, és nekem is számtalan programmal voltak igen erős problémáim, amik Java-ban íródtak...
De azért lehet találni jó szoftvert is, ami most a büdös francért sem jut eszembe, milyen jó progit használtam már. Egyébként Java VM miatt tényleg többnyire lassúak ezek a progik. Meg valahogy azt is megfigyeltem, hogy a Java-ban íródott progik nagy részénél gányolás történik. Tehát a hibák nagy része a programozó figyelmetlenségéből is eredhet, nem feltétlenül a Java hülyeségei miatt.
Mostanában C#-ot használom, ami most sokkal jobban tetszik, mint a Java, pedig eléggé hasonló, kár, hogy az nem platformfüggetlen, bár vannak rá próbálkozások a Mono projecttel, de az nem teljeskörű. Viszont a .NET-nél szinte mindent a programozó segge alá tolnak."Miért van az, hogy a JavaScripthez értő emberek, akik ismerik is az Operát, mind el vannak foglalva és soha nincs idejük semmire?"
Hát bocs már, hogy most épp nincsenek felesleges napjaim esetleges bugok okait keresgélni, kiismerni az Operához való extension-fejlesztés mikéntjét, félév elején még talán lett volna időm rá, de most nem igazán, elég szopás van így is. Hogy mások miért nem érnek rá, azt nem tudom, de gondolom nekik is van elég dolguk. Viszont ha ennyire zavar, és neked viszont időd is lenne rá, akkor javaslom, kezdd el tanulni a JavaScriptet, én is magamtól tanultam meg ehhez mindent, szóval neked sem mentség, hogy egyelőre nem értesz hozzá eléggé. (#366) ntomka: hát szerintem nekem max. félév vége felé lesz időm ezzel foglalkozni, addig sajnos nem valószínű.
-
ntomka
nagyúr
"Lassan odáig jutnak sebességben..."
Könnyen lehet.
Ideje lenne már a funkcionalitásra is rágyúrni." a chrome kezdetű függvényneveknek mi a megfelelője a többi böngészőben? "
Hát ebben mondjuk pont nem, mert én is úgy csinálnám, hogy megnézném mit használok az egyikben és megkeresném a megfelelőjét a másikban. Egyiknek sincs szerencséje túl nagy API-ja még, szóval sokat nem kell olvasni a dokumentációt.
"Az XSS csak userJS-eknél volt probléma, kiegészítőknél elvileg a config.xml-ben kell megadni access origin-ben a PH lapcsalád oldalait és működnie kell(ene), legalábbis a hibakonzol kiírna valami erre vonatkozót."
Mondjuk ezt pont nem tudom mire gondolsz, mert ha ennyire belemélyedtél, biztos láttad, hogy a mootoolst is berántottam és az AJAX-os dolgokat is ezen keresztül intézem el. XSS nincs, mert a külön meg kell adnom az engedélyt az oldalhoz való hozzáférésre az adott szervereken, amit a felhasználótól is megkérdez településkor, ezután viszont normál AJAX kérésként futnak a dolgok a szerver felé. Persze a domaint ekkor is meg kell adnom a kódban, de ha más szerverre hivatkozok, akkor pont az XSS elkerülése miatt egyszerűen JS error-t dob a böngésző.
-
-
ntomka
nagyúr
Te figyeled ezt a topicot?
Majd meglátjuk az Opera meddig bírja átfésülni az összes kiegészítőt, amit feltöltenek hozzájuk. A hivatalos magyarázat a googlenál is az volt anno, hogy túl sok spammer van, ők meg nem pazarolnak erőforrásokat minden egyes felkerülő kieg vizsgálatára (a mozilla sem győzi). Ez érthető is ha tényleg így van, és ha belegondolsz, azért az az 5 dodó nem nagyon összeg, tehát nem ezen fog meggazdagodni a google, főleg, hogy egy accounthoz csak egyszer kell fizetni, utána bármennyit tölthetsz. Ahogy írtam, ez nálam elvi megfontolás volt, és a source ettől még mindenkinél open. Ha holnap bejelentenék, hogy az Ubuntuért és változataiért 5 dodót kell fizetnem kiadásonként, megtenném, mert szeretem és használom, és attól még az ő kiadásaik is open source maradnak, mert gnu (l)gpl alatt letölthetem minden komponensét az oprendszernek.
-
ntomka
nagyúr
Ha az én kiegészítőmről van szó, akkor az nincs kategória, hiszen én csak Chromera fejlesztettem le.
(#226) Penge_4: Nem volt időm vele foglalkozni egyáltalán, még a Chrome verzióval sem.
(#229) föccer: Na de várj, hogy kapsz arról a témáról értesítőt, amit nem vettél fel (ha jól értem, mert azt írod alapból be volt kapcsolva, de lehet én nem értem jól amit mondasz).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
): 
Ez most hogy jött ide?
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 tartalom scriptek továbbra sem futnak le. Persze lehet én csinálok valamit rosszul, sőt, biztos. Amíg nem jövök rá mi a probléma, addig nem tudok továbbhaladni.
Új hozzászólás Aktív témák
- exHWSW - Értünk mindenhez IS
- Álláskeresés, interjú, önéletrajz
- Miért álltak az oldalak egy hétig, mi történt?
- Milyen okostelefont vegyek?
- Luck Dragon: Asszociációs játék. :)
- Milyen billentyűzetet vegyek?
- sziku69: Fűzzük össze a szavakat :)
- Könyvajánló
- PROHARDVER! feedback: bugok, problémák, ötletek
- Szétveri a kritikus gondolkodás képességét a ChatGPT
- További aktív témák...
- Xiaomi Redmi Note 14 Pro 5G 256GB Lavender Purple, Karcmentes, Újszerű, Lila, Garanciális
- Gyári állapot !! Macbook Pro Retina 16" M1 Pro 10C CPU / 16C GPU / 32 GB MEMÓRIA/ 512 SSD / Garancia
- Xiaomi Redmi Note 14 Pro 5G 256GB Lavender Purple, Karcmentes, Újszerű, Lila, Garanciális
- Akciós áron eladó HP Elitebook 850 G7 / I-7 10610U/16 GB/512 SSD/15"/FHD/IPS/Garancia
- Dell Precision 7550 15.6 FHD Touch / i7-10850H 32GB / 512GB / nVidia Quadro / IR workstation tervező
- Huawei Nova Y70 128GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- Bomba ár! HP Elitebook 850 G5 - i5-8GEN I 16GB I 256GB SSD I 15,6" FULLHD I Cam I W11 I Gari!
- Bomba ár! Lenovo ThinkPad T460 - i5-6GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
- Nvidia Quadro M2000/ M4000/ P2000/ P2200/ P4000/ P5000/ RTX 4000/ RTX A2000