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

• #20118 Penge_4 veterán Sk8erPeter #20117

  Új Válasz 2013-07-30 20:58:17 #20118

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Penge_4

  veterán

  válasz Sk8erPeter #20117 üzenetére

  "Miért értelmetlen karaktersorozat a nevük?"

  hlojmnjdcnblobllbpphiemfbdilpiol, hompjdfbfmmmgflfjdlnkohcplmboaeo és társaira gondolok.

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

  Elméletben biztos. A gyakorlatban viszont a backup fájl visszaállítása után már eltűntek a kiegészítők az Extensions mappából.

  "Csak az extensionök oldalánál hasonló hibaüzenetet kiírt, mint nálad, javítottam, újratöltöttem, és már volt kiegészítő."

  Ez nem az a probléma. Csak az unpacked extensionoknál van Reload gomb. Továbbá még felül sem lehet írni (reinstall), mert az a túlintelligens Chrome Webstore látja, hogy telepítve van már a kiegészítő és nem tudsz felülírást csinálni.

  "A régi Operánál is nyugodtan elcsesződhettek kiegészítők. Az pedig a kiegészítő felelőssége, hogy biztosít-e mondjuk adatexportálási lehetőséget."

  Igen. De a régi Operánál az alapfunkciók natívan voltak megcsinálva, így csak kb. 10%-ban kellett kiegészítőkre támaszkodni. Itt meg 100%-ban. Ez nem mindegy.

  "Pontosan ezért dobta tehát teljes joggal az "invalid value"-t, mert valóban érvénytelen értéket (stringet tartalmazó egyelemű tömböt (lásd szögletes zárójelek)) adtál meg."

  Köszi. Így már működik. Már csak arra kell rájönnöm, hogy hogyan lehet a három (azaz kettő, mivel a document_idle a default) közül valamelyikkel az Operás működést elérnem.

  Konkrétan most annyit akartam, hogy a tab aliaser nevű kiegészítőm akkor fusson le, amikor Operában. De document_start-ra az egész title mező törlődik és csak URL lesz title helyett, document_start pedig ugyanaz, mint a document_idle. Vagyis a teljes betöltődés után cseréli ki a title-t.

  "A "külön kiegészítő kell még erre is" speciel a fejlesztői panel esetében picit túlzás, mivel amit eddig hiányoltál, és ami egyáltalán nem volt meg (vagy más formában), az a screenshot-készítő és color picker natívan."

  Dragonfly-ban a Storage fülön lehet szerkeszteni is a cookiekat. Mellesleg natív funkció is egyben az oldal tulajdonságainál. Szóval ez is megvolt.

  "Ezt jelenti tehát a fentebbi padding:4px 3px 2px 1px; sor, a kettő teljes mértékben ekvivalens, DE CSAK EGY HELYEN KELL SZERKESZTENI, NEM 4 HELYEN... capisce?"

  Oké, akkor mondom: Ha nekem van már két padding !important-os értékem a left-re és a right-ra, akkor egyben szeretném egyetlen (nem kettő, egy) érték átírásával módosítani.

  Vagyis jelenjen meg, hogy padding: 5px, ami vonatkozik elviekben mind a 4-re, de csak annyi jelenik meg, hogy 5px.

  Nem 5px 5px 5px 5px (amiből kettő át van húzva az !important-os felülbírálás miatt).

  Ha viszont közös paddingot szeretnék mind a 4 oldalnak, akkor is kényelmetlen, hogy 4 értéket jelöl ki. 1 globálisat jelöljön ki, az vonatkozzon mindenre.

  "Hogy mit ne jelöljön ki? Ezt most már nem is értem. Mintha két külön nyelvet beszélnénk."

  Oké, akkor képpel magyarázom:
  Web Inspector:
  
  Dragonfly:
  

  "valamint nem a CSS-fájlokban megadott módon szedi szét a stílust, hanem összegzi a végső renderelés eredményét, és kész."

  Pont látszik, mivel így ha userCSS vagy kiegészítő módosított valamit is mutatja.

  "Hidd el, a külön-külön módosítás kényelmesebb, mert akkor teljesen egyértelmű, hogy épp mit módosítasz, csak ránézel a tulajdonság nevére, és már tiszta, nem kell gondolkodni, milyen sorrendben is van."

  Tényleg nem értelek. Pont Dragonfly-ban tudod külön-külön szerkeszteni pl. a paddingot, míg Chrome-ban kibonthatod, de nem felül tudod szerkeszteni csak. A kibontottra hiába kattintgat az ember.

  Mellesleg Dragonfly-ban van jobbklikk menü. Olyan, ami a Chrome-os DevToolsban nincs. Ott meg van olyan, hogy "Expand shorthands", ha te arra vágysz.

  "és hogy ne kelljen alkalmazni az amúgy kerülendő !important kulcsszót, ez nagyon is számít"

  Webfejlesztésnél biztos, userCSS-nél nem hiszem.

  "egy szar, kényelmetlen megoldást választottak, hogy nekem manuálisan kelljen hozzáadnom egy attribútumot, jobb klikk, Add attribute, "style" bepötyögésének bénázásával"

  Miért kéne ilyet csinálnod? Duplaklikk egy teljesen irreleváns, de az adott DIV-hez tartozó elembe, majd Enterrel csinálsz egy sortörést, az új sorba meg már azt írsz, amit akarsz.

  "Itt olyan jellegű problémáról beszélünk, mintha kábé az otthoni fürdőszobádban a WC-tartályodon végül is lehetne egy lehúzózsinór, de te minden alkalommal inkább felmászol a vécédeszka tetejére, és kézzel lenyomod a lehúzókart, mert az úgy tök vagány."

  A régebbi, nem víztakarékos WC tartálynál, ami lehúzáskor leengedte a teljes tartály tartalmát, úgy csináltam, mert úgy vissza is lehetett tolni a kart.

  "Fejlesztés során nem egyszer fordult már elő, hogy mondjuk egy divet p-re akartam cserélni, vagy egy p-t spanre, vagy hasonló, ebben az esetben ráklattyolok az adott tagre, és mind a kezdő-, mind a zárótaget egyből lecseréli, szemben az Opera megoldásával, ahol nekem ezt manuálisan kell megtennem, még a HTML-szerkesztős részben, vagy ha rosszul csinálom (pl. elfelejtem lezárni), az is lehet, hogy a Dragonfly automatikusan kicsapja a kódból az adott taget"

  Most próbáltam ki. Duplaklikk a DIV-en, megnyílik szerkesztésre egy <i></i>-vel körülzárt rész. A felső i-re duplaklikkelek, kijelölődik az i betű. Átírom p-re, majd nyomok egy Enter-t. Meglepő módon a zárótag is kicserélődött p-re.

  "Ennél a résznél is elvesztettem a fonalat, most milyen hülyeséget is akarunk felülbírálni? Hogy ne irányítson át?"

  Pl. Fit-to-Width, pl. Cookie szerkeszthetőség és még folytathatnám a sort. Az Operában volt egy csomó olyan, amivel felül tudtad bírálni az oldalak hülyeségét. Egyébként oldalspecifikusan az átirányítást is le lehetett tiltani :-) Ahogy a send refferer information-t is és még sok mást.

  "Aha, tényleg, amit nem látunk, amit letakarnak előlünk, az tényleg tuti sokkal jobb."

  Az egyik logikailag nem következik a másikból, viszont a történelem során eddig az esetek többségében amit rejtegettek azt okkal rejtegették. Úgy értem, mindig volt mögöttes ok a publikus és nyilvánvaló okokon kívül.

  De valóban, amíg nem látjuk a forráskódot, addig nem tudjuk eldönteni, hogy melyik a jobb, csak egyéni, szubjektív véleményünk lehet. Az enyém az, hogy a Presto egy forradalmi motor volt, amely még abban a szellemiségben született, amikor a webet geekek és programozók uralták, nem marketingmenedzserek és zombi átlaguserek, a bugjai többsége a népszerűtlenségéből és annak utóhatásából (workaroundok sorozata) keletkezett (pl. 10.00-s Operában semmi probléma nem volt a position:fixed oldalakon való scrollozással, próbáld ki ha nem hiszed el. Gyönyörűen gördül a szöveg fix hátteres és fix dobozos oldalakon is).

  Illetve szarul marketingelték, a piac hiénái pedig megölték. Ahogy tették azt régebben is párszor fejlettebb, korukat meghaladó innovációkkal (BetaMax, Dymaxion vagy EV1).

  "Ja, tényleg, mielőtt megfeledkezem róla, a JSON-fájlok feldolgozása, írása gyorsabb, mint az INI-fájloké."

  Az XML-é meg még gyorsabb. Vagy ha már gyorsaságra megyünk, állítólag a Lua script a leggyorsabb. És az még hasonlít is a JSON-ra.

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

  Végül is, ebben van igazság. Csak így meg olyan furcsa, hogy az a pont nem értelmeződik.

  Mert ha én pl. úgy adom meg, hogy *.example.com, akkor lehet, hogy direkt az a célom, hogy a http://example.com-ra ne vonatkozzon, csak az example.com oldal ezernyi subdomainjára.

  Hogy életszerű példát mondjak: pistike.atw.hu-n meg gizike.atw.hu-n meg józsika.atw.hu-n is jelen lévő valamit akarok módosítani, létrehozni, törölni, de azt nem szeretném, ha a fő atw.hu oldalon is módosulna/létrejönne/törlődne.

  Ezt gondolom úgy oldom meg, hogy a sima domaint ilyenkor az exclude_matches-be rakom bele.

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