Hirdetés
-
A Coca-Cola következő nagy újítása az AI
it 1,1 milliárd dolláros üzletet kötött a Coca-Cola és a Microsoft, hogy előbbi használja majd a redmondi felhőt és AI-t.
-
Mégis megjelenik Switch-re a Deliver Us the Moon
gp Közel négy évvel a hibrid konzolora szánt változat elkaszálása után a készítők úgy döntöttek, hogy mégis megjelenik a Switch verzió.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
PROHARDVER!
Új hozzászólás Aktív témák
-
#20101
scott_free
senior tag
scott_free
senior tag
- az Opera 15-ben miért mások a betűtípusok ugyanazon az oldalon, mint a 12-ben?
pl. facebook:
- az alapértelmezett zoomot be lehet állítani 120%-ra 125 helyett?
- valahogyan lehet nagyítani a címsor (és a fülek neveinek) betűméretét?
köszi!
-
#20102
Penge_4
veterán
scott_free
#20101
Penge_4
veterán
válasz
scott_free
#20101
üzenetére
"az Opera 15-ben miért mások a betűtípusok ugyanazon az oldalon, mint a 12-ben?"
Mert az Opera egyedi betűsimítást alkalmazott, ami olyan fasza volt, amit még egy Chrome fejlesztő is elismert.
"az alapértelmezett zoomot be lehet állítani 120%-ra 125 helyett?"
Nem. Maximum dqdb kiegészítőjével, de az kiegészítő, nem natív funkció, emiatt értelemszerűen küzd azokkal a korlátokkal, amikkel minden más kiegészítő.
"valahogyan lehet nagyítani a címsor (és a fülek neveinek) betűméretét?"
Windows beállításaiból globálisan igen, de Opera-specifikusan szerintem sehogy.
Amúgy minél többször próbálgatom a Chrome-ot, kényszerítve magamat az elkerülhetetlenre, annál inkább rájövök, hogy mennyire szerettem az Operát, amikor újra azzal böngészek. Olyan triviális dolgok is, mint a Linuxos topicban kialakult fontokkal kapcsolatos vitában is rájövök újra és újra, hogy mennyi minden volt alap és természetes az Operában, ami Chrome-ban nincs/nehézkes/körülményes vagy egyenesen lehetetlen.
Pl. itt gondolom a fejlett fontbeállításokat (akár h1-től h6-ig meg lehet adni egyedi dolgokat, tényleg mindent testreszabni, amihez nem kell egyedi UserCSS-kkel szopni) nem kell részleteznem. Chrome-ban ocsmány Times New Roman van. Ami önmagában még nem is lenne gond, de DejaVu Sans-ra módosítva a 16-os tényleg 16-os méretűnek tűnik (ugyanez az érték van Times New Roman-nál is, de az inkább 12-esnek tűnik), emiatt csúnya, nagy és széttolja a layoutot. Pl. itt IT Cafén a "Legfrissebb anyagok" dobozban 4-5 sorba tördelődnek a 16-os betűk. Nosza, csökkentsük le. Oh, wait! Nem csökken, csak egyszerre az összes, emiatt még a natív lapokon (beállítások, about:memory) is hangyafasznyi méretű betűk lesznek. Na akkor nézzünk bele a Preferences JSON-ba (ha megint el nem baszom és rakhatom újra a kiegészítőket, azok beállításaival együtt, mert a buborék 404-et mutat, miután sikerült visszaállítanom), hátha ott lehet specifikusan is módosítani. Nem, nem lehet ott sem...
Arról nem beszélve, hogy minél többször használom a Chrome-ot, annál inkább rájövök, hogy mennyi olyan bug van benne (durvább módon), ami régebben Operában is volt és mennyien "bezzegatöbbiböngésző"-ztek ilyenkor. Csak így hirtelen mikor be van ágyazva egy DIV-be egy sokkal nagyobb (akár több megapixeles) kép, akkor a görgetés veszedelmesen akad. Régen ez Operában is volt, de itt azóta már egész tűrhető.
[ Szerkesztve ]
-
dqdb
Topikgazda
válasz
Penge_4
#20100
üzenetére
Hogy én mennyire gyűlölöm a JSON-t...
Ennek a hibaüzenetnek és az okának konkrétan a JSON-hoz, mint formátumhoz semmi köze nincsen. Itt van az URL maszkokról a leírás, rendes magyarázat, BNF és hasznos példák hozzá (Sk8erPeterrel együtt nem véletlenül dicsértem a dokumentáció minőségét).Olyat nem tudsz, amiben betallózom, hogy a profile/userjs és a profile/usercss könyvtárban lévő JS-eket és CSS-ket futtassa le normálisan? Vagy az már ugyanannyira sok erőforrást zabálna, mint a Tampermonkey?
Chrome alá elvileg lehetne, de Opera 16 alá nem tudok, mert a HTML5 File API segítségével nem lehet ilyet készíteni, és a chrome.fileSystem API nem elérhető. De sok értelmét sem látnám, akkor már ott van a Tampermonkey/Stylish páros. Sőt, konkrétan nulla értelmét látom egy ilyen kiegészítőnek: aki advanced user, annak nem probléma a manifest.json megszerkesztése (és adott esetben a DOMContentLoad esemény használata miatt a user JS módosítása sem), aki nem, annak a Tampermonkey működése (sőt létezésének értelme) is sok.az alapértelmezett zoomot be lehet állítani 120%-ra 125 helyett?
Nem. Maximum dqdb kiegészítőjével.
A jelenlegi változatával annak sem, mert nem támogatom a default zoomot sem a My Operán található régebbi, sem a GitHubon található eggyel frissebb verzióban, csak a gépemen lévő fejlesztés alatt állóban. Majd valamikor a héten frissítem mindenhol, és feltöltöm a hivatalos oldalra is engedélyezésre.DejaVu Sans-ra módosítva a 16-os tényleg 16-os méretűnek tűnik (ugyanez az érték van Times New Roman-nál is, de az inkább 12-esnek tűnik
Ugyanakkora betűméret esetén egy sans serif font betűi mindig nagyobbnak tűnnek egy serif font betűinél. Ráadásul a DejaVu Sans betűi a szokásosnál szélesebbnek tűnnek.Amit nem értek: nekem ez a renderelésbeli különbség érdekes módon fel sem tűnt, míg a Linux számomra ronda fontkezelésétől rosszul vagyok.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#20104
Sk8erPeter
nagyúr
Penge_4
#20066
Sk8erPeter
nagyúr
válasz
Penge_4
#20066
üzenetére
"A Network tabon ömlesztve van, a Resources tabon viszont kategorizálva. Na, az Operában sokkal átláthatóbb az egész, Chrome-ban meg egyedül az az egy pozitívum van (bár gondolom a webRequest API miatt), hogy "failed"-del kiírja azokat, amiket blokkolt. Az Operában meg se jelennek a blokkolt elemek."
Hát akkor ide-oda egy-egy pont. Amúgy egyszerűbb lett volna, ha linkelsz egy screenshotot, az beszédesebb minden szónál
Bekereteztem helyetted a lényegetOpera 12.16 (build 1860, x86), Dragonfly :
Opera Next 16.0.1196.14 Inspector :
Ez mondjuk a Dragonfly-ban speciel tényleg jó, az újban csak MIME type alapján lehet rendezni az összeset ömlesztve, az oszlop nevére kattintással.
De ilyen alapon az újban viszont a fejléceknél van ilyen füles megoldás
O 12.16, Dragonfly:
O 16.0:
"Mert alapértelmezésben nem tudod kiválasztani az oldalon az elemet, csak ha belekattintasz a nagyítóba. "
Erre mondtam korábban is, hogy jobb klikk az elemen, "Inspect element". Egyébként értem, mire gondolsz, ebben van is valami.
De ez az, ami sokkal kevésbé zavaró dolog fejlesztésnél - legalábbis számomra, nyilván az igények változnak -, mint az az elképesztő amatőr dolog, hogy a webfejlesztős panelt csak egy példányban lehet futtatni (lásd Dragonfly).
De ha már itt tartunk, speciel ezt Mozilláék nagyon ügyesen kitalálták, ott 3 dimenziós ábrázolásban láthatod az elemek hierarchiáját is, nagyon sokat segít az áttekintésben, és ezt natívan tudja (nem kell hozzá a Firebug). Például ezt átvehetné a többi böngésző, legalábbis valami hasonló megoldást, mert nagyon hasznos. Szóval ebben például ők találtak ki egy jó dolgot, ami segíti a fejlesztést, így a fejlesztőpanelek olvasztása lenne a legjobb. Mégis saját fejlesztéseim közben eddig a Google panelét találtam a leggördülékenyebben használhatónak.
Ez nem jelenti azt, hogy ne vehetne át dolgokat akár a Dragonfly-tól, akár a Firebugtól, akár az említett Firefoxos 3D-s megoldástól.">>"2. a paddinget nem cseréli le 4 helyen, hogy 4 helyen kelljen módosítgatnod, de lenyitható, és akkor szétbontva is látszik - hogyan csináltad?"
Nem tudom hogy csináltam, de utána már nem tudtam a lenyílóba belekattintani, hanem a globálisat kellett átírnom. Olyan nehézkes az egész."Továbbra sem értem, mi a nehézkes.
Most az alábbi ábrán látható módon beírtam az egyik bekezdéshez, hogy
padding:4px 3px 2px 1px;
ekkor ez lenyitható lesz (de nem muszáj lenyitni
), hogy szépen lásd kibontva is ennek az ömlesztett változatnak a megfelelőjét (mi a top, right, bottom, left padding):
viszont ha módosítani szeretném, akkor az ömlesztett változatot tudom módosítani, teljesen logikusan:
A nyomorult Dragonfly-ban rámegyek az elemre, és nem is tudom így egyből módosítani a tulajdonságait az épp kijelölt elemnek:
csak ha hozzáadom a style attribútumot, és elkezdem bepötyörészni, amit akarok, vagy alul, a "New style" részben olyan selectort pötyögök be, ami épp illeszkedik erre az elemre, de akkor meg nem úgy viselkedik, mint az inline style-nál (mint amikor a style attribútumba pötyörészem az értékeket), hanem csak mintha a CSS-fájl végére dobáltam volna be... na ez a másik, ami rettenetesen idegesítő. Hát milyen szinten béna már ez?
"Az Adblock és az Adblock Plus meg nem kezeli az nth-child-eket, ami miatt egy csomó esetben cseszhetem."
Hogyhogy "nem kezeli"?"Van rá kiegészítő is. Kár, hogy sem privát módban nyitott képeknél, sem localhostról nyitott képeknél nem működik."
Az egy dolog, ha a kiegészítőt szarul írják meg, de ettől még ez nem változtat azon, hogy az Imgur egy nagyon jó képfeltöltő és -megosztó szolgáltatás... tulajdonképpen nem tudom, ezzel most mit akartál igazolni... (Vagy ez a szokásos csak-azért-is-megpróbálom-megtalálni-a-sebezhető-pontot-jellegű kötekedés?)Az átirányítósdis, képmegosztós problémádra pedig szerintem itt dqdb elég jól igazolta, hogy jelen esetben rossz dologba kötsz bele, és rossz dolog miatt minősíted a WebKit/Blink-vonalat szarabbnak. Könyörgöm, itt oldalak hülyeségeiről beszélünk, nem pedig a böngészőmotoréról. Kezd egy kicsit olyan érzése lenni az embernek, hogy mindenáron be akarod bizonyítani, hogy a WebKit/Blink-vonal egy gány tákolmány fos, csak azért, mert kiherélték az Operát, de immár minden apróságban keresed a hibát, pedig a régi Operánál is lehetett találni bőven. Mindegyik böngészőmotornak megvan a maga hülyesége. Az valóban a Google hülyesége, hogy a legtöbb felhasználó miatt a böngésző beállíthatósága egyszerű, mint a faék, de ez még nem bizonyítja, hogy fos a böngészőmotor is. Vagy ha az, remélhetőleg majd az Opera közreműködésre révén javul.
Sk8erPeter
-
#20105
Sk8erPeter
nagyúr
Penge_4
#20100
Sk8erPeter
nagyúr
válasz
Penge_4
#20100
üzenetére
"Hogy én mennyire gyűlölöm a JSON-t...
"
Pedig hidd el, hogy akkor veled és/vagy a kiegészítőddel van a baj, és nem a Chrome Extension API-val, meg nem is a JSON-formátummal.
A JSON egy nagyon egyszerű, programozásban jól és könnyen használható, széles körben támogatott formátum, nyilván nem véletlenül.
Azért, mert nem sikerül hozzászoknod az új API-hoz elsőre, nem másokban kell keresni a hibát. Inkább próbálj rájönni a hiba okára. Nem látjuk a kiegészítőd kódját, akkor ennyi alapján hogyan segítsünk? Nyilván Te csesztél el valamit a kódban, még ha nehéz is beismerni, és nem a JSON-formátum a szar...[ Szerkesztve ]
Sk8erPeter
-
-
brd
nagyúr
Ha valakinek van kedve, kérem szánjon meg egy kis segítséggel! A logout-on a háttér egy része egy kép, ezt hogyan lehet lecserélni egy sajátra, hogy ne legyen annyira fehér? A többi portálon megoldottam CCS hekkeléssel UserJS-ből, de itt nemtom', mert nem értek annyira ehhez.
The only real valuable thing is intuition.
-
#20108
Sk8erPeter
nagyúr
brd
#20107
Sk8erPeter
nagyúr
Nem User CSS-sel oldottad meg eddig? De végül is mindegy. Konkrétan melyik képet szeretnéd lecserélni? Írj egy selectort, vagy linkelj egy screenshotot, hogy tudjuk, miről van szó.
Ilyen célra írni egy miniextensiont rohadt egyszerű, csak írd le, végül is pontosan mit szeretnél.Sk8erPeter
-
Penge_4
veterán
"Itt van az URL maszkokról a leírás, rendes magyarázat, BNF és hasznos példák hozzá (Sk8erPeterrel együtt nem véletlenül dicsértem a dokumentáció minőségét)."
Miért azt jelzi, hogy a harmadik content script nulladik match-jával van gebasz, amikor a hiba (egész pontosan a csillag után nem tettem pontot) az ötödik content scriptben volt?
"De sok értelmét sem látnám, akkor már ott van a Tampermonkey/Stylish páros."
Csak azzal az a baj, hogy az értelmetlen karaktersorozat nevű kiegészítők könyvtárait rendszeresen kell backupolni, mert egyszer csesződik el valami a JSON-ban, és onnantól a kiegészítők megszűntek létezni. A kiegészítő könyvtárai eltűnnek és a kiegészítők chrome://-es (vagy opera://-es) URL-jei 404-es hibaoldalra mutatnak, a kiegészítőikon pedig puzzle ikonná változik.
A Tampermonkey meg fos, mert egy csomó mindent kell konfigurálni benne, meg egyenként kell hozzáadogatnom a scripteket.
Meg most komolyan, minden kiegészítőt egyenként backupolgassak? Natív funkció kéne ezekre, mert ez így katasztrófa. Instabil és veszélyes, ilyesmiben nemhogy Notes, Bookmarks, UserJS és társait nem szabad tárolni, de még napi ToDo-t sem bíznék rájuk. Korrumpálódik az adatbázis, törlődik az értelmetlen karaktersorozatú könyvtár, aztán elfelejtem megetetni a hörcsögöt és az kimúlik.
"és adott esetben a DOMContentLoad esemény használata miatt a user JS módosítása sem"
Oké. Hogy adom meg ezt? "run_at": [ "document_start" ],
Amúgy a DomContentLoaded (ami Operában még működött) részt ki kellett szedni a userJS-ből ahhoz, hogy egyáltalán működjön. De most a run-at-ra ezt a hibát dobja:
Invalid value for 'content_scripts[5].run_at'.
"Ugyanakkora betűméret esetén egy sans serif font betűi mindig nagyobbnak tűnnek egy serif font betűinél. Ráadásul a DejaVu Sans betűi a szokásosnál szélesebbnek tűnnek."
Ezzel megvigasztaltál. Operában ezt át lehet hidalni, Chrome-ban még ezt sem.
"míg a Linux számomra ronda fontkezelésétől rosszul vagyok."
Amiket mutogattak elrettentő példaként screenshotokon, azoktól én is, de amit én használok attól nem. Sőt, szerintem sokkal szebbek, mint a Windows 7-es TrueType.
(#20104) Sk8erPeter: Amit még kifelejtettem: WebDev Tools-ban nem lehet szerkeszteni a cookie-kat, csak megnézni meg asszem törölni. Szóval végképp el van lehetetlenítve a cookie szerkesztés, tényleg külön kiegészítő kell még erre is. Még a DevTools sem tudja.
"A nyomorult Dragonfly-ban rámegyek az elemre, és nem is tudom így egyből módosítani a tulajdonságait az épp kijelölt elemnek:"
De nem is 4 különböző érték lesz ott, csak 1. Az, amit szerkesztesz akár globálisan, akár lokálisan. Ha az összes többi padding 10, kivéve a left, ami 8, akkor ne jelölje már ki nekem az összeset.
Még egy: Jelöld ki a "Legfrissebb anyagok" egy linkjét Dragonfly-ban és nyisd le a "Computed Styles"-t. Fogsz látni egy ilyet:
font: normal normal 400 12px/16px Arial;
Chrome-ban meg bontva van, egyenként másolgassam ki az összeset."úgy viselkedik, mint az inline style-nál (mint amikor a style attribútumba pötyörészem az értékeket), hanem csak mintha a CSS-fájl végére dobáltam volna be... na ez a másik, ami rettenetesen idegesítő. Hát milyen szinten béna már ez?"
Én pl. kifejezetten szeretem, ha nem akar a program okosabb lenni, mint én, mert az ilyen próbálkozások mindig kudarccal végződtek. Nem létezik olyan algoritmus, ami engem ki tudna ismerni.
Pl. Dragonfly-ban ha HTML nézetben ráklikkelek duplán egy tag-re, akkor nem a taget akarja szerkeszteni, hanem az egész tag alá tartozó részt. Itt meg ez is külön van csapva gondolom userbarát célból. De nekem nagyon nem tetszik ez sem.
"Hogyhogy "nem kezeli"?"
Úgy, hogy natívan a blokkolandó DIV kiválasztásánál nincs ilyen funkcionalitása. Pedig 150-200 megát zabáló cuccnak illene ilyennek is lennie.
"tulajdonképpen nem tudom, ezzel most mit akartál igazolni... (Vagy ez a szokásos csak-azért-is-megpróbálom-megtalálni-a-sebezhető-pontot-jellegű kötekedés?)"
Nem. Ez a szokásos "még a legjobb és viszonylag egyszerű ötletet is képesek elbaszni" típusú monológ volt.
Pl. tegnap ért sokkhatásként az is, hogy a VLC (legújabb verzió) a mai napig nem képes olyan triviális dologra, hogy a feliratot az alsó fekete sávra renderelje rá. Pedig úgy gondoltam, hogy legalább ezt már tudja, de ezek szerint még ezt sem. Ennek általánosságban annyi köze van az Operához, hogy vannak fasza, funkciógazdag szoftverek, amiket senki nem használ, meg vannak buta, funkciószegény szoftverek, amik népszerűek és ha megpróbálsz érvelni teljesen logikus dolgok mellett, akkor néznek rád, mint valami UFO-ra, mintha ezek a dolgok annyira rétegigények lennének.
"itt dqdb elég jól igazolta, hogy jelen esetben rossz dologba kötsz bele, és rossz dolog miatt minősíted a WebKit/Blink-vonalat szarabbnak."
Oké, elismerem, a népszerűség átka, hogy köcsög oldalak visszaélnek a helyzetükkel. De ettől még az tény marad, hogy ha a böngészőben nincs konfigurálási lehetőség, hogy felülbíráld egy oldal hülyeségét, akkor az igenis faék.
Szar meg nem azért lesz, mert jelenleg faék, hanem azért, mert 2008-as megjelenése óta nemhogy Opera szintre, de még Firefox szintre sem sikerült senkinek felhozni eme nyílt forráskódú csodát. Pedig forkokból Dunát lehet rekeszteni. Még beépített torrent klienses Torch Browser is van.
Ha pedig valami 5 éve képtelen erről a buta szintről feljebb emelkedni, ott erősen gyanítható az, hogy nagyon mélyen bele kéne nyúlni abba a "solid foundation"-be (mondhatni, pincét és mélygarázst utólag húzni a már felépült Burj Dubaj alá), hogy akár csak megközelítse a Presto-s Opera szintjét bármilyen téren.
Egyébként a standalone M2 is jó móka így a Presto-val. Szerintem az is csak azért van, hogy legyen indokuk, miért nem adják ki a Presto forráskódját. Mert akkor kiderülne az igazság... Aztán nem kizárt, hogy én esnék pofára. Bárcsak úgy lenne. De sajnos eddig minden pesszimista megérzésem bejött.
"A JSON egy nagyon egyszerű, programozásban jól és könnyen használható, széles körben támogatott formátum, nyilván nem véletlenül."
De miért kell ágyúval verébre? Programozásra biztos jó, de arra, amire nekem kellett egy INI is bőven megfelelt. Linuxban miért is nem JSON-ban vannak a config fájlok? Talán mert elmebetegség lenne ilyen triviális célokra egy karácsonyfa programnyelvet alkalmazni? Jó, hogy nem brainfuck-ban kell UserJS-eket menedzselni.
"Te csesztél el valamit a kódban, még ha nehéz is beismerni, és nem a JSON-formátum a szar..."
Igen. Úgy adtam meg, hogy http://*example.com/* nem pedig úgy, hogy "http://*.example.com/*"
A dokumentáció szerint ez a sima example.hu-ra is vonatkozni nem csak a www-re (meg a többi aldomainre, ha van olyan).
Na ez például logikus? Mert én eddig abban a (tév)hitben éltem, hogy a csillag helyettesítő karakter. Ennél fogva helyettesíti a . (azaz pont)example.com előtti részt. De mivel a domain http://example.com (pont nélkül), nem pedig http://.example.com, ezért logikusnak tűnt, hogy így adom meg.
[ Szerkesztve ]
-
#20110
brd
nagyúr
Sk8erPeter
#20108
brd
nagyúr
válasz
Sk8erPeter
#20108
üzenetére
Ezt a két fehéret szeretném lecserélni valami barátibbra, mondjuk #EEEBE3-ra (még Opera 12.x-ben):
The only real valuable thing is intuition.
-
#20113
atillaahun
veterán
atillaahun
veterán
A 12.16-os Opera már nem támogatja többé a pdf fájlok beépített nyomtatását?
Egyik napról a másikra eltűnt a nyomtató ikon a fejlécből (beépülő), és ezzel így nem tudok dolgozni.
-
#20114
fatal`
titán
atillaahun
#20113
fatal`
titán
válasz
atillaahun
#20113
üzenetére
A beépülőt az adobe reader kezeli, feltéve, hogy azt használsz.
-
#20117
Sk8erPeter
nagyúr
Penge_4
#20109
Sk8erPeter
nagyúr
válasz
Penge_4
#20109
üzenetére
"Miért azt jelzi, hogy a harmadik content script nulladik match-jával van gebasz, amikor a hiba (egész pontosan a csillag után nem tettem pontot) az ötödik content scriptben volt?"
0-tól indexelődik (ahogy általában a numerikus kulccsal ellátott tömbök; itt a content_scripts objektumok tömbje), így ez elvileg azt jelenti, hogy sorban a negyedik elemben (0-1-2-3) kellett volna, hogy legyen a hiba. Hogy nem pontosan ott volt, azt így kód híján nem tudjuk megmondani.Vannak egyébként online JSON-validáló eszközök.
"értelmetlen karaktersorozat nevű kiegészítők"
Miért értelmetlen karaktersorozat a nevük? Melyek ezek? Saját, vagy letöltött? Ha saját, akkor miért nem adsz tisztességes nevet nekik? "egyszer csesződik el valami a JSON-ban, és onnantól a kiegészítők megszűntek létezni"
A kiegészítők léteznek, csak legfeljebb nem tudnak betöltődni, mert már a manifest.json-validáció során elbuknak. Javítani kell a hibát, és máris megszűnik ez a probléma."A kiegészítő könyvtárai eltűnnek"
Azt hogy, mitől? Hova tűnnek el? Egy fekete lyuk beszippantja? Csak mert ilyet még nem tapasztaltam a JSON-fájl elcseszése során. Csak az extensionök oldalánál hasonló hibaüzenetet kiírt, mint nálad, javítottam, újratöltöttem, és már volt kiegészítő."Meg most komolyan, minden kiegészítőt egyenként backupolgassak? Natív funkció kéne ezekre, mert ez így katasztrófa. Instabil és veszélyes, ilyesmiben nemhogy Notes, Bookmarks, UserJS és társait nem szabad tárolni, de még napi ToDo-t sem bíznék rájuk. Korrumpálódik az adatbázis, törlődik az értelmetlen karaktersorozatú könyvtár, aztán elfelejtem megetetni a hörcsögöt és az kimúlik.
"
Most itt nem értettem, végül is konkrétan mivel is van a gond? Mert eddig a JSON-formátumot szidtad (bár jogtalanul), meg a Chrome Extension API-t, aztán a Tampermonkey-t, aztán még ki tudja mit, most meg már elvesztettem a fonalat, hogy mi is lett más például ebben, mint a régi Opera esetén. A régi Operánál is nyugodtan elcsesződhettek kiegészítők. Az pedig a kiegészítő felelőssége, hogy biztosít-e mondjuk adatexportálási lehetőséget.
Milyen natív funkcióra gondolsz? A tárolásról beszélünk, vagy miről? localStorage, sessionStorage és társai?
Vagy a kiegészítő-fájlrendszer teljes mentésére szeretnél natív eszközt? (Ezt mondjuk megteheted külső programmal.)"run_at": [ "document_start" ],
Ez így NEM jó, lásd dokumentáció:
https://developer.chrome.com/extensions/content_scripts.html#run_at
string típust vár, tehát csak simán:
"run_at": "document_start",
Pontosan ezért dobta tehát teljes joggal az "invalid value"-t, mert valóban érvénytelen értéket (stringet tartalmazó egyelemű tömböt (lásd szögletes zárójelek)) adtál meg."WebDev Tools-ban nem lehet szerkeszteni a cookie-kat, csak megnézni meg asszem törölni. Szóval végképp el van lehetetlenítve a cookie szerkesztés, tényleg külön kiegészítő kell még erre is. Még a DevTools sem tudja."
Valóban csak megtekinteni és törölni lehet a Resources fülön, a Cookies-nál. JavaScripttel tudnád módosítgatni őket a Console fülön (pl. [link]). Speciel ez nekem megint nem egy nagy érvágás, mert nem igazán hiányzott. Bár valóban bővíthetnék ezzel a funkcionalitással, túl nagy programozói tudást nem igényelne.
A "külön kiegészítő kell még erre is" speciel a fejlesztői panel esetében picit túlzás, mivel amit eddig hiányoltál, és ami egyáltalán nem volt meg (vagy más formában), az a screenshot-készítő és color picker natívan. Ez tény, ettől még maga a fejlesztői panel speciel igen jó."De nem is 4 különböző érték lesz ott, csak 1."
Hogy mi van?? Most szándékosan szívatsz, ugye?!
Itt részletesen kifejtettem, hogy rohadtul nem 4 érték lesz, csak ezt az 1 értéket ki lehet bontani a befelé mutató nyílra kattintva értelemszerűen a paddingnél, hogy szépen lásd, hogy mit is jelent egész pontosan az a sor, hogy
padding:4px 3px 2px 1px;
De akkor a kedvedért leírom, mit is jelent ez külön-külön, és még egyszer belinkelem neked a képet, hogy jól lásd:padding-top:4px;
padding-right:3px;
padding-bottom:2px;
padding-left:1px;Ezt jelenti tehát a fentebbi padding:4px 3px 2px 1px; sor, a kettő teljes mértékben ekvivalens, DE CSAK EGY HELYEN KELL SZERKESZTENI, NEM 4 HELYEN... capisce?
Az, hogy ki tudod bontani erre a 4 értékre, OPCIONÁLIS. CSAK AZ ÁTTEKINTHETŐSÉGET SEGÍTI. A Te érdekedben. Nem kib@szásként. NEM MUSZÁJ KIBONTANOD, ÉS AKKOR NEM LESZ BELŐLE 4 ÉRTÉK 1 HELYETT. Kezd derengeni már, hogy ez csak a kényelmet szolgálja, de NEM egy fikáznivaló dolog? Szólj, ha még mindig nem esett le, hogy NEM "4 különböző érték lesz ott", hanem csak 1, mert akkor elmagyarázom még tízféleképpen. De azért reménykedem, hogy szép lassan átmegy az üzenet."Az, amit szerkesztesz akár globálisan, akár lokálisan."
Milyen globális-lokálisról is beszélsz? A fentebb is látható képen az adott elemre vonatkozó stílust módosítom, tök egyszerű módon, belekattintva az element.style részbe, ami teljes mértékben ekvivalens azzal, ha én a régi Operában tökölősen hozzáadom a style attribútumot KÉZZEL (mennyire ratyi, hogy nem lehet ezt egyszerűbben, ilyen logikusan, mint ahogy a Chrome/Chromium panelénél van), aztán ott belepötyörészem, amit akarok. Az CSAK az adott elemre fog vonatkozni. Nincs semmiféle globális vonatkozása. Nem egy selectort adtam meg, aminek megfelelő elemek stílusa meg fog változni, hanem az adott elem stílusát módosítottam."Ha az összes többi padding 10, kivéve a left, ami 8, akkor ne jelölje már ki nekem az összeset."
Hogy mit ne jelöljön ki? Ezt most már nem is értem. Mintha két külön nyelvet beszélnénk."Még egy: Jelöld ki a "Legfrissebb anyagok" egy linkjét Dragonfly-ban és nyisd le a "Computed Styles"-t. Fogsz látni egy ilyet:
font: normal normal 400 12px/16px Arial;
Chrome-ban meg bontva van, egyenként másolgassam ki az összeset."
Valóban nem a shorthand CSS property-ket adja. Szerintem viszont pont szar az Opera Dragonfly-ban, hogy egyáltalán nem mutatja, hogy melyik fájlból szedi konkrétan melyik betűstílust, és melyik értékek lettek felülbírálva egy később jövő stílusfájlból származó értékekkel; valamint nem a CSS-fájlokban megadott módon szedi szét a stílust, hanem összegzi a végső renderelés eredményét, és kész.
Chrome-ban ezzel szemben a nyílra való kattintás után kibontva láthatod mindezt, és a fájlnevek még be is vannak linkelve, hogy azokra kattintva könnyen át is tudd írni egyből magában a fájlban az értékeket, így a stílusok érvényre jutásának sorrendje is egyezni fog azzal, ahogyan az épp fejlesztett oldal renderelődik a böngészőben.
Dragonfly-ban megmondanád, hogyan is szerkesztek bele konkrétan az egyes fájlokba?
A shorthand CSS property-kkel az a baj, hogy átláthatatlanabb, könnyebb elcseszni, szétbontott formában jóval beszédesebb, ráadásul ha a shorthand CSS property-k közül kihagyod valamelyiket, akkor faszán felülírod a máshol különbontva szerkesztett stílust, és az az alapértelmezett értékre áll be, lásd:
https://developer.mozilla.org/en-US/docs/Web/CSS/font
Pont ezért, meg a nehezebb átláthatósága és nehezebb módosíthatósága miatt én speciel kerülöm ennek a használatát.
Bár ha karakterspórolás a cél, akkor jó lehet... (de ez ne legyen már érv manapság, főleg a CSS compressorok korában)font: normal normal 400 12px/16px Arial;
ez speciel nálam Tahoma, tehát:
font: normal normal 400 12px/16px Tahoma;
de tök mindegy, ennek a megfelelője Chrome-ban:font-family: Tahoma;
font-size: 12px;
font-style: normal;
font-variant: normal;
font-weight: normal;
line-height: 16px;(a "normal" érték egyenlő a 400-zal, lásd ezt)
ebből látható, hogy csak a line-height tulajdonságot kell "egyenként" hozzámásolni, a többi pont egymás alatt van, így szépen kijelölhető az egész, én is úgy illesztettem ide.Egyébként egészen pontosan sorrendben a shorthand CSS property-k megfelelője így néz ki:
font: normal normal 400 12px/16px Tahoma;
ekvivalens ezzel (sorrendben, ahogy itt látható):
font-style: normal;
font-variant: normal;
font-weight: normal;
font-size: 12px;
line-height: 16px;
font-family: Tahoma;Nem mintha a sorrend nem lenne tökéletesen mindegy, csak a pontosság kedvéért leírtam ide.
Szóval itt is úgy érzem, bolhából csinálsz elefántot.
Hidd el, a külön-külön módosítás kényelmesebb, mert akkor teljesen egyértelmű, hogy épp mit módosítasz, csak ránézel a tulajdonság nevére, és már tiszta, nem kell gondolkodni, milyen sorrendben is van. De ha ez a fejedben lenne, még akkor sem érezném ezt olyan problémának, ami tényleg számíthat fejlesztés során.
Sőt, ezt a megoldást én az említett fájlfelsorolós megoldás miatt jóval praktikusabbnak találom, mivel így egész pontosan követheted, adott esetben mivel sikerült - rosszul - felülbírálnod egy másik stílust (és hogy ne kelljen alkalmazni az amúgy kerülendő !important kulcsszót, ez nagyon is számít)."Én pl. kifejezetten szeretem, ha nem akar a program okosabb lenni, mint én, mert az ilyen próbálkozások mindig kudarccal végződtek. Nem létezik olyan algoritmus, ami engem ki tudna ismerni."
Nagyon ügyes vagy, de hogy jön ez ide, amikor arról beszélünk, hogy Dragonfly-ban egy szar, kényelmetlen megoldást választottak, hogy nekem manuálisan kelljen hozzáadnom egy attribútumot, jobb klikk, Add attribute, "style" bepötyögésének bénázásával, amikor ez tök egyszerűen elkerülhető lenne úgy, ahogy Google-nál megoldották, hogy eleve felkínálták a style-attribútum módosításának lehetőségét, és csak akkor kerül az elembe a style-attribútum több értéke, amikor már oda be is pötyögtél valamit? Most itt a lázadozásod nem vagány, meg nem válasz semmire.
Itt olyan jellegű problémáról beszélünk, mintha kábé az otthoni fürdőszobádban a WC-tartályodon végül is lehetne egy lehúzózsinór, de te minden alkalommal inkább felmászol a vécédeszka tetejére, és kézzel lenyomod a lehúzókart, mert az úgy tök vagány. Ja, várjunk csak, mégsem.![;]](//cdn.rios.hu/dl/s/v1.gif)
"Pl. Dragonfly-ban ha HTML nézetben ráklikkelek duplán egy tag-re, akkor nem a taget akarja szerkeszteni, hanem az egész tag alá tartozó részt. Itt meg ez is külön van csapva gondolom userbarát célból. De nekem nagyon nem tetszik ez sem."
Hát akkor ebben is tök más az igényünk. Fejlesztés során nem egyszer fordult már elő, hogy mondjuk egy divet p-re akartam cserélni, vagy egy p-t spanre, vagy hasonló, ebben az esetben ráklattyolok az adott tagre, és mind a kezdő-, mind a zárótaget egyből lecseréli, szemben az Opera megoldásával, ahol nekem ezt manuálisan kell megtennem, még a HTML-szerkesztős részben, vagy ha rosszul csinálom (pl. elfelejtem lezárni), az is lehet, hogy a Dragonfly automatikusan kicsapja a kódból az adott taget, mert invalid abban a formában (mivel elfelejtettem jól lezárni). Nem is beszélve arról, ami NAGYON a Google megoldása mellett szól, hogy ha például egy adott taget módosítani akarsz, és azonbelül van mondjuk egy b@szomnagy <table>, akkor nekem azon végig kell görgetnem a textarea-ban (mondjuk igaz, van Ctrl+End, de érted). Szóval nem "userbarát" célból (ezt a szót itt egy fejlesztőpanel esetében nem is értem, mire akartál ezzel célozni? Szerinted az átlaguser tudja egyáltalán, hogy van ilyen?), hanem "fejlesztőbarát" célból.
A HTML szerkesztése pedig jobb klikk, "Edit as HTML", ne mondd, hogy ez akkora katasztrófa.Már tényleg nüansznyi dolgokon vitatkozunk, szerintem tök feleslegesen.
Az AdBlockeres probléma-felvetésre nem tudok mit reagálni, nem próbálgattam még ezt a részét. De ha a CSS-útvonalról van szó, azt megbeszéltük, hogy nagy hátránya a Google-ös megoldásnak, valóban gáz, hogy kimaradt, addig oldd meg Firefox-szal, vagy kiegészítővel, vagy nem vágom. Ezt én is hiányolom, ahogy írtam is. Remélhetőleg majd vmikor bekerül.
"Nem. Ez a szokásos "még a legjobb és viszonylag egyszerű ötletet is képesek elbaszni" típusú monológ volt."
Mint a fentiekből látszik, nem biztos, hogy a panel fejlesztőivel volt a gond. Máshoz szoktál hozzá, vagy kákán is keresed a csomót."ha a böngészőben nincs konfigurálási lehetőség, hogy felülbíráld egy oldal hülyeségét, akkor az igenis faék"
Ennél a résznél is elvesztettem a fonalat, most milyen hülyeséget is akarunk felülbírálni? Hogy ne irányítson át? Korábban már meg lett beszélve (Te magad bizonyítottad be), hogy az Opera sem védekezik ez ellen, mert megkérték rá a másik oldalnál, hogy menjen át a másik címre, és át is ment. Hát felháborító valóban.A beállíthatóság hiánya a Chrome-nál teljesen más kérdés, ezt ne keverjük ide. De ez is olyan dolog, ami nem a WebKit/Blink-vonal gyengesége, általad kitalált "szar kódja" miatt van, hanem valószínűleg azért, mert ez a koncepció (kiindulópont: a userek hülyék, a sok beállítás csak összekavarja őket) - de ezt még Te magad is kifejtetted. Akkor most miért azt igazolod, hogy ez a szar kódja miatt van?
Az meg továbbra is inkább a vicc kategória, hogy az, hogy nem adják ki nyílt forráskódnak a Presto kódját, azt igazolja számodra (azt írtad, ez "már önmagában elegendő bizonyíték"), hogy az márpedig sokkal jobb és igényesebb. Aha, tényleg, amit nem látunk, amit letakarnak előlünk, az tényleg tuti sokkal jobb.
Végül is lehetne az ember előtt tányéron kirakva egy székelykáposzta, meg egy fém ételhordóban egy darab szar is, és a fém ételhordóban lévő valamire simán ráfoghatnánk, hogy az biztos jobb kaja, mert nem látjuk. Jó, nyilván a Presto nem egy darab szar, de érted az ellentmondást...
Nem tudom, milyen, ahogy Te sem. Csak tippelni tudunk. A Presto-t ötezer éve fejlesztették, épp emiatt tartalmazhatott rendkívül elavult, mégis bedrótozott kódokat, amiktől függött egy csomó minden más. Ez lehetett akár gány is. De lehet, hogy ezt folyamatosan javították. Lehet, hogy igényesebb, mint a WebKit/Blink, lehet, hogy pont nem. Ezt így egyikünk sem tudja eldönteni. Az tény, hogy sok mindent tudott, sok mindenben meg ezzel voltak problémák. Érdemes lenne sztem lezárni ezt a "szerintem akkor is sokkal jobb volt a Presto"-vitát, amíg pontosabb információk birtokába nem jutunk."De miért kell ágyúval verébre?"
Kezd fárasztó lenni ez a téma. Ugyan miért lenne már a JSON ágyúval verébre? "Programozásra biztos jó, de arra, amire nekem kellett egy INI is bőven megfelelt."
Aha, mert az INI tényleg sokkal jobb, mint a JSON, főleg feldolgozás és adatstruktúrák, típusok szempontjából... na ne már. Ez viccnek is rossz. Azt azért elárulhatnád, hogyan deklarálod objektumok tömbjét INI-ben.
Ja, tényleg, mielőtt megfeledkezem róla, a JSON-fájlok feldolgozása, írása gyorsabb, mint az INI-fájloké."Linuxban miért is nem JSON-ban vannak a config fájlok? Talán mert elmebetegség lenne ilyen triviális célokra egy karácsonyfa programnyelvet alkalmazni?"
Te milyen karácsonyfa programnyelvről beszélsz? Eleve milyen "programnyelvről"? A JSON nem egy "programnyelv".
Hogy a JSON "karácsonyfa" lenne, az meg eleve vicc, meg nem is nagyon támasztható alá semmivel. Szóval bocs, de ez hülyeség úgy, ahogy van."Igen. Úgy adtam meg, hogy http://*example.com/* nem pedig úgy, hogy "http://*.example.com/*"
A dokumentáció szerint ez a sima example.hu-ra is vonatkozni nem csak a www-re (meg a többi aldomainre, ha van olyan).
Na ez például logikus? Mert én eddig abban a (tév)hitben éltem, hogy a csillag helyettesítő karakter. Ennél fogva helyettesíti a . (azaz pont)example.com előtti részt. De mivel a domain http://example.com (pont nélkül), nem pedig http://.example.com, ezért logikusnak tűnt, hogy így adom meg."Nyilván megvolt az oka, hogy így találták ki. De a "logikusnak tűnt" állítások helyett mennyivel ésszerűbb lenne olvasni a dokumentációt, nem?
https://developer.chrome.com/extensions/match_patterns.html
A példád egész pontosan ott van a "Here are some examples of (I)invalid(/I) pattern matches:" részben:
Bad pattern:
http://*foo/bar
Why it's bad
'*' in the host can be followed only by a '.' or '/'A *example.com egyébként ilyen alapon illeszkedne az "example.com" és "fosexample.com" hostokra is (fosexample meg nyilván tök más domain, míg a fos.example.com esetében a "fos" egy aldomain az "example.com" domainhez).
A *.example.com meg illeszkedik a sima example.com-ra, www.example.com-ra, meg a fos.example.com-ra is.[ Szerkesztve ]
Sk8erPeter
-
#20118
Penge_4
veterán
Sk8erPeter
#20117
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.
-
brd
nagyúr
válasz
Penge_4
#20118
üzenetére
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).
Nem ölték meg, simán meghalt, mert érdektelenné vált (pontosabban lecsökkent egy adott érdektelenségi szint alá - túlságosan elterjedt ugye sosem volt sajnos). Nem hozta a többség számára (és ők a fontosak egy profitorientált cég számára) a "just works" feelinget, ezért nem használták. Ezzel szemben pl. az EV1-eket kimondottan megsemmisítették (vásárlók lettek volna dögivel, ha jól tudom), mert túl jól sikerültek, így szerintem nem jó a példa.
The only real valuable thing is intuition.
-
stvnppp
senior tag
Sziasztok!
Nekem olyan gondom lenne, hogy az Opera 12.16 verzióban az outlook.com bejelentkezés után egy sima fehér képernyő fogad, és frissítésre sem reagál semmire sem. IE és Chrome alatt betölt rendesen. Erre van valamilyen megoldás?
Üdv
István -
#20124
Sk8erPeter
nagyúr
Penge_4
#20118
Sk8erPeter
nagyúr
válasz
Penge_4
#20118
üzenetére
"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."
Hát ez meglehetősen fura. Akkor ez valami új Opera-specifikus bug lehet, ha valóban így van, legalábbis ilyet én Chrome-nál még soha nem tapasztaltam kiegészítők kapcsán."Ez nem az a probléma. Csak az unpacked extensionoknál van Reload gomb."
Jaja, de azt hittem, arról beszélünk. De ha nem unpackedről beszélünk, akkor meg ott van a pipa kiszed-pipa visszarak módszer... Ugyanazt éred el vele."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."
Ebben egyetértünk, ebben nem is volt vitánk eddig sem, sőt, ezt már sztem egyszer-kétszer részletesen ki is tárgyaltuk. Ettől még viszont a Chrome Extension API kialakítása, minősége, dokumentációjának minősége nagyon jó. Az másik kérdés, hogy bizonyos funkciók a Chrome-ban miért nem elérhetők inkább alapból IS (!), hogy ne kelljen kiegészítő hozzájuk. Meg miért nem lehet átszabni a Chrome felületét kicsit, miért nem lehet oldalra dokkolni a könyvjelzősávot, és hasonló alapvetően elvárható dolgok, amikről már beszélgettünk. Na de most nem az volt a téma."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)."
Huhh, akkor még mindig elbeszélünk egymás mellett, sztem én sem értem, te mit szeretnél, és te sem érted, én mit mondok...
Tehát négyféleképpen is lehet megadni a paddinget, direkt más és más értékeket használok, hogy elkülöníthető legyen:
https://developer.mozilla.org/en-US/docs/Web/CSS/padding
padding: 5px;
mind a 4 oldalra fog vonatkozni az 5px
padding: 5px 10px;
fölül-alul 5px, bal-jobb oldalt 10px
padding: 5px 10px 20px;
fölül 5px, bal-jobb oldalt 10px, alul 20px
padding: 5px 10px 20px 30px;
fölül 5px, jobb oldalt 10px, alul 20px, bal oldalt 30pxNa, vegyük azt, hogy az utóbbi formában van megadva, hogy padding:5px 5px 5px 5px;, ekkor rámegyek a szerkesztésre, és szépen a fölül lévő paddingre ráállok a kurzorral, és elkezdem nyomogatni a felfelé vagy épp lefelé nyilakat, az alábbi képen például épp a felfelé nyílra nyomogatok, és csakis a fölső paddinget növeli:
Tök jól lehet csak a fölső paddinget növelni ebben a shorthand CSS property formában is, kényelmesen a nyilat nyomogatva. Mi ebben a nehéz, mi ezzel a probléma?
A belinkelt Operás képeden pontosan ugyanezt csinálod, csak úgy tűnik, nem fedezted fel, hogy ezt Chrome-ban is pontosan ugyanúgy meg lehet csinálni...
"Ott meg van olyan, hogy "Expand shorthands""
Ez viszont jogos, erről megfeledkeztem."Pont látszik, mivel így ha userCSS vagy kiegészítő módosított valamit is mutatja."
Na, akkor screenshotoljunk ismét.
Kérlek, mondd már meg, hogy Opera Dragonfly-ban mégis hol mutatja a Computed Styles részben azt, hogy pontosan az adott tulajdonság melyik fájlokból is származik:Chrome:
Dragonfly:
"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."
Asszem ennél most értettem meg, mi a problémád. Beírom a Dragonfly-ba, hogy padding:5px 5px 5px 5px;, erre csinál nekem belőle egy padding:5px;-et. Milyen alapon? Ha meg az "Expand shorthands"-re megyek, akkor mindenhol kibontja. Ha kiszedem ebből a pipát, akkor visszaalakítja a túl rövid változatra. Hadd döntsem már el, hogy én milyen formában szeretném szerkeszteni, helyettem ne rövidítse le padding:5px-re. Nem kell ezzel persze egyetérteni, de pont te mondtad, hogy egy program ne akarjon okosabb lenni nálad, belekontárkodni abba, amit csinálsz, hát akkor ez mi, ha nem pontosan ez a viselkedés?!
Felülbírálja az akaratomat, menjen az anyjába, ne bírálgasson felül.
Szóval megint elég következetlen az érvelésed, mert egyszer azt mondod, hogy te akarsz mindent irányítani, most meg elégedett vagy azzal, hogy a Dragonfly helyetted okoskodik. Ez akkor hogy jön össze?"Webfejlesztésnél biztos, userCSS-nél nem hiszem."
Nem tipikus, de miért ne fordulhatna elő, hogy meghatározol egy általánosabb stílust pl. bekezdésekre, és egy specifikusabb stílust is adott bekezdésekre az előzőeken felül, amit máris elkúr az imént meghatározott !important, vagy pedig ide is ki kell rakni az !important kulcsszót? Ez User CSS-nél pontosan ugyanúgy előfordulhat, mint webfejlesztésnél.">>"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."
Hát nem gondoltam, hogy még ezt is külön el kell magyarázni. Egyrészt: nem biztos, hogy lesz egyáltalán a stílusfájlokban olyan meghatározás, ami az adott divre vonatkozik. Vágod? Így hogyan fogod szerkeszteni? Csakis úgy, ahogy leírtam. Szépen kézzel kell bénán bepötyörészni a style attribútumot, hogy CSAK az adott elemre vonatkozzon.
Másrészt: mi van, ha én CSAK az adott elemre szeretném vonatkoztatni a stílusváltoztatásokat, nem pedig globálisan, minden hasonló divre?Na, de hogy konkretizáljuk az első felvetést:
http://jsfiddle.net/72sKE/No, tessék, itt kérlek a Dragonfly-ban mutasd meg, hogyan fogod csak az adott divre vonatkozó stílust módosítani azok nélkül a módszerek nélkül, amiket írtam (vonatkozó selector írása a New style résznél, vagy pedig a kézzel való style-attribútum hozzáadása). Előre válaszolok: nem fog menni.
De screenshot legyen megint:Chrome:
Opera Dragonfly:
Hopsz, az Opera Dragonfly megint alulmaradt.
"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."
Akkor kérlek itt írd át a <p>-t <div>-re:
Lehet, hogy valamit kihagytam, de hiába duplaklikkeltem a <p>-re, nekem következetesen csak a HTML-szerkesztés jött elő. Habár pont te említetted ezt korábban, mint előny, úgyhogy most nem tudom, miért érvelsz amellett, hogy jobb a Dragonfly, ha neked mégis sikerült duplaklikkre NEM azt a viselkedést előidézni, amit szeretsz....
(ismét ellentmondás, nemde?)">>"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."Ezt mégis honnan veszed? Ez ilyen formában egészen biztos, hogy nem igaz. Erre is vonatkozik a sokszor előkerülő "attól függ"-szabály. Azért ilyen merész kijelentések előtt inkább végezz valami komoly tesztet az adott környezetre vonatkozóan, különben így sokat nem ér a kijelentés.
Egyébként nekem az a véleményem, hogy ilyen feladatra a JSON gyorsabb lehet, de mivel nem vagyok róla teljesen meggyőződve (nyilván van mindkét oldalra szóló felmérés ESETFÜGGŐEN, ahogy ez általában lenni szokott, sűrűn vitáznak az XML vs. JSON-ről), ezért inkább tartózkodom.
Mindenesetre számomra az extension API esetében kényelmesebb a JSON-formátum, örülök is neki, hogy ez a formátum lett a befutó.Sk8erPeter
-
#20126
stvnppp
senior tag
scott_free
#20125
stvnppp
senior tag
válasz
scott_free
#20125
üzenetére
köszi a visszajelzést!
Kiterjesztés egyáltalán semmi sincs telepítve, újraindítás sem segít. cookiek törlése sem. -
#20127
Penge_4
veterán
Sk8erPeter
#20124
Penge_4
veterán
válasz
Sk8erPeter
#20124
üzenetére
"Kérlek, mondd már meg, hogy Opera Dragonfly-ban mégis hol mutatja a Computed Styles részben azt, hogy pontosan az adott tulajdonság melyik fájlokból is származik:"
Mivel alul mutatja, így nem tartottam szükségét, hogy ott a szerkeszthetetlen computed styles-ban is mutassa.
"Szóval megint elég következetlen az érvelésed, mert egyszer azt mondod, hogy te akarsz mindent irányítani, most meg elégedett vagy azzal, hogy a Dragonfly helyetted okoskodik. Ez akkor hogy jön össze?"
Úgy, hogy Dragonfly-ban van expand shorthands toggle, míg Chrome-ban azt kapod, amit a fejlesztők megálmodtak neked, nincs opciód.
"Hopsz, az Opera Dragonfly megint alulmaradt."
Ezt nem értem. Eddig akárhány helyen ganéztam a CSS-t, mindenhol volt element.style a Dragonfly-ban is az ID és Class nélküli tageknél.
"nem tudom, miért érvelsz amellett, hogy jobb a Dragonfly, ha neked mégis sikerült duplaklikkre NEM azt a viselkedést előidézni, amit szeretsz.... (ismét ellentmondás, nemde?)"
Duplaklikkre megnyitja a HTML formátumú szerkesztést. Utána duplaklikk a tag <> közötti betűin és kijelöli az egész taget.
Viszont most jöttem rá egy újabb hiányosságra a DevToolsban. A nyitó tag szerkesztésénél valóban megváltozik a zárótag is, de a zárótaget nem tudod szerkeszteni. Tehát ha elcseszték a zárótaget, akkor nem tudod egyszerűen megváltoztatni. De most próbáltam ki HTML-ként szerkesztve átírtam a h3 lezáró h3-ját h4-re és visszaváltoztatta Enter után h3-ra.
-
#20128
Rypejakten
addikt
Rypejakten
addikt
sziasztok,
több, mint valószínű, hogy user error, de bárhányszor próbálkozom, nem enged fel FB-ra, mert egyből összeomlik a böngésző. eddig sütiket és előzményeket töröltem, a helyzet változatlan.
mi lehet az oka?még nem az új verziót használom, hanem a 12.14-et.
-
#20129
LonGleY
veterán
Rypejakten
#20128
LonGleY
veterán
válasz
Rypejakten
#20128
üzenetére
Akkor mehet is rá az 5-ös vagy 6-os végű. Azon kívül marad a profiltörlés, win újratelepítés.
P4 és S8: ezt a semmiről való filozofálást nem lehetne mostantól privátban?
[ Szerkesztve ]
-
#20130
whiskeys
őstag
Rypejakten
#20128
whiskeys
őstag
válasz
Rypejakten
#20128
üzenetére
nekem csak m.facebook cimmel megy sajna operánál omlás nélkül....
"Jól jegyezd meg,ha egy krokodil a kezedből eszik, az enni fog a lábadból is."
-
#20131
zseko
veterán
Rypejakten
#20128
zseko
veterán
válasz
Rypejakten
#20128
üzenetére
Biztonságos kapcsolat: súlyos hiba (49)
https://www.facebook.com/
A tanúsítvány érvényes, de a hozzáférés megtagadva.
Nálam meg ezt adja. Azóta találtam egy másik oldalt, amit szintén nem tölt be. Van ami olyan szinten fogja a gépet hogy hihetetlen, leginkább a guglis megoldások, G+, map, gmail. Egyre szarabb lesz az Opera sajna
HR24.hu
-
#20132
OiSkinPubi
csendes tag
OiSkinPubi
csendes tag
Hali!
Nekem csak annyi lenne a kérdésem hogy a témát hol tudom lecserélni,
vagyis saját képet szeretnékAbit AX78/AMD Athlon X2 2,7Ghz/2*1Gb Kingmax 1066 Mhz/MSI Radeon HD4870 512mb/Cihftec gps-400aa-101a/Seagate 80Gb SATA2/
-
#20133
LonGleY
veterán
OiSkinPubi
#20132
LonGleY
veterán
-
dqdb
Topikgazda
Jó hírek:
- bookmarks backed is done, UI is being constructed
- Sync backed is being constructed, favorites sync is already working internally
- Customizable start page (start options) is done internally.
- Search engine manager is done internally
Hopefully next week, but please don't be disappointed if that's not going to happen
[link] [link]Rossz hír:
what about Opera Notes? Extremely useful feature.
Sorry, it's currently somewhere at the bottom of our priorities.
[link]Mókás hír:
DNA-8751 - Disappearing text in Google search
Origin of this problem is on the Google web-side, afaik. By that it happens for O15, O16 and O17. We are working together with Google on the fix. Even though we have Blink as browser engine, we've made enough changes around it that the problems exist only for Opera.
[link]tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Penge_4
veterán
"Rossz hír:
what about Opera Notes? Extremely useful feature.
Sorry, it's currently somewhere at the bottom of our priorities."Annyira nem rossz. Legalább ott van a prioritások között, nem pedig elzárkóztak előle teljes mértékben.
"Even though we have Blink as browser engine, we've made enough changes around it that the problems exist only for Opera."
A végén még visszajön az NSL és a position:fixed is.
más: Tök jó ez a natív UserJS/UserCSS megoldás. Még külön processzt (emiatt egy rakás memóriát) sem használ. Kár, hogy egy pár régi Operás userJS nem megy Chrome-mal, például a Snap Links. Pedig a Linkclump is 10 megát zabál külön processzben a semmiért.
Egyébként hogyhogy nem rendeződik külön processzbe? Mert eddig egy Chrome-os kiegészítőnél tapasztaltam ezt, az pedig a Fine Link Selector volt (ki lehet jelölni a linkek szövegét).
[ Szerkesztve ]
-
dqdb
Topikgazda
válasz
Penge_4
#20135
üzenetére
Egyébként hogyhogy nem rendeződik külön processzbe?
Valószínűleg azért, mert nem tartozik a kiegészítőhöz aktív háttérfolyamat (állandóan futó background page vagy átmenetileg futó event page). Csak script injection van, amit natív kód indít el a manifest.json tartalma alapján, és ezt a böngésző az adott fülhöz tartozó folyamaton belül elintézi, hiszen azt úgyis az oldal kontextusában kell lefuttatni.Snap Links: linket tudsz adni?
LinkClump: legtöbb saját ikonnal nem rendelkező, csak az oldalba belepiszkáló kiegészítő átírható, csak ebben az esetben bukod a beállítások oldalt.Ezt olvasd el, így a jövőben könnyebb lesz olyan specifikációkat megértened, ahol formalizálják a szabályokat, mint a content_script blokknál.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Penge_4
veterán
"Snap Links: linket tudsz adni?"
Mindkettő ugyanannak tűnik.
"LinkClump: legtöbb saját ikonnal nem rendelkező, csak az oldalba belepiszkáló kiegészítő átírható, csak ebben az esetben bukod a beállítások oldalt."
Tehát akkor gyakorlatilag egy hülye gomb vagy egy beállítások oldal (amit ritkán vagy általában csak első alkalommal piszkál az ember) miatt rendeződik külön processzbe, ezzel nagyban megnövelve a saját memóriaigényét? Ennek semmi értelme nincs. Mikor egy kiegészítő elcrashel, akkor különben is újra kell tölteni az összes lapot, ahhoz, hogy aktív legyen a kiegészítő.
Mert még ha valami buborékfüggő kiegészítőről van szó, vagy dinamikus gombról (időjárás ikon, árfolyam, stb., aminek különben is kicsi az a gomb, egy speed dial már célirányosabb), de általában a legtöbb esetben nem erről van szó.
Amúgy meg régen a scripteket is jobban megírták, hogy magában a scriptben írt át az ember boolean meg integer értékeket a kikommentelt dokumentáció alapján, de mivel ezeket a kiegészítőket úgy tervezték, hogy a beállítások oldalon lehessen elvégezni a beállításokat, kétlem, hogy ilyen szépen lenne a kód megvalósítva.
"Ezt olvasd el, így a jövőben könnyebb lesz olyan specifikációkat megértened, ahol formalizálják a szabályokat, mint a content_script blokknál."
Itt relációs jelek között van az érték, vessző helyett pipe választja el, a végén, sima egyenlőségjel helyett ::= van, és a sorok vége sincs lezárva vesszővel. Ettől még magát a JSON-t nem fogom jobban érteni, csak ha bemagolom a szintaxist. De azt utáltam mindig, ezért inkább használat során sajátítom el, így könnyebben rögzül hosszútávon. Ha elolvasnám a dokumentációt, mivel nincs fotografikus memóriám, pár nap múlva már tuti félrenéznék valamit (_ helyett - vagy fordítva) és megint nézhetném meg újra a dokumentációt. Azért köszi.
Más: btw, seems that rocker gestures will be included in the initial O17 release
Bár ez a teljesértékű Wand-dal és a Fast Forwarddal lenne az igazi. De már ez is valami.
[ Szerkesztve ]
-
dqdb
Topikgazda
válasz
Penge_4
#20137
üzenetére
Snap Links: nem volt kedvem kibogozni a forrását, és a Linkclump is eléggé intenzíven dobálta a labdát az event és a content script között ahhoz, hogy 10 percen belül eredményt produkáljak, ezért kerestem egy egyszerűbbet, aminél könnyen el lehetett távolítani a háttérszáltól függést.
Tehát akkor gyakorlatilag egy hülye gomb vagy egy beállítások oldal (amit ritkán vagy általában csak első alkalommal piszkál az ember) miatt rendeződik külön processzbe, ezzel nagyban megnövelve a saját memóriaigényét?
Nem mindig, de sokszor igen. Ha a kiegészítő szeretné használni a chrome.* API-k valamelyikét, akkor nem elég a user JS. Ha csak azért használja, hogy beállításokat tároljon, akkor ez a rész relatíve fájdalommentesen leválasztható, ha bevállalod a kézzel bedrótozott értékeket. Ha tárol belső állapotot a kiegészítő, ami oldalfüggő, akkor is kis módosítással megoldható: ekkor az átírt változatban az érték a kiegészítő saját localStorage objektuma vagy a szinkronizált chrome.storage helyett az oldal localStorage-ébe mented el. Ha ez az állapot fülek között megosztott, akkor ez nem járható út. Ha olyan a kód, hogy az oldalakba beágyazott kód egy könnyű réteg, míg az event page tartalmazza a húzósabb részt, akkor sem éri meg valószínűleg átalakítani, mert inkább memóriát érdemes beáldozni, mint minden oldalbetöltést lassítani egy hosszabb kód injektálásával.Szóval a kérdés összetett, de a kiegészítők egy része simán átírható content scriptté.
Az is érdekes kérdés, hogy érdemes-e pár ritkábban frissülő kiegészítőt összedrótozni egy nagyobbá, megspórol-e ezzel az ember annyi erőforrást, hogy megérje a ráfordított időt? Nem, annyira nem vagyok kíváncsi a válaszra, hogy elszórakozzak vele
Ettől még magát a JSON-t nem fogom jobban érteni, csak ha bemagolom a szintaxist ... Ha elolvasnám a dokumentációt, mivel nincs fotografikus memóriám, pár nap múlva már tuti félrenéznék valamit (_ helyett - vagy fordítva) és megint nézhetném meg újra a dokumentációt.
Erre való a dokumentáció. Szerinted ennek a függvénynek fejből vágom az összes paraméterét annak ellenére, hogy 15 éve közel napi rendszerességgel leírom? Természetesen nem, a sűrűn használt konstansok neve fejből megy, ezzel szemben például a FILE_FLAG_WRITE_THROUGH értékről csak annyit tudok, hogy létezik ilyen lehetőség, ha kell, akkor megkeresem, pontosan hogyan hívják (pár évente van rá szükség amúgy). A fejlesztés nem arról szól, hogy mindent tudsz fejből, hanem arról, hogy amit napi rutinnal használsz, azt tudod fejből, amit ritkábban, annak tudod, hogyan tudod gyorsan elérni/hol van a leírása, amit szinte soha, azt meg tudod fogalmazni angolul, és gyorsan meg is tudod találni a Google-Bing párossal. 30-40 MSDN fül, 4-5 Stack Overflow fül, 2-3 CodeProject fül, pár fejlesztői blog, további 15-20 fülön későbbi olvasásra félrerakott érdekesség, így néz ki nálam tipikusan a munkahelyi Opera profil.hunfatal: a letöltésekről még sajnos semmi infó.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
zseko
veterán
A fejlesztés nem arról szól, hogy mindent tudsz fejből, hanem arról, hogy amit napi rutinnal használsz, azt tudod fejből, amit ritkábban, annak tudod, hogyan tudod gyorsan elérni/hol van a leírása
Kár hogy az oktatásban nem ezt gondolják. Bocs a bele vau-vauzásért
ez csak kikívánkozott, ezért rüheltem meg az oktatást HR24.hu
-
Orlin
addikt
Opera Next 16 - for weekend testers
Highlights
Disappearing text in Google search is no more!
Number of fixes for tab bar
... and moreDNA-4468 CJK strings size is larger than others at address field
DNA-7056 [Mac] Crash when pasting url to address field while tab with certificate dialog is open
DNA-7739 Esc on HTTP auth does not display 401 response body and hangs tab
DNA-8163 Crash when closing browser with notification dialog on
DNA-8294 Impossible to change site address when Find on Page is opened
DNA-8696 Crash in closing Opera with notification dialog on (other one)
DNA-8699 OS X 10.6 should not have Enter Full Screen in Main Menu
DNA-8707 Internal pages duplicates on Mac
DNA-9022 Inline find hides when you switch tabs
DNA-9144 [Mac] Crash when opening link from other application while all tabs are closed
DNA-9147 [Mac] Cannot open file while all tabs are closed
DNA-9197 "Close Tab" and "Close all but active" should be greyed out when window is not opened
DNA-9198 "Close other tabs" should be inactive with only 1 tab
DNA-9252 'Find", "Find Next" and "Find Previous" should be greyed out when no window is opened
DNA-9255 Find Next via Enter doesn't work after switching tabs
DNA-9269 Fix shared memory comunication for browser.js in op_site_patcher
DNA-9286 Crash pressing the geolocation reset button[ Szerkesztve ]
LENOVO IDEAPAD 5 Pro 16 - Ryzen 5 6600HS, 16, 1000 GB, 16GB, Radeon 660M Graphics, Win11
-
dqdb
Topikgazda
-
-
dqdb
Topikgazda
válasz
Wolverine
#20148
üzenetére
De az Operáé, a Desktop Team Blog kommentjei alapján a legutolsó (lehet, azóta már javították) browser.js frissítés a probléma forrása.
Az elmúlt pár nap termése a várható (és a nem igazán várható) fejlesztésekről:
"Will we be able to stack tabs as before? This is the most unique and useful tab management that opera had."
"Not for now at least. But we plan to deliver you different type of tabs enchanement."
[link]"Why can't we had custom images to the Speed Dial background?"
"Yes you can.. In O17 "
[link]"Why can we not pin and group tabs?"
"Pined tabs are already implemented. Please wait for first O17 dev stream."
[link]"Why are there no bookmarks?"
"Hopefully you should see basic browsers functionality in O17 and further enchancements for bookmarks in following versions."
[link][ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
), hogy szépen lásd kibontva is ennek az ömlesztett változatnak a megfelelőjét (mi a top, right, bottom, left padding):
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Kérdés előtt olvasd el az
összefoglalót!
- Háztartási gépek
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Autós topik
- Xbox tulajok OFF topicja
- Házimozi belépő szinten
- Asztalos klub
- Samsung Galaxy A54 - türelemjáték
- Garancia kérdés, fogyasztóvédelem
- Luck Dragon: Asszociációs játék. :)
- Ukrajnai háború
- További aktív témák...
